烧写mini2440的过程小结

过程也挺费周折的,这里记录一下。

我的开发板是mini2440的128M nandflash,2M norflash

原来的linux系统是2.6.29,烧录后为2.6.32

用的镜像是www.arm9.net上放着的文件linux-images-20100113.zip

第一步,其实是要更形supervivi这个需要的,原以为在就的supervivi的选项里选择v然后就从dnw程序通过usb下载进去,好像不行,后来通过H-JTAG才烧写成功,这需要一个10元左右的10pin通过并口的jtag烧写模块,好在我之前就有了,这会就帮上忙了,当然用jlink也可以,但我的jlink没有转接板,是20pin的,在mini2440上不管用,具体细节,感兴趣,本人可以详述。

第二步,要在supervivi的界面,通过q进入vivi的shell,然后通过下列命令修改分区的大小:

press q to goto shell of vivi
> part del kernel
> part del root
> part add kernel 0x00060000 0x00500000 0
> part add root 0x00560000 0x40000000 0
> part save

因为要烧进去的kernel会大于默认的2M,调大一些。

第三步,烧写kernel,我选的是zImage_N35

第四步,烧写rootfs,我选的是root_qtopia-128M.img

烧完后,选择b,就可以用了

由于一开始我搞错了一件事,以为我的开发板的配置是64M的nandflash,就只烧写了64M的rootfs镜像,结果在烧完启动时就出现下面的现象:

yaffs_read_super: isCheckpointed 0
VFS: Mounted root (yaffs filesystem) on device 31:3.
Freeing init memory: 160K
Warning: unable to open an initial console.
Failed to execute /linuxrc.  Attempting defaults...
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
Backtrace:
[<c0035270>] (dump_backtrace+0x0/0x10c) from [<c03958f0>] (dump_stack+0x18/0x1c)


 r7:00000000 r6:c0503ed0 r5:c0503660 r4:c04c61a0
[<c03958d8>] (dump_stack+0x0/0x1c) from [<c0395940>] (panic+0x4c/0x134)
[<c03958f4>] (panic+0x0/0x134) from [<c00305a4>] (init_post+0xec/0x178)
 r3:00000000 r2:c3954200 r1:c0539000 r0:c045348c
[<c00304b8>] (init_post+0x0/0x178) from [<c00084c4>] (kernel_init+0xf4/0x124)
 r5:c00205d4 r4:c00205d4
[<c00083d0>] (kernel_init+0x0/0x124) from [<c004d1a4>] (do_exit+0x0/0x62c)
 r7:00000000 r6:00000000 r5:00000000 r4:00000000

之后就卡死不往下走了,后来我从头一行log一直看下来,发现是打印了一些加载外设等等信息,看起来前面的log都正常的啊,突然看到一个128M nandflash的信息,这是系统自检出来的,不应该有错,才去确查了一下,发现开发板上的nandflash型号为K9F1G08的,这是128M的nandflash,而我之前以为是K9F1208的即64M的,结果老是不行,小错误导致浪费了很多时间。这跟rootfs的制作有关,不能混用,bootloader也是不能用错了。另外我还怀疑有坏块导致的问题,后来发现nandflash有一些坏块也正常,不影响系统的运行。

其实还有第零步,就是安装好usb host的驱动,即这个“SEC S3C2410X Test BD driver”,网上找的这个SuperVivi-Transfer-Tool-Complete.zip

里面有一个下载和上传的工具,所以也就没有用到dnw了。

你可能感兴趣的:(烧写mini2440的过程小结)