[U-Boot] [PATCH] sandbox: Add improved RAM simulation

[Mike Frysinger <vapier@gentoo.org>]

On Tuesday 01 November 2011 12:05:05 Matthias Weisser wrote:
> Am 01.11.2011 16:28, schrieb Mike Frysinger:
> > On Tuesday 01 November 2011 10:07:31 Matthias Weisser wrote:
> >> --- a/arch/sandbox/lib/board.c
> >> +++ b/arch/sandbox/lib/board.c
> >> 
> >> +static gd_t gd_mem;
> > 
> > i don't think this indirection is necessary.  probably can replace the
> > static
> > 
> > gd_mem with:
> > 	gd_t gd;
> 
> AFAIK gd is a pointer. So I think we always need some sort of memory
> where the actual structure is stored.

only if you use the DECLARE macro.  but it's fine either way.

> >> +#define CONFIG_SYS_SDRAM_BASE		0x20000000
> >> ...
> >> -	mem = malloc(size);
> >> +	mem = os_mmap((void *)CONFIG_SYS_SDRAM_BASE, CONFIG_SYS_SDRAM_SIZE,
> >> +			0, 0, -1, 0);
> > 
> > mmap() makes no guarantee that the requested address is what you'll get
> > back. so there's no point in having this SDRAM_BASE define.  punt it and
> > pass in NULL instead.
> 
> But it works in most cases :-) The point of adding it was that I really
> like to have memory aligned on a 256MB boundary or so like it is in most
> SOCs. But thats a personal preference. And if it doesn't work you can
> still get the address of physical memory from bdinfo.
> 
> > also, with Simon's other patch to md to use the remap func, the address
> > of our memory backing store doesn't matter.
> 
> Well, you are right. But with the posted patch you don't need any remap
> function and md/mm/mtest/mw works out of the box.

except for when that base address happens to already be used, then any 
assumptions about memory addresses are now invalid.

the internal memory layout should be disconnected from the user-api facing 
layout.  so while internally sandbox does an anon mmap of some chunk of 
memory, where that is based should not matter.  the memory as seen by commands 
run from the console should always be the same.  which is what Simon's patch 
gets us.

as for sandbox working the same as random SoCs, that's going to be highly SoC 
and architecture specific.  i'd keep it simple and have sandbox expose its 
chunk of memory starting at address 0 and work its way up.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111101/b031d604/attachment.pgp