[U-Boot] Multiple device support - none at all?

[Wolfgang Denk]

Dear ksi at koi8.net,

In message <Pine.LNX.4.64ksi.0903121033170.8624 at home-gw.koi8.net> you wrote:
> 
> It is supposed to be a "Universal" bootloader. Here is what wiki says:

There is a certain difference between "universal" and "omnipotent".
Note that it's called "U-Boot", not "O-Boot".

> === Cut ===
> Das U-Boot (Universal Bootloader, short for "Das Unterseeboot", German for
> "the submarine") is a boot loader for a number of different computer
> architectures, including PPC, ARM, AVR32, MIPS, x86, 68k, Nios, and
> MicroBlaze. 
> === Cut ===

And this is 100% correct, isn't it?

> I'm not even talking about using several USB/I2C/SPI/Serial/whatever devices
> concurently; it is only about being able to pick one of several at run
> time...

You seem to be the first to express such a requirement. And U-Boot
provides you with all the means (free software etc.) that enables you
to extend it and to add such a feature.

U-Boot never claimed to provide a turnkey solution for any obscure
requirement.

> That is actually not sufficient because we have one device that must be
> enabled at all times -- the console. That means we must have one USB

Wrong. You can switch console devices on the fly. Including assigning
it to the null device. Of course you better know exactly what you are
doing.

> controller permanently enabled if we use USB keyboard that in turn means the
> boot device absolutely must reside on that same controller in current
> architecture.

Wrong. You can switch on the fly.

> Eh, I did offer such a model for I2C :) And that model can be extended to

We might come bck on this after the next release is out. Heiko has all
your stuff in his repository. And some more.

> into the U-Boot proper. I wasted 2+ weeks for I2C without any result (that
> is not counting another couple of weeks I spent on that before starting
> sending patches to the list.)

It's a pity when you consider discussion the principle parts of a new
design wasted time. 

As such, I wonder why you waste time for the messages in this current
thread.

> The model can be really simple. Just use an array of structures with
> function pointers to several adapter drivers and make a simple wrapper
> calling an appropriate function depending on device chosen (i.e. "current"
> device.) Don't call all e.g. USB adapter submit message functions
> "submit_XXX_msg" and link that only one that is chosen at compile time and
> exported. Make them e.g. "adapter_submit_XXX_msg" instead, then do something
> like this:

Submit a patch? Then we can see the code, the size impact, etc. 

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
The human race is a race of cowards; and I am not  only  marching  in
that procession but carrying a banner.                   - Mark Twain