[LinuxBIOS] Problems with Filo booting - HELP

Corey Osgood corey.osgood at gmail.com
Thu Oct 4 05:50:36 CEST 2007


joe at smittys.pointclark.net wrote:
> Quoting Corey Osgood <corey.osgood at gmail.com>:
>
>> joe at smittys.pointclark.net wrote:
>>> Quoting ron minnich <rminnich at gmail.com>:
>>>
>>>
>>>> you might try forcing the size (in code) to 32M or some such in
>>>> hardwaremain.c and see if it works then. There's  something odd with
>>>> your ram.
>>>>
>>>> ron
>>>>
>>>>
>>> It won't have anything to do with the fact that:
>>>
>>> a. It is onboard 128MB memory
>>> b. It doesn't have a SPD module
>>> c. It is located in the second slot not first.
>>>
>>
>> It shouldn't, no, especially not the first 2.
>>
>>> This is wierd because it passes the ram_check() from auto.c earlier in
>>> the process just fine.
>>>
>>> /* Check RAM. */
>>> ram_check(0, 640 * 1024);
>>>
>>> Thanks - Joe
>>
>> All that's checking is the first 640K. To check the rest of the memory,
>> use ram_check(1024*1024, 1024*1024*128), starting at 1mb to avoid any
>> reserved areas. Make sure your ram_resource() calls also avoids those
>> reserved areas.
>>
>> -Corey
>>
> Ok, I think I figured out what is going on here. The ram_check from
> 0-640K works fine. But ram_check from 1MB-128MB fails. My DRB
> registers are set correctly, and report 128MB of memory. Why? That is
> the golden question of the year. Can anyone help out a thinning hair
> (from pulling out - stress related) guy in desperate need?
>
> Thanks - Joe
>

Where does it fail? What address(es) does it start to fail at? Does it
return junk (but semi-coherent) values or NULL/zeros? Knowing exactly
where the ram goes from good to bad could help find the start of the
problem.

-Corey




More information about the coreboot mailing list