On Thu, 12 Mar 2009, Wolfgang Denk wrote: > Dear [email protected], > > In message <[email protected]> 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. --- ****************************************************************** * k...@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ****************************************************************** _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
