| Submitter | Myles Watson |
|---|---|
| Date | 2010-12-02 16:28:32 |
| Message ID | <AANLkTinXS0cTww=P-FttP2Gor+4gKkP7ZrOnkhYmDxRe@mail.gmail.com> |
| Download | mbox | patch |
| Permalink | /patch/2385/ |
| State | Accepted |
| Commit | r6148 |
| Headers | show |
Comments
On Thu, Dec 2, 2010 at 9:17 AM, Myles Watson <mylesgw@gmail.com> wrote: >> "Why does the current code for handling fixed resources allow the mmconf >> space to get allocated to a PCI device? Function avoid_fixed_resources >> calls function constrain_resources, which recursively searches the >> device tree for fixed io and memory resources. The ioapic fixed memory >> address is found and avoided during the recursive search because this >> southbridge device is below the level where the search starts. On the >> other hand, the mmconf fixed resource is added from the northbridge code, >> and falls under 'APIC_CLUSTER: 0'. This device is not part of the search >> for two reasons. One is that it is not at or below 'pci_domain 0' in the >> device tree. Another reason is that its type is APIC_CLUSTER and not >> PCI_DOMAIN." > I don't see any reason not to move that resource into the northbridge > to avoid that issue. It's a simple fix. Is there a good reason for > having the MMCONF BAR in the APIC cluster? This is what I was thinking. Build tested only. Signed-off-by: Myles Watson <mylesgw@gmail.com> Thanks, Myles Thanks Myles. I tested using the Kino project. With mmconf_base_address set to e0000000, mmconf_bus_number set to 256, and no patch, booting hangs in vbios init. Adding the patch allows it to boot, and I find no bars overlapping the mmconf area. This patch seems to solve the problem for me. If I get a chance, I will try Win7 boot also. Thanks, Scott
> > I don't see any reason not to move that resource into the northbridge > > to avoid that issue. It's a simple fix. Is there a good reason for > > having the MMCONF BAR in the APIC cluster? > This is what I was thinking. Build tested only. > > Signed-off-by: Myles Watson <mylesgw@gmail.com> > > Thanks, > Myles > > Thanks Myles. I tested using the Kino project. With mmconf_base_address > set to e0000000, mmconf_bus_number set to 256, and no patch, booting > hangs in vbios init. Adding the patch allows it to boot, and I find no > bars overlapping the mmconf area. This patch seems to solve the problem > for me. If I get a chance, I will try Win7 boot also. I'm glad it worked. The next thing would be to fix it so that it didn't have to be in a fixed location. It should be relatively easy to do. Thanks, Myles
Myles Watson wrote: > On Thu, Dec 2, 2010 at 9:17 AM, Myles Watson <mylesgw@gmail.com> wrote: >>> "Why does the current code for handling fixed resources allow the mmconf >>> space to get allocated to a PCI device? Function avoid_fixed_resources >>> calls function constrain_resources, which recursively searches the >>> device tree for fixed io and memory resources. The ioapic fixed memory >>> address is found and avoided during the recursive search because this >>> southbridge device is below the level where the search starts. On the >>> other hand, the mmconf fixed resource is added from the northbridge code, >>> and falls under 'APIC_CLUSTER: 0'. This device is not part of the search >>> for two reasons. One is that it is not at or below 'pci_domain 0' in the >>> device tree. Another reason is that its type is APIC_CLUSTER and not >>> PCI_DOMAIN." >> I don't see any reason not to move that resource into the northbridge >> to avoid that issue. It's a simple fix. Is there a good reason for >> having the MMCONF BAR in the APIC cluster? > This is what I was thinking. Build tested only. > > Signed-off-by: Myles Watson <mylesgw@gmail.com> > Oh, this was very good! Thank you! Now I can load Linux kernel on the M4A78-EM, although it doesn't boot successfully yet. The boot is via Coreboot -> SeaBIOS -> Grub2 (Debian default) from SATA -> Linux from SATA disk. Linux boot seems to proceed otherwise nicely, except that it has problems initializing SATA and USB controllers on the SB700. IDE works better, as it can at least identify the CD drive model. ACPI does not work either. The boot log is attached. At least USB is complaining about missing interrupts. Perhaps that is also the case with SATA. I'll have to do some more testing to find out more. Best regards, Juhana Helovuo
Juhana Helovuo wrote: > Oh, this was very good! Thank you! Now I can load Linux kernel on the > M4A78-EM, although it doesn't boot successfully yet. [...] > > I'll have to do some more testing to find out more. More testing done, and now Linux boots to login prompt. I regenerated irq_tables.c, and noticed that ACPI was missing because -oops- it was disabled in Kconfig. After these fixes, Linux finds interrupts for USB and SATA controllers. The system seems to run quite nicely, e.g. SATA, IDE, Ethernet, USB, and VGA work. All of this is integrated to the mainboard. Linux boots to X.org and it works, USB mouse and all. "sensors" finds (CPU?) temperature sensor and gives a sane readout. ACPI poweroff does not yet work. The kernel is also adjusting CPU frequency with "powernow-k8" right out of the box. Also booting Debian installer CD from SeaBIOS seems to work, although I did not test through the entire install process. The only changes from M4A785-M to M4A78-EM so far are: * config option SOUTHBRIDGE_AMD_SB700_SKIP_ISA_DMA_INIT is not needed * changed MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID * regenerated irq_tables.c Should I make patches for this board to create an almost identical board-specific directory? I am in doubt, because there is already much stuff there that I suspect to be invalid, unnecessary, or otherwise needlessly duplicated, since it has been originally copy-pasted from AMD Tilapia board. Best regards, Juhana Helovuo
> >> I don't see any reason not to move that resource into the northbridge > >> to avoid that issue. It's a simple fix. Is there a good reason for > >> having the MMCONF BAR in the APIC cluster? > > This is what I was thinking. Build tested only. > > > > Signed-off-by: Myles Watson <mylesgw@gmail.com> > > > > Oh, this was very good! Thank you! Now I can load Linux kernel on the > M4A78-EM, although it doesn't boot successfully yet. I'm glad it's getting better. Your e820 doesn't look right, though. [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f400 (usable) [ 0.000000] BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000002ffef000 (usable) [ 0.000000] BIOS-e820: 000000002ffef000 - 0000000040000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) Your devices have resources mapped from c0000000-e0000000 that don't show up. I can't remember where it would get that value from, but I think it is worth looking into. Thanks, Myles
Myles Watson wrote: >>>> I don't see any reason not to move that resource into the northbridge >>>> to avoid that issue. It's a simple fix. Is there a good reason for >>>> having the MMCONF BAR in the APIC cluster? >>> This is what I was thinking. Build tested only. >>> >>> Signed-off-by: Myles Watson <mylesgw@gmail.com> >>> >> Oh, this was very good! Thank you! Now I can load Linux kernel on the >> M4A78-EM, although it doesn't boot successfully yet. > > I'm glad it's getting better. Your e820 doesn't look right, though. > > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f400 (usable) > [ 0.000000] BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) > [ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) > [ 0.000000] BIOS-e820: 0000000000100000 - 000000002ffef000 (usable) > [ 0.000000] BIOS-e820: 000000002ffef000 - 0000000040000000 (reserved) > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) > > Your devices have resources mapped from c0000000-e0000000 that don't show > up. I can't remember where it would get that value from, but I think it is > worth looking into. Yes, now I have the board booting to Linux. And you are right, the PCI resources do not show up. The resources of the PCI root device include PCI: 00:18.0 resource base c0000000 size 10000000 align 28 gran 20 limit dff8 PCI: 00:18.0 resource base d0000000 size 4400000 align 26 gran 20 limit dfff0 These resources do not show up in the coreboot table either: coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000c0000-000000002ffeffff: RAM 3. 000000002fff0000-000000002fffffff: CONFIGURATION TABLES 4. 0000000030000000-000000003fffffff: RESERVED 5. 00000000e0000000-00000000efffffff: RESERVED Wrote coreboot table at: 2fffe000 - 2fffe1bc checksum ba50 But does it really matter? There is now physical RAM only up to 40000000. Or is it going to be a problem if there is more than 3 GB RAM? Best regards, Juhana Helovuo
> And you are right, the PCI resources do not show up. The resources of > the PCI root device include > > PCI: 00:18.0 resource base c0000000 size 10000000 align 28 gran 20 limit > dff8 > PCI: 00:18.0 resource base d0000000 size 4400000 align 26 gran 20 limit > dfff0 > > > These resources do not show up in the coreboot table either: > > coreboot memory table: > 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES > 1. 0000000000001000-000000000009ffff: RAM > 2. 00000000000c0000-000000002ffeffff: RAM > 3. 000000002fff0000-000000002fffffff: CONFIGURATION TABLES > 4. 0000000030000000-000000003fffffff: RESERVED > 5. 00000000e0000000-00000000efffffff: RESERVED > Wrote coreboot table at: 2fffe000 - 2fffe1bc checksum ba50 > > > But does it really matter? There is now physical RAM only up to > 40000000. Or is it going to be a problem if there is more than 3 GB RAM? I'm worried that Linux will put something in the wrong place if it doesn't know what areas are used. It may not matter in practice, but as long as things are broken for you it's probably worth checking into. Thanks, Myles
On Mon, Dec 6, 2010 at 11:41 AM, Myles Watson <mylesgw@gmail.com> wrote: >> And you are right, the PCI resources do not show up. The resources of >> the PCI root device include >> >> PCI: 00:18.0 resource base c0000000 size 10000000 align 28 gran 20 limit >> dff8 >> PCI: 00:18.0 resource base d0000000 size 4400000 align 26 gran 20 limit >> dfff0 >> >> >> These resources do not show up in the coreboot table either: >> >> coreboot memory table: >> 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES >> 1. 0000000000001000-000000000009ffff: RAM >> 2. 00000000000c0000-000000002ffeffff: RAM >> 3. 000000002fff0000-000000002fffffff: CONFIGURATION TABLES >> 4. 0000000030000000-000000003fffffff: RESERVED >> 5. 00000000e0000000-00000000efffffff: RESERVED >> Wrote coreboot table at: 2fffe000 - 2fffe1bc checksum ba50 >> >> >> But does it really matter? There is now physical RAM only up to >> 40000000. Or is it going to be a problem if there is more than 3 GB RAM? > I'm worried that Linux will put something in the wrong place if it doesn't > know what areas are used. It may not matter in practice, but as long as > things are broken for you it's probably worth checking into. Never mind. I don't have any reserved areas in my tables. I was confusing myself. So the only problem that you have now is incorrectly routed interrupts? Or is there something more? Thanks, Myles
7.12.2010 6:31, Myles Watson kirjoitti: > > So the only problem that you have now is incorrectly routed > interrupts? Or is there something more? > Hello, Now I have interrupts working for at least SATA, IDE, USB, and Ethernet. Audio is still untested. The next thing I am missing is to have the mmconf patch you sent to this list on 2nd December commited to SVN. That should create a trunk revision, which is usable on this board without any source patching. Best regards, Juhana Helovuo
On Thu, Dec 2, 2010 at 9:17 AM, Myles Watson <mylesgw@gmail.com> wrote: >> "Why does the current code for handling fixed resources allow the mmconf >> space to get allocated to a PCI device? Function avoid_fixed_resources >> calls function constrain_resources, which recursively searches the >> device tree for fixed io and memory resources. The ioapic fixed memory >> address is found and avoided during the recursive search because this >> southbridge device is below the level where the search starts. On the >> other hand, the mmconf fixed resource is added from the northbridge code, >> and falls under 'APIC_CLUSTER: 0'. This device is not part of the search >> for two reasons. One is that it is not at or below 'pci_domain 0' in the >> device tree. Another reason is that its type is APIC_CLUSTER and not >> PCI_DOMAIN." > I don't see any reason not to move that resource into the northbridge > to avoid that issue. It's a simple fix. Is there a good reason for > having the MMCONF BAR in the APIC cluster? This is what I was thinking. Build tested only. Signed-off-by: Myles Watson <mylesgw@gmail.com> Thanks, Myles Thanks for this patch Myles. Acked-by: Scott Duplichan <scott@notabs.org> Thanks, Scott
On Tue, Dec 7, 2010 at 8:44 AM, Scott Duplichan <scott@notabs.org> wrote: > On Thu, Dec 2, 2010 at 9:17 AM, Myles Watson <mylesgw@gmail.com> wrote: >>> "Why does the current code for handling fixed resources allow the mmconf >>> space to get allocated to a PCI device? Function avoid_fixed_resources >>> calls function constrain_resources, which recursively searches the >>> device tree for fixed io and memory resources. The ioapic fixed memory >>> address is found and avoided during the recursive search because this >>> southbridge device is below the level where the search starts. On the >>> other hand, the mmconf fixed resource is added from the northbridge code, >>> and falls under 'APIC_CLUSTER: 0'. This device is not part of the search >>> for two reasons. One is that it is not at or below 'pci_domain 0' in the >>> device tree. Another reason is that its type is APIC_CLUSTER and not >>> PCI_DOMAIN." >> I don't see any reason not to move that resource into the northbridge >> to avoid that issue. It's a simple fix. Is there a good reason for >> having the MMCONF BAR in the APIC cluster? > This is what I was thinking. Build tested only. > > Signed-off-by: Myles Watson <mylesgw@gmail.com> > > Thanks, > Myles > > > Thanks for this patch Myles. > Acked-by: Scott Duplichan <scott@notabs.org> Rev 6148. I think that some nice next steps would be: - Set the size of the MMCONF area based on the number of busses in the machine. - Let the resource allocator assign the location so that it doesn't waste address space. I don't think it would be too difficult, but it would require some testing. Thanks, Myles
Patch
Index: svn/src/northbridge/amd/amdfam10/northbridge.c =================================================================== --- svn.orig/src/northbridge/amd/amdfam10/northbridge.c +++ svn/src/northbridge/amd/amdfam10/northbridge.c @@ -684,6 +684,13 @@ static void amdfam10_domain_read_resourc resource->flags = IORESOURCE_MEM; } #endif +#if CONFIG_MMCONF_SUPPORT + struct resource *res = new_resource(dev, 0xc0010058); + res->base = CONFIG_MMCONF_BASE_ADDRESS; + res->size = CONFIG_MMCONF_BUS_NUMBER * 4096*256; + res->flags = IORESOURCE_MEM | IORESOURCE_RESERVE | + IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; +#endif } static u32 my_find_pci_tolm(struct bus *bus, u32 tolm) @@ -1447,13 +1454,6 @@ static void cpu_bus_noop(device_t dev) static void cpu_bus_read_resources(device_t dev) { -#if CONFIG_MMCONF_SUPPORT - struct resource *resource = new_resource(dev, 0xc0010058); - resource->base = CONFIG_MMCONF_BASE_ADDRESS; - resource->size = CONFIG_MMCONF_BUS_NUMBER * 4096*256; - resource->flags = IORESOURCE_MEM | IORESOURCE_RESERVE | - IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; -#endif } static void cpu_bus_set_resources(device_t dev)