The Pistachio and DBM690T ACPI code uses MMCONFIG to access southbridge PCI config registers. This fails because we explicitly disable MMCONFIG accesses with disable_pcie_bar3(). The comments in the code state that coreboot is expected to reenable MMCONFIG, but that never happens.
This patch is a totally ugly workaround, but it fixes the ACPI code for me.
To verify the fix or create a better fix, please boot Linux with the boot parameter acpi.debug_level=0x10807 and look for the string "E0090024" in dmesg. If you can't find that string, please recompile your kernel with CONFIG_ACPI_DEBUG=y
Broken: evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0 (@ffffffff803a9598) Address 00000000E0090024 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0 (@ffffffff803a9598) Address 00000000E0090025 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0 (@ffffffff803a9598) Address 00000000E0090026 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0 (@ffffffff803a9598) Address 00000000E0090027 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0 (@ffffffff803a9598) Address 0000000100000128 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0 (@ffffffff803a9598) Address 00000001000001A8 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0 (@ffffffff803a9598) Address 0000000100000228 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0 (@ffffffff803a9598) Address 00000001000002A8 [SystemMemory]
OK: evregion-0398 [00] ev_address_space_dispa: Handler ffff88013fad5ae0 (@ffffffff803a9598) Address 00000000E0090024 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff88013fad5ae0 (@ffffffff803a9598) Address 00000000E0090025 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff88013fad5ae0 (@ffffffff803a9598) Address 00000000E0090026 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff88013fad5ae0 (@ffffffff803a9598) Address 00000000E0090027 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff88013fad5ae0 (@ffffffff803a9598) Address 00000000FC409129 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff88013fad5ae0 (@ffffffff803a9598) Address 00000000FC4091A9 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff88013fad5ae0 (@ffffffff803a9598) Address 00000000FC409229 [SystemMemory] evregion-0398 [00] ev_address_space_dispa: Handler ffff88013fad5ae0 (@ffffffff803a9598) Address 00000000FC4092A9 [SystemMemory]
Note that the broken version tries to access memory above 4 GB. The correct version accesses SATA_BAR5 instead.
I don't know the correct place to re-enable MMCONFIG access.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: LinuxBIOSv2-asus_m2a-vm/src/boot/hardwaremain.c =================================================================== --- LinuxBIOSv2-asus_m2a-vm/src/boot/hardwaremain.c (Revision 4010) +++ LinuxBIOSv2-asus_m2a-vm/src/boot/hardwaremain.c (Arbeitskopie) @@ -36,7 +36,9 @@ #include <part/hard_reset.h> #include <part/init_timer.h> #include <boot/elf.h> +#include "../southbridge/amd/rs690/rs690.h"
+ /** * @brief Main function of the DRAM part of coreboot. * @@ -49,6 +51,7 @@ void hardwaremain(int boot_complete) { struct lb_memory *lb_mem; + device_t nb_dev;
post_code(0x80);
@@ -83,6 +86,8 @@ dev_initialize(); post_code(0x89);
+ nb_dev = dev_find_slot(0, PCI_DEVFN(0, 0)); + enable_pcie_bar3(nb_dev); /* PCIEMiscInit */ /* Now that we have collected all of our information * write our configuration tables. */
2009/3/17 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
The Pistachio and DBM690T ACPI code uses MMCONFIG to access southbridge PCI config registers. This fails because we explicitly disable MMCONFIG accesses with disable_pcie_bar3(). The comments in the code state that coreboot is expected to reenable MMCONFIG, but that never happens.
I think either of these options would be less ugly: 1. Don't disable MMCONFIG. 2. Enable it in dev.init for the southbridge. (the equivalent of Phase 6 in v3.)
Index: LinuxBIOSv2-asus_m2a-vm/src/boot/hardwaremain.c
--- LinuxBIOSv2-asus_m2a-vm/src/boot/hardwaremain.c (Revision 4010) +++ LinuxBIOSv2-asus_m2a-vm/src/boot/hardwaremain.c (Arbeitskopie) @@ -36,7 +36,9 @@ #include <part/hard_reset.h> #include <part/init_timer.h> #include <boot/elf.h> +#include "../southbridge/amd/rs690/rs690.h"
/** * @brief Main function of the DRAM part of coreboot. * @@ -49,6 +51,7 @@ void hardwaremain(int boot_complete) { struct lb_memory *lb_mem;
- device_t nb_dev;
why call it nb_dev when it's a southbridge?
Thanks, Myles
On 17.03.2009 23:35, Myles Watson wrote:
2009/3/17 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
The Pistachio and DBM690T ACPI code uses MMCONFIG to access southbridge PCI config registers. This fails because we explicitly disable MMCONFIG accesses with disable_pcie_bar3(). The comments in the code state that coreboot is expected to reenable MMCONFIG, but that never happens.
I think either of these options would be less ugly:
- Don't disable MMCONFIG.
The code comments around disable_pcie_bar3() indicate that the MMCONFIG address range may be relocated by the resource allocator (it is represented by a BAR) and relocating an active range is bad.
- Enable it in dev.init for the southbridge. (the equivalent of Phase 6 in v3.)
The RS690 BIOS developer's guide suggests that MMCONFIG should be used as early as possible and for all accesses involving the southbridge. I see two ways to achieve this: 1. Somehow tell the resource allocator that the MMCONFIG area is fixed and should not be relocated nor deactivated. Done. 2. If the MMCONFIG area should be relocatable (possible on RS690), make sure it gets special handling (disable directly before relocation, reenable directly after relocation).
Index: LinuxBIOSv2-asus_m2a-vm/src/boot/hardwaremain.c
--- LinuxBIOSv2-asus_m2a-vm/src/boot/hardwaremain.c (Revision 4010) +++ LinuxBIOSv2-asus_m2a-vm/src/boot/hardwaremain.c (Arbeitskopie) @@ -36,7 +36,9 @@ #include <part/hard_reset.h> #include <part/init_timer.h> #include <boot/elf.h> +#include "../southbridge/amd/rs690/rs690.h"
/**
- @brief Main function of the DRAM part of coreboot.
@@ -49,6 +51,7 @@ void hardwaremain(int boot_complete) { struct lb_memory *lb_mem;
device_t nb_dev;why call it nb_dev when it's a southbridge?
Cut-n-paste code. A RS690 variant can be northbridge if it is attached to an Intel processor. That's unsupported by our code, though.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
- If the MMCONFIG area should be relocatable (possible on RS690),
make sure it gets special handling (disable directly before relocation, reenable directly after relocation).
I like this the best. Well done finding+fixing the bug!
If you don't feel like taking this on at the moment maybe it's a good candidate for a ticket in trac, and the ugly workaround can be committed?
Acked-by: Peter Stuge peter@stuge.se
On 18.03.2009 12:29, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
- If the MMCONFIG area should be relocatable (possible on RS690),
make sure it gets special handling (disable directly before relocation, reenable directly after relocation).
I like this the best. Well done finding+fixing the bug!
If you don't feel like taking this on at the moment maybe it's a good candidate for a ticket in trac,
I'm seriously time-contrained (max. coreboot time is a few minutes per week) until April 7th due to university exams. Could you please open a ticket or look otherwise into this?
and the ugly workaround can be committed?
Acked-by: Peter Stuge peter@stuge.se
Thanks. The workaround unfortunately pollutes every single x86 board in the tree with RS690 specific code, so I'm hesitant to apply it. And I don't fully understand the v2 device model, so I have no idea where to place the correct fix.
Regards, Carl-Daniel
On 18.03.2009 12:43 Uhr, Carl-Daniel Hailfinger wrote:
On 18.03.2009 12:29, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
- If the MMCONFIG area should be relocatable (possible on RS690),
make sure it gets special handling (disable directly before relocation, reenable directly after relocation).
I like this the best. Well done finding+fixing the bug!
If you don't feel like taking this on at the moment maybe it's a good candidate for a ticket in trac,
I'm seriously time-contrained (max. coreboot time is a few minutes per week) until April 7th due to university exams. Could you please open a ticket or look otherwise into this?
and the ugly workaround can be committed?
Acked-by: Peter Stuge peter@stuge.se
Thanks. The workaround unfortunately pollutes every single x86 board in the tree with RS690 specific code, so I'm hesitant to apply it. And I don't fully understand the v2 device model, so I have no idea where to place the correct fix.
I think it might belong in chip->dev_init of the rs690.
On 18.03.2009 12:29 Uhr, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
- If the MMCONFIG area should be relocatable (possible on RS690),
make sure it gets special handling (disable directly before relocation, reenable directly after relocation).
I like this the best. Well done finding+fixing the bug!
If you don't feel like taking this on at the moment maybe it's a good candidate for a ticket in trac, and the ugly workaround can be committed?
Acked-by: Peter Stuge peter@stuge.se
No, sorry, this does not work. NACK. The patch touches hardwaremain for a single board specific change, and thus can definitely not be committed like this.
It is good, however, that we have a fix that someone with the time to do it can work on.
On 17.03.2009 23:27, Carl-Daniel Hailfinger wrote:
The Pistachio and DBM690T ACPI code uses MMCONFIG to access southbridge PCI config registers. This fails because we explicitly disable MMCONFIG accesses with disable_pcie_bar3(). The comments in the code state that coreboot is expected to reenable MMCONFIG, but that never happens.
This patch is a totally ugly workaround, but it fixes the ACPI code for me.
[...] Note that the broken version tries to access memory above 4 GB. The correct version accesses SATA_BAR5 instead.
I don't know the correct place to re-enable MMCONFIG access.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Surprise! It seems this patch has serious WTF style side effects: - It will cause the onboard ethernet to fail (no MAC address, still unresponsive even after manually setting the MAC address). Unexplained PCI config changes are: Cache line size 64->32 bytes, MaxReadReq 4096->512 bytes. - It will change the PCI subsystem ID of some devices. Surprisingly, the subsystem IDs are strange without the patch, so this is a fix, but my earliest successful boots with coreboot were correct as well. Needs to be investigated further.
How do I dump the PCI config space of all available devices directly before passing control to the payload? dump_pci_devices() uses the early PCI functions (device_t is u32) and is thus not suitable for code compiled with device_t = struct device *.
Regards, Carl-Daniel
On 18.03.2009 15:30, Carl-Daniel Hailfinger wrote:
On 17.03.2009 23:27, Carl-Daniel Hailfinger wrote:
The Pistachio and DBM690T ACPI code uses MMCONFIG to access southbridge PCI config registers. This fails because we explicitly disable MMCONFIG accesses with disable_pcie_bar3(). The comments in the code state that coreboot is expected to reenable MMCONFIG, but that never happens.
This patch is a totally ugly workaround, but it fixes the ACPI code for me.
[...] Note that the broken version tries to access memory above 4 GB. The correct version accesses SATA_BAR5 instead.
I don't know the correct place to re-enable MMCONFIG access.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Surprise! It seems this patch has serious WTF style side effects:
- It will cause the onboard ethernet to fail (no MAC address, still
unresponsive even after manually setting the MAC address). Unexplained PCI config changes are: Cache line size 64->32 bytes, MaxReadReq 4096->512 bytes.
Ward, can you confirm this bug on the M2A-VM? It seems that if I enable the workaround, the RTL8169 memory BAR becomes inaccessible and reads return 0xff. Absolutely no idea why. I speculate that it will be helpful to run lspci with/without the workaround before and after any RTL8169 driver is loaded.
- It will change the PCI subsystem ID of some devices. Surprisingly, the
subsystem IDs are strange without the patch, so this is a fix, but my earliest successful boots with coreboot were correct as well. Needs to be investigated further.
Looks like the non-designation of the MMCONFIG area causes the kernel to stomp on it. Sometimes.
How do I dump the PCI config space of all available devices directly before passing control to the payload? dump_pci_devices() uses the early PCI functions (device_t is u32) and is thus not suitable for code compiled with device_t = struct device *.
Ron?
Regards, Carl-Daniel
the way we want to dump dev config space is walk the device tree, That's something we need anyway. I'll try to write this but it won't get done today.
ron
On 19.03.2009 01:25, ron minnich wrote:
the way we want to dump dev config space is walk the device tree, That's something we need anyway. I'll try to write this but it won't get done today.
Take your time. My next coreboot window is Tuesday, but only a few hours around 13:00 MET.
Maybe someone else with a M2A-VM can test as well.
It seems the last bits of coreboot support are always the hardest challenge.
Regards, Carl-Daniel
On Wed, Mar 18, 2009 at 8:30 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 17.03.2009 23:27, Carl-Daniel Hailfinger wrote:
The Pistachio and DBM690T ACPI code uses MMCONFIG to access southbridge PCI config registers. This fails because we explicitly disable MMCONFIG accesses with disable_pcie_bar3(). The comments in the code state that coreboot is expected to reenable MMCONFIG, but that never happens.
This patch is a totally ugly workaround, but it fixes the ACPI code for me.
[...] Note that the broken version tries to access memory above 4 GB. The correct version accesses SATA_BAR5 instead.
I don't know the correct place to re-enable MMCONFIG access.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Surprise! It seems this patch has serious WTF style side effects:
- It will cause the onboard ethernet to fail (no MAC address, still
unresponsive even after manually setting the MAC address). Unexplained PCI config changes are: Cache line size 64->32 bytes, MaxReadReq 4096->512 bytes.
- It will change the PCI subsystem ID of some devices. Surprisingly, the
subsystem IDs are strange without the patch, so this is a fix, but my earliest successful boots with coreboot were correct as well. Needs to be investigated further.
This must be why they said to use MMConfig accesses whenever possible. :)
Here's my 2 cents: 1. Overwrite read resources so it doesn't touch your MMConfig BAR (sizing it would not be good) 2. Overwrite set_resources so that it: a. disables MMConfig accesses b. writes the new value to the MMConfig BAR c. enables MMConfig accesses
Then everywhere else you can use MMConfig accesses. Enable them as early as possible.
Thanks, Myles
On Thu, Mar 19, 2009 at 4:32 AM, Myles Watson mylesgw@gmail.com wrote:
Here's my 2 cents:
- Overwrite read resources so it doesn't touch your MMConfig BAR
(sizing it would not be good) 2. Overwrite set_resources so that it: a. disables MMConfig accesses b. writes the new value to the MMConfig BAR c. enables MMConfig accesses
I assume you mean to change which ever 690 device operations struct it is. Then check the address for the bar and skip it if mmconfig otherwise do a normal read/write. That sounds good to me.
Marc
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com]
On Thu, Mar 19, 2009 at 4:32 AM, Myles Watson mylesgw@gmail.com wrote:
Here's my 2 cents:
- Overwrite read resources so it doesn't touch your MMConfig BAR
(sizing it would not be good) 2. Overwrite set_resources so that it: a. disables MMConfig accesses b. writes the new value to the MMConfig BAR c. enables MMConfig accesses
I assume you mean to change which ever 690 device operations struct it is. Then check the address for the bar and skip it if mmconfig otherwise do a normal read/write. That sounds good to me.
Thanks for clarifying. It was a little early :)
Skip it for read_resources. Disable, write, then enable using conf1 pci config accesses for set_resources. Otherwise use the default.
I think that will allow you to use mmconfig accesses everywhere else.
Thanks, Myles
-
Carl-Daniel Hailfinger -
Marc Jones -
Myles Watson -
Peter Stuge -
ron minnich -
Stefan Reinauer