RE: [U-Boot-Users] Device chaining, anyone interested?
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@denx.de] Sent: Thursday, August 21, 2003 10:02 AM To: Woodruff, Richard Cc: u-boot-users@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
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
participants (2)
-
Detlev Zundel -
Woodruff, Richard