[U-Boot] Multiple device support -- sorry state :(

[U-Boot] Multiple device support -- sorry state :(

[ksi at koi8.net]

OK, this is _NOT_ just multiple I2C adapters... The entire thing is
fundamentally broken.

One supposed to have _THE_ device and only this device is somehow supported.

Now it is USB. Each and every USB driver exports the same set of functions,
submit_XXX_msg(...) That means there can be one and only one USB device in
the system.

Let's take e.g. widely used ISP1563 PCI USB controller. It has _TWO_ OHCI
controllers. Existing usb_ohci.c code only supports one. That means that one
can only use odd numbered ports (1 and 3) for any USB devices. Ports 2 and 4
are not usable at all. Not just together with odd numbered ones but even
_INSTEAD_ of those.

But wait, there is more... This very same controller also has a 4-port EHCI
controller for USB 2.0 support. This is not supported at all because
usb_ehci_pci.c is a mere stub that does NOT support _ANY_ PCI EHCI
controller. But it would not do any good if it did support ISP1563 -- there
should be one and only one USB controller, _THE_ USB controller... EHCI
driver, usb_ehci_core.c exports exactly the same submit_XXX_msg() set of
function so it can _NOT_ coexist with anything else.

So what's the choice? Let's say we somehow made that usb_ehci_pci.c stub in
a real driver and got ISP1563 (or _ANY_ other USB2.0 PCI adapter) recognized
and initialized. This hypothetically gives us all 4 ports because all 4 are
supported by EHCI vs. only 2 by OHCI. Would it do any good? The answer is
_NO_.

EHCI does _NOT_ support slower USB1.X ports so one can _NOT_ hook his e.g.
USB keyboard to EHCI controller. It is only for hi-speed devices. USB2.0
controller actually consists of an EHCI and set of slower USB1.X controllers
that share the same USB pins. If a connected device supports high speed,
EHCI is used. If it does NOT support high speed, driver should made EHCI
controller to give up ownership of that particular USB port to OHCI (or
whatever it is) and pass control to OHCI driver. That is how USB works.

Now we suddenly have _THREE_ USB controllers while our software only
supports one. And that is _NOT_ some exotic situation with multiple chips or
other strange design -- e.g. MPC8548 does NOT have a built-in USB controller
so I added a single PCI chip to provide for a USB interface.

One can recommend using only the first OHCI controller in U-Boot somehow
tolerating it being painfully slow with storage devices etc. and limited
with what ports can be used but that is also _NOT_ a solution... OHCI only
allows for 2 ports and in our case they are both already used (KBD + MOUSE.)
Sure we don't need a mouse in U-Boot but we _DO_ need it to be connected
anyways because we boot full-blown Fedora with X that uses mouse. That means
we do NOT have any USB ports available for storage or anything else...

USB keyboard is another grand kludge deserving its own chapter... As of now
one can only switch to it from command line because USB is not even
initialized until do_usb() from cmd_usb.c is called... What if we do NOT
have a serial console at all?

Grrr...

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] Multiple device support -- sorry state :(

[Jerry Van Baren]

ksi at koi8.net wrote:
> OK, this is _NOT_ just multiple I2C adapters... The entire thing is
> fundamentally broken.
> 
> One supposed to have _THE_ device and only this device is somehow supported.
> 
> Now it is USB. Each and every USB driver exports the same set of functions,
> submit_XXX_msg(...) That means there can be one and only one USB device in
> the system.

[snip the badly scorched spot ;-)]

> USB keyboard is another grand kludge deserving its own chapter... As of now
> one can only switch to it from command line because USB is not even
> initialized until do_usb() from cmd_usb.c is called... What if we do NOT
> have a serial console at all?

Dumb question because I have not looked seriously at the v2 fork of 
u-boot: how does the v2 fork handle this?  Better?  Since the v2 fork 
uses (or is close to) the linux driver model, I would expect it to be 
better.

Best regards,
gvb

[U-Boot] Multiple device support -- sorry state :(

[ksi at koi8.net]

On Wed, 8 Apr 2009, Jerry Van Baren wrote:

> ksi at koi8.net wrote:
> > OK, this is _NOT_ just multiple I2C adapters... The entire thing is
> > fundamentally broken.
> > 
> > One supposed to have _THE_ device and only this device is somehow
> supported.
> > 
> > Now it is USB. Each and every USB driver exports the same set of
> functions,
> > submit_XXX_msg(...) That means there can be one and only one USB
> device in
> > the system.
> 
> [snip the badly scorched spot ;-)]
> 
> > USB keyboard is another grand kludge deserving its own chapter... As
> of now
> > one can only switch to it from command line because USB is not even
> > initialized until do_usb() from cmd_usb.c is called... What if we do
> NOT
> > have a serial console at all?
> 
> Dumb question because I have not looked seriously at the v2 fork of
> u-boot:
> how does the v2 fork handle this?  Better?  Since the v2 fork uses (or
> is
> close to) the linux driver model, I would expect it to be better.

Nothing's changed here...

And that is _NOT_ just USB, it is everywhere -- I2C, SPI, etc. It is stiff,
inflexible, everything written in stone and that stone is permanently set in
concrete.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] Multiple device support -- sorry state :(

[Robert Schwebel]

Hi Jerry,

On Wed, Apr 08, 2009 at 03:19:19PM -0400, Jerry Van Baren wrote:
> ksi at koi8.net wrote:
> > OK, this is _NOT_ just multiple I2C adapters... The entire thing is
> > fundamentally broken.
> >
> > One supposed to have _THE_ device and only this device is somehow supported.
> >
> > Now it is USB. Each and every USB driver exports the same set of functions,
> > submit_XXX_msg(...) That means there can be one and only one USB device in
> > the system.
>
> [snip the badly scorched spot ;-)]
>
> > USB keyboard is another grand kludge deserving its own chapter... As of now
> > one can only switch to it from command line because USB is not even
> > initialized until do_usb() from cmd_usb.c is called... What if we do NOT
> > have a serial console at all?
>
> Dumb question because I have not looked seriously at the v2 fork of
> u-boot: how does the v2 fork handle this? Better? Since the v2 fork
> uses (or is close to) the linux driver model, I would expect it to be
> better.

Right, we use something close to the driver model, so no problem with
that in v2 land. Other than linux, we have per-device parameters.

Example, with a freshly checked out tree:

  rsc at thebe:u-boot-v2$ make sandbox_defconfig
  rsc at thebe:u-boot-v2$ make
  rsc at thebe:u-boot-v2$ ./scripts/ubootenv -s -p 0x10000 examples/environment/ env.bin

That gets you an u-boot-v2 (user mode u-boot) plus the example
environment.

Let's start it:

  rsc at thebe:u-boot-v2-denx$ ./uboot -e env.bin
  add file env.bin()


  U-Boot 2.0.0-rc8-00084-g97568fd (Apr  8 2009 - 21:54:30)

  Board: sandbox
  Malloc space: 0xb761f008 -> 0xb7e1f008 (size  8 MB)
  Open /dev/env0 Function not implemented
  running /env/bin/init...
  not found
  uboot:/

Let's check which devices we have:

  uboot:/ devinfo
  devices:
  |----env0
  |----console0
  |----mem
  |----eth0
  |----filesystem: /
  |----filesystem: /dev

  drivers:
     console
   cfi_flash
         mem
         ram
         rom
      cramfs
       ramfs
       devfs
    hostfile

Let's check what parameters are there:

  uboot:/ devinfo /dev/console0
  base  : 0x00000000
  size  : 0x00000000
  driver: console

  no info available for console0
  Parameters:
            active = ioe

So you can have as many devices as you want, plus each device has parameters
attached to it, so it's completely object oriented, without any global variable
crap.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] Multiple device support -- sorry state :(

[Robert Schwebel]

On Wed, Apr 08, 2009 at 12:25:16PM -0700, ksi at koi8.net wrote:
> On Wed, 8 Apr 2009, Jerry Van Baren wrote:
> 
> > ksi at koi8.net wrote:
> > > OK, this is _NOT_ just multiple I2C adapters... The entire thing is
> > > fundamentally broken.
> > > 
> > > One supposed to have _THE_ device and only this device is somehow
> > supported.
> > > 
> > > Now it is USB. Each and every USB driver exports the same set of
> > functions,
> > > submit_XXX_msg(...) That means there can be one and only one USB
> > device in
> > > the system.
> > 
> > [snip the badly scorched spot ;-)]
> > 
> > > USB keyboard is another grand kludge deserving its own chapter... As
> > of now
> > > one can only switch to it from command line because USB is not even
> > > initialized until do_usb() from cmd_usb.c is called... What if we do
> > NOT
> > > have a serial console at all?
> > 
> > Dumb question because I have not looked seriously at the v2 fork of
> > u-boot:
> > how does the v2 fork handle this?  Better?  Since the v2 fork uses (or
> > is
> > close to) the linux driver model, I would expect it to be better.
> 
> Nothing's changed here...
> 
> And that is _NOT_ just USB, it is everywhere -- I2C, SPI, etc. It is stiff,
> inflexible, everything written in stone and that stone is permanently set in
> concrete.

I suppose you didn't look in the right place. We don't even have support
for i2c and spi in v2 :-)

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] Multiple device support -- sorry state :(

[ksi at koi8.net]

On Wed, 8 Apr 2009, Robert Schwebel wrote:

> On Wed, Apr 08, 2009 at 12:25:16PM -0700, ksi at koi8.net wrote:
> > On Wed, 8 Apr 2009, Jerry Van Baren wrote:
> > 
> > > ksi at koi8.net wrote:
> > > > OK, this is _NOT_ just multiple I2C adapters... The entire thing
> is
> > > > fundamentally broken.
> > > > 
> > > > One supposed to have _THE_ device and only this device is somehow
> > > supported.
> > > > 
> > > > Now it is USB. Each and every USB driver exports the same set of
> > > functions,
> > > > submit_XXX_msg(...) That means there can be one and only one USB
> > > device in
> > > > the system.
> > > 
> > > [snip the badly scorched spot ;-)]
> > > 
> > > > USB keyboard is another grand kludge deserving its own chapter...
> As
> > > of now
> > > > one can only switch to it from command line because USB is not
> even
> > > > initialized until do_usb() from cmd_usb.c is called... What if we
> do
> > > NOT
> > > > have a serial console at all?
> > > 
> > > Dumb question because I have not looked seriously at the v2 fork of
> > > u-boot:
> > > how does the v2 fork handle this?  Better?  Since the v2 fork uses
> (or
> > > is
> > > close to) the linux driver model, I would expect it to be better.
> > 
> > Nothing's changed here...
> > 
> > And that is _NOT_ just USB, it is everywhere -- I2C, SPI, etc. It is
> stiff,
> > inflexible, everything written in stone and that stone is permanently
> set in
> > concrete.
> 
> I suppose you didn't look in the right place. We don't even have support
> for i2c and spi in v2 :-)

Ah, that's that forked one! Sorry, my bad... I thought about the new version
of a legacy one that just shuffled source files to put device drivers under
devices/*...

Can you tell me where it lives to clone the repository? I'd rather give up
on v1 entirely because it is not going anywhere...

Do you have a separate mailing list for v2?

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] Multiple device support -- sorry state :(

[Robert Schwebel]

On Wed, Apr 08, 2009 at 01:18:45PM -0700, ksi at koi8.net wrote:
> > I suppose you didn't look in the right place. We don't even have support
> > for i2c and spi in v2 :-)
>
> Ah, that's that forked one! Sorry, my bad... I thought about the new version
> of a legacy one that just shuffled source files to put device drivers under
> devices/*...
>
> Can you tell me where it lives to clone the repository? I'd rather give up
> on v1 entirely because it is not going anywhere...

git clone git://www.denx.de/git/u-boot-v2

> Do you have a separate mailing list for v2?

No, just use this one. As long as the traffic keeps low, I suppose there
is no need for a separate list. However, it's probably a good idea to
have Sascha on Cc: :-)

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] Multiple device support -- sorry state :(

[ksi at koi8.net]

On Wed, 8 Apr 2009, Robert Schwebel wrote:

> On Wed, Apr 08, 2009 at 01:18:45PM -0700, ksi at koi8.net wrote:
> > > I suppose you didn't look in the right place. We don't even have
> support
> > > for i2c and spi in v2 :-)
> >
> > Ah, that's that forked one! Sorry, my bad... I thought about the new
> version
> > of a legacy one that just shuffled source files to put device drivers
> under
> > devices/*...
> >
> > Can you tell me where it lives to clone the repository? I'd rather
> give up
> > on v1 entirely because it is not going anywhere...
> 
> git clone git://www.denx.de/git/u-boot-v2
> 
> > Do you have a separate mailing list for v2?
> 
> No, just use this one. As long as the traffic keeps low, I suppose there
> is no need for a separate list. However, it's probably a good idea to
> have Sascha on Cc: :-)

OK, thanks. Cloning now :)

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] Multiple device support -- sorry state :(

[ksi at koi8.net]

On Wed, 8 Apr 2009, ksi at koi8.net wrote:

> On Wed, 8 Apr 2009, Robert Schwebel wrote:
> 
> > On Wed, Apr 08, 2009 at 01:18:45PM -0700, ksi at koi8.net wrote:
> > > > I suppose you didn't look in the right place. We don't even have
> > support
> > > > for i2c and spi in v2 :-)
> > >
> > > Ah, that's that forked one! Sorry, my bad... I thought about the new
> > version
> > > of a legacy one that just shuffled source files to put device
> drivers
> > under
> > > devices/*...
> > >
> > > Can you tell me where it lives to clone the repository? I'd rather
> > give up
> > > on v1 entirely because it is not going anywhere...
> > 
> > git clone git://www.denx.de/git/u-boot-v2
> > 
> > > Do you have a separate mailing list for v2?
> > 
> > No, just use this one. As long as the traffic keeps low, I suppose
> there
> > is no need for a separate list. However, it's probably a good idea to
> > have Sascha on Cc: :-)
> 
> OK, thanks. Cloning now :)

OK, got a look at it. Looks promising but it is in very early stage yet... I
wouldn't say in pre-conception stage, but definitely on a very beginning of
the first trimester :)

I have the first prototype of MPC8548E-based big motherboard sitting on my
desk right now and it is in full bringup stage. All the hardware is checked,
bunch of smoked parts replaced and fixed, all clocks are ticking, CPU
fetching etc.

I will definitely join V2 development but for now I'll probably make a huge
set of horrible hacks over V1 to test everything and get my revision 2
started. Then I will be able to work on U-Boot V2 while my revision 2 is
made (schematic rework, re-layout, PCB, missing parts sourcing, assembly
etc.)

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] Multiple device support -- sorry state :(

[Robert Schwebel]

On Wed, Apr 08, 2009 at 02:25:57PM -0700, ksi at koi8.net wrote:
> > OK, thanks. Cloning now :)
> 
> OK, got a look at it. Looks promising but it is in very early stage yet... I
> wouldn't say in pre-conception stage, but definitely on a very beginning of
> the first trimester :)

Well, you are free to send patches. We use it mainly for ARM systems
which happen to be flash based (NAND, NOR), without PCI. So what was
implemented was what we needed. No reason for you not to send us your
favourite and fancy new features :-)

> I have the first prototype of MPC8548E-based big motherboard sitting
> on my desk right now and it is in full bringup stage. All the hardware
> is checked, bunch of smoked parts replaced and fixed, all clocks are
> ticking, CPU fetching etc.
> 
> I will definitely join V2 development but for now I'll probably make a
> huge set of horrible hacks over V1 to test everything and get my
> revision 2 started. Then I will be able to work on U-Boot V2 while my
> revision 2 is made (schematic rework, re-layout, PCB, missing parts
> sourcing, assembly etc.)

Go ahead, we definitely are looking forward to more community
contribution.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[U-Boot] Multiple device support -- sorry state :(

[ksi at koi8.net]

On Wed, 8 Apr 2009, Robert Schwebel wrote:

> On Wed, Apr 08, 2009 at 02:25:57PM -0700, ksi at koi8.net wrote:
> > > OK, thanks. Cloning now :)
> > 
> > OK, got a look at it. Looks promising but it is in very early stage
> yet... I
> > wouldn't say in pre-conception stage, but definitely on a very
> beginning of
> > the first trimester :)
> 
> Well, you are free to send patches. We use it mainly for ARM systems
> which happen to be flash based (NAND, NOR), without PCI. So what was
> implemented was what we needed. No reason for you not to send us your
> favourite and fancy new features :-)

Sure I will :) Ah, ARM, my old love, still remeber that talk -- ldmia,
stmfd... Romantic times, eh...

> > I have the first prototype of MPC8548E-based big motherboard sitting
> > on my desk right now and it is in full bringup stage. All the hardware
> > is checked, bunch of smoked parts replaced and fixed, all clocks are
> > ticking, CPU fetching etc.
> > 
> > I will definitely join V2 development but for now I'll probably make a
> > huge set of horrible hacks over V1 to test everything and get my
> > revision 2 started. Then I will be able to work on U-Boot V2 while my
> > revision 2 is made (schematic rework, re-layout, PCB, missing parts
> > sourcing, assembly etc.)
> 
> Go ahead, we definitely are looking forward to more community
> contribution.

OK, I probably will. V1, IMHO, is beyond repair; I even contemplated forking
off my own...

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************