Dear k...@koi8.net, In message <pine.lnx.4.64ksi.0903121203270.8...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 1000 pains = 1 Megahertz _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
