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