Re: [U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)
Hello
Magnus Lilja lilja.magnus@gmail.com 23.07.09 11.18 Uhr >>>
Hi
2009/7/22 Ulrich Gerster gersteru@dhbw-loerrach.de: Hello
Magnus Lilja lilja.magnus@gmail.com 14.07.09 19.43 Uhr >>>
Hi
2009/7/14 Ulrich Gerster gersteru@dhbw-loerrach.de:
Hello.
> Magnus Lilja lilja.magnus@gmail.com 14.07.09 16.03 Uhr >>>
I used the patch from you out of this posting: [U-Boot-Users] [PATCH RFC 3/5] i.MX31: Add i.MX31 NAND Flash Controller driver. http://lists.denx.de/pipermail/u-boot/2008-August/038239.html
They should work, or not? Do they require something else?
I haven't tried that driver on a recent U-boot so I don't know if (or how) it will work when applied to a recent U-Boot.
I'm using the u-boot master release of middle of June. How can I ensure that your patch is working? Or how do I know what is missing that it works?
You need to use either a debugger or add printf's to see what's going on (to the mxc_nd.c or whatever the file is called.
I have the drivers working now. But there's a little problem left. When I try to use u-boot to update itself (write itself from RAM to Flash) it seems that it overwrites the out of band information too.
That's normal since writing new data means writing a new error correcting code.
Well, you're right.
So when I try to reboot nothing is working because every program assumes that the first blocks are bad. Do you have a suggestion how to fix that issue?
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.
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?
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?
Thanks! Ulrich Gerster
Hi
2009/7/23 Ulrich Gerster gersteru@dhbw-loerrach.de:
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
Hi,
maybe this is too off-topic, but maybe it helps:
I am currently proting U-Boot to a MPC512x design (with NAND boot). AFAIK the NFC is similar on MPX512x and iMX.31,
The MPC512x nand flash driver, that is now available in U-Boot seems to maintain the ECC by software. I could use it to read/write the NAND.
But: The ECC stored is incompatible to the ECC that is optionally calculated by the NFC HW. When after a reset, the NFC HW extracts the first sector from NAND, it detects an unrecoverable ECC error and avoid to let it execute.
For my MPC512x, I currently went back to my private, hacked driver (which uses HW ECC). I willt ry to adapt the mpc512x_nfc driver to support HW ECC, at least as an option. The problem is, that if the way to store ECC is changed on only part of the SW environment (e.g. only in U-Boot, but not in Linux), some strange effects may come up :-)
So: Maybe you have the same problem on iMX.31?
wkr, Thomas.
Magnus Lilja wrote:
Hi
2009/7/23 Ulrich Gerster gersteru@dhbw-loerrach.de:
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 U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
participants (3)
-
Magnus Lilja -
Thomas Dörfler -
Ulrich Gerster