[coreboot] coreboot halts at "doing early_mtrr"

[Corey Osgood]

Patch attached to remove the call to early_mtrr_init(), provide a
little more feedback on the amount of ram that's been found, and
correct the ram initialization order and clarify a comment on an old
hack. I don't have any hardware to test this patch on.

On Sat, Jul 31, 2010 at 1:33 AM, Patrick Georgi <patrick at georgi-clan.de> wrote:
> Am 30.07.2010 23:20, schrieb austinro at msu.edu:
>> Commenting out the call to early_mtrr_init() lets coreboot run to
>> completion.
> I suspect that call is a left-over from pre-CAR times on C7.
>
> Please provide a patch. See
> http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for
> our rules.
>
> Do you need any more changes to get your board to run? After all, that's
> a different board than listed by coreboot - it would be nice to support
> your board explicitely, too.
>
>> That's odd.  I assumed the call to "write_cr0(cr0)" in cache.h was
>> responsible somehow, since that was where it stopped when
>> "early_mtrr_init" called "disable_cache", but I left the print
>> statements in disable_cache, and they were all printed repeatedly this
>> time, so "write_cr0" only causes a problem when called early (during
>> "early_mtrr_init")?
> The problem is that write_cr0 is the function that actually disables the
> cache.
> While in early_mtrr_init, the only memory coreboot has to work in _is_
> the cache (Cache as RAM configures the CPU to map the cache to some RAM
> addresses and locks it to prevent eviction).
> If you disable the cache at this point, there's no memory to use. In
> particular, the stack is gone, so the next time a function is called or
> left, the CPU doesn't know where to go.
>
> On later occassions of disable_cache(), RAM is configured and used, so
> disabling the cache merely slows the system down a bit, but doesn't
> entirely prevent it from working.
>
>> Tried it again and with memtest as the payload and it doesn't see any
>> memory.  Memtest pops up on the screen :
>> L1 cache: 64K
>> L2 cache: 128K
>> L3 cache: none
>> Memory :    0K
>> (That last one is a zero K).
>>
>> Hmmm.
> This might be a matter of issues with the various tables. The fact that
> you can run up to memtest indicates that there _is_ RAM. :-)
>
> For testing you could try to disable HAVE_HIGH_TABLES - if memtest works
> then, your memtest doesn't know the forwarder entry we introduced last
> year or so.
>
>
> Patrick
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: j7f24.diff
Type: text/x-patch
Size: 3940 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100731/d642d3a9/attachment.diff>