原创 关于LOCAL_MEM_AUTOSIZE--网友留言

On pcPentium* derived BSPs, I will show you how the implementation(!)<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

of the LOCAL_MEM_AUTOSIZE is related with the crash depending on

vxWorks location, and thus becomes the major weakness of those BSPs.

Furthermore there is some risk of bootrom/vxWorks overlap, which is

not visible in the build Macro values.

Details:

--------

LOCAL_MEM_AUTOSIZE

------------------

LOCAL_MEM_AUTOSIZE does a binary search for the highest writeable

memory location in the address space.

Unfortunately some chipsets are mapping certain hardware into the

address space (e.g. single config registers or the entire graphic card

memory) If by accident the binary search traps into such hardware

register the memory size is computed wrong (vxWorks will crash later)

or an illegal value is in the config register (hardware crashes

immediately).

  what addresses are accessed, depends, because of the

binary search, highly counter-intuitively on slight changes of start

and end addresses of the search.  The search area is between symbol

_end (end of static vxWorks image) and Macro PHYS_MEM_MAX.

So the slightest change of vxWorks image location or size can affect

the behaviour pseudo-randomly!

Workaround: in sysPhysMemTop() make sure that only the range between

minimum expected RAM size and minimum address of potential memory

mapped hardware is searched (yes, then the BSP is board dependent).

Fix: In romInit.s call the appropriate BIOS-function to hardware

independent getting the RAM size, and store this in a hardcoded