On 2011.07.13 12:03, Andrew Goodbody wrote:
I'll start with the aside, that if "failing" means instantly supporting more than 90% of Intel based motherboards produced in the last 10 years
Yes, universal means everything. If you do not support everything then it is not universal. The use of universal sets false expectations.
In that case, "unlimited broadband" means truly unlimited, and fair expectations are not supposed to be applied to the claim. I guess if you would prefer an asterisk after the Universal in UBRX, with a "Terms and Conditions apply", this can be arranged... ;)
This being said, the 90% with regards to Intel chipsets applies to the *PoC* (guesstimate obviously, but I think I'm probably pessimistic when only those weird ITE init and non PnP Super I/Os are expected to fail detection, which I doubt many of the ICH motherboard from the last 10 years would have). The final version could be a lot closer to the 100% mark, especially if we attempt detect both native UART and USB 3.0 debug, as legacy free hardware, which I suppose is expected to have PCI-E, would just need an xHCI PCI-E card we can detect to get going.
I also don't think the idea of dropping support for non PnP SIO chips detracts from the claim of Universality(*) that much. A comparison would be to claim that Windows software released in 2011 does not actually qualify as being "Windows compatible" or put Windows on the box if it doesn't support Windows 98 (And, just like Windows software comes with a "minimum system requirements", our Readme comes with about the same thing in the form of current UBRX limitations). My understanding is that most manufacturers would have switched to PnP SIOs around '98 as well, so the Windows 98 comparison seems appropriate.
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.
At least I am hoping that it is OK to come to this list, with something that is still incomplete, to see if there is interest, and not being requested to come back with a solution that is feature complete and spotless.
Yes we see different priorities for a panic room, but I think you misunderstood how much knowledge of the platform I was suggesting needed to be configured.
OK, that's probably fair.
To me a panic room should be as simple and bullet proof as possible and if that means pre-configuring the build then so be it.
The problem I have with pre-configured is you need to have prior knowledge. So in effect, your panic room would be restricted to only platforms that coreboot already supports, which, to mirror your "unnecessary complication" below, I would see as an "unnecessary limitation".
Being 'hardware agnostic' helps in putting it on a new platform, assuming that platform conforms to the restrictions, but it does not help in actual operation of the panic room. So to me that would be an unnecessary complication. Your example of a panic room ondie with a UART is not hardware agnostic at all, you have pre-knowledge of the critical elements for establishing a console.
Call me confrontational, but I am going to dispute the "not hardware agnostic at all".
If AMD and Intel agreed tomorrow to provide an UART ondie, accessed in the same fashion, on all of their future x86 chips, should we consider that this knowledge should be out of bounds? Or how about FPUs? Older x86 CPUs did not have an FPU unit ondie. Should we then consider that a program that just uses the FPU, since it has been for about the past 20 years, and no external hardware, can not be considered hardware agnostic and should have performed FPU detection?
To me there is such thing as internal hardware, which is 100% fair game to use as soon as it is introduced, as, in the worst case scenario, it can easily be detected from the public CPU specs, and external hardware, which, and this is the critical point, may include elements that have not even been designed yet. So I would say that a panic room ondie with an UART, if all CPUs from the same line have this feature, is hardware agnostic. But then again, whether hardware agnosticism applies to a CPU that is irrelevant to coreboot doesn't bring much to the discussion.
OK, well how about the SIO support from UBRX being one of the SIO modules that can be chosen. My main concern is allowing a simple method of getting panic room support to work on boards that do not meet your restrictions.
That's one of my concerns too.
As I indicated above, I am not planning to spend much time on getting non PnP SIOs, or PnP SIOs that require some weird init to be supported by UBRX.
This being said, UBRX does support the VMWare virtual SIO, which is not PnP, and I think your idea about trying to be modular in UBRX is a good one. I can probably create a separate module for the VMWare non PnP SIO, which could be used as a template for other SIOs that people want to see supported, and that may not be detected in UBRX main. Such modules could then be selected and included conditionally at buildtime. 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.
With this, unconditional universality may actually apply to UBRX after all (though some may claim that if everything isn't supported at the same time, it's still not universal)... ;)
Superiotool, not so much... Also picking a coreboot BIOS from one machine and soldering it into another, with the expectation that even if the motherboards have nothing in common but the flash they use, panic-room access will be available, can have its advantages, be it only for ghetto-style budget-constrained tinkerers.
Shudders! Do we really want to encourage that?
I most certainly see some merit in that for the following reasons: One is the consideration that people who may have a lot of time on their end may not be the ones with the highest means of income, and coreboot could probably use people with a time on their hand to support new motherboards. The second reason is that there are an awful lot of proprietary systems out there with soldered (non SPI) flash chips (Dell, Compaq, etc...), that could really benefit from coreboot. Past their prime, these systems can be obtained fairly cheaply, from corporate sales, etc., and therefore are a good target for coreboot development. However, when the first step of coreboot development is to install a BIOS socket as well as get an external flasher, this is likely to put potential contributors off. On the other hand, while there is obviously a risk that the U(*)BRX panic-room may not work, there's a good chance that it will and thus provide developers with both the possibility to explore their hardware and test a coreboot development payload.
So I guess the question is: do we want a panic-room that only applies to systems that coreboot already support? Or do we want it to also be used as a tool for the adding of new systems. If only the former, then U(*)BRX is likely an overkill. But even a panic-room seems a bit of an overkill to me, as all you probably want from it is flash recovery...
Regards,
/Pete
(*) Terms and Conditions apply