[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Ulrich Gerster]

Hello,

I have a board with a i.MX31, NAND-Flash and RAM.
On the Board a RedBoot is preinstalled and runs properly.
I want to replace the RedBoot with my U-Boot port.

How can I test U-Boot out of RedBoot when I load the u-boot image in the RAM?
What do I have to configure in my u-boot if i want to test it from ram before burning it into the nand flash?

Thanks a lot for your help.
Ulrich Gerster

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Magnus Lilja]

Hi

2009/7/8 Ulrich Gerster <gersteru@dhbw-loerrach.de>:
> Hello,
>
> I have a board with a i.MX31, NAND-Flash and RAM.
> On the Board a RedBoot is preinstalled and runs properly.
> I want to replace the RedBoot with my U-Boot port.
>
> How can I test U-Boot out of RedBoot when I load the u-boot image in the RAM?
> What do I have to configure in my u-boot if i want to test it from ram before burning it into the nand flash?

You should define CONFIG_SKIP_LOWLEVEL_INIT since redboot has already
setup the SDRAM. If you load U-boot to the address it's set up to
execute from you should also define CONFIG_SKIP_RELOCATE_UBOOT.

It's been a long while since I used redboot to start u-boot (on the
i.MX31 PDK) so I don't remember the correct redboot command but make
sure the MMU is off when jumping to U-Boot.

Regards, Magnus

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Ulrich Gerster]

Hello

>>>> Magnus Lilja <lilja.magnus@gmail.com> 08.07.09 17.42 Uhr >>>
> Hi
> 
> You should define CONFIG_SKIP_LOWLEVEL_INIT since redboot has already
> setup the SDRAM. If you load U-boot to the address it's set up to
> execute from you should also define CONFIG_SKIP_RELOCATE_UBOOT.

> It's been a long while since I used redboot to start u-boot (on the
> i.MX31 PDK) so I don't remember the correct redboot command but make
> sure the MMU is off when jumping to U-Boot.

> Regards, Magnus

I made the defines you mentioned above and build the image with make mx31guf_config (it's quite similar to the PDK board). Then I loaded the resulting u-boot.bin to 0x81000000 and tried to "run 0x81000000". The "run" command is with caches and MMU tured off.
I get absolutely no output on the console and I have to reset the board.
What could be the problem? How can I debug this?

Thanks a lot for your help.
Best Regards
Ulrich Gerster

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Magnus Lilja]

Hi

Could you please do reply-all and keep all addresses when replying to
a mail? I don't read all mail from the list so it's easy to miss a
followup.

2009/7/9 Ulrich Gerster <gersteru@dhbw-loerrach.de>:
> Hello
>
>>>>> Magnus Lilja <lilja.magnus@gmail.com> 08.07.09 17.42 Uhr >>>
>> Hi
>>
>> You should define CONFIG_SKIP_LOWLEVEL_INIT since redboot has already
>> setup the SDRAM. If you load U-boot to the address it's set up to
>> execute from you should also define CONFIG_SKIP_RELOCATE_UBOOT.
>
>> It's been a long while since I used redboot to start u-boot (on the
>> i.MX31 PDK) so I don't remember the correct redboot command but make
>> sure the MMU is off when jumping to U-Boot.
>
>> Regards, Magnus
>
> I made the defines you mentioned above and build the image with make mx31guf_config (it's quite similar to the PDK board). Then I loaded the resulting u-boot.bin to 0x81000000 and tried to "run 0x81000000". The "run" command is with caches and MMU tured off.
> I get absolutely no output on the console and I have to reset the board.
> What could be the problem? How can I debug this?

Did you define CONFIG_SKIP_RELOCATE_UBOOT? If so, that may be the
problem (although I'm not 100% sure) if TEXT_BASE is not 0x81000000
(in your board config.mk). For most i.MX31 boards TEXT_BASE is
0x87f00000.

/Magnus

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Magnus Lilja]

Hi

2009/7/14 Ulrich Gerster <gersteru@dhbw-loerrach.de>:
> Hello.
>
>>>> Magnus Lilja <lilja.magnus@gmail.com> 09.07.09 19.08 Uhr >>>
>
>>> I made the defines you mentioned above and build the image with make mx31guf_config (it's quite similar to the PDK
>>> board). Then I loaded the resulting u-boot.bin to 0x81000000 and tried to "run 0x81000000". The "run" command is with
>>> caches and MMU tured off.
>>> I get absolutely no output on the console and I have to reset the board.
>>> What could be the problem? How can I debug this?
>
>> Did you define CONFIG_SKIP_RELOCATE_UBOOT? If so, that may be the
>> problem (although I'm not 100% sure) if TEXT_BASE is not 0x81000000
>> (in your board config.mk). For most i.MX31 boards TEXT_BASE is
>> 0x87f00000.
>
> That was the point.
> Now I'm able to boot u-boot out of the RAM. It's working well but I have some issues.
>
> I can ping my linux host and I'm able to download a binary file via TFTP into RAM.
> But I'm not able to ping the boad with u-boot from my linux host. In my config-file I
> defined CONFIG_NETMASK and CONFIG_IPADDR. What could be wrong?

Nothing is wrong here. As far as I know, the networking in U-boot is
not running in background, i.e it's only on/enabled when u-boot itself
issues a ping-command, tftp or something similar.

>
> Another strange thing is the nand driver. I build my u-boot with:
> #define CONFIG_MX31_NAND ? 1
> #define CONFIG_CMD_NAND
> #define CONFIG_SYS_NO_FLASH ? 1
> #define CONFIG_ENV_IS_IN_NAND ? 1
> #define CONFIG_SYS_NAND_BASE ? CS0_BASE
> #define CONFIG_SYS_MAX_NAND_DEVICE ? ? ?1
> #define CONFIG_SYS_NAND_MAX_CHIPS ? ? ? 1
>
> If I then try to get "flinfo" information u-boot jumps to the next command line and prints nothing.
> If I try "nand info" I get information about nand device 0.
> Another strange thing is that I can't read from nand flash but I can write.
>
> Do you have any suggestions?

The only i.MX31 NAND driver I've used in U-boot is the one I submitted
to the list last year but it was rejected. Other people have sent
updated drivers (I think there was a i.MX27 driver posted not long
ago), but I haven't tried these.
Even so, the CONFIG_SYS_NAND_BASE looks incorrect but I don't know if
that's the only problem.

Regards, Magnus Lilja

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Ulrich Gerster]

Hello again,

>>> Magnus Lilja <lilja.magnus@gmail.com> 14.07.09 13.08 Uhr >>>
> Hi

>> Another strange thing is the nand driver. I build my u-boot with:
>> #define CONFIG_MX31_NAND   1
>> #define CONFIG_CMD_NAND
>> #define CONFIG_SYS_NO_FLASH   1
>> #define CONFIG_ENV_IS_IN_NAND   1
>> #define CONFIG_SYS_NAND_BASE   CS0_BASE
>> #define CONFIG_SYS_MAX_NAND_DEVICE      1
>> #define CONFIG_SYS_NAND_MAX_CHIPS       1
>>
>> If I then try to get "flinfo" information u-boot jumps to the next command line and prints nothing.
>> If I try "nand info" I get information about nand device 0.
>> Another strange thing is that I can't read from nand flash but I can write.
>>
>> Do you have any suggestions?

> The only i.MX31 NAND driver I've used in U-boot is the one I submitted
> to the list last year but it was rejected. Other people have sent
> updated drivers (I think there was a i.MX27 driver posted not long
> ago), but I haven't tried these.
> Even so, the CONFIG_SYS_NAND_BASE looks incorrect but I don't know if
> that's the only problem.

CONFIG_SYS_NAND_BASE   CS0_BASE should be correct because the Flash is located at 0xA0000000 which should be CS0_BASE. Why do you think it is wrong?

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?

Thanks a lot for your help.

Best Regards 
Ulrich Gerster

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Ulrich Gerster]

Hello,

>>>> Wolfgang Denk <wd@denx.de> 14.07.09 13.22 Uhr >>>
> Dear "Ulrich Gerster",

> In message <4A5C71DA0200004D00014C8A@hochblauen.ba-loerrach.de> you wrote:
>> 
>> I can ping my linux host and I'm able to download a binary file via TFTP into RAM.
>> But I'm not able to ping the boad with u-boot from my linux host. In my config-file I 
>> defined CONFIG_NETMASK and CONFIG_IPADDR. What could be wrong?

>Nothing is wrong. That's expected and documented behaviour.

>> Another strange thing is the nand driver. I build my u-boot with:
>> #define CONFIG_MX31_NAND   1
>> #define CONFIG_CMD_NAND
>> #define CONFIG_SYS_NO_FLASH   1
>> #define CONFIG_ENV_IS_IN_NAND   1
>> #define CONFIG_SYS_NAND_BASE   CS0_BASE
>> #define CONFIG_SYS_MAX_NAND_DEVICE 	1
>> #define CONFIG_SYS_NAND_MAX_CHIPS	1
>> 
>> If I then try to get "flinfo" information u-boot jumps to the next command line and prints nothing.

>Seems you don't have NOR flash on your board, then (or no driver
>configured for it).

> If I try "nand info" I get information about nand device 0.

> OK.

> Another strange thing is that I can't read from nand flash but I can write.

> That's indeed strange. How do you know you can write then when you
> cannot read the data back for verification?

Your're right. I only use NAND Flash.
At the moment I'm starting u-boot out of RAM using RedBoot.
I'm assuming that U-Boot is writing something to the NAND Flash because if I enter a commad in U-Boot like "saveenv" or "nand write" my RedBoot is not working anymore after that. I have to reprogramm RedBoot in the Flash before I can boot it again.

Thanks for helping.
Best Regards 
Ulrich Gerster

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Wolfgang Denk]

Dear "Ulrich Gerster",

In message <4A5C8FD30200004D00014C9B@hochblauen.ba-loerrach.de> you wrote:
> 
> > Another strange thing is that I can't read from nand flash but I can =
> write.
> 
> > That's indeed strange. How do you know you can write then when you
> > cannot read the data back for verification?
> 
> Your're right. I only use NAND Flash.
> At the moment I'm starting u-boot out of RAM using RedBoot.
> I'm assuming that U-Boot is writing something to the NAND Flash because if
> I enter a commad in U-Boot like "saveenv" or "nand write" my RedBoot is
> not working anymore after that. I have to reprogramm RedBoot in the Flash
> before I can boot it again.

So you just know that it's corrupting he previous content - for
example, erase might be working. But you have no indication of a
successful write operation, so you better do not assume that write
was working.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Contrary to popular belief, thinking does not cause brain damage.

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Magnus Lilja]

Hi

2009/7/14 Ulrich Gerster <gersteru@dhbw-loerrach.de>:
> Hello again,
>
>>>> Magnus Lilja <lilja.magnus@gmail.com> 14.07.09 13.08 Uhr >>>
>> Hi
>
>>> Another strange thing is the nand driver. I build my u-boot with:
>>> #define CONFIG_MX31_NAND ? 1
>>> #define CONFIG_CMD_NAND
>>> #define CONFIG_SYS_NO_FLASH ? 1
>>> #define CONFIG_ENV_IS_IN_NAND ? 1
>>> #define CONFIG_SYS_NAND_BASE ? CS0_BASE
>>> #define CONFIG_SYS_MAX_NAND_DEVICE ? ? ?1
>>> #define CONFIG_SYS_NAND_MAX_CHIPS ? ? ? 1
>>>
>>> If I then try to get "flinfo" information u-boot jumps to the next command line and prints nothing.
>>> If I try "nand info" I get information about nand device 0.
>>> Another strange thing is that I can't read from nand flash but I can write.
>>>
>>> Do you have any suggestions?
>
>> The only i.MX31 NAND driver I've used in U-boot is the one I submitted
>> to the list last year but it was rejected. Other people have sent
>> updated drivers (I think there was a i.MX27 driver posted not long
>> ago), but I haven't tried these.
>> Even so, the CONFIG_SYS_NAND_BASE looks incorrect but I don't know if
>> that's the only problem.
>
> CONFIG_SYS_NAND_BASE ? CS0_BASE should be correct because the Flash is located at 0xA0000000 which should be CS0_BASE. Why do you think it is wrong?

Because the NAND flash is not connected to any of the standard memory
mapped chip selects of the i.MX31. The i.MX31 has a dedicated NAND
interface. But I don't think CONFIG_SYS_NAND_BASE matters for the
i.MX31, the rest of U-boot needs it to be defined to something.

>
> 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.

Did you define the following two as well (they might have been renamed
since last year).
#define CFG_ENV_OFFSET		0x40000
/* CFG_ENV_SIZE has to be a multiple of the NAND block size */
#define CFG_ENV_SIZE		(128 * 1024)

If CFG_ENV_OFFSET (or perhaps it's called CONFIG_ENV_OFFSET nowadays)
is zero, then 'saveenv' will overwrite your existing redboot.

/Magnus

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Ulrich Gerster]

Hello.

>>> Magnus Lilja <lilja.magnus@gmail.com> 14.07.09 16.03 Uhr >>>

>> CONFIG_SYS_NAND_BASE   CS0_BASE should be correct because the Flash
>> is located at 0xA0000000 which should be CS0_BASE. Why do you think it is wrong?

> Because the NAND flash is not connected to any of the standard memory
> mapped chip selects of the i.MX31. The i.MX31 has a dedicated NAND
> interface. But I don't think CONFIG_SYS_NAND_BASE matters for the
> i.MX31, the rest of U-boot needs it to be defined to something.

I will check that. 

>> 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?

> Did you define the following two as well (they might have been renamed
> since last year).
> #define CFG_ENV_OFFSET		0x40000
> /* CFG_ENV_SIZE has to be a multiple of the NAND block size */
> #define CFG_ENV_SIZE		(128 * 1024)
>
> If CFG_ENV_OFFSET (or perhaps it's called CONFIG_ENV_OFFSET nowadays)
> is zero, then 'saveenv' will overwrite your existing redboot.

Yes, I defined them and you're right my offset was zero. But I think in a working u-boot thats no problem. But I will change that.

In your previous mail you mentioned a newer nand driver patch for the i.MX27.
Do you mean this one?
http://lists.denx.de/pipermail/u-boot/2009-June/053898.html
Does this one work with i.MX31 aswell?

Thanks a lot for your help.
Ulrich Gerster

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Magnus Lilja]

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.

>> Did you define the following two as well (they might have been renamed
>> since last year).
>> #define CFG_ENV_OFFSET ? ? ? ? ? ? ? ?0x40000
>> /* CFG_ENV_SIZE has to be a multiple of the NAND block size */
>> #define CFG_ENV_SIZE ? ? ? ? ?(128 * 1024)
>>
>> If CFG_ENV_OFFSET (or perhaps it's called CONFIG_ENV_OFFSET nowadays)
>> is zero, then 'saveenv' will overwrite your existing redboot.
>
> Yes, I defined them and you're right my offset was zero. But I think in a working u-boot thats no problem. But I will change that.

I do think that's a problem in a working u-boot since it defines the
offset for the environment from the start of the flash.

>
> In your previous mail you mentioned a newer nand driver patch for the i.MX27.
> Do you mean this one?
> http://lists.denx.de/pipermail/u-boot/2009-June/053898.html

Yes.

> Does this one work with i.MX31 aswell?

Don't know, but the author claims that it should work (perhaps with
some adjustments).

Regards, Magnus

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Ulrich Gerster]

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.
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?

Thanks.
Ulrich Gerster

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Magnus Lilja]

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.

> 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. 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. 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).

/Magnus

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Ulrich Gerster]

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

[U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Magnus Lilja]

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] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)

[Thomas Dörfler]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot


-- 

--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler        Obere Lagerstrasse 30
D-82178 Puchheim       Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9