[U-Boot-Users] U-boot code etiquette

[Wolfgang Denk]

Dear Neil,

in message <41F4F2D7.31679.675965 at localhost> you wrote:
> 
> I thought my suggestions may prove unpopular,
> but I did not expect quite such a roasting ;-)

This was not intended as "roasting" - sorry if it sounded as such.  I
just wanted to prevent you from running down a dead end road.

> Please read my defence below.

No need to defend yourself. We're just discussion technical options.

> > Don't do that. Using  an  EEPROM  for  the  environment  has  several
> > serious   disadvantages   (slow   boot  speed,  risk  of  losing  the
> > environment). I strongly  recommend  to  use  flash,  porobably  even
> > redundand flash sectors.
> 
> For some reason, which I do not know, a policy decision has 
> been made to use EEPROM for all configuration data.  This 

Tell them that others did that before, and failed. Depending on  your
hardware,  you  may lose all data in EEPROM, even if everything works
fine initially. See doc/I2C_Edge_Conditions - to give  you  just  one
example  of  failure modes: assume for example that your power supply
starts to age in two years from now,  and  that  causes  the  voltage
rises more slowly. Then your CPU may start running, but will be reset
by  the  system  monitor, eventually several times until the voltage.
Chances are, that one of these resets will  catch  the  system  right
after  the  processor  started  reading the environment. Chances are,
that this will write random data into the EEPROM.  --  This  is  more
than  theory.  One of our customers had a system that lost the EEPROM
contents in 2 out of 3 power cycles.

> includes U-Boot environment variables.  Now this is a 
> particularly weak argument on my part, but in this context, 
> I am just blindly following orders.  However, I can ask  

Never do that. NEVER.

Always keep your eyes open and the brain online. It is part  of  your
responsibility  as  an engineer to prevent managers from doing stupid
things.

> the question to my policy-makers and make a strong 
> argument to them based on your reservations NOT to use 
> EEPROM for U-boot environment variables.  This point
> shall be followed up.

[but probably not here on the list - unless it is of general interest]

> > Who says that Linux and U-Boot cannot share the same storage?
> Good point, but parsing can be a pain with the way that U-Boot 
> stores environment variables.  It throws everything into one big 

You must be joking. The code  do  parse  the  U-Boot  environment  is
around  20  lines  of C code, including inti calls and error handling
and everything.

> pile and passes all the work of finding what you need to the driver.
> My proposed scheme is to help simplify parsing.

Sorry, but I realy don;t now what you mean.  Reading  or  writing  an
U-Boot  environment  variable  is  a  very simple and straightforward
procedure. It may be non-optimal in terms of speed  (linear  search),
but in terms of simplicity you will have problems to beat it.

> > Right. So share the environment.
> Yes, if the environment was nice to use.  I get the impression that
> as it was designed to use FLASH, U-Boot can be very generous in the
> amount of space it reserves for a simple value.  We have a small 
> EEPROM and I cannot justify this expense.

What exactly is your problem? That somebody might define long  values
for variables? You don't have to do that.

> > > To divide the EEPROM into a psuedo-file structure.  We have data 
> > 
> > What a overkill.
> How can you say this with such little knowledge of what is proposed?

The "name=value" list method  used  for  the  U-Boot  environment  is
pretty  efficient.  If  you  don't  fall  back  to  hard-coded binary
structures which are a major PITA to maintain then you will have hard
times to find a simpler solution.

> The current U-Boot scheme works very well for the limited number of
> variables needed by the environment.  But with other OSes (not Linux)
> this number can be very large.  If a single flag (1bit) has to be 
> stored as an ascii encoded identifier followed by 'yes' or 'no',
> we will soon run out of space.  Using a single byte, I can represent

Then don't do it. Who prevents you from defining "flags=deadbeef"? 15
bytes of storage for 4 byte of data or 32 bits of data. Or use a long
long with a single character name - 19 bytes of storage for 8 byte or
64 bits.

> > Please provide an example that cannot be encoded in the way mentioned
> > above.
> The difficulty is not to encode the data, but to encode it 
> efficiently and easily accessible by the OS driver that has to use 
> it.

Don't forget the benefits from  being  able  to  read  your  settings
without  special  tools. With the current U-Boot method, you can even
read the environment in flah when all you have available  is  a  JTAG
debugger.

> This is exactly the idea.  To have common data shared between an OS 
> and U-Boot, but not using the U-Boot method for storing the common 
> data.

> My proposal is to use one set of data.  The intention is to extend 
> not duplicate.  The long and the short is that U-Boot stores data in 
> a way that is friendly only to U-Boot.  Any other driver that needs
> access to this data has an horrendous job of parsing it.

C'me on. Did you really read the code of the getenv() function?

> I have to support several other OSes aside from Linux.  I am happy to 

This is OK - but try to implement a method which is common to all  of
then, and to U-Boot.

> board.  The problem is, that the env_x and cmd_x code is in the 
> common area.

Thisi s not a problem, it is  a  good  thing,  preventing  people  to
reinvent the wheel :-)

> My final point is, if I make the changes in a board-specific 
> directory, would you include it in the U-Boot tree?  If not,
> then I shall stop working on this problem now.

I have  to  repeat  myself:  I  don't  think  that  there  should  be
board-specific  code for this. Either provide access functions to the
U-Boot environment for your other OSes that need to access (read  and
write)  configuration  data,  or  then  use  a  new  format  to store
"environment variables"  for  all  parties  involved  and  provide  a
complete new access method for U-Boot (which then goes into common/).

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
If a man had a child who'd gone  anti-social,  killed  perhaps,  he'd
still tend to protect that child.
	-- McCoy, "The Ultimate Computer", stardate 4731.3