Use uboot to burn the file system with QT to NAND Flash (k9f1208)

A file system with QT was prepared a few days ago, and it was successfully mounted through NFS, but the interface flash badly. After analysis, it is concluded that the NIC conflicts with the VGA because the NIC is normally displayed when the network is closed, but the file system mounted through NFS cannot work without the NIC. After the NIC is disabled, it is displayed as normal, but the mouse and keyboard are no longer available. Therefore, you need to burn the file system to flash and run it to find out the cause. The procedure is as follows:

1. Use the mkyaffsimage tool to make a file system with QT into an image in the yaffs format.

# Cd/home/ayj/work/nfsroot

# Mkyaffsimage fs_qtopia fs_qtopia.yaffs

Production completed.

2. Start the development board to the uboot Console (uboot has been transplanted successfully and supports NFS), download the file system to the memory through NFS, and then run the NAND write command to burn it into flash.

# NFS 0x31000000 192.168.1.100:/home/ayj/work/nfsroot/fs_qtopia.yaffs (download the file system to the memory through NFS)

# NAND erase 0x00b00000 0x4000000 (erased)

# NAND write. yaffs 0x31000000 0x00b00000 0x3800000 (burning)

Modify the command line parameter to use the mtd3 partition as the file system (0x00b00000 is the starting address of mtd3). Make the following settings on the uboot console:

# Set bootargs noinitrd confole = ttysac0 root =/dev/mtdblock3 rootfstype = yaffs

# Saveenv

Restart the Development Board. After the kernel is started, the file system will be mounted to mtd3.

 

After startup, the file system is mounted successfully and the following information is displayed:

......

IP-config: complete:
Device = eth0, ADDR = 192.168.1.70, mask = 255.255.0, GW = 192.168.1.110,
Host = yc2440, domain =, Nis-domain = arm9.net,
Bootserver = 192.168.1.101, rootserver = 192.168.1.100, rootpath =
Yaffs: Dev is 32505859 name is "mtdblock3"
Yaffs: passed flags ""
Yaffs: Attempting MTD mounted on 31.3, "mtdblock3"
Eth0: link up, 100 Mbps, full-duplex, LPA 0x45e1
VFS: mounted root (yaffs filesystem ).
Freeing init memory: 136 K
Init started: busybox v1.7.0 (19:57:11 Cst)
Starting PID 755, tty '': '/etc/init. d/Rs'
Done
Starting PID 767, tty '': '/usr/sbin/telnetd'

......

 

The display also displays the QT interface, but it still flashes, so the network is closed and the display is normal. The mouse and keyboard can also be used. It seems that there is a conflict between the nic and vga, leading to the previous problem. (No solution has been found .)

Run the following command on the console to disable the network:

# Ifconfig eth0 down

 

Additional: problems encountered when downloading fs_qtopia.yaffs to the memory using NFS.

At the beginning, the command NFS 0x31000000 192.168.1.100:/home/ayj/work/nfsroot/fs_qtopia.yaffs fails to be downloaded. The download stops when the following information is displayed.

U-boot 2008.10 (Oct 6 2009-11:43:29)

I2C: Ready
DRAM: 64 MB
Flash: 1 MB
Nand: NAND device: Manufacturer ID: 0xec, chip ID: 0x76 (Samsung NAND 64mib, 3 V 8-bit)
64 MIB
In: Serial
Out: Serial
Err: Serial
Hit any key to stop autoboot: 0
Mini2440 # NFS 0x31000000 192.168.1.100:/home/ayj/work/nfsroot/fs_qtopia.yaffs
Dm9000 I/O: 0x19000300, ID: 0x90000a46
Dm9000: Running in 16 Bit mode
Mac: 08: 00: 3E: 26: 0a: 5b
File Transfer via NFS from server 192.168.1.100; our IP address is 192.168.1.70
Filename '/home/ayj/work/nfsroot/fs_qtopia.yaffs '.
Load address: 0x31000000
Loading :*
Done

 

It is depressing that it has been a waste of more than an hour. I found many places, but I couldn't find the reason. All other files can be downloaded through NFS, but the above information is prompted when I download fs_qtopia.yaffs, it cannot be downloaded. After a long time, I stopped and started to analyze the problem. I began to suspect that NFS does not support large-text transmission, because the fs_qtopia.yaffs is close to 31 m. Try downloading other large files to download. Exclude this conjecture. Later, I suspected the permission problem because I used the current user to compile it during compilation. In fedora8, the console minicom is started through Su, so the permission to view fs_qtopia.yaffs is a permission problem because it only supports the current user ayj reading and the permission is successfully downloaded!

(This is a very simple problem, but sometimes it is these simple problems that waste our precious time... so we can make some records for reference !)

 

 

 

Note:
You can enter help in the console to view the uboot console command usage.