Using a custom DSDT with Fedora

Arjan van de Ven arjan at fenrus.demon.nl
Mon Oct 9 15:31:30 UTC 2006


On Mon, 2006-10-09 at 11:10 -0400, David Zeuthen wrote:
> On Mon, 2006-10-09 at 09:17 +0200, Arjan van de Ven wrote:
> > > > Please read my blog entry. The ACPI interpreter isn't broken, the BIOS
> > > > just doesn't read from the hardware like it should.
> > > 
> > > Then the BIOS is broken, complain to the BIOS vendor?
> > 
> > this is a good place to plug the bios<->linux test tool that Intel
> > recently released:
> > 
> > http://www.linuxfirmwarekit.org
> > 
> > The aim is to make it real easy for bios folks to test with linux, but
> > normal users can use it too, say for evaluating what to buy etc.
> 
> That is an awesome effort Arjan!
> 
> Reading the whole thread I think we need to fix a few things in Fedora
> though. Here's an example where Richard actually fixed a bug. Can anyone
> explain why Richard needs to jump through hoops to actually apply his
> bug fix? Clearly something is broken with Fedora here.

no there is something broken with his bios, not with fedora.

> 
> At the very least we ought to provide the option to mkinitrd so it can
> include the new DSDT and load it into the kernel at startup. IIRC the
> main resistance is that upstream kernel and other developers don't like
> to deal with bug reports when a custom DSDT is used. So perhaps one way
> of dealing with this is to taint the kernel if that isn't happening
> already.

no the main resistance is that this is THE WRONG THING

you're allowing to replace code *while it's live*. If you have a very
tiny delta, you might just get away with it. But in general, it's a
pretty stupid idea.

The kernel does allow an override, but then EARLY. before the code
starts executing.

if you want to make that more userfriendly, then sure.
with objcopy you can replace the kernel content on a per section basis.
Use that to do it right...


> 
> I also think we need to think about the experience we want people to
> have when they use Fedora. We already have thousands of work arounds and
> quirks for broken hardware in Fedora, why doesn't this apply to the
> DSDT? Just because it's firmware?

No because it's replacing live code! While there are function pointer
equivalents to it and while it is executing.


> In other words: Why can't we ship updated DSDT tables if the vendor
> (Lenovo in this case) have ACK'ed the DSDT with the bug fix and said
> it's the right update? (maybe there are redistribution issues here)

you can't ship them because bios code is copyrighted. and it's easier to
get them to provide a bios upgrade than to get permission to ship a
modified copy ourselves


> Further, if a vendor has an updated BIOS and it's suitable for
> redistribution in Fedora, why can't we include that BIOS image and ask
> the user if he wants to flash his BIOS?

we don't need to. Dell has a nice yum repo for this (vendor neutral);
that is much more the right approach than including stuff on a CD

> hooks into, for example, HAL and provides the implementation for an
> UpdateFirmware() method.

that btw is really really hard as general thing. Only one or two vendors
have linux flash tools and usually it's mobo specific even. get the
wrong one and you have a brick





More information about the fedora-devel-list mailing list