Hi 2009/7/23 Ulrich Gerster <[email protected]>: >> Not sure that I understand what "every program assumes..." means. > > I try to explain my problem in more detail. I had a working u-boot programed > in NAND-Flash. Then I wanted to update it. I used the nand write command and > wrote a the new image in the NAND-Flash. When I then restarted the Board > U-Boot > wasn't responding. Then I loaded RedBoot to RAM using a BDI. But when I was > trying > to access NAND-Flash with RedBoot (factive nand) RedBoot was freezing. The > only > chance I had was to clear the the NAND and the OOB. After I did that I was > able to > access the NAND-Flash with RedBoot. After that I programed the same u-boot > image > in the NAND-Flash using the RedBoot fis write command. > The result was a working u-boot.
Seems like nand_spl and redboot are compatible with each other but not the U-boot mxc_nand-driver. Have you compared the data in the flash before and after using U-boot to update it? >> But my guess is that the OOB layout may be different in >> nand_spl/nand_boot_fsl_nfc.c compared to drivers/mtd/nand/mxc_nd.c so >> the nand_spl may interpret the OOB information that mxc_nd.c has >> written in a different way. > > Ok. So I should compare this. Which function does take care for that? Don't remember, look for "bad block" or OOB-layout. > >> This is especially true for large page NAND since the i.MX31 controller uses >> a non-standard layout, for small page NAND there should be no problem >> (although I don't know if nand_spl has been tested on small page nand yet). > > So now it is tested. I'm using small page nand with (512 + 16 spare) Bytes. > Do you think it is a problem of the nand_spl or the nand driver? Hmm, my first guess would be a problem with nand_spl. /Magnus _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
