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