On 2011.07.14 11:59, Andrew Goodbody wrote:
I object to the use of an absolute description to refer to something that is not absolute.
I would prefer it not be described as universal at all.
Point taken.
Believe me, I'd really like to keep you happy and change the U to something like "Useful" instead of "Universal" (though I guess even "Useful" could not be used in the absolute, since people may say UBRX isn't useful to them), and I almost went ahead with that... But on second thoughts, I really don't see why UBRX should lack the punch that both USB or U-boot have, through their use of "Universal", especially when our aspirations are exactly the same (the choice of the UBRX acronym was partially inspired by U-boot).
Arguably, the Universal in USB does not apply to the protocol itself, since a protocol is of course universal between all entities that that speak it (RS232 is universal too), so the scope of Universal in USB has to be with regards of its intended reach, just as is the case with U-boot. And clearly both USB and U-boot are abusing the Universal in their name then, since I don't see how they too can qualify as absolute universal (unless one acquires the right to use universal only once they are successful enough).
If you want to say it's a misnomer or abuse, you are of course technically correct, so I'm not going to dispute that. But I wouldn't mind having people be drawn to a project because they see that its aspiration is to provide something that is as universal as can be, just like USB and U-boot, than a project whose name is factually correct, but which may leave newcomers with some doubt about what its intended target reach is.
If people want a specific target supported, that UBRX does not support, then, resources permitting (and provided there is interest in UBRX, which remains to be seen), I'll do my best to get it supported. I'm currently not aware of any board that we shouldn't technically be able to support: Unless they are crazy fast, we should be able to disable watchdogs from automating the upload of a panic-room payload, so we are unlikely to need a special case for that. Dual BIOS is more of an issue, but the main problem is that we don't have data on Dual BIOS, and nobody seems to have reverse engineered much of it. So the only big unknown I have is with regards to the powering up of LDs, as well as any extra chipset initialization, such as the 48 MHz clock init from SB800, that I may have missed. Thus, the target of being universal is more likely to be constrained by resources than by technical feasibility.
If U-boot can use Universal, I think I'm going to follow suit, while agreeing with you that the Universal from UBRX is unlikely to ever be absolute.
Finally, please remember that this is only a PoC, which is expected to be incomplete or, gasp, have bugs (still working on it). Most of the limitations or problems currently applying, can either be lifted or worked around one way or another. However, there is only so much I can test so yes, in its current instance, U(*)BRX does fall short of its established goal of Universality(*). However, I'm not seeing a major reason why it couldn't get there, hence the claim.
And so increase complexity and reducing reliability.
Or prevent misconfiguration errors, ensure that most of the code (since much of it would be common/factorized) has been tested by a greater number of people, and increase reliability and reach.
I was suggesting being able to build knowledge into a specific build of the panic room in order to reduce complexity and so get closer to your aim of universal support.
OK. There actually is some of that in the latest version.
But I do see the need for blanket detection being the main focus, if we can easily perform it and it avoids being limited to only what we know.
Yes, but not at the cost of excessive complexity and reduced reliability.
I'm not seeing the reliability being reduced that much. The more universal something is to use (i.e. the less configuration is required) the greater the reach and thus the greater testing and reliability. I could talk about USB/HID vs PS/2 for reliability, for low bandwidth devices (keyboards/mice) but you'll likely dismiss this as a straw man.
I'm also assuming that you anticipate a series of special cases, when talking about "excessive complexity", where, on the other hand, I anticipate factorization, since I have seen a good chunk of it already (unless I misread the datasheet, the intel ICH/SIO init, for all ICHs, factorizes amazingly well).
And while I'm talking about factorization, since I went through most of the early_serial.c sources from coreboot, it looks like much of the code there could be factorized. Or at least some harmonization could benefit some of the SIO inits. I would even venture to say that, from not duplicating/factorizing existing tried and tested code, there likely exists reduced reliability in the coreboot early_serial sources.
Well your plan requires two motherboards plus a development system.
Not at all.
Only one motherboard and a development system, which is what most people would have. I talked earlier about picking one chip from one system to put it onto another, but that was in a different scope.
Use flashrom to flash the BIOS, with only an UBRX bootblock, and you (should) now have access to a panic-room, which you can use to explore the hardware, test a section of your dev BIOS, reflash, etc, provided the relevant panic-room payloads are available, which isn't UBRX's scope...
Total investment: one null-modem cable. Especially, no need for a second motherboard, a second flash ROM or even a flash socket. And with USB 2.0 debug cables being $95 a piece (at least USB 3.0 should be better in that aspect), even if coreboot decides on an EHCI/xHCI USB debug only route for its panic-room, UBRX would still have the economical edge for most boards.
What if it does not work? You have no way forward.
If it does not work, then, and only then, you unsolder the chip, invest in an external programmer (or second mobo), and add a socket... which is what coreboot development, for the boards we are talking about, currently requires.
But at least, you have been given a fair chance to avoid having to do any of that...
Regards,
/Pete