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

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

[ksi at koi8.net]

Hi, everyone.

I wonder if I'm dreaming or the U-Boot is fundamentally broken...

It looks like there is no support for multiple devices of a same kind at
all.

I'm porting U-Boot to my new MPC8548-based board and it pops up
everywhere...

The first case was I2C subsystem that does not provide for several I2C
adapters except rudimentary hacks for fsl_i2c.

Now it is USB. I have 2 OHCI USB controllers on the board, OHCI module in
NXP ISP1563 and OHCI controller in Silicon Motion SM502 MFD. The former is
supported in drivers/usb/usb_ohci.c, the latter is kinda trivial to add,
BUT...

It looks like nobody even considered the case when a board can have several
controllers... Looking at usb_lowlevel_init() I can see it only works for
the first device found, there is absolutely no provision for several
devices. And things are getting even nastier if there are devices of the
same type with different interfaces (e.g. on-SoC USB controller and a PCI
one.)

And this seems to be the case for each and every device type. Am I missing
something or U-Boot is actually flawed in FUNDAMENTAL way and it is time to
start a new one from scratch?

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

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

[Jerry Van Baren]

ksi at koi8.net wrote:
> Hi, everyone.
> 
> I wonder if I'm dreaming or the U-Boot is fundamentally broken...

Well... broken can be a relative term.  I like to think of it as an 
opportunity to stand on the shoulders of giants.  ;-)

> It looks like there is no support for multiple devices of a same kind at
> all.
> 
> I'm porting U-Boot to my new MPC8548-based board and it pops up
> everywhere...
> 
> The first case was I2C subsystem that does not provide for several I2C
> adapters except rudimentary hacks for fsl_i2c.
> 
> Now it is USB. I have 2 OHCI USB controllers on the board, OHCI module in
> NXP ISP1563 and OHCI controller in Silicon Motion SM502 MFD. The former is
> supported in drivers/usb/usb_ohci.c, the latter is kinda trivial to add,
> BUT...
> 
> It looks like nobody even considered the case when a board can have several
> controllers... Looking at usb_lowlevel_init() I can see it only works for
> the first device found, there is absolutely no provision for several
> devices. And things are getting even nastier if there are devices of the
> same type with different interfaces (e.g. on-SoC USB controller and a PCI
> one.)
> 
> And this seems to be the case for each and every device type. Am I missing
> something or U-Boot is actually flawed in FUNDAMENTAL way and it is time to
> start a new one from scratch?

U-Boot started life as a boot loader.  You know, simple.  It has gotten 
more complex over time, but the modus operandi of u-boot is and shall 
remain that.  Simple. (quoting our benevolent dictator, WD)

The counter-question for your application is to challenge what you are 
trying to use u-boot for: do you actually need to use both USB 
controllers (simultaneously or even sequentially) to boot linux?  Do you 
really need to use multiple I2C controllers to boot linux?  Can you 
simplify your system to get linux running without supporting multiple 
USB or I2C adapters?

If you really need multiple adapter support, you are going to have to 
blaze new ground (or build out some hacks into more acceptable levels of 
support).  That is the cost of being the leader.  :-/

The fundamental concept of u-boot isn't to handle all your devices, it 
is to boot linux (or other OS) and use the OS to handle the multiple 
devices.

Best regards,
gvb

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

[ksi at koi8.net]

On Tue, 10 Mar 2009, Jerry Van Baren wrote:

> ksi at koi8.net wrote:
> > Hi, everyone.
> > 
> > I wonder if I'm dreaming or the U-Boot is fundamentally broken...
> 
> Well... broken can be a relative term.  I like to think of it as an
> opportunity to stand on the shoulders of giants.  ;-)

:)

> > It looks like there is no support for multiple devices of a same kind at
> > all.
> > 
> > I'm porting U-Boot to my new MPC8548-based board and it pops up
> > everywhere...
> > 
> > The first case was I2C subsystem that does not provide for several I2C
> > adapters except rudimentary hacks for fsl_i2c.
> > 
> > Now it is USB. I have 2 OHCI USB controllers on the board, OHCI module in
> > NXP ISP1563 and OHCI controller in Silicon Motion SM502 MFD. The former is
> > supported in drivers/usb/usb_ohci.c, the latter is kinda trivial to add,
> > BUT...
> > 
> > It looks like nobody even considered the case when a board can have several
> > controllers... Looking at usb_lowlevel_init() I can see it only works for
> > the first device found, there is absolutely no provision for several
> > devices. And things are getting even nastier if there are devices of the
> > same type with different interfaces (e.g. on-SoC USB controller and a PCI
> > one.)
> > 
> > And this seems to be the case for each and every device type. Am I missing
> > something or U-Boot is actually flawed in FUNDAMENTAL way and it is time to
> > start a new one from scratch?
> 
> U-Boot started life as a boot loader.  You know, simple.  It has gotten more
> complex over time, but the modus operandi of u-boot is and shall remain that.
> Simple. (quoting our benevolent dictator, WD)
> 
> The counter-question for your application is to challenge what you are trying
> to use u-boot for: do you actually need to use both USB controllers
> (simultaneously or even sequentially) to boot linux?  Do you really need to
> use multiple I2C controllers to boot linux?  Can you simplify your system to
> get linux running without supporting multiple USB or I2C adapters?

Yes, I _DO_ need both controllers. There are numerous scenarios for that --
e.g. I can have a keyboard on a slow controller and a storage device or
network adapter on another one. I can have multiple storage devices and want
to choose which to boot from and so on.

> If you really need multiple adapter support, you are going to have to blaze
> new ground (or build out some hacks into more acceptable levels of support).
> That is the cost of being the leader.  :-/

Thanks, I already tried this for I2C... Now it is a hack (separate driver
and core) in my $(BOARD) directory. USB is next, then I have additional
serial ports...

> The fundamental concept of u-boot isn't to handle all your devices, it is to
> boot linux (or other OS) and use the OS to handle the multiple devices.

The same is true for a PC BIOS, but it DOES handle all of my devices. And it
allows me to choose which device to boot from. And it is extendable so I can
add a PCI card with e.g. RAID controller and boot off of that RAID. And it
is not handling of all devices, it is _BASIC_ functionality...

I don't mind reconfiguring and rebuilding the thing for my parcticular
configuration instead of just changing some settings in interactive setup
utility, but the current implementation won't allow even that...

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

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

[Detlev Zundel]

Hi ksi (was it Sergei?),

>> The fundamental concept of u-boot isn't to handle all your devices, it is to
>> boot linux (or other OS) and use the OS to handle the multiple devices.
>
> The same is true for a PC BIOS, but it DOES handle all of my devices. And it
> allows me to choose which device to boot from. And it is extendable so I can
> add a PCI card with e.g. RAID controller and boot off of that RAID. And it
> is not handling of all devices, it is _BASIC_ functionality...

Actually I don't know what you're talking about in the PC BIOS area
here.  Usually the computers I own cannot boot from the devices that are
bought somewhat after the motherboard.  But maybe you have different
instances of computers...

> I don't mind reconfiguring and rebuilding the thing for my parcticular
> configuration instead of just changing some settings in interactive setup
> utility, but the current implementation won't allow even that...

Actually we are thinking about "going generic" here also for a while
already.  Look for example at the BOF session notes of OLS 2007[1]
"Device Tree Run Time Configuration".

We are all aware that a "proper" device model will be needed at a
certain stage, only nobody started into that direction yet.

As Jerry pointed out - booting embedded hardware used to be a comparably
simple operation ;)

Cheers
  Detlev

[1] http://www.denx.de/wiki/view/U-Boot/OLSUbootBOF

-- 
... that every year or so they're going to give you a new release full
of 50 000  additional lines of code all  written  by monkeys.  Because
they generally follow  the  ``million monkeys typing,   and eventually
they'll come up with something useful'' school of system development.
	                                    -- Richard M. Stallman
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

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

[ksi at koi8.net]

On Thu, 12 Mar 2009, Detlev Zundel wrote:

> Hi ksi (was it Sergei?),
> 
> >> The fundamental concept of u-boot isn't to handle all your devices, it is to
> >> boot linux (or other OS) and use the OS to handle the multiple devices.
> >
> > The same is true for a PC BIOS, but it DOES handle all of my devices. And it
> > allows me to choose which device to boot from. And it is extendable so I can
> > add a PCI card with e.g. RAID controller and boot off of that RAID. And it
> > is not handling of all devices, it is _BASIC_ functionality...
> 
> Actually I don't know what you're talking about in the PC BIOS area
> here.  Usually the computers I own cannot boot from the devices that are
> bought somewhat after the motherboard.  But maybe you have different
> instances of computers...

First of all, there are several bootable devices on a motherboard itself.
These days almost every motherboard has PATA and some kind of SATA RAID
controller onboard. Then, it can usually boot off of USB while having USB
keyboard/mouse. As for add-on devices, it usually CAN boot off of those
devices. They have their own BIOS for that that gets attached to the
motherboard's one when it initializes and those devices are added to the
boot table.

> > I don't mind reconfiguring and rebuilding the thing for my parcticular
> > configuration instead of just changing some settings in interactive setup
> > utility, but the current implementation won't allow even that...
> 
> Actually we are thinking about "going generic" here also for a while
> already.  Look for example at the BOF session notes of OLS 2007[1]
> "Device Tree Run Time Configuration".
> 
> We are all aware that a "proper" device model will be needed at a
> certain stage, only nobody started into that direction yet.
> 
> As Jerry pointed out - booting embedded hardware used to be a comparably
> simple operation ;)

There is a whole world beyond that keyhole... Embedded devices yes, but
there are other boards that don't fall in that category. My current MPC8548
based board is not an embedded one, it is full-blown mATX motherboard with
several USB controllers, PATA, SATA, Video Capture, VGA/LCD controller,
PCI-X/PCI/PCIe connectors 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 - none at all?

[Detlev Zundel]

Hello ksi (so I'll leave it at that),

> First of all, there are several bootable devices on a motherboard itself.
> These days almost every motherboard has PATA and some kind of SATA RAID
> controller onboard. Then, it can usually boot off of USB while having USB
> keyboard/mouse. As for add-on devices, it usually CAN boot off of those
> devices. They have their own BIOS for that that gets attached to the
> motherboard's one when it initializes and those devices are added to the
> boot table.

It may come as a surprise to you, but I actually also use such system :)

What I wanted to say is that your blatant "it allows me to choose from
which device to boot from" does not coincide with my experiences in real
life.  Moreover what you call "to boot from" is in the BIOS world the
transfer of usually one block followed by a jump.  I have yet to see a
BIOS booting Linux in a flexible way.  This is hardly comparably to the
support (just think filesystems) that we have for ages in U-Boot.  

But actually I think that this is not news to most people on the ML so
I'll stop here.

>> As Jerry pointed out - booting embedded hardware used to be a comparably
>> simple operation ;)
>
> There is a whole world beyond that keyhole... Embedded devices yes, but
> there are other boards that don't fall in that category. My current MPC8548
> based board is not an embedded one, it is full-blown mATX motherboard with
> several USB controllers, PATA, SATA, Video Capture, VGA/LCD controller,
> PCI-X/PCI/PCIe connectors etc.

Yes, and again, you may notice that U-Boot was meant for "embedded
devices" so the "impedance mismatch" you now realize for "full-blown
motherboards" was kind of to be expected...

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

Miracles in 24 hours?  Ok, I'm looking forward to a device model
implementation tomorrow evening then ;)

Cheers
  Detlev

-- 
Windows Vista? And what a vista! All you see as you look around your
garden is a 60foot high brick wall -- Crosbie Fitch.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

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

[ksi at koi8.net]

On Thu, 12 Mar 2009, Detlev Zundel wrote:

> Hello ksi (so I'll leave it at that),
> 
> > First of all, there are several bootable devices on a motherboard itself.
> > These days almost every motherboard has PATA and some kind of SATA RAID
> > controller onboard. Then, it can usually boot off of USB while having USB
> > keyboard/mouse. As for add-on devices, it usually CAN boot off of those
> > devices. They have their own BIOS for that that gets attached to the
> > motherboard's one when it initializes and those devices are added to the
> > boot table.
> 
> It may come as a surprise to you, but I actually also use such system :)
> 
> What I wanted to say is that your blatant "it allows me to choose from
> which device to boot from" does not coincide with my experiences in real
> life.  Moreover what you call "to boot from" is in the BIOS world the
> transfer of usually one block followed by a jump.  I have yet to see a
> BIOS booting Linux in a flexible way.  This is hardly comparably to the
> support (just think filesystems) that we have for ages in U-Boot.  

Yes, that's great, but that filesystem _MUST_ reside on a device connected
to _ONE_ particular controller. And it becomes even more complicated if you
have a keyboard (or console) on USB...

> But actually I think that this is not news to most people on the ML so
> I'll stop here.
> 
> >> As Jerry pointed out - booting embedded hardware used to be a comparably
> >> simple operation ;)
> >
> > There is a whole world beyond that keyhole... Embedded devices yes, but
> > there are other boards that don't fall in that category. My current MPC8548
> > based board is not an embedded one, it is full-blown mATX motherboard with
> > several USB controllers, PATA, SATA, Video Capture, VGA/LCD controller,
> > PCI-X/PCI/PCIe connectors etc.
> 
> Yes, and again, you may notice that U-Boot was meant for "embedded
> devices" so the "impedance mismatch" you now realize for "full-blown
> motherboards" was kind of to be expected...

It is supposed to be a "Universal" bootloader. Here is what wiki says:

=== Cut ===
Das U-Boot (Universal Bootloader, short for "Das Unterseeboot", German for
"the submarine") is a boot loader for a number of different computer
architectures, including PPC, ARM, AVR32, MIPS, x86, 68k, Nios, and
MicroBlaze. 
=== Cut ===

I'm not even talking about using several USB/I2C/SPI/Serial/whatever devices
concurently; it is only about being able to pick one of several at run
time...

That is actually not sufficient because we have one device that must be
enabled at all times -- the console. That means we must have one USB
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.

> > ******************************************************************
> > *  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
> > *  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
> > ******************************************************************
> 
> Miracles in 24 hours?  Ok, I'm looking forward to a device model
> implementation tomorrow evening then ;)

Eh, I did offer such a model for I2C :) And that model can be extended to
anything else. That is what I'm actually implementing for my new board. But
that goes into $(BOARD)/* because I simply don't have time for pushing it
into the U-Boot proper. I wasted 2+ weeks for I2C without any result (that
is not counting another couple of weeks I spent on that before starting
sending patches to the list.)

The model can be really simple. Just use an array of structures with
function pointers to several adapter drivers and make a simple wrapper
calling an appropriate function depending on device chosen (i.e. "current"
device.) Don't call all e.g. USB adapter submit message functions
"submit_XXX_msg" and link that only one that is chosen at compile time and
exported. Make them e.g. "adapter_submit_XXX_msg" instead, then do something
like this:

=== Cut ===
	Header file:
.
.
.
typedef struct usb_functions_mux {
        int     (*submit_bulk_msg)(struct usb_device *dev,
                                        unsigned long pipe,
                                        void *buffer,
                                        int transfer_len);
        int     (*sumbit_control_msg)(struct usb_device *dev,
                                        unsigned long pipe,
                                        void *buffer,
                                        int transfer_len,
                                        struct devrequest *setup);
        int     (*submit_int_msg)(struct usb_device *dev,
                                        unsigned long pipe,
                                        void *buffer,
                                        int transfer_len,
                                        int interval);
        void    (*usb_event_poll)(void);
        int     (*usb_lowlevel_init)(void);
        int     (*usb_lowlevel_stop)(void);

        char    *name;
        int     inited;
} usb_func_t;
.
.
.

	USB adapter driver:
.
.
.
usb_func_t      sm501_usb_func {
        .submit_bulk_msg        =       sm501_submit_bulk_msg;
        .submit_control_msg     =       sm501_submit_control_msg;
        .submit_int_msg         =       sm501_submit_int_msg;
        .usb_event_poll         =       sm501_usb_event_poll;
        .usb_lowlevel_init      =       sm501_usb_lowlevel_init;
        .usb_lowlevel_stop      =       sm501_usb_lowlevel_stop;
        .name                   =       "SM501_OHCI"
        .inited                 =       0;
}
.
.
.


	USB wrapper:
.
.
.
extern usb_func_t       sm501_usb_func;
extern usb_func_t       isp1563_usb_func;

static usb_func_t *usb_func[] = {
        &sm501_usb_func,
        &isp1563_usb_func,
};

int     cur_usb_adap = 0;
.
.
.
int submit_bulk_msg(struct usb_device *dev,
                                unsigned long pipe,
                                void *buffer,
                                int transfer_len)
{
	return usb_func[cur_usb_adap]->submit_bulk_msg(dev,
							pipe,
							buffer,
							transfer_len);
}
.
.
.
=== Cut ===

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

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

[Wolfgang Denk]

Dear ksi at koi8.net,

In message <Pine.LNX.4.64ksi.0903121033170.8624@home-gw.koi8.net> you wrote:
> 
> It is supposed to be a "Universal" bootloader. Here is what wiki says:

There is a certain difference between "universal" and "omnipotent".
Note that it's called "U-Boot", not "O-Boot".

> === Cut ===
> Das U-Boot (Universal Bootloader, short for "Das Unterseeboot", German for
> "the submarine") is a boot loader for a number of different computer
> architectures, including PPC, ARM, AVR32, MIPS, x86, 68k, Nios, and
> MicroBlaze. 
> === Cut ===

And this is 100% correct, isn't it?

> I'm not even talking about using several USB/I2C/SPI/Serial/whatever devices
> concurently; it is only about being able to pick one of several at run
> time...

You seem to be the first to express such a requirement. And U-Boot
provides you with all the means (free software etc.) that enables you
to extend it and to add such a feature.

U-Boot never claimed to provide a turnkey solution for any obscure
requirement.

> That is actually not sufficient because we have one device that must be
> enabled at all times -- the console. That means we must have one USB

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.

> 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.

> Eh, I did offer such a model for I2C :) And that model can be extended to

We might come bck on this after the next release is out. Heiko has all
your stuff in his repository. And some more.

> into the U-Boot proper. I wasted 2+ weeks for I2C without any result (that
> is not counting another couple of weeks I spent on that before starting
> sending patches to the list.)

It's a pity when you consider discussion the principle parts of a new
design wasted time. 

As such, I wonder why you waste time for the messages in this current
thread.

> The model can be really simple. Just use an array of structures with
> function pointers to several adapter drivers and make a simple wrapper
> calling an appropriate function depending on device chosen (i.e. "current"
> device.) Don't call all e.g. USB adapter submit message functions
> "submit_XXX_msg" and link that only one that is chosen at compile time and
> exported. Make them e.g. "adapter_submit_XXX_msg" instead, then do something
> like this:

Submit a patch? Then we can see the code, the size impact, etc. 

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
The human race is a race of cowards; and I am not  only  marching  in
that procession but carrying a banner.                   - Mark Twain

[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.0903121033170.8624@home-gw.koi8.net> you wrote:
> > 
> > It is supposed to be a "Universal" bootloader. Here is what wiki says:
> 
> There is a certain difference between "universal" and "omnipotent".
> Note that it's called "U-Boot", not "O-Boot".

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.

> > === Cut ===
> > Das U-Boot (Universal Bootloader, short for "Das Unterseeboot", German for
> > "the submarine") is a boot loader for a number of different computer
> > architectures, including PPC, ARM, AVR32, MIPS, x86, 68k, Nios, and
> > MicroBlaze. 
> > === Cut ===
> 
> And this is 100% correct, isn't it?

Yes. It is truth, only truth and nothing but truth. But it is not the entire
truth :)

There is no "embedded" here...

> > I'm not even talking about using several USB/I2C/SPI/Serial/whatever devices
> > concurently; it is only about being able to pick one of several at run
> > time...
> 
> You seem to be the first to express such a requirement. And U-Boot
> provides you with all the means (free software etc.) that enables you
> to extend it and to add such a feature.
> 
> U-Boot never claimed to provide a turnkey solution for any obscure
> requirement.

It is not obscure. E.g. ISP1563 PCI USB controller (that is somehow
supported with drivers/usb/usb_ohci.c) has 3 devices, not one. They are 2
OHCI and 1 EHCI controllers. For EHCI, that allows for all 4 ports (but HS
only, will not work with e.g. USB keyboard) we do _NOT_ have any support;
drivers/usb/usb_ehci_pci.c is just a stub that does _NOT_ support _ANY_ EHCI
controller. What we are left with is _TWO_ OHCI controllers, each serving 2
ports (odd for one controller and even for another one.)

Our existing driver only supports _ONE_ controller. That means not just we
are not able to use HS USB 2.0 at all having to stick with USB 1.1 but also
that we must use 2 specific ports out of available 4 because only one OHCI
controller is detected and supported.

That _MIGHT_ be not an issue for an embedded board where everything is
hardwired and we _DO_ know where anything is connected to but it _IS_ an
issue for a regular motherboard with something like 6 or 8 USB connectors on
it's back panel. All USB are born equal, aren't they?

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.

> > That is actually not sufficient because we have one device that must be
> > enabled at all times -- the console. That means we must have one USB
> 
> 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...

> > 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.

> > Eh, I did offer such a model for I2C :) And that model can be extended to
> 
> We might come bck on this after the next release is out. Heiko has all
> your stuff in his repository. And some more.
> 
> > into the U-Boot proper. I wasted 2+ weeks for I2C without any result (that
> > is not counting another couple of weeks I spent on that before starting
> > sending patches to the list.)
> 
> It's a pity when you consider discussion the principle parts of a new
> design wasted time. 
> 
> 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...

> > The model can be really simple. Just use an array of structures with
> > function pointers to several adapter drivers and make a simple wrapper
> > calling an appropriate function depending on device chosen (i.e. "current"
> > device.) Don't call all e.g. USB adapter submit message functions
> > "submit_XXX_msg" and link that only one that is chosen at compile time and
> > exported. Make them e.g. "adapter_submit_XXX_msg" instead, then do something
> > like this:
> 
> 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.

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

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

[Wolfgang Denk]

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

[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@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.   *
******************************************************************

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

[Heiko Schocher]

Hello ksi,

ksi at koi8.net wrote:
[...]
> Eh, I did offer such a model for I2C :) And that model can be extended to
> anything else. That is what I'm actually implementing for my new board. But
> that goes into $(BOARD)/* because I simply don't have time for pushing it
> into the U-Boot proper. I wasted 2+ weeks for I2C without any result (that
>   

You wasted? You told us you get money for it ... We didn;t, so what would we
say?

BTW: I have ready 2 new branches in the I2C git. One with exactly your
patches, and one with the suggestions by wolfgang and me. I think, when
v2009.03 is released I can make them public, and we can discuss them
objective (because we have now 2 versions which we can compare, so
no arguments must come from the sky ;-) again ...

> is not counting another couple of weeks I spent on that before starting
> sending patches to the list.)
>   

When you want to get this in mainline, maybe next time you first ask
before spending "couple of weeks" for it?

bye
Heiko

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany 

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

[Heiko Schocher]

Hello ksi,

ksi at koi8.net wrote:
> On Thu, 12 Mar 2009, Wolfgang Denk wrote:
>
>   
>> Dear ksi at koi8.net,
>>
>> In message <Pine.LNX.4.64ksi.0903121203270.8874@home-gw.koi8.net> you wrote:
>>     
[...]
>>> 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
>   

That was the problem, you didn;t tried my code ... you just trusted your
theory.

> 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.
>   

Maybe there are more than one good theory?

> Numerous experiments in the dark is not an effective way to do things. It
>   

I really don;t want to start this discussion here again, before v2009.03 is
released, but we did such an analysis, and I posted patches for example
how we can do the bitbang driver in another way. You just ignored it. If
you did a analysis of the code I posted, you would have seen that for the
bitbang driver our sourcecode changes were minimal, and resulting
codesize is smaller than in your approach. But please, starting with
this discussion when code is public ...

bye
Heiko

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany