[U-Boot-Users] Multiple flash Support

[Ulf Samuelsson <ulf@atmel.com>]

> Wolfgang Denk stated on 8/24/2006 4:40 AM:
>> In message <000e01c6c752$e8502510$654765d5@atmel.com> you wrote:
>>> Maybe this is too late, 
>>> but it may make sense to add an 8 kB serial EEPROM to a board
>>> (which is probably a development board anyway)
>>> and store the environment in this chip.
>> 
>> No! Please DON'T do this.
> Agreed. It is too late for that and to top it all, our marketing folks
> will not like the extra cost :(.
 
Our marketing folks will like the extra billing :-)

> Ulf Samuelsson stated on 8/24/2006 2:57 AM:
>> If you can read the switch, you can make decisions inside your boot.
> yes that is the implementation we have currently done.
> 
>> I can see a point in the request.
>> If it is a board that is sold as a development tool, and one of their
> customers
>> wants to download and upgrade the u-boot binary from their website,
>> then it is a significant chance that the customer will download the
> wrong image to the flash memory
>> This results in a call the support team, which is costly and the
> customer problem will often reflect on them.
> 
> Aaah, Ulf, you are reading my mind :).

benn there, done that...

> 
> The base question remains: Is the current U-Boot architecture flexible
> enough to support this? if not, what is the suggested approach?
> 
You can store an environment in a different chip that the chip you are booting from,
but this chip needs then to be accessible in all configurations.

The first support for Dataflash had the environment still in the parallel flash.

There are other issues.

If you enable boot from dataflash, the current u-boot source tree fails miserably.
It just freezes in the middle.
Dont have JTAG emulator which works on Linux handy where I am
so I resorted to debugging using LEDs.
The loader loaded the U-Boot into DRAM, printed out a message on the UART.
Jumped to U-boot and then tried to printout using a routine compatible with the 
UART routine in the loader.
Eventually I discovered that U-boot was linked to the wrong address = 0x00000000
and any constant string pointer, pointed to  a zero length string.

I modified u-boot.lds to link to 0x21f00000, and then everything started to work.

Best Regards
Ulf Samuelsson