OK, this is _NOT_ just multiple I2C adapters... The entire thing is fundamentally broken.
One supposed to have _THE_ device and only this device is somehow supported. Now it is USB. Each and every USB driver exports the same set of functions, submit_XXX_msg(...) That means there can be one and only one USB device in the system. Let's take e.g. widely used ISP1563 PCI USB controller. It has _TWO_ OHCI controllers. Existing usb_ohci.c code only supports one. That means that one can only use odd numbered ports (1 and 3) for any USB devices. Ports 2 and 4 are not usable at all. Not just together with odd numbered ones but even _INSTEAD_ of those. But wait, there is more... This very same controller also has a 4-port EHCI controller for USB 2.0 support. This is not supported at all because usb_ehci_pci.c is a mere stub that does NOT support _ANY_ PCI EHCI controller. But it would not do any good if it did support ISP1563 -- there should be one and only one USB controller, _THE_ USB controller... EHCI driver, usb_ehci_core.c exports exactly the same submit_XXX_msg() set of function so it can _NOT_ coexist with anything else. So what's the choice? Let's say we somehow made that usb_ehci_pci.c stub in a real driver and got ISP1563 (or _ANY_ other USB2.0 PCI adapter) recognized and initialized. This hypothetically gives us all 4 ports because all 4 are supported by EHCI vs. only 2 by OHCI. Would it do any good? The answer is _NO_. EHCI does _NOT_ support slower USB1.X ports so one can _NOT_ hook his e.g. USB keyboard to EHCI controller. It is only for hi-speed devices. USB2.0 controller actually consists of an EHCI and set of slower USB1.X controllers that share the same USB pins. If a connected device supports high speed, EHCI is used. If it does NOT support high speed, driver should made EHCI controller to give up ownership of that particular USB port to OHCI (or whatever it is) and pass control to OHCI driver. That is how USB works. Now we suddenly have _THREE_ USB controllers while our software only supports one. And that is _NOT_ some exotic situation with multiple chips or other strange design -- e.g. MPC8548 does NOT have a built-in USB controller so I added a single PCI chip to provide for a USB interface. One can recommend using only the first OHCI controller in U-Boot somehow tolerating it being painfully slow with storage devices etc. and limited with what ports can be used but that is also _NOT_ a solution... OHCI only allows for 2 ports and in our case they are both already used (KBD + MOUSE.) Sure we don't need a mouse in U-Boot but we _DO_ need it to be connected anyways because we boot full-blown Fedora with X that uses mouse. That means we do NOT have any USB ports available for storage or anything else... USB keyboard is another grand kludge deserving its own chapter... As of now one can only switch to it from command line because USB is not even initialized until do_usb() from cmd_usb.c is called... What if we do NOT have a serial console at all? Grrr... --- ****************************************************************** * 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
