[coreboot] Trying to get coreboot running on VIA EPIA-M (lzma: Decoding error = 1)

[Aaron Durbin]

On Thu, May 30, 2013 at 5:30 AM, Peter Stuge <peter at stuge.se> wrote:
> Marius Schäfer wrote:
>> Can you read anything out of these lines and help me?
> ..
>> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 63MB of RAM.
>> ------------[ cut here ]------------
>> WARNING: at arch/x86/kernel/cpu/mtrr/cleanup.c:971
>> mtrr_trim_uncached_memory+0x411/0x42e()
>> Pid: 0, comm: swapper Not tainted 3.2.44 #7
>> Call Trace:
>>  [<c1017964>] ? warn_slowpath_common+0x63/0x74
>>  [<c12f98f2>] ? mtrr_trim_uncached_memory+0x411/0x42e
>>  [<c10179f8>] ? warn_slowpath_null+0xd/0x11
>>  [<c12f98f2>] ? mtrr_trim_uncached_memory+0x411/0x42e
>>  [<c12f5165>] ? setup_arch+0x4eb/0x9dd
>>  [<c12f3421>] ? start_kernel+0x5e/0x275
>> ---[ end trace 4eaa2a86a8e2da22 ]---
>
> As Ron says, work on fixing this MTRR problem.
>
>
>> update e820 for mtrr
>> modified physical RAM map:
>>  modified: 0000000000000000 - 0000000000001000 type 16
>>  modified: 0000000000001000 - 00000000000a0000 (reserved)
>>  modified: 0000000000100000 - 0000000004000000 (reserved)
>>  modified: 0000000004000000 - 000000001dfe0000 (usable)
>>  modified: 000000001dfe0000 - 000000001e000000 type 16
>> last_pfn = 0x1dfe0 max_arch_pfn = 0x100000
>> Kernel panic - not syncing: Cannot allocate trampoline
>>
>> Pid: 0, comm: swapper Tainted: G        W    3.2.44 #7
>> Call Trace:
>>  [<c12245eb>] ? panic+0x57/0x12a
>>  [<c12f77e7>] ? setup_trampolines+0x40/0xb1
>>  [<c12f51df>] ? setup_arch+0x565/0x9dd
>>  [<c12f3421>] ? start_kernel+0x5e/0x275
>
> Check the kernel source to find out what the constraints are for that
> trampoline allocation. Maybe it must be in some region where there
> isn't any available RAM, which would be a bug in the memory map for
> this (and more?) mainboards.
>

The crux of the problem is the following. 0 -> 64MiB is set to be
uncacheable. The message from the kernel about 63MiB is because the
fixed mtrrs cover the first meg. I'm not sure where the memory
controller messages reside in the original log but if there is memory
there ensure it is added as cacheable memory resource.


MTRR: Physical address space:
0x0000000000000000 - 0x0000000004000000 size 0x04000000 type 0
0x0000000004000000 - 0x000000001e000000 size 0x1a000000 type 6
0x000000001e000000 - 0x0000000100000000 size 0xe2000000 type 0
MTRR: Fixed MSR 0x250 0x0000000000000000
MTRR: Fixed MSR 0x258 0x0000000000000000
MTRR: Fixed MSR 0x259 0x0000000000000000
MTRR: Fixed MSR 0x268 0x0000000000000000
MTRR: Fixed MSR 0x269 0x0000000000000000
MTRR: Fixed MSR 0x26a 0x0000000000000000
MTRR: Fixed MSR 0x26b 0x0000000000000000
MTRR: Fixed MSR 0x26c 0x0000000000000000
MTRR: Fixed MSR 0x26d 0x0000000000000000
MTRR: Fixed MSR 0x26e 0x0000000000000000
MTRR: Fixed MSR 0x26f 0x0000000000000000
call enable_fixed_mtrr()
CPU physical address size: 32 bits
MTRR: default type WB/UC MTRR counts: 5/4.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000004000000 mask 0x00000000fc000000 type 6
MTRR: 1 base 0x0000000008000000 mask 0x00000000f8000000 type 6
MTRR: 2 base 0x0000000010000000 mask 0x00000000f0000000 type 6
MTRR: 3 base 0x000000001e000000 mask 0x00000000fe000000 type 0