[coreboot] DL145 G1 with dual dualcore CPU using coreboot ?

[Myles Watson]

On Fri, Aug 20, 2010 at 8:32 AM, Oskar Enoksson <enok at lysator.liu.se> wrote:
> Myles Watson wrote:
>>> I'll send the updated patch when I'm at the office in the morning.
>>>
>>> I want to say also: this code should probably be regarded as
>>> experimental. I already know it doesn't boot with Opteron 248 CPU's, and
>>> sometimes it hangs on my 280 CPU's also.
>>>
>> I don't remember seeing the boot logs.  Have you compared the failing boot
>> logs with the working ones?
>>
> I think I solved a problem with the memory (mux) initialization
> (memreset and memreset_setup), now I can safely boot on both the 2x 248
> server and the 2x 280 server.
Good news.

> But I noticed that memtest86+ hangs. After some trial-and-error I
> noticed that if I use CONFIG_WRITE_HIGH_TABLES=y then everything works
> fine in Linux, but memtest86+ hangs. If I use CONFIG_WRITE_HIGH_TABLES=n
> memtest86+ works fine, but the Linux kernel fails to initialize the
> ethernet NIC's. What could be wrong?
My guess is that memtest doesn't like the reserved area in the middle
of RAM, but I don't know for sure.

> The original BIOS reports this memory map:
>  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
>  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
>  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
>  BIOS-e820: 0000000000100000 - 00000000f9ff0000 (usable)
>  BIOS-e820: 00000000f9ff0000 - 00000000f9fff000 (ACPI data)
>  BIOS-e820: 00000000f9fff000 - 00000000fa000000 (ACPI NVS)
>  BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
>
> My coreboot reports:
>  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
>  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
>  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
>  BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
>  BIOS-e820: 000000007fff0000 - 0000000080000000 (reserved)
>  BIOS-e820: 0000000080000000 - 00000000f7fff000 (usable)
>  BIOS-e820: 00000000f7fff000 - 00000000f8000000 (reserved)
>
> Is there something that looks wrong with the coreboot table?
I'm surprised that the high tables ended up in the middle of RAM.  I'd
reccommend looking through the log to see why that area gets reserved
there (is it reserved twice?)

>One more
> oddity that could be related: when booting with coreboot and then
> running flashrom I always get an error like this:
>
> flashrom is free software, get the source code at http://www.flashrom.org
> Error accessing high tables, 0x100000 bytes at 0x7fff2000
Odd that it wants to acess 1M of high tables at an unaligned address.

> /dev/mem mmap failed: Invalid argument
> In Linux this error can be caused by the CONFIG_NONPROMISC_DEVMEM (<2.6.27),
> CONFIG_STRICT_DEVMEM (>=2.6.27) and CONFIG_X86_PAT kernel options.
> Please check if either is enabled in your kernel before reporting a failure.
> You can override CONFIG_X86_PAT at boot with the nopat kernel parameter but
> disabling the other option unfortunately requires a kernel recompile. Sorry!
> Failed getting access to coreboot high tables.
> Found chipset "AMD AMD8111", enabling flash write... OK.
> This chipset supports the following protocols: Non-SPI.
> Calibrating delay loop... delay loop is unreliable, trying to continue OK.
> Found chip "SST SST49LF040" (512 KB, LPC) at physical address 0xfff80000.
>
> It works though and I can write to the flash. With the factory BIOS
> there are no error messages:
>
> flashrom is free software, get the source code at http://www.flashrom.org
> No coreboot table found.
> Found chipset "AMD AMD8111", enabling flash write... OK.
> This chipset supports the following protocols: Non-SPI.
> Calibrating delay loop... OK.
> Found chip "SST SST49LF040" (512 KB, LPC) at physical address 0xfff80000.

Using the mailing list will generally get you a better response and
help others later.

Thanks,
Myles