Hello Myles, Kevin and others
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. Using acpi=noirq still hangs so I believe the problem is not related to the acpi irqoverride.
The DSDT been dumped from the legacy BIOS using acpidump and this is what I am including in the build process to test. Actually I've based my code on the mainboard\intel\eagleheigths.
I wanted to discard the linux problem so far and concentrate on Windows XP install. I've been disabling the ACPI ( pressing F7 in early install ) and it goes well until "Starting windows..." then I get a BSOD : STOP: 0x0000007B (0xF8980524, 0xc0000034, 0x0000000, 0x00000000).
This error indeed point to "Inaccessible Boot Device" and the second argument 0xc0000043 points to "Status Object Name Not Found"
This post is quite old and nothing have been answered to it since July 2008. You probably been able to fix that issue. What is related to missing floppy disk controller or something else?
Thank you.
Arnaud
reference email :
/ -----Original Message-----
/>/ From: Kevin O'Connor [mailto:kevin at koconnor.net http://www.coreboot.org/mailman/listinfo/coreboot] />/ Sent: Friday, July 25, 2008 9:49 PM />/ To: Myles Watson />/ Cc: Coreboot />/ Subject: Re: SeaBIOS WinXP install />/ />/ Hi Myles, />/ />/ On Fri, Jul 25, 2008 at 03:58:05PM -0600, Myles Watson wrote: />/ > Just for the fun of it I tried installing XP with the old Bochs BIOS and />/ > then booting it with SeaBIOS. It installs fine, then can't boot with />/ either />/ > BIOS. With SeaBIOS, it blue screens with the same message as the />/ install />/ > CD. Here's the log: />/ />/ The log looks like a CD boot log - was it the same for the hd boot? / After an install, you have to reboot with the CD.
/ A couple of notes:
/>/ />/ A "STOP: 0x0000007B" message is an INACCESSIBLE_BOOT_DEVICE error />/ according to: />/ />/ http://blogs.technet.com/asksbs/archive/2008/03/30/how-to-troubleshoot- />/ the-stop-error-0x0000007b.aspx />/ />/ I did notice that the last log message always seems to be: />/ />/ > fail floppy_13XX:709(00000001): />/ > a=00001507 b=00000003 c=0000000f d=00065000 si=00005026 di=00000000 />/ > ds=00001a49 es=0000504a ip=000055be cs=00001000 f=00000212 r=00000c02 />/ />/ you could try enabling the CONFIG_FLOPPY_SUPPORT on your machine. If />/ that doesn't work, you could try just enabling a floppy_1315() handler />/ that always sets regs->ah=0 and calls set_success(). / I'll try it.
/ Another thing to try would be to set DEBUG_HDL_13 and DEBUG_HDL_40 to
/>/ 1 so that you see every call into the bios disk handlers. />/ />/ BTW, what are you using to log the output from serial? If something />/ is sending backspaces - is there a way to capture that? / I'm using HyperTerminal. Thanks for pointing this out. It shoots my theory about backspaces, because HyperTerminal logs those. Any thoughts on where the disappearing output might go?
/
/>/ Also, you reported that Bochs 1.186 is working with ADLO. Does a more />/ recent version of Bochs also work? The seabios code is basically in />/ synch with the latest bochs (v1.211). / I can try it.
/ I wish there was more help I could give; unfortunately I'm seeing a
/>/ totally different set of failures here. :-( / Hopefully we'll get to a common case eventually so we can help each other better.
Thanks, Myles
* *
Hi Arnaud,
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.
Rudolf knows how to reserve the MMCONFIG area properly so that Linux is happy with it. I've seen all sorts of boot problems on machines where Linux disabled MMCONFIG.
Using acpi=noirq still hangs so I believe the problem is not related to the acpi irqoverride.
The DSDT been dumped from the legacy BIOS using acpidump and this is what I am including in the build process to test. Actually I've based my code on the mainboard\intel\eagleheigths.
Regards, Carl-Daniel
Hi
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.
The DSDT been dumped from the legacy BIOS using acpidump and this is what I am including in the build process to test. Actually I've based my code on the mainboard\intel\eagleheigths.
Please try to develop minimalistic DSDT based on M2V-MX SE and read the ACPI guide on the wiki.
You need to have linux working first and then go for windows.
Please try to read the wiki pages and then ask so we can improve the pages. http://www.coreboot.org/ACPI_in_coreboot
Rudolf
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
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 add_mainboard_resource().
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
Arnaud
*
*
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.
I don't think the IO port location is a problem, unless it conflicts with something in the DSDT. The IRQ setting is also different. 145 seems pretty high.
Thanks, Myles
Myles Watson wrote:
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.
I don't think the IO port location is a problem, unless it conflicts with something in the DSDT. The IRQ setting is also different. 145 seems pretty high.
What this IRQ 145 (or 58) relates to. On the legacy BIOS this is an ACPI=force boot and on coreboot this is an ACPI=off. Is this IRQ assigned by coreboot, by seabios or the operating system. I just want to verify if this is normal or not.
Thank you,
Arnaud
I don't think the IO port location is a problem, unless it conflicts
with
something in the DSDT. The IRQ setting is also different. 145 seems
pretty
high.
What this IRQ 145 (or 58) relates to. On the legacy BIOS this is an ACPI=force boot and on coreboot this is an ACPI=off. Is this IRQ assigned by coreboot, by seabios or the operating system. I just want to verify if this is normal or not.
I wish I knew more about it. Here's the part of Rudolf's page about that: http://www.coreboot.org/ACPI_in_coreboot#Interrupt_routing_in_DSDT
My understanding is that the IRQs are specified as offsets from IOAPICs, each of which supply some number of IRQs. If your DSDT specifies this differently than the chipset was configured by Coreboot, it breaks.
Myles
On Wed, Sep 02, 2009 at 04:31:19PM +0200, Arnaud Maye wrote:
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
If you see these messages after Linux starts, then something very strange is occurring.
If you're seeing these messages prior to the Linux start, then they like normal -- the messages are just warnings resulting from a call with invalid parameters (looks like grub is probing for a second hard drive).
-Kevin
On Tue, Sep 1, 2009 at 7:00 AM, Arnaud Mayearnaud.maye@4dsp.com wrote:
Hello Myles, Kevin and others
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. Using acpi=noirq still hangs so I believe the problem is not related to the acpi irqoverride.
If you boot using acpi=off you can use the Linux Firmware Developers Kit ( http://linuxfirmwarekit.org/ ) to debug ACPI issues. Then you'll have lspci available to check against what the tables are saying.
The DSDT been dumped from the legacy BIOS using acpidump and this is what I am including in the build process to test. Actually I've based my code on the mainboard\intel\eagleheigths.
I couldn't use the factory DSDT for my mainboard because so many of the initialization values were different when booted with Coreboot.
I wanted to discard the linux problem so far and concentrate on Windows XP install. I've been disabling the ACPI ( pressing F7 in early install ) and it goes well until "Starting windows..." then I get a BSOD : STOP: 0x0000007B (0xF8980524, 0xc0000034, 0x0000000, 0x00000000).
Linux is much more forgiving. I personally wouldn't try Windows without Linux working. There's much more debugging information available with Linux.
This error indeed point to "Inaccessible Boot Device" and the second argument 0xc0000043 points to "Status Object Name Not Found"
This post is quite old and nothing have been answered to it since July 2008. You probably been able to fix that issue. What is related to missing floppy disk controller or something else?
I haven't looked at it since then. One of the things that makes my s2895 challenging is multiple PCI root buses. I haven't gotten that quite right yet.
Thanks, Myles
On Tue, Sep 01, 2009 at 03:00:44PM +0200, Arnaud Maye wrote:
The DSDT been dumped from the legacy BIOS using acpidump and this is what I am including in the build process to test. Actually I've based my code on the mainboard\intel\eagleheigths.
As others have mentioned, using the stock DSDT tables wont work with coreboot and SeaBIOS.
-Kevin
-
Arnaud Maye -
Carl-Daniel Hailfinger -
Kevin O'Connor -
Myles Watson -
Rudolf Marek