Porting to Asus M4A78-EM

[Juhana Helovuo]

Hello all,

I bought a new Asus M4A78-EM mainboard and started porting Coreboot to 
it. This board is very similar to M4A785-M board I had recently.

Since the chipset is almost the same, and the Super I/O is the same, I 
configured and compiled for M4A785-M and Coreinfo worked on the first 
try, VGA and all. No code changes were required. The BIOS for onboard 
VGA was extracted with the bios_extract utility.

I documented my initial results into the Coreboot wiki: 
http://www.coreboot.org/ASUS_M4A78-EM

Summary of results so far:

* Coreinfo: runs fine, both on serial and VGA.
* SeaBIOS: ok, both on serial and VGA. USB mouse attached makes SeaBIOS 
freeze on initialization.
* SeaBIOS can load Coreinfo, which again works.
* SeaBIOS can load FreeDOS from IDE CDROM. Seems to work ok.
* SeaBIOS freezes when loading Debian installer (syslinux) from IDE 
CDROM. No useful output on serial and VGA is blank.
* SeaBIOS can load Grub2 from SATA disk. Text "Welcome to Grub!" flashes 
on VGA, then the mainboard powers down, which makes debugging rather 
difficult.

A boot log is attached. In this case FreeDOS was booted. Trying the same 
with Debian installer CD looks the same from the serial port (except for 
CD medium size).

Any good ideas how to proceed from here?
Do you see anything suspicious in the boot log?

Best regards,
Juhana Helovuo

[Liu Tao]

Hi Juhana,

Is the problem possiable caused by ACPI tables?
Maybe you can remove HAVE_ACPI_TABLES from mainboard Kconfig file
and have a try.

On Mon, Nov 29, 2010 at 3:43 AM, Juhana Helovuo  wrote:
> Hello all,
>
> I bought a new Asus M4A78-EM mainboard and started porting Coreboot to it.
> This board is very similar to M4A785-M board I had recently.
>
> Since the chipset is almost the same, and the Super I/O is the same, I
> configured and compiled for M4A785-M and Coreinfo worked on the first try,
> VGA and all. No code changes were required. The BIOS for onboard VGA was
> extracted with the bios_extract utility.
>
> I documented my initial results into the Coreboot wiki:
> http://www.coreboot.org/ASUS_M4A78-EM
>
> Summary of results so far:
> Coreinfo: runs fine, both on serial and VGA.
> SeaBIOS: ok, both on serial and VGA. USB mouse attached makes SeaBIOS
>
> freeze on initialization.
> SeaBIOS can load Coreinfo, which again works.
> SeaBIOS can load FreeDOS from IDE CDROM. Seems to work ok.
> SeaBIOS freezes when loading Debian installer (syslinux) from IDE CDROM.
>
> No useful output on serial and VGA is blank.
> SeaBIOS can load Grub2 from SATA disk. Text "Welcome to Grub!" flashes on
>
> VGA, then the mainboard powers down, which makes debugging rather difficult.
>
> A boot log is attached. In this case FreeDOS was booted. Trying the same
> with Debian installer CD looks the same from the serial port (except for CD
> medium size).
>
> Any good ideas how to proceed from here?
> Do you see anything suspicious in the boot log?

[Juhana Helovuo]

30.11.2010 3:46, Liu Tao kirjoitti:
> Hi Juhana,
>
> Is the problem possiable caused by ACPI tables?
> Maybe you can remove HAVE_ACPI_TABLES from mainboard Kconfig file
> and have a try.

Hello Liu and others,

I tried commenting out HAVE_ACPI_TABLES, but the result was the same. I 
think ACPI tables are not accessed from SeaBIOS (or FILO, or Grub, or 
syslinux) at all. I think the first read access to ACPI tables is from 
Linux kernel. (Except for BIOS e820 calls to query available RAM.)

On the other hand, there is more progress with this port:

FILO works nicely. It recognizes IDE CD and SATA disk, and can load 
Linux kernel and initrd from SATA.

However, trying to boot that kernel results in "Decompressing Linux ... 
Out of memory while allocating output buffer."

I guess this is some kind of problem with RAM allocation. Someone is 
confused about what RAM is available and where.

Also a modified Memtest86 can be executed from SeaBIOS, but clearly it 
gets a wrong idea of memory regions to test and quickly overwrites the 
VGA buffer (display trashed) and its own executable (crash with register 
dump). If the memtest is quickly interrupted to configuration menu and 
the test region is limited to only, e.g. addresses 300M - 1G, then it 
seems to run ok. Memtest claims that it is reading the coreboot tables 
to find out RAM areas to test.

Now that I look again at the various memory maps, something seems out of 
place. Coreboot log shows that there is RAM available in two regions:

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

Then later from SeaBIOS:

e820 map has 6 items:
   0: 0000000000000000 - 000000000009f400 = 1
   1: 000000000009f400 - 00000000000a0000 = 2
   2: 00000000000f0000 - 0000000000100000 = 2
   3: 0000000000100000 - 000000002ffef000 = 1
   4: 000000002ffef000 - 0000000040000000 = 2
   5: 00000000e0000000 - 00000000f0000000 = 2

Now e820 map is not marking Coreboot map region 0, "configuration 
tables" as reserved (=2) but usable (=1). Can this be correct?

Also, the PCI resource allocation puts resources to addresses
1000 - 3fff, but maybe those are IO ports and have nothing to do with 
memory addresses?

Best regards,
Juhana Helovuo

[Scott Duplichan]

-----Original Message-----
From: coreboot-bounces+scott=[e-mail] [mailto:coreboot-bounces+scott=[e-mail]] On Behalf Of Juhana
Helovuo
Sent: Thursday, December 02, 2010 08:05 AM
To: Liu Tao
Cc: [e-mail]
Subject: Re: [coreboot] Porting to Asus M4A78-EM

30.11.2010 3:46, Liu Tao kirjoitti:
> Hi Juhana,
>
> Is the problem possiable caused by ACPI tables?
> Maybe you can remove HAVE_ACPI_TABLES from mainboard Kconfig file
> and have a try.

]Hello Liu and others,
]
]I tried commenting out HAVE_ACPI_TABLES, but the result was the same. I 
]think ACPI tables are not accessed from SeaBIOS (or FILO, or Grub, or 
]syslinux) at all. I think the first read access to ACPI tables is from 
]Linux kernel. (Except for BIOS e820 calls to query available RAM.)
]
]
]On the other hand, there is more progress with this port:
]
]FILO works nicely. It recognizes IDE CD and SATA disk, and can load 
]Linux kernel and initrd from SATA.
]
]However, trying to boot that kernel results in "Decompressing Linux ... 
]Out of memory while allocating output buffer."
]
]I guess this is some kind of problem with RAM allocation. Someone is 
]confused about what RAM is available and where.
]
]Also a modified Memtest86 can be executed from SeaBIOS, but clearly it 
]gets a wrong idea of memory regions to test and quickly overwrites the 
]VGA buffer (display trashed) and its own executable (crash with register 
]dump). If the memtest is quickly interrupted to configuration menu and 
]the test region is limited to only, e.g. addresses 300M - 1G, then it 
]seems to run ok. Memtest claims that it is reading the coreboot tables 
]to find out RAM areas to test.

I am not too familiar with memtest86, but an overwrite of the UMA memory
should be easy to debug. From your e820 map, it looks like the DRAM
reserved for UMA use is at 30000000-3fffffff. The frame buffer maps the
same DRAM to a different address, such as D0000000. If the display is
written, then one of these two ranges is getting written. What is your
frame buffer address?

An experiment you could do is add a PCI video card and build without UMA
graphics support.

]Now that I look again at the various memory maps, something seems out of 
]place. Coreboot log shows that there is RAM available in two regions:
]
]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
]
]Then later from SeaBIOS:
]
]e820 map has 6 items:
]   0: 0000000000000000 - 000000000009f400 = 1
]   1: 000000000009f400 - 00000000000a0000 = 2
]   2: 00000000000f0000 - 0000000000100000 = 2
]   3: 0000000000100000 - 000000002ffef000 = 1
]   4: 000000002ffef000 - 0000000040000000 = 2
]   5: 00000000e0000000 - 00000000f0000000 = 2

This looks reasonable if you are using a 1GB DIMM and 256MB
is used by UMA.

]Now e820 map is not marking Coreboot map region 0, "configuration 
]tables" as reserved (=2) but usable (=1). Can this be correct?

I think the table memory eventually becomes free for OS use.

]Also, the PCI resource allocation puts resources to addresses
]1000 - 3fff, but maybe those are IO ports and have nothing to do with 
]memory addresses?

True, memory addresses and port I/O address are unrelated.

Thanks,
Scott

]Best regards,
]Juhana Helovuo

[Juhana Helovuo]

2.12.2010 17:31, Scott Duplichan kirjoitti:
> ]Also a modified Memtest86 can be executed from SeaBIOS, but clearly it
> ]gets a wrong idea of memory regions to test and quickly overwrites the
> ]VGA buffer (display trashed) and its own executable (crash with register
> ]dump). If the memtest is quickly interrupted to configuration menu and
> ]the test region is limited to only, e.g. addresses 300M - 1G, then it
> ]seems to run ok. Memtest claims that it is reading the coreboot tables
> ]to find out RAM areas to test.
>
> I am not too familiar with memtest86, but an overwrite of the UMA memory
> should be easy to debug. From your e820 map, it looks like the DRAM
> reserved for UMA use is at 30000000-3fffffff. The frame buffer maps the
> same DRAM to a different address, such as D0000000. If the display is
> written, then one of these two ranges is getting written. What is your
> frame buffer address?
>
> An experiment you could do is add a PCI video card and build without UMA
> graphics support.

Hello Scott,

Coreboot maps the frame buffer (or overall GPU memory) to
e0000000-efffffff.

Testing without UMA also crossed my mind, but it has to wait until I 
manage to get a VGA card with DVI and PCI or PCI-E, so I can connect to 
the mainboard and monitor. My current junk^H^H^H^Hspare parts box has 
only cards with either analog VGA & PCI or DVI & AGP.

Still, my main concern is not memtest86, but getting Linux to boot at 
least so far that I can see some kernel boot messages to know what is 
happening.

Best regards,
Juhana Helovuo

[Scott Duplichan]

-----Original Message-----
From: Juhana Helovuo [mailto:[e-mail]] 
Sent: Thursday, December 02, 2010 09:53 AM
To: Scott Duplichan
Cc: [e-mail]
Subject: Re: [coreboot] Porting to Asus M4A78-EM

2.12.2010 17:31, Scott Duplichan kirjoitti:
> ]Also a modified Memtest86 can be executed from SeaBIOS, but clearly it
> ]gets a wrong idea of memory regions to test and quickly overwrites the
> ]VGA buffer (display trashed) and its own executable (crash with register
> ]dump). If the memtest is quickly interrupted to configuration menu and
> ]the test region is limited to only, e.g. addresses 300M - 1G, then it
> ]seems to run ok. Memtest claims that it is reading the coreboot tables
> ]to find out RAM areas to test.
>
> I am not too familiar with memtest86, but an overwrite of the UMA memory
> should be easy to debug. From your e820 map, it looks like the DRAM
> reserved for UMA use is at 30000000-3fffffff. The frame buffer maps the
> same DRAM to a different address, such as D0000000. If the display is
> written, then one of these two ranges is getting written. What is your
> frame buffer address?
>
> An experiment you could do is add a PCI video card and build without UMA
> graphics support.

]Hello Scott,
]
]Coreboot maps the frame buffer (or overall GPU memory) to
]e0000000-efffffff.
]
]Testing without UMA also crossed my mind, but it has to wait until I 
]manage to get a VGA card with DVI and PCI or PCI-E, so I can connect to 
]the mainboard and monitor. My current junk^H^H^H^Hspare parts box has 
]only cards with either analog VGA & PCI or DVI & AGP.
]
]Still, my main concern is not memtest86, but getting Linux to boot at 
]least so far that I can see some kernel boot messages to know what is 
]happening.
]
]
]Best regards,
]Juhana Helovuo

Hello Juhana,
> From your 11/28/2010 log file it looks like both mmconf and uma are

getting assigned a memory address of E0000000. A while back I found
such a conflict is possible:

"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."

My current work around for this problem is to set mmconf_base_address
to f8000000 and mmconf_bus_number to 16.

Thanks,
Scott

[Myles Watson]

> "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?

Thanks,
Myles

[Myles Watson]

On Thu, Dec 2, 2010 at 9:17 AM, Myles Watson  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

Thanks,
Myles

[Scott Duplichan]

On Thu, Dec 2, 2010 at 9:17 AM, Myles Watson  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

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

[Myles Watson]

> > 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
>
> 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

[Juhana Helovuo]

Myles Watson wrote:
> On Thu, Dec 2, 2010 at 9:17 AM, Myles Watson  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

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]

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

[Myles Watson]

> > > 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
>
> 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

[Juhana Helovuo]

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
> >
> > 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

[Myles Watson]

> 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
> 0000000000001000-000000000009ffff: RAM
> 00000000000c0000-000000002ffeffff: RAM
> 000000002fff0000-000000002fffffff: CONFIGURATION TABLES
> 0000000030000000-000000003fffffff: RESERVED
> 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

[Myles Watson]

On Mon, Dec 6, 2010 at 11:41 AM, Myles Watson  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

[Juhana Helovuo]

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

[Scott Duplichan]

On Thu, Dec 2, 2010 at 9:17 AM, Myles Watson  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

Thanks,
Myles

Thanks for this patch Myles.
Acked-by: Scott Duplichan

Thanks,
Scott

[Myles Watson]

On Tue, Dec 7, 2010 at 8:44 AM, Scott Duplichan  wrote:
> On Thu, Dec 2, 2010 at 9:17 AM, Myles Watson  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
>
> Thanks,
> Myles
>
> Thanks for this patch Myles.
> Acked-by: Scott Duplichan

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