[U-Boot] Multiple device support - none at all?
Wolfgang Denk
wd at denx.de
Thu Mar 12 22:29:10 CET 2009
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.
> 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
More information about the U-Boot
mailing list