[U-Boot-Users] Multiple flash Support

[U-Boot-Users] Multiple flash Support

[Nishanth Menon]

Wolfgang Denk stated on 8/24/2006 7:22 AM:
> U-Boot is probably flexible enough to support this, but it  does  not
> provide much existing infrastructure for it - i. e., you will have to
> implement most of this in your own board support code.
Hmm thanks for the confirmation :(
>
> You should try to keep the environment variables at a fixed  location
> though;  most  of this configuration is done at compile-time (to save
> code size) and cannot be changed dynamically.
>
some constraints that do not allow this - like the flashes are plug and
play(at least cold) :(. Will try and get a patch for the modifications
done to the rest of the files. The board support code is on OMAP2430, so
it might tend to be a bit difficult to push in at this moment.

Regards,
Nishanth Menon

[U-Boot-Users] Multiple flash Support

[Nishanth Menon]

Hi All,

I have a generic question with regards to a  ARM based board: The board
in question has capability for 4 or more flashes (mixture of nand,
onenand, Nor flashes) all operating at the same time, however, with a
dip switch change on the board, the actual flash from which Uboot boots
up changes. I do not want to recompile UBoot for each configuration.

Is it possible to have a single UBoot which could boot off each of the
flash device? each boot would need to take the environment variable off
that specific flash (with configurability to take it off a common
location as part of the wishlist).

Regards,
Nishanth Menon

[U-Boot-Users] Multiple flash Support

[Wolfgang Denk]

In message <44ED0F52.4060806@gmail.com> you wrote:
> 
> I have a generic question with regards to a  ARM based board: The board
> in question has capability for 4 or more flashes (mixture of nand,
> onenand, Nor flashes) all operating at the same time, however, with a
> dip switch change on the board, the actual flash from which Uboot boots
> up changes. I do not want to recompile UBoot for each configuration.
> 
> Is it possible to have a single UBoot which could boot off each of the
> flash device? each boot would need to take the environment variable off
> that specific flash (with configurability to take it off a common
> location as part of the wishlist).

Everything is possible. The question is if it makes sense, and if the
required effort deems acceptable. I tend to answer both of this  with
no, but YMMV.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To be a winner, all you need to give is all you have.

[U-Boot-Users] Multiple flash Support

[Ulf Samuelsson]

> In message <44ED0F52.4060806@gmail.com> you wrote:
>> 
>> I have a generic question with regards to a  ARM based board: The board
>> in question has capability for 4 or more flashes (mixture of nand,
>> onenand, Nor flashes) all operating at the same time, however, with a
>> dip switch change on the board, the actual flash from which Uboot boots
>> up changes. I do not want to recompile UBoot for each configuration.
>> 
>> Is it possible to have a single UBoot which could boot off each of the
>> flash device? each boot would need to take the environment variable off
>> that specific flash (with configurability to take it off a common
>> location as part of the wishlist).
> 

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.

If you can read the switch, you can make decisions inside your boot.

> Everything is possible. The question is if it makes sense, and if the
> required effort deems acceptable. I tend to answer both of this  with
> no, but YMMV.

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.


> Best regards,
> 
> Wolfgang Denk
> 
> -- 

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com
Best AVR  link: www.avrfreaks.net

[U-Boot-Users] Multiple flash Support

[Wolfgang Denk]

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.

I recommend against using EEPROM (at least on I2C) for any  important
data.  See  doc/I2C_Edge_Conditions  for  just  one problem which can
cause data loss on such devices. Don't  say  this  is  a  theoretical
issue. I know of systems that suffered from this.

Also, EEPROM is slow to read, and  adds  for  LONG  and  random  boot
delays.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"This isn't brain surgery; it's just television."   - David Letterman

[U-Boot-Users] Multiple flash Support

[Ulf Samuelsson]

> 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.
> 
> I recommend against using EEPROM (at least on I2C) for any  important
> data.  See  doc/I2C_Edge_Conditions  for  just  one problem which can
> cause data loss on such devices. Don't  say  this  is  a  theoretical
> issue. I know of systems that suffered from this.
> 

There are plenty of serial EEPROMs (and Serial Flash) and some are on I2C and other are on SPI.
A very large percentage of my customers only have an SPI flash on the board and nothing else.

If this indeed is a development board, cost is probalby not a big issue.
A 4 Mbit serial flash in an SO-8 is anyway dirt cheap and runs at 66 Mbps or 8,25 MByte/s

The U-boot dataflash driver does not support so small dataflashes, but you can 
add a 16 Mbit CASON-8 package in the same foot print and set the
CONFIG_ENV_IN_DATAFLASH (IIRC) and a few other things, (see include/configs/at91rm9200dk.h)
and off you go.
 
A small patch to the dataflash driver should allow the use of the smaller size.
The main issue will be the fact that the sectors are 512+16 bytes instead of 1024+32 bytes

> Also, EEPROM is slow to read, and  adds  for  LONG  and  random  boot delays.
> Best regards,
> 
> Wolfgang Denk
> 

Best Regards
Ulf Samuelsson   

[U-Boot-Users] Multiple flash Support

[Nishanth Menon]

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

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

The base question remains: Is the current U-Boot architecture flexible
enough to support this? if not, what is the suggested approach?

Regards,
Nishanth Menon

[U-Boot-Users] Multiple flash Support

[Ulf Samuelsson]

> 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