[U-Boot] Multiple device support - none at all?

[ksi at koi8.net]

On Thu, 12 Mar 2009, Wolfgang Denk wrote:

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