pc386 BSP on board with UMA

[Joel Sherrill]

On 12/09/2009 06:16 PM, Chris Johns wrote:
> Joel Sherrill wrote:
>    
>> Hi,
>>
>> I have been debugging a lock up during initialization
>> on an embedded PC with 1GB RAM but the last part is
>> reserved for video, etc.. See Section 5.4 in this
>> manual.
>>
>> =================================================================
>> http://www.intel.com/assets/pdf/datasheet/252615.pdf
>>
>> Voids of physical addresses that are not accessible as general system
>> memory and reside within
>> system memory address range (<  TOM) are created for SMM-mode and legacy
>> VGA graphics
>> compatibility. It is the responsibility of BIOS to properly initialize
>> these regions. The number
>> of UMA options has been extended. Allocation is at a fixed address in
>> terms of rigid positioning
>> of UMA system memory 􀃆TOM-TSEG-UMA(size), but it is mapped at any
>> available address by
>> a PCI allocation algorithm. GMADR and MMADR are requested through BARs.
>> The following table details the location and attributes of the regions.
>>
>> Table 33. Pre-allocated System Memory
>> System Memory Segments Attributes Comments
>> 00000000H - 03E7FFFFH R/W Available system memory 62.5 -MB
>> 03E80000H - 03F7FFFFH R/W Pre-allocated Graphics VGA memory
>> 1-MB (or 4/8/16/32- MB) when IGD is
>> enabled
>> 03F80000H - 03FFFFFFH SMM Mode Only - CPU Reads TSEG Address Range
>> 03F80000H - 03FFFFFFH SMM Mode Only - CPU Reads TSEG Pre-allocated
>> system memory
>>
>> =================================================================
>>
>>      
> Interesting manual. Seems to assume you know what TSEG, SMM etc is.
>
>    
I found SMM .. System Management Mode.  (I think)
>> The memory sizing algorithm finds 1007MB on this board.
>>      
> What memory sizing code is this ?
>
>    
startup/bspgetworkarea.c .. should be same code that
has existed in the bsp for ages.


FWIW zero'ing the workspace is what made it write to
this memory.  Normally we don't need 1GB of RAM. :)

>> But
>> if you clear all of that memory, the system locks up. If I
>> decrease that to 1004MB, things work. My reading of the
>> above is that we shouldn't touch the last 64MB RAM.
>>
>> Does that make sense? Is there some way to know this?
>>
>>      
> I have not followed in detail the size you need to leave, but I would
> have thought the BIOS would have taken this into account for you.
>    
Does that mean the multiboot info would be right?

The sizing code has 3 options:

+ RamSize from linkcmds
+ dynamic sizing
+ multiboot info.

I think the code is structured such that it takes
the multiboot, then overwrites it with either the
sizing or hardcoded number.

Hmmm... this code looks different on the head vs 4.9
but the sizing algorithm is the same.  I will have to look
at it in detail tomorrow to see if 4.9 might have given higher
priority to the multiboot info.

What do you think?

--joel
> Chris
>
>    
>> Help... :)
>>      
>
>
>