[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

[Removed the linuxppc-dev address; this is off topic there.]

In message <44512C25.2080105 at smiths-aerospace.com> you wrote:
>
> Disagree because, while u-boot needs/uses some env variables, 
> engineers/companies/end users are free to add variables and, I dare say, 
> most do.  If a given board needs to pass certain non u-boot parameters 
> to linux, it would simply add that to its env (which already happens).

Yes, of course. But we  are  talking  about  parameters  like  memory
sizes,  bank  start  addresses, clock frequencies and that stuff. You
don't want to have this in your environment.  At  least  not  in  the
environment we have today.

Of course we can discuss a  more  structured  approach  with  certain
"system" variables, which are not stored in flash, but autogenerated,
etc. But this is a different story.

> I'm not sure you (Wolfgang and Kumar) are following my thought fully (or 
> my ignorance is showing to everybody but me).  The thought is to change 
> the native format of the u-boot environment storage from the 
> key-string/value-string pairs to the flat tree (OpenFirmware) format 
> which still supports the same key-string/value-string capability (but 
> can do more than that).

I see three serious problems with such an approach:

* memory footprint (both code and data size)
* boot time
* backward compatibility

For example, there are systems in the field which use a 1 kB or 2  kB
EEPROM  on  a slow I2C bus to store the environment (and a 128 kB ROM
for the U-Boot  code).  The  current  format  works  well  with  such
systems. How much of this is left if you switch to OFT format?

> The advantage, as I see it, is that it would be unifying and thus easier 
> to maintain the common variables (call it the GRand Unifying Flat Tree 
> (GRAFT) ;-).  One language (flat tree), no shims, equivalent key/value 

I guess you cannot convince me before you can show that Linux on  ARM
and MIPS (or at least *one* of these) will accept this, too.

> The disadvantage is that it would be disruptive to u-boot and may cause 
> some bloating and discomfort.

Grrrlp.

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
Lots of folks confuse bad management with destiny.   -- Frank Hubbard