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

[Wolfgang Denk <wd@denx.de>]

Dear ksi at 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

-- 
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: wd at denx.de
1000 pains                                              = 1 Megahertz