Does anyone have an updated HOWTO for booting XP with SeaBIOS? I'm specifically wondering if there's an option we should add to v2 which relocates BIOS tables so that SeaBIOS doesn't overwrite them, or if we should add that to buildrom.
Thanks, Myles
Myles Watson wrote:
Does anyone have an updated HOWTO for booting XP with SeaBIOS? I'm specifically wondering if there's an option we should add to v2 which relocates BIOS tables so that SeaBIOS doesn't overwrite them, or if we should add that to buildrom.
Thanks, Myles
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
I wrote a (more or less) generic patch to do that. Let me extract it from our internal tree and send it around.
Stefan
On Tue, Jan 20, 2009 at 11:50 AM, Stefan Reinauer stepan@coresystems.de wrote:
Myles Watson wrote:
Does anyone have an updated HOWTO for booting XP with SeaBIOS? I'm specifically wondering if there's an option we should add to v2 which relocates BIOS tables so that SeaBIOS doesn't overwrite them, or if we should add that to buildrom.
Thanks, Myles
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
I wrote a (more or less) generic patch to do that. Let me extract it from our internal tree and send it around.
Great!
Thanks, Myles
Here's my latest patch. It contains generic parts, northbridge specific parts and board specific parts.
Please let me know what you think.
Myles Watson wrote:
On Tue, Jan 20, 2009 at 11:50 AM, Stefan Reinauer stepan@coresystems.de wrote:
Myles Watson wrote:
Does anyone have an updated HOWTO for booting XP with SeaBIOS? I'm specifically wondering if there's an option we should add to v2 which relocates BIOS tables so that SeaBIOS doesn't overwrite them, or if we should add that to buildrom.
Thanks, Myles
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
I wrote a (more or less) generic patch to do that. Let me extract it from our internal tree and send it around.
Great!
Thanks, Myles
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Wed, Jan 21, 2009 at 12:08:57AM +0100, Stefan Reinauer wrote:
Here's my latest patch. It contains generic parts, northbridge specific parts and board specific parts.
Please let me know what you think.
Thanks Stefan,
A couple of comments:
--- src/mainboard/kontron/986lcd-m/mainboard.c (revision 3886) +++ src/mainboard/kontron/986lcd-m/mainboard.c (working copy) @@ -21,8 +21,31 @@
#include <device/device.h> +#include <console/console.h> +#include <boot/tables.h> #include "chip.h"
+/* in arch/i386/boot/tables.c */ +extern uint64_t high_tables_base, high_tables_size;
+/* in northbridge/intel/i945/northbridge.c */ +extern uint64_t uma_memory_base, uma_memory_size;
+int add_mainboard_resources(struct lb_memory *mem) +{ +#if HAVE_HIGH_TABLES == 1
- printk_debug("Adding high table area\n");
- lb_add_memory_range(mem, LB_MEM_TABLE,
high_tables_base, high_tables_size);+#endif
Isn't there a way we can add this support without having to change every platform?
--- src/arch/i386/boot/tables.c (revision 3886) +++ src/arch/i386/boot/tables.c (working copy)
[...]
/* Write ACPI tables */ /* write them in the rom area because DSDT can be large (8K on epia-m) which * pushes coreboot table out of first 4K if set up in low table area */ +#if HAVE_LOW_TABLES == 1 rom_table_end = write_acpi_tables(rom_table_end); rom_table_end = (rom_table_end+1023) & ~1023;
+#endif +#if HAVE_HIGH_TABLES == 1
- if (high_tables_base) {
high_table_end = write_acpi_tables(high_table_end);high_table_end = (high_table_end+1023) & ~1023;- }
+#endif
I'm a little concerned about generating the data twice. That could confuse debugging efforts (the OS might see one version while the user investigates another). The data wont be identical because acpi has pointers in the data structures.
I like the idea of always keeping support for tables in 0xf0000 - maybe we could just copy the 36 byte ACPI RSDP struct to low memory when HIGH_TABLES are enabled. (And similarly, the 12 byte "mptable floating structure".)
/* The smp table must be in 0-1K, 639K-640K, or 960K-1M */+#if HAVE_LOW_TABLES == 1 new_low_table_end = write_smp_table(low_table_end); // low_table_end is 0x10 at this point +#endif +#if HAVE_HIGH_TABLES == 1
if (high_tables_base) {high_table_end = write_smp_table(high_table_end);high_table_end = (high_table_end+1023) & ~1023;}+#endif
-#if HAVE_MP_TABLE==1 +#if HAVE_MP_TABLE == 1 /* Don't write anything in the traditional x86 BIOS data segment, * for example the linux kernel smp need to use 0x467 to pass reset vector * or use 0x40e/0x413 for EBDA finding...
I think the above "#if HAVE_MP_TABLE" branch doesn't make any sense. Currently, coreboot tries to put the mptable in the first 1KiB of ram. If it can't fit, it will put it into the 0xf0000 segment. This complexity doesn't make any sense, because there is no reason why we can't always put the mptable in the 0xf0000 segment.
That is, in the HAVE_LOW_TABLES case, we can use:
rom_table_end = write_smp_table(rom_table_end); rom_table_end = (rom_table_end+1023) & ~1023;
and completely remove the HAVE_MP_TABLE case.
-Kevin
Kevin O'Connor wrote:
--- src/mainboard/kontron/986lcd-m/mainboard.c (revision 3886) +++ src/mainboard/kontron/986lcd-m/mainboard.c (working copy) @@ -21,8 +21,31 @@
#include <device/device.h> +#include <console/console.h> +#include <boot/tables.h> #include "chip.h"
+/* in arch/i386/boot/tables.c */ +extern uint64_t high_tables_base, high_tables_size;
+/* in northbridge/intel/i945/northbridge.c */ +extern uint64_t uma_memory_base, uma_memory_size;
+int add_mainboard_resources(struct lb_memory *mem) +{ +#if HAVE_HIGH_TABLES == 1
- printk_debug("Adding high table area\n");
- lb_add_memory_range(mem, LB_MEM_TABLE,
high_tables_base, high_tables_size);+#endif
Isn't there a way we can add this support without having to change every platform?
We probably could, by parsing the device tree and finding the memory resource.
But then again, this only makes sense on those platforms where we have ACPI which is a small hand full.
Also, even without the high tables code, most boards will need a locat "add_mainboard_resources" function for their PCIe BAR or their UMA graphics (or both)
--- src/arch/i386/boot/tables.c (revision 3886) +++ src/arch/i386/boot/tables.c (working copy)
[...]
/* Write ACPI tables */ /* write them in the rom area because DSDT can be large (8K on epia-m) which * pushes coreboot table out of first 4K if set up in low table area */ +#if HAVE_LOW_TABLES == 1 rom_table_end = write_acpi_tables(rom_table_end); rom_table_end = (rom_table_end+1023) & ~1023;
+#endif +#if HAVE_HIGH_TABLES == 1
- if (high_tables_base) {
high_table_end = write_acpi_tables(high_table_end);high_table_end = (high_table_end+1023) & ~1023;- }
+#endif
I'm a little concerned about generating the data twice. That could confuse debugging efforts (the OS might see one version while the user investigates another). The data wont be identical because acpi has pointers in the data structures.
So am I, as you probably saw from my "HAVE_LOW_TABLES" guards. It's possible to disable the "low tables" and that would generally be a good idea, if all payloads would start copying tables around. But
- only SeaBIOS does this (so far?) (and seabios users can help it with the HAVE_LOW_TABLES=0 switch - SeaBIOS will wipe away the low tables in FSEG upon load - The "high tables" are never searched by the OS in case the low tables are found
So it's a trade off, and basically it's a smart thing to disable the tables that the payload or kernel will not really use.
I like the idea of always keeping support for tables in 0xf0000 - maybe we could just copy the 36 byte ACPI RSDP struct to low memory when HIGH_TABLES are enabled. (And similarly, the 12 byte "mptable floating structure".)
So are you suggesting to write 48 bytes to the fseg both in coreboot and in seabios, and have the "rest" in the "high tables area"? That would work.
But what about DMI. How do we handle DMI? It needs to go to the FSEG and it doesn't have pointers afaik.
-#if HAVE_MP_TABLE==1 +#if HAVE_MP_TABLE == 1 /* Don't write anything in the traditional x86 BIOS data segment, * for example the linux kernel smp need to use 0x467 to pass reset vector * or use 0x40e/0x413 for EBDA finding...
I think the above "#if HAVE_MP_TABLE" branch doesn't make any sense. Currently, coreboot tries to put the mptable in the first 1KiB of ram. If it can't fit, it will put it into the 0xf0000 segment. This complexity doesn't make any sense, because there is no reason why we can't always put the mptable in the 0xf0000 segment.
That is, in the HAVE_LOW_TABLES case, we can use:
rom_table_end = write_smp_table(rom_table_end); rom_table_end = (rom_table_end+1023) & ~1023;
and completely remove the HAVE_MP_TABLE case.
I think YhLu added that for some side case... Yinghai.. mind to share the insight?
Stefan
On Tue, Jan 20, 2009 at 6:12 PM, Stefan Reinauer stepan@coresystems.de wrote:
Kevin O'Connor wrote:
-#if HAVE_MP_TABLE==1 +#if HAVE_MP_TABLE == 1 /* Don't write anything in the traditional x86 BIOS data segment, * for example the linux kernel smp need to use 0x467 to pass reset vector * or use 0x40e/0x413 for EBDA finding...
I think the above "#if HAVE_MP_TABLE" branch doesn't make any sense. Currently, coreboot tries to put the mptable in the first 1KiB of ram. If it can't fit, it will put it into the 0xf0000 segment. This complexity doesn't make any sense, because there is no reason why we can't always put the mptable in the 0xf0000 segment.
That is, in the HAVE_LOW_TABLES case, we can use:
rom_table_end = write_smp_table(rom_table_end); rom_table_end = (rom_table_end+1023) & ~1023;and completely remove the HAVE_MP_TABLE case.
I think YhLu added that for some side case... Yinghai.. mind to share the insight?
should be ok. just need to make sure not mess up with 0x467 and ebda stuff.
YH
On Tue, Jan 20, 2009 at 07:00:42PM -0800, yhlu wrote:
On Tue, Jan 20, 2009 at 6:12 PM, Stefan Reinauer stepan@coresystems.de wrote:
Kevin O'Connor wrote:
Currently, coreboot tries to put the mptable in the first 1KiB of ram. If it can't fit, it will put it into the 0xf0000 segment. This complexity doesn't make any sense, because there is no reason why we can't always put the mptable in the 0xf0000 segment.
I think YhLu added that for some side case... Yinghai.. mind to share the insight?
should be ok. just need to make sure not mess up with 0x467 and ebda stuff.
Can we always put the MPTable in the 0xf0000 segment?
-Kevin
On Wed, Jan 21, 2009 at 03:12:00AM +0100, Stefan Reinauer wrote:
Kevin O'Connor wrote:
I like the idea of always keeping support for tables in 0xf0000 - maybe we could just copy the 36 byte ACPI RSDP struct to low memory when HIGH_TABLES are enabled. (And similarly, the 12 byte "mptable floating structure".)
So are you suggesting to write 48 bytes to the fseg both in coreboot and in seabios, and have the "rest" in the "high tables area"?
Yes. The PIRQ would also need to live in both places, but since the PIRQ has no pointers it can be memcpy'd.
But what about DMI. How do we handle DMI? It needs to go to the FSEG and it doesn't have pointers afaik.
SMBIOS/DMI also has a pointer struct (32 bytes).
-Kevin
On Tue, Jan 20, 2009 at 4:08 PM, Stefan Reinauer stepan@coresystems.de wrote:
Here's my latest patch. It contains generic parts, northbridge specific parts and board specific parts.
Please let me know what you think.
Sorry it has taken so long, I have been working on implementing ACPI for my board so that I could try it out.
Your patch works fine for me. Seabios gets the tables, Linux finds them from there.
I'm having trouble with my fadt (FACP) and DSDT (the only ones I really have to do :) since coreboot has support for SRAT, RSDT, RSDP, and APIC ). I'm attaching the current patches that I'm using. They apply on top of the patch you sent.
- I can't figure out the correspondence between pnp devices in /proc/ioports and coreboot. The ACPI device is missing, and I'm not sure how to add it. That causes problems when it tries to read the timer specified in fadt.c. If I remove the timer reference Linux complains but continues until it breaks based on interrupt routing.
- The disassembled dsdt from the board doesn't match the way coreboot configures the board, so I was trying to add my own based on another board...
- I don't see the relationship between /proc/interrupts and how to generate the _PRT in the dsdt
- I've looked for a tutorial or Mindshare book on ACPI tables, but can't find a decent one. Can anyone recommend one? The spec's examples don't have enough information for me.
- I just want the bare minimum for now. If there's something I should disable to make it simpler, I'm happy to do that.
Thanks, Myles
And the patches.
On Wed, Feb 11, 2009 at 9:38 AM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Jan 20, 2009 at 4:08 PM, Stefan Reinauer stepan@coresystems.de wrote:
Here's my latest patch. It contains generic parts, northbridge specific parts and board specific parts.
Please let me know what you think.
Sorry it has taken so long, I have been working on implementing ACPI for my board so that I could try it out.
Your patch works fine for me. Seabios gets the tables, Linux finds them from there.
I'm having trouble with my fadt (FACP) and DSDT (the only ones I really have to do :) since coreboot has support for SRAT, RSDT, RSDP, and APIC ). I'm attaching the current patches that I'm using. They apply on top of the patch you sent.
- I can't figure out the correspondence between pnp devices in
/proc/ioports and coreboot. The ACPI device is missing, and I'm not sure how to add it. That causes problems when it tries to read the timer specified in fadt.c. If I remove the timer reference Linux complains but continues until it breaks based on interrupt routing.
- The disassembled dsdt from the board doesn't match the way coreboot
configures the board, so I was trying to add my own based on another board...
- I don't see the relationship between /proc/interrupts and how to
generate the _PRT in the dsdt
- I've looked for a tutorial or Mindshare book on ACPI tables, but
can't find a decent one. Can anyone recommend one? The spec's examples don't have enough information for me.
- I just want the bare minimum for now. If there's something I should
disable to make it simpler, I'm happy to do that.
Thanks, Myles
Hi, http://www.coreboot.org/ACPI_in_coreboot
Did you checked link above?
- I can't figure out the correspondence between pnp devices in
/proc/ioports and coreboot. The ACPI device is missing, and I'm not sure how to add it. That causes problems when it tries to read the timer specified in fadt.c. If I remove the timer reference Linux complains but continues until it breaks based on interrupt routing.
You dont need ACPI device...
- The disassembled dsdt from the board doesn't match the way coreboot
configures the board, so I was trying to add my own based on another board...
- I don't see the relationship between /proc/interrupts and how to
generate the _PRT in the dsdt
You need to check the MPTable/PIRQ the _PRT is just another way how to express the tables. Check the link above.
- I just want the bare minimum for now. If there's something I should
disable to make it simpler, I'm happy to do that.
Well, for Linux you can remove:
+ Method (_CRS, 0, NotSerialized) + { + Name (BUF0, ResourceTemplate () + { + IO (Decode16, + 0x0CF8, // Address Range Minimum + 0x0CF8, // Address Range Maximum + 0x01, // Address Alignment + 0x08, // Address Length + ) + WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, + 0x0000, // Address Space Granularity + 0x0000, // Address Range Minimum + 0x0CF7, // Address Range Maximum + 0x0000, // Address Translation Offset + 0x0CF8, // Address Length + ,, , TypeStatic) + }) + /* Methods bellow use SSDT to get actual MMIO regs + * The IO ports are from 0xd00, optionally an VGA, + * otherwise the info from MMIO is used. + */ + Concatenate (_SB.GMEM (0x00, _SB.PCI0.SBLK), BUF0, Local1) + Concatenate (_SB.GIOR (0x00, _SB.PCI0.SBLK), Local1, Local2) + Concatenate (_SB.GWBN (0x00, _SB.PCI0.SBLK), Local2, Local3) + Return (Local3) + }
As well the Include ("amdk8_util.asl")
From mptable:
165 // Onboard ck804 SATA 0 166 smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_ck804_0, ((sbdn +7)<<2)|0, apicid_ck804, 0x17); // 23 167 168 // Onboard ck804 SATA 1 169 smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_ck804_0, ((sbdn +8)<<2)|0, apicid_ck804, 0x16); // 22 170
The sbdn is static? Lets assume SBDN is 0 for now.
for SATA 0 the _PR looks like this:
Package (0x04) { 0x0007FFFF, 0x00, 0x00, 0x17 }, //sata at 7.0 goes to IRQ 23
Similar for other devices. Hope it helps.
Rudolf
On Wed, Feb 11, 2009 at 10:01 AM, Rudolf Marek r.marek@assembler.cz wrote:
Hi, http://www.coreboot.org/ACPI_in_coreboot
Did you checked link above?
No. Thanks for the pointer and the help! Sorry I missed it.
- I can't figure out the correspondence between pnp devices in
/proc/ioports and coreboot. The ACPI device is missing, and I'm not sure how to add it. That causes problems when it tries to read the timer specified in fadt.c. If I remove the timer reference Linux complains but continues until it breaks based on interrupt routing.
You dont need ACPI device...
- The disassembled dsdt from the board doesn't match the way coreboot
configures the board, so I was trying to add my own based on another board...
- I don't see the relationship between /proc/interrupts and how to
generate the _PRT in the dsdt
You need to check the MPTable/PIRQ the _PRT is just another way how to express the tables. Check the link above.
- I just want the bare minimum for now. If there's something I should
disable to make it simpler, I'm happy to do that.
Well, for Linux you can remove:
Method (_CRS, 0, NotSerialized){Name (BUF0, ResourceTemplate (){IO (Decode16,0x0CF8, // Address Range Minimum0x0CF8, // Address Range Maximum0x01, // Address Alignment0x08, // Address Length)WordIO (ResourceProducer, MinFixed,MaxFixed, PosDecode, EntireRange,
0x0000, // Address Space Granularity0x0000, // Address Range Minimum0x0CF7, // Address Range Maximum0x0000, // Address Translation Offset0x0CF8, // Address Length,, , TypeStatic)})/* Methods bellow use SSDT to get actualMMIO regs
* The IO ports are from 0xd00, optionallyan VGA,
* otherwise the info from MMIO is used.*/Concatenate (\_SB.GMEM (0x00,_SB.PCI0.SBLK), BUF0, Local1)
Concatenate (\_SB.GIOR (0x00,_SB.PCI0.SBLK), Local1, Local2)
Concatenate (\_SB.GWBN (0x00,_SB.PCI0.SBLK), Local2, Local3)
Return (Local3)}As well the Include ("amdk8_util.asl")
From mptable:
165 // Onboard ck804 SATA 0 166 smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_ck804_0, ((sbdn +7)<<2)|0, apicid_ck804, 0x17); // 23 167 168 // Onboard ck804 SATA 1 169 smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_ck804_0, ((sbdn +8)<<2)|0, apicid_ck804, 0x16); // 22 170
The sbdn is static? Lets assume SBDN is 0 for now.
for SATA 0 the _PR looks like this:
Package (0x04) { 0x0007FFFF, 0x00, 0x00, 0x17 }, //sata at 7.0 goes to IRQ 23
Similar for other devices. Hope it helps.
I really needed the shove in the right direction!
Thanks,
Myles
On Wed, Feb 11, 2009 at 10:01 AM, Rudolf Marek r.marek@assembler.cz wrote:
Hi, http://www.coreboot.org/ACPI_in_coreboot
Did you checked link above?
- I can't figure out the correspondence between pnp devices in
/proc/ioports and coreboot. The ACPI device is missing, and I'm not sure how to add it. That causes problems when it tries to read the timer specified in fadt.c. If I remove the timer reference Linux complains but continues until it breaks based on interrupt routing.
You dont need ACPI device...
I wasn't clear. I needed the address for the fadt pm_base. Since coreboot allocates it at 0x1000 and the factory BIOS allocates it at 0x8000 I was having a hard time finding it.
- The disassembled dsdt from the board doesn't match the way coreboot
configures the board, so I was trying to add my own based on another board...
- I don't see the relationship between /proc/interrupts and how to
generate the _PRT in the dsdt
You need to check the MPTable/PIRQ the _PRT is just another way how to express the tables. Check the link above.
- I just want the bare minimum for now. If there's something I should
disable to make it simpler, I'm happy to do that.
Well, for Linux you can remove:
Method (_CRS, 0, NotSerialized){Name (BUF0, ResourceTemplate (){IO (Decode16,0x0CF8, // Address Range Minimum0x0CF8, // Address Range Maximum0x01, // Address Alignment0x08, // Address Length)WordIO (ResourceProducer, MinFixed,MaxFixed, PosDecode, EntireRange,
0x0000, // Address Space Granularity0x0000, // Address Range Minimum0x0CF7, // Address Range Maximum0x0000, // Address Translation Offset0x0CF8, // Address Length,, , TypeStatic)})/* Methods bellow use SSDT to get actualMMIO regs
* The IO ports are from 0xd00, optionallyan VGA,
* otherwise the info from MMIO is used.*/Concatenate (\_SB.GMEM (0x00,_SB.PCI0.SBLK), BUF0, Local1)
Concatenate (\_SB.GIOR (0x00,_SB.PCI0.SBLK), Local1, Local2)
Concatenate (\_SB.GWBN (0x00,_SB.PCI0.SBLK), Local2, Local3)
Return (Local3)}As well the Include ("amdk8_util.asl")
It doesn't help to take this out, except that it removes this error: ACPI Error (psargs-0358): [SBLK] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0530): Method parse/execution failed [_SB_.PCI0._CRS] (Node ffff88013fc01720), AE_NOT_FOUND
Do you get that error too, or was I supposed to change some value to make it work?
From mptable:
165 // Onboard ck804 SATA 0 166 smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_ck804_0, ((sbdn +7)<<2)|0, apicid_ck804, 0x17); // 23 167 168 // Onboard ck804 SATA 1 169 smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_ck804_0, ((sbdn +8)<<2)|0, apicid_ck804, 0x16); // 22 170
The sbdn is static? Lets assume SBDN is 0 for now.
It is 0.
for SATA 0 the _PR looks like this:
Package (0x04) { 0x0007FFFF, 0x00, 0x00, 0x17 }, //sata at 7.0 goes to IRQ 23
Thanks, that helped a lot. I'm still not booting though. I get this error in the boot log, then the hard drives stop working. The interrupts shouldn't be at fault, because they match the mptable.
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... ..... (found apic 0 pin 0) ... ....... failed. ...trying to set up timer as Virtual Wire IRQ... ..... failed. ...trying to set up timer as ExtINT IRQ... ..... works.
Here's the first line from the acpi=off boot: ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=0 pin2=0
Unfortunately I can't see where it gets set to correct it.
I'm attaching my latest dsdt file. Thanks for guiding me through this!
Myles
Hello,
I wasn't clear. I needed the address for the fadt pm_base. Since coreboot allocates it at 0x1000 and the factory BIOS allocates it at 0x8000 I was having a hard time finding it.
OK hopefully it is static ;)
Do you get that error too, or was I supposed to change some value to make it work?
Perhaps something was missing? I dont know. Lets solve this later.
It is 0.
OK
for SATA 0 the _PR looks like this:
Package (0x04) { 0x0007FFFF, 0x00, 0x00, 0x17 }, //sata at 7.0 goes to IRQ 23
Thanks, that helped a lot. I'm still not booting though. I get this error in the boot log, then the hard drives stop working. The interrupts shouldn't be at fault, because they match the mptable.
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... ..... (found apic 0 pin 0) ... ....... failed. ...trying to set up timer as Virtual Wire IRQ... ..... failed. ...trying to set up timer as ExtINT IRQ... ..... works.
Here's the first line from the acpi=off boot: ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=0 pin2=0
Unfortunately I can't see where it gets set to correct it.
Aha you need also a MADT table. It seems this table is bit mess:
This is for IRQ9 to be the ACPI irq level low triggered:
+ current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *) + current, 0, 9, 9, 0xF);
You need this:
/* IRQ0 -> APIC IRQ2. */ current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *) current, 0, 0, 2, 0x0);
Check the original BIOS whats inside the MADT please.
the first zero is 0 which is ISA bus. The second 0 is bus relative source of IRQ - IRQ0 in our case. But IRQ0 is not mapped to IRQ0 but to pin2 on APIC so We create a mapping of IRQ0->IRQ2
Also this is also wrong: /* Write NVIDIA CK804 IOAPIC. */ + current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current, 4, + IO_APIC_ADDR, 0); + + /* Write AMD 8131 two IOAPICs. */ + /* FIXME should find device and ask for address! */ + apic_addr = 0xfc200000; + current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current, 5, + apic_addr, 0); + apic_addr = 0xfc201000; + current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current, 6, + apic_addr, 0);
The last parameter of both APIC cannot be 0, it must be the offset called "system vector base" usually if the first apic has 24 inputs. Second base starts at 24... This just put the numbers in _PRT to relationship in what APIC is what global IRQ (sometimes called GSI)
Good is a figure on page 138 (in pdf) in acpi 3.0 specs. You will get it quickly once looking to the picture.
Also very good is a picture in MP specs which shows how the 8259 and apics are connected:
http://www.intel.com/design/pentium/datashts/24201606.pdf Its on page 65.
There you see why the IRQ2 override is neccessary. The bus 0 which is ISA has identity mappings of 8259 IRQs 0-15 to apic pins 0-15 with exception of IRQ0(APIC) where no timer is connected but the output from 8259s. The IRQ2 (pin2) on APIC is used as IRQ0(ISA)
I think there is a chance that it will start to work. You will also need to put the APIC in SB to virtual wire mode, so the 8259 can be used. (This is for DOS, I think linux needs that only for a while)
Rudolf
On Fri, Feb 13, 2009 at 2:27 PM, Rudolf Marek r.marek@assembler.cz wrote:
Hello,
I wasn't clear. I needed the address for the fadt pm_base. Since coreboot allocates it at 0x1000 and the factory BIOS allocates it at 0x8000 I was having a hard time finding it.
OK hopefully it is static ;)
I read it from the device in fadt.c. If it needs to be set somewhere else, I haven't found it yet.
Do you get that error too, or was I supposed to change some value to make it work?
Perhaps something was missing? I dont know. Lets solve this later.
Sure.
for SATA 0 the _PR looks like this:
Package (0x04) { 0x0007FFFF, 0x00, 0x00, 0x17 }, //sata at 7.0 goes to IRQ 23
Thanks, that helped a lot. I'm still not booting though. I get this error in the boot log, then the hard drives stop working. The interrupts shouldn't be at fault, because they match the mptable.
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... ..... (found apic 0 pin 0) ... ....... failed. ...trying to set up timer as Virtual Wire IRQ... ..... failed. ...trying to set up timer as ExtINT IRQ... ..... works.
Here's the first line from the acpi=off boot: ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=0 pin2=0
Unfortunately I can't see where it gets set to correct it.
Aha you need also a MADT table. It seems this table is bit mess:
This is for IRQ9 to be the ACPI irq level low triggered:
current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)current, 0, 9, 9, 0xF);
This one matches the factory BIOS, but I'll try the other one.
You need this:
/* IRQ0 -> APIC IRQ2. */ current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *) current, 0, 0, 2, 0x0);Check the original BIOS whats inside the MADT please.
They are now identical except for the headers and the addresses of the IOAPICs.
the first zero is 0 which is ISA bus. The second 0 is bus relative source of IRQ - IRQ0 in our case. But IRQ0 is not mapped to IRQ0 but to pin2 on APIC so We create a mapping of IRQ0->IRQ2
Also this is also wrong: /* Write NVIDIA CK804 IOAPIC. */
current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current,4,
IO_APIC_ADDR, 0);/* Write AMD 8131 two IOAPICs. *//* FIXME should find device and ask for address! */apic_addr = 0xfc200000;current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current,5,
apic_addr, 0);apic_addr = 0xfc201000;current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current,6,
apic_addr, 0);The last parameter of both APIC cannot be 0, it must be the offset called "system vector base" usually if the first apic has 24 inputs. Second base starts at 24... This just put the numbers in _PRT to relationship in what APIC is what global IRQ (sometimes called GSI)
Good catch! I saw that I needed to set the APIC offsets from the documentation, but I couldn't see where it belonged. Thanks.
Good is a figure on page 138 (in pdf) in acpi 3.0 specs. You will get it quickly once looking to the picture.
Thanks for the pointer.
Also very good is a picture in MP specs which shows how the 8259 and apics are connected:
http://www.intel.com/design/pentium/datashts/24201606.pdf Its on page 65.
There you see why the IRQ2 override is neccessary. The bus 0 which is ISA has identity mappings of 8259 IRQs 0-15 to apic pins 0-15 with exception of IRQ0(APIC) where no timer is connected but the output from 8259s. The IRQ2 (pin2) on APIC is used as IRQ0(ISA)
I think there is a chance that it will start to work. You will also need to put the APIC in SB to virtual wire mode, so the 8259 can be used. (This is for DOS, I think linux needs that only for a while)
I'll look around in the source.
Thanks, Myles
Hi,
current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)current, 0, 9, 9, 0xF);This one matches the factory BIOS, but I'll try the other one.
It should be OK to leave it as it is. You dont have another IRQ overrides? Perhaps there must be some for timer IRQ...
They are now identical except for the headers and the addresses of the IOAPICs.
hmm this is strange... maybe we can leave there the only irq9 override for now. But you will need to put APIC to virtual wire mode maybe.
Good catch! I saw that I needed to set the APIC offsets from the documentation, but I couldn't see where it belonged. Thanks.
I updated the wiki page. Check it.
Rudolf
On Fri, Feb 13, 2009 at 3:58 PM, Rudolf Marek r.marek@assembler.cz wrote:
Hi,
current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t*)
current, 0, 9, 9, 0xF);This one matches the factory BIOS, but I'll try the other one.
Just to make sure, I added the override for 2.
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored.
It should be OK to leave it as it is. You dont have another IRQ overrides? Perhaps there must be some for timer IRQ...
I don't know. In the mptable, I see an interrupt from 0x0 t0 0x2, but it is on bus 0x82, not bus 0. It doesn't make too much sense to me.
add intsrc srcbus 0x82 srcbusirq 0x0, dstapic 0x4, dstirq 0x0 add intsrc srcbus 0x82 srcbusirq 0x1, dstapic 0x4, dstirq 0x1 add intsrc srcbus 0x82 srcbusirq 0x0, dstapic 0x4, dstirq 0x2 add intsrc srcbus 0x82 srcbusirq 0x3, dstapic 0x4, dstirq 0x3 add intsrc srcbus 0x82 srcbusirq 0x4, dstapic 0x4, dstirq 0x4 add intsrc srcbus 0x82 srcbusirq 0x6, dstapic 0x4, dstirq 0x6 add intsrc srcbus 0x82 srcbusirq 0x7, dstapic 0x4, dstirq 0x7 add intsrc srcbus 0x82 srcbusirq 0x8, dstapic 0x4, dstirq 0x8 add intsrc srcbus 0x82 srcbusirq 0xc, dstapic 0x4, dstirq 0xc add intsrc srcbus 0x82 srcbusirq 0xd, dstapic 0x4, dstirq 0xd add intsrc srcbus 0x82 srcbusirq 0xe, dstapic 0x4, dstirq 0xe add intsrc srcbus 0x82 srcbusirq 0xf, dstapic 0x4, dstirq 0xf add intsrc srcbus 0x0 srcbusirq 0x5, dstapic 0x4, dstirq 0xa add intsrc srcbus 0x0 srcbusirq 0x8, dstapic 0x4, dstirq 0x15 add intsrc srcbus 0x0 srcbusirq 0x9, dstapic 0x4, dstirq 0x14 add intsrc srcbus 0x0 srcbusirq 0x10, dstapic 0x4, dstirq 0x14 add intsrc srcbus 0x0 srcbusirq 0x1c, dstapic 0x4, dstirq 0x17 add intsrc srcbus 0x0 srcbusirq 0x20, dstapic 0x4, dstirq 0x16 add intsrc srcbus 0x0 srcbusirq 0x28, dstapic 0x4, dstirq 0x15 add intsrc srcbus 0x2 srcbusirq 0x0, dstapic 0x4, dstirq 0x12 add intsrc srcbus 0x2 srcbusirq 0x1, dstapic 0x4, dstirq 0x13 add intsrc srcbus 0x2 srcbusirq 0x2, dstapic 0x4, dstirq 0x10 add intsrc srcbus 0x2 srcbusirq 0x3, dstapic 0x4, dstirq 0x11 add intsrc srcbus 0x1 srcbusirq 0x14, dstapic 0x4, dstirq 0x13 add intsrc srcbus 0x1 srcbusirq 0x10, dstapic 0x4, dstirq 0x10 add intsrc srcbus 0x1 srcbusirq 0x11, dstapic 0x4, dstirq 0x11 add intsrc srcbus 0x1 srcbusirq 0x12, dstapic 0x4, dstirq 0x12 add intsrc srcbus 0x1 srcbusirq 0x13, dstapic 0x4, dstirq 0x13 add intsrc srcbus 0x80 srcbusirq 0x28, dstapic 0x7, dstirq 0x15 add intsrc srcbus 0x81 srcbusirq 0x0, dstapic 0x7, dstirq 0x12 add intsrc srcbus 0x81 srcbusirq 0x1, dstapic 0x7, dstirq 0x13 add intsrc srcbus 0x81 srcbusirq 0x2, dstapic 0x7, dstirq 0x10 add intsrc srcbus 0x81 srcbusirq 0x3, dstapic 0x7, dstirq 0x11 add intsrc srcbus 0x41 srcbusirq 0x10, dstapic 0x6, dstirq 0x0 add intsrc srcbus 0x41 srcbusirq 0x11, dstapic 0x6, dstirq 0x1 add intsrc srcbus 0x41 srcbusirq 0x12, dstapic 0x6, dstirq 0x2 add intsrc srcbus 0x41 srcbusirq 0x13, dstapic 0x6, dstirq 0x3 add intsrc srcbus 0x41 srcbusirq 0x24, dstapic 0x6, dstirq 0x1 add intsrc srcbus 0x41 srcbusirq 0x25, dstapic 0x6, dstirq 0x2 add intsrc srcbus 0x41 srcbusirq 0x26, dstapic 0x6, dstirq 0x3 add intsrc srcbus 0x41 srcbusirq 0x27, dstapic 0x6, dstirq 0x0 add intsrc srcbus 0x41 srcbusirq 0x18, dstapic 0x6, dstirq 0x2 add intsrc srcbus 0x41 srcbusirq 0x19, dstapic 0x6, dstirq 0x3 add intsrc srcbus 0x41 srcbusirq 0x10, dstapic 0x5, dstirq 0x0 add intsrc srcbus 0x41 srcbusirq 0x11, dstapic 0x5, dstirq 0x1 add intsrc srcbus 0x41 srcbusirq 0x12, dstapic 0x5, dstirq 0x2 add intsrc srcbus 0x41 srcbusirq 0x13, dstapic 0x5, dstirq 0x3 add intsrc srcbus 0x82 srcbusirq 0x0, dstapic 0xff, dstirq 0x0 add intsrc srcbus 0x82 srcbusirq 0x0, dstapic 0xff, dstirq 0x1
Looking at this made me remember that only PCI0 gets parsed by the kernel. I don't know why it skips the other root buses. ACPI: bus type pci registered PCI: Using configuration type 1 for base access ACPI: EC: Look up EC in DSDT ACPI: Interpreter enabled ACPI: (supports S0 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: 0000:00:01.0 reg 10 io port: [2400, 247f] PCI: 0000:00:01.0 reg 14 32bit mmio: [f5200000, f5200fff] ... PCI: 0000:02:00.0 reg 30 32bit mmio: [f5000000, f501ffff] PCI: bridge 0000:00:0e.0 32bit mmio: [f0000000, f50fffff] PCI: bridge 0000:00:0e.0 64bit mmio pref: [e0000000, efffffff] ACPI: PCI Interrupt Routing Table [_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [_SB_.PCI0.PCIL._PRT] ACPI: PCI Interrupt Routing Table [_SB_.PCI0.PE16._PRT] Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered
I was expecting to see entries for PCI1 and PCI2. When I run acpiexec I can see them with the namespace command.
They are now identical except for the headers and the addresses of the IOAPICs.
hmm this is strange... maybe we can leave there the only irq9 override for now. But you will need to put APIC to virtual wire mode maybe.
As long as I make it match the mptable, shouldn't it just work?
Right now I can't get it to match because the other busses are never parsed so those PRT entries are ignored.
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored.
OK maybe it belongs to another APIC dont know. Maybe just ignore this.
Looking at this made me remember that only PCI0 gets parsed by the kernel. I don't know why it skips the other root buses.
Do you have them in DSDT? Please post your current DSDT. You will need also some another device for second PCI bus.
As long as I make it match the mptable, shouldn't it just work?
It should.
Right now I can't get it to match because the other busses are never parsed so those PRT entries are ignored.
Check this FAQ: http://www.acpi.info/acpi_faq.htm
Q: But how about a multiple root bus machine? How do I report several CPU-to-PCI bridges (root PCI Buses) in the ACPI NameSpace?
You will need _BBN object.
Thanks, Rudolf
On Tue, Feb 17, 2009 at 1:59 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored.
OK maybe it belongs to another APIC dont know. Maybe just ignore this.
Looking at this made me remember that only PCI0 gets parsed by the kernel. I don't know why it skips the other root buses.
Do you have them in DSDT?
I tried to put them in there :)
Please post your current DSDT.
Attached.
You will need also some another device for second PCI bus.
I added a device for each root PCI bus.
As long as I make it match the mptable, shouldn't it just work?
It should.
Right now I can't get it to match because the other busses are never parsed so those PRT entries are ignored.
Check this FAQ: http://www.acpi.info/acpi_faq.htm
Q: But how about a multiple root bus machine? How do I report several CPU-to-PCI bridges (root PCI Buses) in the ACPI NameSpace?
You will need _BBN object.
I didn't see what I'm missing there.
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
- From the first overlook it looks fine. Please enable the ACPI debug stuff in kernel. Then we should see what is going on. Also lspci from running system would be fine.
Rudolf
On Tue, Feb 17, 2009 at 2:41 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
- From the first overlook it looks fine. Please enable the ACPI debug stuff in
kernel. Then we should see what is going on. Also lspci from running system would be fine.
The lspci is easy. I'll reconfigure and recompile the kernel tomorrow.
Thanks, Myles
On Tue, Feb 17, 2009 at 2:41 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
- From the first overlook it looks fine. Please enable the ACPI debug stuff in
kernel.
Do you have a suggestion for debug values to pass in? The default value doesn't seem high enough but I'm not excited about the spew I might get if I enable it all :)
It boots but still doesn't find the other buses. It turns out that the hard coded 0xfec00000 wasn't the right IOAPIC address for coreboot. Now interrupts are working, but there are still some things that are not quite right.
Thanks, Myles
Hi,
Do you have a suggestion for debug values to pass in? The default value doesn't seem high enough but I'm not excited about the spew I might get if I enable it all :)
Sorry no idea.
It boots but still doesn't find the other buses. It turns out that the hard coded 0xfec00000 wasn't the right IOAPIC address for coreboot. Now interrupts are working, but there are still some things that are not quite right.
As the other busses missing in ACPI or something else too?
Thanks, Rudolf
Thanks, Myles
On Tue, Jan 20, 2009 at 4:08 PM, Stefan Reinauer stepan@coresystems.de wrote:
Here's my latest patch. It contains generic parts, northbridge specific parts and board specific parts.
Please let me know what you think.
Index: src/northbridge/intel/i945/northbridge.c =================================================================== --- src/northbridge/intel/i945/northbridge.c (revision 3886) +++ src/northbridge/intel/i945/northbridge.c (working copy) @@ -93,12 +93,18 @@ return tolm; }
+#if HAVE_HIGH_TABLES==1 +#define HIGH_TABLES_SIZE 64 // maximum size of high tables in KB +extern uint64_t high_tables_base, high_tables_size; +#endif +uint64_t uma_memory_base=0, uma_memory_size=0; + static void pci_domain_set_resources(device_t dev) { uint32_t pci_tolm; uint8_t tolud, reg8; uint16_t reg16; - unsigned long long tomk, tolmk; + unsigned long long tomk;
pci_tolm = find_pci_tolm(&dev->link[0]);
@@ -120,13 +126,13 @@ switch (reg8) { case 0: tseg_size = 1024; - break; + break; /* TSEG = 1M */ case 1: tseg_size = 2048; - break; + break; /* TSEG = 2M */ case 2: tseg_size = 8192; - break; + break; /* TSEG = 8M */ }
printk_debug("%dM\n", tseg_size >> 10); @@ -150,24 +156,32 @@
printk_debug("%dM UMA\n", uma_size >> 10); tomk -= uma_size; + + /* For reserving UMA memory in the memory map */ + uma_memory_base = tomk * 1024ULL; + uma_memory_size = uma_size * 1024ULL; }
/* The following needs to be 2 lines, otherwise the second * number is always 0 */ - printk_info("Available memory: %dK", tomk); - printk_info(" (%dM)\n", (tomk >> 10)); + printk_info("Available memory: %dK", (uint32_t)tomk); + printk_info(" (%dM)\n", (uint32_t)(tomk >> 10));
- tolmk = tomk; - /* Report the memory regions */ ram_resource(dev, 3, 0, 640); - ram_resource(dev, 4, 768, (tolmk - 768)); + ram_resource(dev, 4, 768, (tomk - 768)); if (tomk > 4 * 1024 * 1024) { ram_resource(dev, 5, 4096 * 1024, tomk - 4 * 1024 * 1024); }
assign_resources(&dev->link[0]); + +#if HAVE_HIGH_TABLES==1 + /* Leave some space for ACPI, PIRQ and MP tables */ + high_tables_base = (tomk - HIGH_TABLES_SIZE) * 1024; + high_tables_size = HIGH_TABLES_SIZE * 1024; +#endif }
Does this work for you with 4G of RAM? I don't have a Kontron board, but I copied the implementation to the amdk8 northbridge code. It works for me when I have the RAM "boosted" and it works when I boot with less than 4G, but if I boot with 4G it tries to put the high tables in the PCI decode space since they overlap.
Besides that the patch is working well for me, and I'd like to see it merged.
If it works in the 4G case and I just didn't implement it right for K8:
Acked-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On Fri, Feb 27, 2009 at 10:42 AM, Myles Watson mylesgw@gmail.com wrote:
Does this work for you with 4G of RAM? I don't have a Kontron board, but I copied the implementation to the amdk8 northbridge code. It works for me when I have the RAM "boosted" and it works when I boot with less than 4G, but if I boot with 4G it tries to put the high tables in the PCI decode space since they overlap.
Besides that the patch is working well for me, and I'd like to see it merged.
If it works in the 4G case and I just didn't implement it right for K8:
Acked-by: Myles Watson mylesgw@gmail.com
Do you have an off by 1 problem? That would cause the problem @ 4GB as you described.
Marc
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Friday, February 27, 2009 10:51 AM To: Myles Watson Cc: Stefan Reinauer; Coreboot Subject: Re: [coreboot] Coreboot patches for v2 with SeaBIOS
On Fri, Feb 27, 2009 at 10:42 AM, Myles Watson mylesgw@gmail.com wrote:
Does this work for you with 4G of RAM? I don't have a Kontron board, but I copied the implementation to the amdk8 northbridge code. It works for me when I have the RAM "boosted" and it works when I boot with less than 4G, but if I boot with 4G it tries to put the high tables in the PCI decode space since they overlap.
Besides that the patch is working well for me, and I'd like to see it
merged.
If it works in the 4G case and I just didn't implement it right for K8:
Acked-by: Myles Watson mylesgw@gmail.com
Do you have an off by 1 problem? That would cause the problem @ 4GB as you described.
I'm confused ( again :) )
I'm not sure where the off by one problem would be.
I thought the problem was that when you have the top of RAM at 0x100000000 and then subtract some small number from it you end up at 0xffff0000, which isn't where you should be accessing normal RAM, or reserving it for ACPI.
Thanks, Myles
On Fri, Feb 27, 2009 at 12:40 PM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Friday, February 27, 2009 10:51 AM To: Myles Watson Cc: Stefan Reinauer; Coreboot Subject: Re: [coreboot] Coreboot patches for v2 with SeaBIOS
On Fri, Feb 27, 2009 at 10:42 AM, Myles Watson mylesgw@gmail.com wrote:
Does this work for you with 4G of RAM? I don't have a Kontron board, but I copied the implementation to the amdk8 northbridge code. It works for me when I have the RAM "boosted" and it works when I boot with less than 4G, but if I boot with 4G it tries to put the high tables in the PCI decode space since they overlap.
Besides that the patch is working well for me, and I'd like to see it
merged.
If it works in the 4G case and I just didn't implement it right for K8:
Acked-by: Myles Watson mylesgw@gmail.com
Do you have an off by 1 problem? That would cause the problem @ 4GB as you described.
I'm confused ( again :) )
I'm not sure where the off by one problem would be.
I thought the problem was that when you have the top of RAM at 0x100000000 and then subtract some small number from it you end up at 0xffff0000, which isn't where you should be accessing normal RAM, or reserving it for ACPI.
I guess I didn't understand what you were saying. I assumed it was a problem with a size calculation at 4GB. If you have 4GB of memory it should hoist (boost) some portion of it. 512MB or 1GB typically. Is there a bug in the memory hoist code? Can you check what the tomk is with 4GB
Marc
On Fri, Feb 27, 2009 at 1:10 PM, Marc Jones marcj303@gmail.com wrote:
On Fri, Feb 27, 2009 at 12:40 PM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Friday, February 27, 2009 10:51 AM To: Myles Watson Cc: Stefan Reinauer; Coreboot Subject: Re: [coreboot] Coreboot patches for v2 with SeaBIOS
On Fri, Feb 27, 2009 at 10:42 AM, Myles Watson mylesgw@gmail.com wrote:
Does this work for you with 4G of RAM? I don't have a Kontron board, but I copied the implementation to the amdk8 northbridge code. It works for me when I have the RAM "boosted" and it works when I boot with less than 4G, but if I boot with 4G it tries to put the high tables in the PCI decode space since they overlap.
Besides that the patch is working well for me, and I'd like to see it
merged.
If it works in the 4G case and I just didn't implement it right for K8:
Acked-by: Myles Watson mylesgw@gmail.com
Do you have an off by 1 problem? That would cause the problem @ 4GB as you described.
I'm confused ( again :) )
I'm not sure where the off by one problem would be.
I thought the problem was that when you have the top of RAM at 0x100000000 and then subtract some small number from it you end up at 0xffff0000, which isn't where you should be accessing normal RAM, or reserving it for ACPI.
I guess I didn't understand what you were saying. I assumed it was a problem with a size calculation at 4GB. If you have 4GB of memory it should hoist (boost) some portion of it. 512MB or 1GB typically. Is there a bug in the memory hoist code? Can you check what the tomk is with 4GB
Sorry that took a while. Here are snippets of the output (full output attached)
//4 GB getting cleared: Setting up local apic... apic_id: 0x00 done. Clearing memory 2048K - 4194304K: --------------------------------------------------------------- done CPU #0 initialized ... //This is from northbridge.c where I grabbed the space for the high tables: 0: mmio_basek=003e0000, basek=003e0000, limitk=00400000 VGA: PCI: 00:18.0 (aka node 0) link 0 has VGA device PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] size 0x00003000 gran 0x0c io <node 0 link 0> PCI: 00:18.0 1b8 <- [0x00fd400000 - 0x00fd3fffff] size 0x00000000 gran 0x14 prefmem <node 0 link 0> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd1fffff] size 0x01200000 gran 0x14 mem <node 0 link 0> PCI: 00:18.0 1da <- [0x0000004000 - 0x0000003fff] size 0x00000000 gran 0x0c io <node 0 link 2> PCI: 00:18.0 1aa <- [0x00fd400000 - 0x00fd3fffff] size 0x00000000 gran 0x14 prefmem <node 0 link 2> PCI: 00:18.0 1a2 <- [0x00fd200000 - 0x00fd3fffff] size 0x00200000 gran 0x14 mem <node 0 link 2> PCI: 00:01.0 10 <- [0x0000002c00 - 0x0000002c7f] size 0x00000080 gran 0x07 io ... //This is the code trying to write the high tables into the ROM :) Devices initialized High Tables Base is ffff0000. Writing IRQ routing tables to 0xffff0000...done. ACPI: Writing ACPI tables at ffff0400. ACPI: * FACS ffff04c0 ACPI: * DSDT ffff0500 ACPI: * DSDT @ ffff0500 Length b7000f6d ACPI: * FACP (FADT) @ ffff0ef0 pm_base: 0x2000 ACPI: could not add ACPI table to RSDT. failed. ACPI: * HPET @ ffff0ff0 ACPI: could not add ACPI table to RSDT. failed. ACPI: * APIC/MADT @ ffff1030 ACPI: could not add ACPI table to RSDT. failed. ACPI: * SRAT @ c0aa8290 SRAT: lapic cpu_index=00, node_id=00, apic_id=00 set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0010 startk=00000000, sizek=00000280 set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0020 startk=00000300, sizek=003dfd00 ACPI: could not add ACPI table to RSDT. failed. ACPI: * SLIT @ c0aa8320 ACPI: could not add ACPI table to RSDT. failed. ACPI: * SSDT @ c0aa8350 processor_brand=AMD Opteron(tm) Processor 248 Pstates Algorithm ...
Thanks, Myles
On Fri, Feb 27, 2009 at 2:10 PM, Myles Watson mylesgw@gmail.com wrote:
On Fri, Feb 27, 2009 at 1:10 PM, Marc Jones marcj303@gmail.com wrote:
On Fri, Feb 27, 2009 at 12:40 PM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Friday, February 27, 2009 10:51 AM To: Myles Watson Cc: Stefan Reinauer; Coreboot Subject: Re: [coreboot] Coreboot patches for v2 with SeaBIOS
On Fri, Feb 27, 2009 at 10:42 AM, Myles Watson mylesgw@gmail.com wrote:
Does this work for you with 4G of RAM? I don't have a Kontron board, but I copied the implementation to the amdk8 northbridge code. It works for me when I have the RAM "boosted" and it works when I boot with less than 4G, but if I boot with 4G it tries to put the high tables in the PCI decode space since they overlap.
Besides that the patch is working well for me, and I'd like to see it
merged.
If it works in the 4G case and I just didn't implement it right for K8:
Acked-by: Myles Watson mylesgw@gmail.com
Do you have an off by 1 problem? That would cause the problem @ 4GB as you described.
I'm confused ( again :) )
I'm not sure where the off by one problem would be.
I thought the problem was that when you have the top of RAM at 0x100000000 and then subtract some small number from it you end up at 0xffff0000, which isn't where you should be accessing normal RAM, or reserving it for ACPI.
I guess I didn't understand what you were saying. I assumed it was a problem with a size calculation at 4GB. If you have 4GB of memory it should hoist (boost) some portion of it. 512MB or 1GB typically. Is there a bug in the memory hoist code? Can you check what the tomk is with 4GB
Sorry that took a while. Here are snippets of the output (full output attached)
//4 GB getting cleared: Setting up local apic... apic_id: 0x00 done. Clearing memory 2048K - 4194304K: --------------------------------------------------------------- done CPU #0 initialized ... //This is from northbridge.c where I grabbed the space for the high tables: 0: mmio_basek=003e0000, basek=003e0000, limitk=00400000
It looks like CONFIG_HW_MEM_HOLE_SIZEK might not be set. I don't think that you are getting any memory hoisted.
Marc
On Fri, Feb 27, 2009 at 2:25 PM, Marc Jones marcj303@gmail.com wrote:
On Fri, Feb 27, 2009 at 2:10 PM, Myles Watson mylesgw@gmail.com wrote:
On Fri, Feb 27, 2009 at 1:10 PM, Marc Jones marcj303@gmail.com wrote:
On Fri, Feb 27, 2009 at 12:40 PM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Friday, February 27, 2009 10:51 AM To: Myles Watson Cc: Stefan Reinauer; Coreboot Subject: Re: [coreboot] Coreboot patches for v2 with SeaBIOS
On Fri, Feb 27, 2009 at 10:42 AM, Myles Watson mylesgw@gmail.com wrote:
Does this work for you with 4G of RAM? I don't have a Kontron board, but I copied the implementation to the amdk8 northbridge code. It works for me when I have the RAM "boosted" and it works when I boot with less than 4G, but if I boot with 4G it tries to put the high tables in the PCI decode space since they overlap.
Besides that the patch is working well for me, and I'd like to see it
merged.
If it works in the 4G case and I just didn't implement it right for K8:
Acked-by: Myles Watson mylesgw@gmail.com
Do you have an off by 1 problem? That would cause the problem @ 4GB as you described.
I'm confused ( again :) )
I'm not sure where the off by one problem would be.
I thought the problem was that when you have the top of RAM at 0x100000000 and then subtract some small number from it you end up at 0xffff0000, which isn't where you should be accessing normal RAM, or reserving it for ACPI.
I guess I didn't understand what you were saying. I assumed it was a problem with a size calculation at 4GB. If you have 4GB of memory it should hoist (boost) some portion of it. 512MB or 1GB typically. Is there a bug in the memory hoist code? Can you check what the tomk is with 4GB
Sorry that took a while. Here are snippets of the output (full output attached)
//4 GB getting cleared: Setting up local apic... apic_id: 0x00 done. Clearing memory 2048K - 4194304K: --------------------------------------------------------------- done CPU #0 initialized ... //This is from northbridge.c where I grabbed the space for the high tables: 0: mmio_basek=003e0000, basek=003e0000, limitk=00400000
It looks like CONFIG_HW_MEM_HOLE_SIZEK might not be set. I don't think that you are getting any memory hoisted.
I guess I'll have to look into it more. CONFIG_HW_MEM_HOLE_SIZEK = 1048576 CONFIG_HW_MEM_HOLE_SIZE_AUTO_INC = 0
The Options.lb files are nearly identical for the s2895 and s2892. The s2895 is hoisting, but 2G of the RAM is in slots attached to the second Opteron. The s2892 isn't hoisting.
Thanks, Myles
On Fri, Feb 27, 2009 at 2:32 PM, Myles Watson mylesgw@gmail.com wrote:
- Show quoted text -
On Fri, Feb 27, 2009 at 2:25 PM, Marc Jones marcj303@gmail.com wrote:
On Fri, Feb 27, 2009 at 2:10 PM, Myles Watson mylesgw@gmail.com wrote:
On Fri, Feb 27, 2009 at 1:10 PM, Marc Jones marcj303@gmail.com wrote:
On Fri, Feb 27, 2009 at 12:40 PM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Friday, February 27, 2009 10:51 AM To: Myles Watson Cc: Stefan Reinauer; Coreboot Subject: Re: [coreboot] Coreboot patches for v2 with SeaBIOS
On Fri, Feb 27, 2009 at 10:42 AM, Myles Watson mylesgw@gmail.com wrote:
> Does this work for you with 4G of RAM? I don't have a Kontron board, > but I copied the implementation to the amdk8 northbridge code. It > works for me when I have the RAM "boosted" and it works when I boot > with less than 4G, but if I boot with 4G it tries to put the high > tables in the PCI decode space since they overlap. > > Besides that the patch is working well for me, and I'd like to see it merged. > > If it works in the 4G case and I just didn't implement it right for K8: > > Acked-by: Myles Watson mylesgw@gmail.com >
Do you have an off by 1 problem? That would cause the problem @ 4GB as you described.
I'm confused ( again :) )
I'm not sure where the off by one problem would be.
I thought the problem was that when you have the top of RAM at 0x100000000 and then subtract some small number from it you end up at 0xffff0000, which isn't where you should be accessing normal RAM, or reserving it for ACPI.
I guess I didn't understand what you were saying. I assumed it was a problem with a size calculation at 4GB. If you have 4GB of memory it should hoist (boost) some portion of it. 512MB or 1GB typically. Is there a bug in the memory hoist code? Can you check what the tomk is with 4GB
Sorry that took a while. Here are snippets of the output (full output attached)
//4 GB getting cleared: Setting up local apic... apic_id: 0x00 done. Clearing memory 2048K - 4194304K: --------------------------------------------------------------- done CPU #0 initialized ... //This is from northbridge.c where I grabbed the space for the high tables: 0: mmio_basek=003e0000, basek=003e0000, limitk=00400000
It looks like CONFIG_HW_MEM_HOLE_SIZEK might not be set. I don't think that you are getting any memory hoisted.
You're right.
I guess I'll have to look into it more. CONFIG_HW_MEM_HOLE_SIZEK = 1048576 CONFIG_HW_MEM_HOLE_SIZE_AUTO_INC = 0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Setting resources... pci_domain_set_resources: HOLE_SIZEK=00100000, mmio_basek=003e0000 before hole check node 0 : mmio_basek=003e0000, basek=00000000, limitk=00400000 node 0 : mmio_basek=003e0000, basek=00000300, limitk=00400000 split needed: basek=00000300, limitk=00400000 first region of split: basek=00000300, pre_sizek=003dfd00 size left: sizek=00020000 node 0@30 basek=003e0000, sizek=00000000 0: mmio_basek=003e0000, basek=003e0000, limitk=00400000 40K table at =f7ff0000 VGA: PCI: 00:18.0 (aka node 0) link 0 has VGA device
It looks like it's using mmio_basek instead of limitk-HOLE_SIZEK for the first region. Then it doesn't do the second region.
Thanks, Myles
Myles Watson wrote:
Does this work for you with 4G of RAM?
My boards don't support that much.. :-( Have to try on the AMD boards some time. But I guess if the chipset supports more than 4G you'd have to put the high_table_base to the top of low memory (default would be below 3G I guess) There's no structural problem that would disallow using the mechanism with any amount of RAM.
I don't have a Kontron board, but I copied the implementation to the amdk8 northbridge code. It works for me when I have the RAM "boosted" and it works when I boot with less than 4G, but if I boot with 4G it tries to put the high tables in the PCI decode space since they overlap.
Besides that the patch is working well for me, and I'd like to see it merged.
If it works in the 4G case and I just didn't implement it right for K8:
Acked-by: Myles Watson mylesgw@gmail.com
Thanks, r3960
On Fri, Feb 27, 2009 at 4:15 PM, Stefan Reinauer stepan@coresystems.de wrote:
Myles Watson wrote:
Does this work for you with 4G of RAM?
My boards don't support that much.. :-(
No problem.
Have to try on the AMD boards some time. But I guess if the chipset supports more than 4G you'd have to put the high_table_base to the top of low memory (default would be below 3G I guess) There's no structural problem that would disallow using the mechanism with any amount of RAM.
It works fine for me with boosted memory. It just doesn't work when the RAM stays low. Maybe I'm hitting some corner case for a 32-bit OS that doesn't want to boost the RAM outside the addressable space.
Thanks, Myles
Myles Watson wrote:
On Fri, Feb 27, 2009 at 4:15 PM, Stefan Reinauer stepan@coresystems.de wrote:
Myles Watson wrote:
Does this work for you with 4G of RAM?
My boards don't support that much.. :-(
No problem.
Have to try on the AMD boards some time. But I guess if the chipset supports more than 4G you'd have to put the high_table_base to the top of low memory (default would be below 3G I guess) There's no structural problem that would disallow using the mechanism with any amount of RAM.
It works fine for me with boosted memory. It just doesn't work when the RAM stays low. Maybe I'm hitting some corner case for a 32-bit OS that doesn't want to boost the RAM outside the addressable space.
What's boosted memory?
You must, under any circumstance, keep the high_table_area in the lower 4G and you must make sure no PCI devices (or other onboard stuff) are where you'd expect memory.
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Friday, February 27, 2009 4:39 PM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] Coreboot patches for v2 with SeaBIOS
Myles Watson wrote:
On Fri, Feb 27, 2009 at 4:15 PM, Stefan Reinauer stepan@coresystems.de
wrote:
Myles Watson wrote:
Does this work for you with 4G of RAM?
My boards don't support that much.. :-(
No problem.
Have to try on the AMD boards some time. But I guess if the chipset supports more than 4G you'd have to put the high_table_base to the top of low memory (default would be below 3G I guess) There's no structural problem that would disallow using the mechanism with any amount of RAM.
It works fine for me with boosted memory. It just doesn't work when the RAM stays low. Maybe I'm hitting some corner case for a 32-bit OS that doesn't want to boost the RAM outside the addressable space.
What's boosted memory?
Boosted memory is when the k8 maps its memory around the PCI space. When you make a hole the memory that gets moved up is boosted.
You must, under any circumstance, keep the high_table_area in the lower 4G and you must make sure no PCI devices (or other onboard stuff) are where you'd expect memory.
So as long as the memory hole is larger than the PCI space it should be fine. If I'm losing memory because it conflicts with PCI space, I'll lose the tables. That makes sense.
Thanks, Myles
-
Kevin O'Connor -
Marc Jones -
Myles Watson -
Rudolf Marek -
Stefan Reinauer -
yhlu