Richard Earnshaw wrote:
>The current BootConfig structure in evbarm/include/bootconfig.h has
>
>#define DRAM_BLOCKS     1
>
>typedef struct _BootConfig {
>        PhysMem dram[DRAM_BLOCKS];
>        u_int dramblocks;
>} BootConfig;
>
>So before I go ahead and do this, is anybody already relying on this 
>structure externally?
>
>This is somewhat back-to-front, in that if I increase DRAM_BLOCKS (as I 
>wish to do) that will move the offset of the dramblocks field.  I'd like 
>to rearrange this structure to:
>
>typedef struct _BootConfig {
>        u_int dramblocks;
>        PhysMem dram[DRAM_BLOCKS];
>} BootConfig;

>so that it is possible in future to bump the size of DRAM_BLOCKS without 
>breaking a binary interface that is notionally shared between 
>netbsd/evbarm and its "bios" (having netbsd able to access a larger array 
>won't hurt, since the size only matters if NetBSD allocates one of these 
>statically, and if it doesn't then it will never access beyond 
>dramblocks-1 entries).  However, doing so will break things if any 
>existing builds are already using a "bios" to probe memory.

The structure came from the Cyclone firmware for CATS.

The value of DRAM_BLOCKS is whatever is allowed by the cpu architecture,
dramblocks is the number actually fitted to the device. I would have
expected DRAM_BLOCKS to be 4 for evbarm as it is for cats.

The only other "bios" that I know of that relies on this layout is the
DEC^WCompaq^WHP one that is used in iPAQs.

Robert Swindells