On 07/13/11 22:25, Pete Batard wrote:
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.
But that is the point. Your support is not universal and unlimited broadband is not unlimited and should not be described as such. I object to the use of an absolute description to refer to something that is not absolute.
I guess if you would prefer an asterisk after the Universal in UBRX, with a "Terms and Conditions apply", this can be arranged... ;)
I would prefer it not be described as universal at all.
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 will not argue over made up statistics.
...
Nor will I argue a strawman.
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.
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.
!!! Of course you are welcome to come to this list with incomplete ideas. I was trying to work with you to improve it. I object to your claim of universal support, not your aim of supporting as much as possible. I do not want your description to set up false expectations. I see no request in that to go away until your support is complete and spotless. That comes only from your desire to make your idea live up to the description you chose.
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".
Not at all. The pre-knowledge of the hardware required is just how to get to the UART. It is very, very far from requiring existing coreboot support. You do not need to know how to set up memory, you do not need to know how the interrupts are configured, you do not need to know what PCI/PCIe devices there are, etc. etc. which are all things needed for coreboot. So no you are not limited to platforms that coreboot already supports.
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.
You are confrontational and you are arguing points that I do not hold and this I think is due to a misunderstanding of 'hardware agnostic'.
All I was saying is that use of internal hardware implies pre-knowledge of that hardware and that is included into the build. My suggestion of being able to configure the use of a different SIO or allowing easy insertion of motherboard specific GPIO settings is on the same level of pre-knowledge as is required to use internal hardware. I never suggested that any knowledge was out of bounds. 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, 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.
I did not ask for support for these to be implemented by you, merely a framework that would allow them to be supported without having to make in depth changes to the core support.
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.
I think we may even both be able to agree that this is a good idea.
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.
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.
Well your plan requires two motherboards plus a development system. The first with an existing coreboot image with working panic room. The second using a compatible BIOS flash chip. You start by removing the BIOS chip, containing the coreboot image with panic room, from a working board, rendering it useless. Then you swap in that BIOS flash chip onto the second board and hope that the panic room still works and will give you a console accessible from your development system. What if it does not work? You have no way forward.
However if you allow the soldering of a socket (the same soldering skill needed as swapping a chip) you can do the following. One motherboard can act as your development system and as your flashing tool by doing a hot flash for the other. You do not need an existing coreboot support for either and you are not left with a useless motherboard. The cost of two sockets should be a lot less than another motherboard and no external flasher is needed.
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.
You guess wrong. The question is how much complexity do we want for little or no discernible gain? Of course using it for new systems would be a good thing and my suggestions in no way prevent that.
Andrew