Im trying to get some information on how to flash u-boot, Linux kernel and rootFS onto nand chip for the Freescale Vybrid Tower module.
I found a document on the timesys website with instructions on how to flash the u-boot to NAND. However im looking for more information on how to boot the whole system from NAND.
Any help would be really appriciated.
Solved! Go to Solution.
I will be updating the instructions on the Timesys website to include information about booting a kernel and RFS image from NAND. This should be finished by tomorrow - I will let you know when the document has been updated.
This does work. However, you should ensure you have the right u-boot (explained in the Wiki). One way to tell is to type help nb_update. The correct version will give three parameters. I did a flash_erase on the boot partition from Linux and this also seems to work (as opposed to the u-boot nand erase.chip). This let me erase the partition, but preserve the rest of the NAND device. However, I have two issue with this mode.
After this was working, I have removed the mmc card. Then the version of u-boot for the Linux-link seems to not allow the saveenv command. You can load an environment over the network with a u-boot script, but it would be considerably easier if the u-boot supported saving an environment to the NAND as opposed to the mmc. People may wish to develop SDHC drivers from something other than mmc.
Compiling the NAND u-boot?
Also, I have difficulty getting the code to compile so that I can boot from NAND. I have compiled an image that boots from mmc, with the updated nb_update, but for some reason it doesn't seem to boot and goes to serial download mode when I flash my own image? Being able to compile my own image, would allow fixing the saveenv area for instance.
$ git remote -v origin https://github.com/Timesys/u-boot-timesys.git (fetch) origin https://github.com/Timesys/u-boot-timesys.git (push) $ git branch 2011.12-mvf * 2011.12-pcm052
EDIT: Compiling the NAND u-boot is a tool issue. Rebuilding source with the TimeSys armv7l gcc/binutils does boot from NAND. Strange my 4.8.1 gcc+binutils does not boot from NAND, but does boot from mmc. The 2011.12-pcm052 is the correct branch to use for a NAND boot build. An update to gcc 4.8.2 also allows a boot.
Anyways, thanks again (to you, Dan Douglass and Russell Robinson) for the initial difficult hurdle of getting this to work at all.
Also, this thread may be useful for others to understand the details of drivers/mtd/nand/fsl_nfc.c.
UPDATE: The PHYTEC Wiki has a better sequence for updating the NAND u-boot from the eMMC u-boot. The key is to pad the u-boot memory with all FFs before using nb_update. I use a Linux flash_eraseall to ensure my partitions are erased. Without the mw.b 0x80400000 0xff 0x40000, to pad the image with FFs whenever I changed the u-boot configuration the image size changed and the NAND image fails to boot. I also recommend a direct serial connection on the TWR-SER board as the USB serial is very buggy when switching between NAND and eMMC.
I'm struggling trying to boot u-boot from NAND. Im working in TWR
I'm able to write in the NAND with the nb_update but not able to boot from NAND yet
Does this branch also applies for TWR board?
How do you build it?
Any additional steps before padding the binary?
Would you share your nand u-boot binary
Never mind. I was able to boot :smileyhappy:.
Moving the proper branch and building in the next way
git checkout -b nand remotes/origin/2011.120-pcm052
dd if=/dev/zero of=u-boot-pad bs=1024 count=1
cat u-boot-pad u-boot.imx > u-boot.nand
key, was the branch
Do you know how to change the u-boot so that it understands that the actual physical NAND flash device is connected as a x8 device, not a x16 device? We can NAND boot the Phytec SoM using its on board flash NAND (x16) but we have not been able to boot another design yet which contains a x8 NAND device. I know the TWR also contains a x16 NAND device. We have the correct RCON2 setting = "0" at reset (NAND bit width set to 8-bit NAND). We are just starting to dig in, but thought others out there may have solved this x* NAND boot already.
Sorry, I have not booted with a x8 device. However, I found it useful to use nanddump -o -n -p to see what is actually written to flash. The u-boot nb_update appears to be writing OOB data to the sector containing the FCB. I still don't understand the stride comment in the document. I guess that 0x40000 is the 2nd stride. However, this FCB is the first thing read by the ROM bootloader and it uses it to configure the NAND controller. If you can connect a logic analyzer or multi-channel scope to the x8 NAND device you will probably be able to get it working; you will see the address and data the the bootloader is getting. The ROM boot loader puts the NAND controller into boot mode and reads raw sectors without the OOB correction. This is why the duplicate hamming ECC is needed.
It looks like a lot of people have looked at the documentation and it isn't quite clear. You need to figure out where the ROM boot loader will read from and put the FCB there with the hamming ECC. I would suggest looking at the addresses using a blank flash. Then, if you get the FCB considered valid, the ROM code should try to read other sectors. You may then be able to fix the FCB or it may work the first time.
Thanks Bill. We got it working with our x8 NAND! Thanks for pointing us in the FCB direction...
We had to do a few things to get the x8 NAND boot working:
1) RCON2 = 0 at power up (boot from 8-bit NAND)
2) modify the fsl_nfc.c driver (NFC_FLASH_CONFIG register, bit-7 = 0) for 8-bit NAND operation (modify both drivers - u-boot and the kernel)
3) use the nb_update command to write u-boot into NAND in order for it to write the FCB blocks: nb_update <image addr> <size> <dest flash addr>
And the last stumbling block that we ran across (obvious now in hindsight) is that the FCB block has to be erased before the nb_update is called...
nand erase 0 0x800
nand erase 0x40000 0x40000
mw.b 0x80400000 0xff 0x40000
fatload mmc 0:2 0x80400000 u-boot.nand
nb_update 0x80400000 0x40000 0x40000
After that, we successfully booted u-boot and a kernel from the NAND - no SD card inserted. We are checking on the other FBC locations now and we have to work on loading the rootfs too...
You can always use an FTM as a timer, even if the pins are not used. That said, the NAND will ignore the NF_IOxx lines as long as the CE line is not asserted. You could even possibly dynamically use the two channel FTM2 even with an 8bit NAND flash (your peripherals also need activation lines). As the FTM module has a common time base, it may have been better to have put one channel of FTM2 on the higher bits. I guess the Vybrid designers thought an 8channel motor control was more important. If you are capturing, I think you want the channels on the same time base. What sort of application do you have where this is a limitation? It must be multiple outputs with different time bases? Ie , audio beep, a back-light PWM, motor control, 1-wire emulation, laser scanner, etc. Even if the time bases are different, you can use multiple channels as outputs as long as the end devices are not used at the same time.