Re: [coreboot] Porting to Asus M4A78-EM

[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