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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
