On Tue, 10 Mar 2009, Jerry Van Baren wrote:

ksi@koi8.net wrote:

...

Hi, everyone.

I wonder if I'm dreaming or the U-Boot is fundamentally broken...

Well... broken can be a relative term. I like to think of it as an opportunity to stand on the shoulders of giants. ;-)

:)

...

It looks like there is no support for multiple devices of a same kind at all.

I'm porting U-Boot to my new MPC8548-based board and it pops up everywhere...

The first case was I2C subsystem that does not provide for several I2C adapters except rudimentary hacks for fsl_i2c.

Now it is USB. I have 2 OHCI USB controllers on the board, OHCI module in NXP ISP1563 and OHCI controller in Silicon Motion SM502 MFD. The former is supported in drivers/usb/usb_ohci.c, the latter is kinda trivial to add, BUT...

It looks like nobody even considered the case when a board can have several controllers... Looking at usb_lowlevel_init() I can see it only works for the first device found, there is absolutely no provision for several devices. And things are getting even nastier if there are devices of the same type with different interfaces (e.g. on-SoC USB controller and a PCI one.)

And this seems to be the case for each and every device type. Am I missing something or U-Boot is actually flawed in FUNDAMENTAL way and it is time to start a new one from scratch?

U-Boot started life as a boot loader. You know, simple. It has gotten more complex over time, but the modus operandi of u-boot is and shall remain that. Simple. (quoting our benevolent dictator, WD)

The counter-question for your application is to challenge what you are trying to use u-boot for: do you actually need to use both USB controllers (simultaneously or even sequentially) to boot linux? Do you really need to use multiple I2C controllers to boot linux? Can you simplify your system to get linux running without supporting multiple USB or I2C adapters?

Yes, I _DO_ need both controllers. There are numerous scenarios for that -- e.g. I can have a keyboard on a slow controller and a storage device or network adapter on another one. I can have multiple storage devices and want to choose which to boot from and so on.

If you really need multiple adapter support, you are going to have to blaze new ground (or build out some hacks into more acceptable levels of support). That is the cost of being the leader. :-/

Thanks, I already tried this for I2C... Now it is a hack (separate driver and core) in my $(BOARD) directory. USB is next, then I have additional serial ports...

The fundamental concept of u-boot isn't to handle all your devices, it is to boot linux (or other OS) and use the OS to handle the multiple devices.

The same is true for a PC BIOS, but it DOES handle all of my devices. And it allows me to choose which device to boot from. And it is extendable so I can add a PCI card with e.g. RAID controller and boot off of that RAID. And it is not handling of all devices, it is _BASIC_ functionality...

I don't mind reconfiguring and rebuilding the thing for my parcticular configuration instead of just changing some settings in interactive setup utility, but the current implementation won't allow even that...

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

On Thu, 12 Mar 2009, Detlev Zundel wrote:

Hi ksi (was it Sergei?),

...

...

The fundamental concept of u-boot isn't to handle all your devices, it is to boot linux (or other OS) and use the OS to handle the multiple devices.

The same is true for a PC BIOS, but it DOES handle all of my devices. And it allows me to choose which device to boot from. And it is extendable so I can add a PCI card with e.g. RAID controller and boot off of that RAID. And it is not handling of all devices, it is _BASIC_ functionality...

Actually I don't know what you're talking about in the PC BIOS area here. Usually the computers I own cannot boot from the devices that are bought somewhat after the motherboard. But maybe you have different instances of computers...

First of all, there are several bootable devices on a motherboard itself. These days almost every motherboard has PATA and some kind of SATA RAID controller onboard. Then, it can usually boot off of USB while having USB keyboard/mouse. As for add-on devices, it usually CAN boot off of those devices. They have their own BIOS for that that gets attached to the motherboard's one when it initializes and those devices are added to the boot table.

...

I don't mind reconfiguring and rebuilding the thing for my parcticular configuration instead of just changing some settings in interactive setup utility, but the current implementation won't allow even that...

Actually we are thinking about "going generic" here also for a while already. Look for example at the BOF session notes of OLS 2007[1] "Device Tree Run Time Configuration".

We are all aware that a "proper" device model will be needed at a certain stage, only nobody started into that direction yet.

As Jerry pointed out - booting embedded hardware used to be a comparably simple operation ;)

There is a whole world beyond that keyhole... Embedded devices yes, but there are other boards that don't fall in that category. My current MPC8548 based board is not an embedded one, it is full-blown mATX motherboard with several USB controllers, PATA, SATA, Video Capture, VGA/LCD controller, PCI-X/PCI/PCIe connectors etc.

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

On Thu, 12 Mar 2009, Detlev Zundel wrote:

Hello ksi (so I'll leave it at that),

...

First of all, there are several bootable devices on a motherboard itself. These days almost every motherboard has PATA and some kind of SATA RAID controller onboard. Then, it can usually boot off of USB while having USB keyboard/mouse. As for add-on devices, it usually CAN boot off of those devices. They have their own BIOS for that that gets attached to the motherboard's one when it initializes and those devices are added to the boot table.

It may come as a surprise to you, but I actually also use such system :)

What I wanted to say is that your blatant "it allows me to choose from which device to boot from" does not coincide with my experiences in real life. Moreover what you call "to boot from" is in the BIOS world the transfer of usually one block followed by a jump. I have yet to see a BIOS booting Linux in a flexible way. This is hardly comparably to the support (just think filesystems) that we have for ages in U-Boot.

Yes, that's great, but that filesystem _MUST_ reside on a device connected to _ONE_ particular controller. And it becomes even more complicated if you have a keyboard (or console) on USB...

But actually I think that this is not news to most people on the ML so I'll stop here.

...

...

As Jerry pointed out - booting embedded hardware used to be a comparably simple operation ;)

There is a whole world beyond that keyhole... Embedded devices yes, but there are other boards that don't fall in that category. My current MPC8548 based board is not an embedded one, it is full-blown mATX motherboard with several USB controllers, PATA, SATA, Video Capture, VGA/LCD controller, PCI-X/PCI/PCIe connectors etc.

Yes, and again, you may notice that U-Boot was meant for "embedded devices" so the "impedance mismatch" you now realize for "full-blown motherboards" was kind of to be expected...

It is supposed to be a "Universal" bootloader. Here is what wiki says:

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

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

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

...

---

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

---

Miracles in 24 hours? Ok, I'm looking forward to a device model implementation tomorrow evening then ;)

Eh, I did offer such a model for I2C :) And that model can be extended to anything else. That is what I'm actually implementing for my new board. But that goes into $(BOARD)/* because I simply don't have time for pushing it 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.)

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:

=== Cut === Header file: . . . typedef struct usb_functions_mux { int (*submit_bulk_msg)(struct usb_device *dev, unsigned long pipe, void *buffer, int transfer_len); int (*sumbit_control_msg)(struct usb_device *dev, unsigned long pipe, void *buffer, int transfer_len, struct devrequest *setup); int (*submit_int_msg)(struct usb_device *dev, unsigned long pipe, void *buffer, int transfer_len, int interval); void (*usb_event_poll)(void); int (*usb_lowlevel_init)(void); int (*usb_lowlevel_stop)(void);

char *name; int inited; } usb_func_t; . . .

USB adapter driver: . . . usb_func_t sm501_usb_func { .submit_bulk_msg = sm501_submit_bulk_msg; .submit_control_msg = sm501_submit_control_msg; .submit_int_msg = sm501_submit_int_msg; .usb_event_poll = sm501_usb_event_poll; .usb_lowlevel_init = sm501_usb_lowlevel_init; .usb_lowlevel_stop = sm501_usb_lowlevel_stop; .name = "SM501_OHCI" .inited = 0; } . . .

USB wrapper: . . . extern usb_func_t sm501_usb_func; extern usb_func_t isp1563_usb_func;

static usb_func_t *usb_func[] = { &sm501_usb_func, &isp1563_usb_func, };

int cur_usb_adap = 0; . . . int submit_bulk_msg(struct usb_device *dev, unsigned long pipe, void *buffer, int transfer_len) { return usb_func[cur_usb_adap]->submit_bulk_msg(dev, pipe, buffer, transfer_len); } . . . === Cut ===

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

On Thu, 12 Mar 2009, Wolfgang Denk wrote:

Dear ksi@koi8.net,

In message Pine.LNX.4.64ksi.0903121033170.8624@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@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

On Thu, 12 Mar 2009, Wolfgang Denk wrote:

Dear ksi@koi8.net,

In message Pine.LNX.4.64ksi.0903121203270.8874@home-gw.koi8.net you wrote:

...

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.

When U-Boot was started, it was for MPC860 only. Well, actually for MPC8xx.

It took until Stefan Roese submitted the firt port to another pro- cessor family (4xx) - before that, supporting other processors was never a goal.

You see the same happen in another area.

That I understand, nobody can predict the future... But now it overgrew itself so some radical changes are in order. No matter how much grease we stuff in the bearings of a horse-cart wheels it can not cope with modern vehicles any more. Iron horse is coming to replace the old peasant's mare :)

...

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.

You mean the code cannot be changed? C'me on...

It can be. But the changes will be really extensive. I might be wrong but I think that all board-specific stuff must go under $(BOARD)/* with the rest of U-Boot proper untouched.

As for now I don't have any other choice than duplicate USB, I2C, and serial drivers (not sure yet what else) under my $(BOARD)/ and add wrappers there. I can _NOT_ use standard drivers because they export access functions that must go through a wrapper in my case with the wrapper itself exporting them. That makes my $(BOARD)/* really big and a lot of source code duplication is required.

I do also have to make some changes to U-Boot proper (e.g. to add switching USB controllers to common/cmd_usb.c) but those are relatively small.

...

...

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

Use stdin on USB keyboard, if you like (I'd prefer netconsole any- way); then define an environment variable that 1) switches stdin to nulldev; 2) reads the file from USB ; 3) switches stdin to USB key- board.

I do not claim that this is especially elegant, but it's a simple workaround that allows you to do what you ask for and takes less than 3 seconds to implement.

There are numerous ways to skin a cat :) Sure, everything can be done eventually but we are developers, not mere end users, aren't we? :) We can make it elegant, that's what we are for...

You are welcoem to provide patches for a more elegant (and more expensive) solution.

...

...

...

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.

It can be used as a quick (even if considered somewhat dirty) workaround.

...

...

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

Well, I think you can blame both sides. You also provided your share of unproven claims, ignoring other opinions, etc.

No, I gave a logical analysis. I did not build several versions and compared them but it is not required. It is only needed if there is no logic or theoretical solution and result can not be calculated. There is nothing more practical than a good theory.

Numerous experiments in the dark is not an effective way to do things. It might be the only one if we deal with something totally unknown but there is no need for experiments to tell if a sledgehammer would deliver a stronger blow than a small hammer. And it doesn't require experimenting to tell which one is easier on an operator.

Once upon a time Soviet military did not have QA departments for software. Nobody tested programs by pushing each and every button in different combinations in hope to find some bug. Every piece of software had to be _PROVEN_ i.e. it's source code was analyzed for dead states, logical deficiencies etc. Every single line of it. That resulted in almost no bugs, everything worked as it supposed to.

I suggest we let this rest for now, and start again in the next release cycle, hoping the minds are quieter tehn.

...

...

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.

OK, so let's wait what will come out the I2C discussion later, and then take the next step.

OK.

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

Hello ksi,

ksi@koi8.net wrote: [...]

Eh, I did offer such a model for I2C :) And that model can be extended to anything else. That is what I'm actually implementing for my new board. But that goes into $(BOARD)/* because I simply don't have time for pushing it into the U-Boot proper. I wasted 2+ weeks for I2C without any result (that

You wasted? You told us you get money for it ... We didn;t, so what would we say?

BTW: I have ready 2 new branches in the I2C git. One with exactly your patches, and one with the suggestions by wolfgang and me. I think, when v2009.03 is released I can make them public, and we can discuss them objective (because we have now 2 versions which we can compare, so no arguments must come from the sky ;-) again ...

is not counting another couple of weeks I spent on that before starting sending patches to the list.)

When you want to get this in mainline, maybe next time you first ask before spending "couple of weeks" for it?

bye Heiko