[U-Boot-Users] Device chaining, anyone interested?

[U-Boot-Users] Device chaining, anyone interested?

[Woodruff, Richard]

Hello,
 
We are in the process of putting together some POST/diagnostic type code for
our OMAP u-boot board.  We have modified the device lists for input/output
such that it will chain to several devices.... ex: can input data at a
serial keyboard OR at the keypad OR at the touchscreen and it will output to
the serial console AND the LCD console (and potentially a USB-client serial
console).  This is all very handy for what we are doing, but I'm not sure if
its something which the generic u-boot code wants (Wolfgang?).  Its been put
together with the standard list functions and such so its not a great
departure in code.
 
Regards,
 
Richard Woodruff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20030820/6a4c8ee8/attachment.htm 

[U-Boot-Users] Device chaining, anyone interested?

[Detlev Zundel]

Hello Richard,

> We are in the process of putting together some POST/diagnostic type
> code for our OMAP u-boot board.?

If you are doing work on POST stuff, I hope that you are aware of the
POST framework which is used only on the PowerPC branch right now.
It'll be great if any effort in this direction could be merged under
this framework.

> We have modified the device lists for input/output such that it will
> chain to several devices.... ex: can input data at a serial keyboard
> OR at the keypad OR at the touchscreen and it will output to the
> serial console AND the LCD console (and potentially a USB-client
> serial console).? This is all very handy for what we are doing, but
> I'm not sure if its something which the generic u-boot code wants
> (Wolfgang?).? Its been put together with the standard list functions
> and such so its not a great departure in code.

I cannot speak for Wolfgang, who is on holidays by the way, but in my
opinion it is a worthwhile effort.  What comes to my mind immediately
is to chain some output device the user can see and the logbuffer
device which is available under Linux after the kernel has taken
control.  So please go ahead and post the patches here.

Cheers
  Detlev

-- 
Emacs is the way to purify your soul using garbage collection.

[U-Boot-Users] Device chaining, anyone interested?

[Woodruff, Richard]

I looked at the POST code and it seemed "so" PPC centric that I was thinking
it would be faster to make a parallel type directory.  I had written a bunch
of tests for another compiler/loader and am starting to port them over.

Actually, I was considering using the new "standalone" code model as a way
to call the tests.  This way they could be more decoupled from the actually
u-boot code itself.

The device chaining seems to be working for us, it pretty much implements a
list of devices which are called in order with heads being stdin/out/error.
The person who did the work this week did seem to indicate that the
deregister stuff that was there wasn't done very well.

Regards,

Richard W.

-----Original Message-----
From: Detlev Zundel [mailto:dzu at denx.de] 
Sent: Thursday, August 21, 2003 10:02 AM
To: Woodruff, Richard
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Device chaining, anyone interested?

Hello Richard,

> We are in the process of putting together some POST/diagnostic type
> code for our OMAP u-boot board.?

If you are doing work on POST stuff, I hope that you are aware of the
POST framework which is used only on the PowerPC branch right now.
It'll be great if any effort in this direction could be merged under
this framework.

> We have modified the device lists for input/output such that it will
> chain to several devices.... ex: can input data at a serial keyboard
> OR at the keypad OR at the touchscreen and it will output to the
> serial console AND the LCD console (and potentially a USB-client
> serial console).? This is all very handy for what we are doing, but
> I'm not sure if its something which the generic u-boot code wants
> (Wolfgang?).? Its been put together with the standard list functions
> and such so its not a great departure in code.

I cannot speak for Wolfgang, who is on holidays by the way, but in my
opinion it is a worthwhile effort.  What comes to my mind immediately
is to chain some output device the user can see and the logbuffer
device which is available under Linux after the kernel has taken
control.  So please go ahead and post the patches here.

Cheers
  Detlev

-- 
Emacs is the way to purify your soul using garbage collection.

[U-Boot-Users] Device chaining, anyone interested?

[Detlev Zundel]

Hello Richard,

> I looked at the POST code and it seemed "so" PPC centric that I was thinking
> it would be faster to make a parallel type directory.  I had written a bunch
> of tests for another compiler/loader and am starting to port them over.
> 
> Actually, I was considering using the new "standalone" code model as a way
> to call the tests.  This way they could be more decoupled from the actually
> u-boot code itself.

Yes, the POST code _is_ PPC centric due to the customer who wanted
it.  It would _still_ be nice to make an effort and integrate new CPUs
into this framework pointing out the weaknesses in the current
framework so it will be easier to merge in more arch specific stuff
later on.

It seems like a waste to me to write e.g. RAM tests for every arch
when the code _already_ in the POST is a very thorough test which
should be usable by other architectures as well.  I am sure that if
the POST framework was made ready for other architectures, everyone
will win in the end.

Note that there is already the concept of "slow" and "fast" POST tests
meant for daily usage aiming at fast boot speeds and trouble-shooting
usage for thorough testing of the hardware.  Concepts like this are
sure to crop up for every CPU so why not solve them in a common way?

> The device chaining seems to be working for us, it pretty much
> implements a list of devices which are called in order with heads
> being stdin/out/error.  The person who did the work this week did
> seem to indicate that the deregister stuff that was there wasn't
> done very well.

I guess this is because there are no real users of the de-registering
code.  To borrow an often read statement from Wolfgang:

FFTSAP (Feel Free To Submit A Patch) ;)

Cheers
  Detlev

-- 
You live and learn