载入中。。。

以下为blog主人的回复：

把vivi的Linux启动参数中设置console=ttySAC0

以下为blog主人的回复：

就是你说的过程，中断响应一定要经过0地址然后跳转的。

以下为blog主人的回复：

文章中说了，用2410的基本就可以。寄存器都是兼容的。

以下为blog主人的回复：

可以启动，串口可以输出，就一点点的跟踪内核吧。44b0没有MMU，随时可以串口输出。不用考虑映射的问题。

至少，内核的自解压没问题吧？如果这里都不行，那....就看看你的串口输出函数了。

以下为blog主人的回复：

你可以吧q->make_request_fn调用的地址打印出来，然后在System.map（编译内核时候生成的地址信息）文件中查找对应的函数。应该有结果。

以下为blog主人的回复：

2.6内核下，如何用ramdisk，我也没有试过。如果你觉得是因为根文件系统搞不定，可以尝试网络文件系统做根，或者，用jffs2。这两种我都比较熟悉，也不算难。当然，ram没有道理不好用的，那应该是最简单的方法吧，呵呵

以下为blog主人的回复：

因为没有MMU，中断处理程序的位置需要和bootloader配合。看看这里是不是已经对应上了？

以下为blog主人的回复：

不清楚你具体的情况和版本，我猜测，你的s3c24xx_serial_startup应该是被定义成struct uart_ops 里面的startup成员，在应用程序，打开串口的时候（我估计应该是open，但是，没有跟踪过，不敢确认），调用startup的。

以下为blog主人的回复：

google一下，有不少例子的，使用

void cdev_init(struct cdev *cdev, struct file_operations *fops);

添加。具体看看内河中的代码，会有所启示，比如：

drivers/char/tty_io.c中有：

 cdev_init(&tty_cdev, &tty_fops);
 if (cdev_add(&tty_cdev, MKDEV(TTYAUX_MAJOR, 0), 1) ||
     register_chrdev_region(MKDEV(TTYAUX_MAJOR, 0), 1, "/dev/tty") < 0)
....

大概就这个意思吧。我现在还是用2.6.9内核，我发现，register_chrdev_region用得并不是很多。再新得内核，我也没有仔细研究过。

以下为blog主人的回复：

make modules的时候定义的MODULE宏

以下为blog主人的回复：

__trap_init函数copy的时候，0x200处的东西，就是__stubs_start的位置的代码也copy到了0xc0002xx这个地方。ARM中的b指令是一个相对跳转指令。比如：

b __real_stubs_start

编译的时候，根据当前代码定位的地址（.LCvectors起始的偏移），和跳转的地址__real_stubs_start（也就是.LCvectors+200）计算跳转的相对位置。得到的结果就是，要跳转到这条指令之后，0x200的地方。这就是我们copy的__stubs_start的东西。

以下为blog主人的回复：

不是很清楚你的疑问。我觉得你说得和实际代码不冲突啊？

这里就是说异常向量放在什么地方。因为没有MMU支持，所以这个地址就要和bootloader配合了。

以下为blog主人的回复：

不好意思，刚才着急开会，最后这句写错了，应该是

“只向内存”

以下为blog主人的回复：

恩，看代码是这个样子。主要问题不是初始化串口的事情。因为在Linux启动阶段，需要创建页表，映射虚拟地址空间，然后才能访问到相应的寄存器。这个过程，对外设地址空间的访问就比较困难。所以，printk在console初始化之前，只向内存中打印。

以下为blog主人的回复：

这些问题就是标准的Linux内核的问题，google去吧。很多答案的。其实我了解的也不是很细，但是需要的时候，很容易找到答案吧。

以下为blog主人的回复：

主要是看这里

$(obj)/vmlinux.lds

对于ARM来说就是arch/arm/kernel/vmlinux.lds文件，这是一个连接脚本，什么段放在什么位置都是这个决定的。它在make的时候是由arch/arm/kernel/vmlinux.lds.S生成的，所以，如果要修改，就改.S的。

以下为blog主人的回复：

 我看你的代码中有

 printk("LCD buffer : %p\n", fbuf);
这一行打印出来了吗?

看

fb0：Vritual frame buffer device,using 1024K of video memory

你似乎使用了

Vritual frame buffer，这是一个在内存中的虚拟framebuffer。不是对应了你的硬件。

以下为blog主人的回复：

 你确认驱动程序在启动的时候被加载了？你代码最后

#ifdef MODULE
module_init(s3c44b0xfb_init);
module_exit(s3c44b0xfb_exit);
#endif

有问题吧？那个#ifdef错了。这样，只有模块加载的时候，s3c44b0xfb_init函数才会被调用的。

以下为blog主人的回复：

 看bootloader内核等的输出信息，看看哪里时间耽误比较长。从上电到起应用程序，10秒钟不算特别长。你用的是S3C44B0吧？这东西本来也不是很快。

我估计，时间主要用在：

1、bootloader把内核从Flash copy到SDRAM——你不是用ramfs做root吧？不需要copy根文件系统吧？

2、内核解压缩——和内核大小有关系

3、如果用jffs2做root，就是mount jffs2做根文件系统比较花时间，如果Flash很大，这里会比较慢。

大概主要也就是这么多了。当然，不排除一些比较容易忽视的“弱”问题，比如：你bootloader或者启动脚本中，故意有几秒钟的延时。

以下为blog主人的回复：

您说的初始化时间，是指哪里初始化时间？

以下为blog主人的回复：

 如果LCD是基于Linux framebuffer的，那就有字模就可以显示。相当于图形界面，把汉字画上去。如果是要在文本模式下显示汉字，估计需要修改内核代码了。

以下为blog主人的回复：

 噢，还有防火墙是不是关掉了？

以下为blog主人的回复：

 我还是第一次看见这个错误。你可以ping大数据包看看是不是可以？