[coreboot] Implementing or not implementing hacks for the OS (was: Change in coreboot[master]: ck804: hide IOAPIC base address in PCI_BASE_ADDRESS_1)

[Paul Menzel]

Dear coreboot folks,


Ron, let’s bring this up on the list for broader audience and easier
discussion by email.

Jonathan’s patch set »ck804: hide IOAPIC base address in
PCI_BASE_ADDRESS_1« [1] does the following.

        Linux unhelpfully "fixes" the value in PCI_BASE_ADDRESS_1 when it is
        0xfec00000 (that is, outside the range of bus 0 address space).  This
        causes IOAPIC interrupts to fail to work under Linux.  This issue was
        originally unnoticed by me when testing as sanity checking such as
        this is not done by NetBSD.
        Hiding the IOAPIC BAR is done by the OEM BIOS on the ck804 boards I've
        checked.

The question raised by Ron is, if such hacks should be implemented in
coreboot or not.

Am Sonntag, den 13.10.2013, 13:55 -0400 schrieb ron minnich:
> "do as the original BIOS does" is an ok rule if the BIOS is clearly
> right and we are wrong. In this case, Linux is presumably covering for
> a broken BIOS, but doing it badly. We've seen this before. Yes, let's
> confront the LKML; some of them read this least and they're usually
> pretty reasonable (not always :). But let's thoroughly document what's
> going on. I'm not comfortable with doing a hack like this for one
> kernel. It's never been a good idea (we've confronted this issue more
> than once in 14 years). Before we know it we'll be asked to put in
> gross hacks for Windows too.

Even if Linux gets fixed, what do we do with distributions with older
Linux kernels which do not have that fix on current installation media
for example? In my opinion it is undesirable to tell people you cannot
use that stable distribution because the Linux kernel has a bug. Build
your own Linux kernel. The same applies for Microsoft Windows. And there
you might even not get it fixed at all. (I do not know, if this
particular problem actually exists in Microsoft Windows.) In the end, we
want that everything that boots with the vendor BIOS also boots with
coreboot, won’t we? Staying compatible with certain hacks the vendor
BIOS does is therefore unavoidable.

One alternative would be to add a Kconfig option to enable such hacks.
No idea if this is doable or not. In the end Jonathan’s fix seems pretty
minimal for the benefit we get.


Thanks,

Paul


[1] http://review.coreboot.org/#/c/3963/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20131013/83a1a79b/attachment.sig>