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
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
