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

[ksi at koi8.net]

On Thu, 12 Mar 2009, Wolfgang Denk wrote:

> 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".

That's true but... It is not that unusual to have several similar interfaces
on a board. There is nothing obscure or weird in that. But allowing for only
one of those interfaces (whichever one chooses) supported by a given binary
is what is weird.

> > === 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?

Yes. It is truth, only truth and nothing but truth. But it is not the entire
truth :)

There is no "embedded" here...

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

It is not obscure. E.g. ISP1563 PCI USB controller (that is somehow
supported with drivers/usb/usb_ohci.c) has 3 devices, not one. They are 2
OHCI and 1 EHCI controllers. For EHCI, that allows for all 4 ports (but HS
only, will not work with e.g. USB keyboard) we do _NOT_ have any support;
drivers/usb/usb_ehci_pci.c is just a stub that does _NOT_ support _ANY_ EHCI
controller. What we are left with is _TWO_ OHCI controllers, each serving 2
ports (odd for one controller and even for another one.)

Our existing driver only supports _ONE_ controller. That means not just we
are not able to use HS USB 2.0 at all having to stick with USB 1.1 but also
that we must use 2 specific ports out of available 4 because only one OHCI
controller is detected and supported.

That _MIGHT_ be not an issue for an embedded board where everything is
hardwired and we _DO_ know where anything is connected to but it _IS_ an
issue for a regular motherboard with something like 6 or 8 USB connectors on
it's back panel. All USB are born equal, aren't they?

And it is _NOT_ that existing U-Boot does not provide a solution for a
particular board. It is that it does not provide _MEANS_ to make a solution.

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

So what? Let's say I'm trying to read a file from a USB device with some
interactive command. I do NOT have a serial console and I want to get a
result somehow...

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

Yes, I can. Will it do any good is totally different question.

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

It was _NOT_ a discussion. It ceased to be one after a couple of days. You
guys somehow got scared by innocent CPP tricks and then discussion degraded
to junk. I didn't even tell that there _IS_ a whole bunch of very similar
CPP-generated code already in U-Boot source. Look at e.g. drivers/pci/pci.c
or drivers/pci/pci_indirect.c...

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

I did it for I2C, it got nothing. There is absolutely no reason to make a
whole bunch of similar patches for other interfaces, they are almost
identical. The design is exactly the same, there is nothing unique there
that was not in I2C.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************