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.
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...
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.
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.
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.
Best regards,
Wolfgang Denk