[coreboot] SeaBIOS WinXP install

Arnaud Maye arnaud.maye at 4dsp.com
Wed Sep 2 16:31:19 CEST 2009

Carl-Daniel Hailfinger wrote:
> On 01.09.2009 22:15, Rudolf Marek wrote:
>>> On 01.09.2009 15:00, Arnaud Maye wrote:
>>>> I've been implementing the ACPI for the ep80579 and so far it is not
>>>> going very well. Linux refuses to boot unless I use acpi=off or
>>>> acpi=ht as boot parameters. acpi=ht seems to display my ACPI ioports
>>>> in proc/ioports as expected ( the ioports addresses are all mapped to
>>>> the ACPI BAR ). Without to disable acpi the kernel complains that the
>>>> 0xE0000000 range is not a reserved  range and the MMCONF is not
>>>> supported and then hangs.
>> It should not hang. The complain is only about e820 map is not
>> reserved. I made recently a small patch for this for K8M890. Simply
>> the problem seems elsewhere to me.
> But if MMCONF is not seen as active, the kernel might allocate something
> else in that area. If the ACPI code uses MMCONF for PCI accesses, this
> means the ACPI code will write/read with undefined side effects.
> Besides that, if you forgot to (re)activate MMCONFIG inside coreboot,
> you might see similar effects. I was fighting with RS690 code which
> enabled MMCONF, used it for a few accesses, then disabled it again, but
> the ACPI code tried to use MMCONF anyway. Effect were SATA problems/hangs.
> Besides that, enabling MMCONF in the chipset may break some classic PCI
> accesses. For example, if I enable MMCONF in the chipset and if the
> kernel doesn't accept it due to missing reservation, my network card
> fails because it uses extended config space for storing the MAC and
> other stuff. When MMCONFIG in the chipset is disabled, it works, so
> there must be some further interaction (maybe enabling MMCONFIG breaks
> other access methods to extended config space).
> Regards,
> Carl-Daniel
Hello Guys,

So actually, I've been able to prevent linux complaining about non 
reserved 0xe0000000 range via

With the intel firmware dev kit pointed by Myles I've been able to 
remove all the obvious ACPI
issues. I've enabled the HPET in the chipset and modified the 
acpi_tables.c file to create that table
as well as the MADT table.

The kernel hangs around the sata! Actually the system hang for a minute 
and then start to display:
ata1.00: exception Emask 0x0 SAct 0x0 Srr 0x0 action 0x2 frozen
ata1.00: cmd a0/00:00:00:24:00/00:00:00:00:00/a0 tag 0 pio 36 in
ata1.00: status: { DRDY }
ata2.00: exception Emask 0x0 DAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
ata2.00: status: { DRDY }
ata1: WARNING: synchronous SCSI scan failed without making any progress,
Buffer I/O error on device sda, logical block 0

Just before the system to hang, seabios displays :
fail handle_legacy_disk:845(1):
   a=ffff0201  b=00000d00  c=00000001  d=47530081 ds=9000 es=9000 ss=9000
  si=fff0fff0 di=0009fff0 bp=00001ff0 sp=00008ff8 cs=9020 ip=1015  f=0283
fail handle_legacy_disk:845(1):
   a=ffff415a  b=000055aa  c=0000fe03  d=47530081 ds=9000 es=9000 ss=9000
  si=fff00d5a di=00090000 bp=00001ff0 sp=00008ffe cs=9020 ip=1043  f=0293

Here is the lspci for both legacy and coreboot :
legacy :
00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01) 
(prog-if 8f [Master SecP SecO PriP PriO])
    Subsystem: Intel Corporation EP80579 S-ATA IDE
    Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 58
    I/O ports at f080 [size=8]
    I/O ports at f070 [size=4]
    I/O ports at f060 [size=8]
    I/O ports at f050 [size=4]
    I/O ports at f040 [size=16]
    Memory at d0100000 (32-bit, non-prefetchable) [size=1K]
    Capabilities: [70] Power Management version 2

00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01) 
(prog-if 8f [Master SecP SecO PriP PriO])
    Subsystem: Intel Corporation Unknown device 2680
    Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 145
    I/O ports at 2410 [size=8]
    I/O ports at 2420 [size=4]
    I/O ports at 2418 [size=8]
    I/O ports at 2424 [size=4]
    I/O ports at 2400 [size=16]
    Memory at d4a07400 (32-bit, non-prefetchable) [size=1K]
    Capabilities: [70] Power Management version 2

Actually same except io ports are located another place and the 
subsystem IDs is set differently by the driver. I do
not think the last one would cause any troubles.

So am not sure where is the problem here, booting with acpi=off does not 
show any sata issue.

Any help/pointers are welcome,

Thank you




More information about the coreboot mailing list