[U-Boot] Sandbox question

[Mike Frysinger]

On Monday 23 April 2012 14:39:59 Wolfgang Denk wrote:
> Simon wrote:
> > I did try to start a discussion on the list about how to deal with
> > this. One idea was to add a translation function in the md command
> > (and potentially then in other code) that converts an effective
> > address as seen by U-Boot into one that can be used by the
> > architecture. The down side is that all architectures except sandbox
> > would have this as a no-op.
> 
> I don't see why such a function would be needed.  Other architectures
> don't need it either.  Yes, some architectures use a common, fixed
> mapping (like PPC, where physical RAM almost always starts at address
> 0x0) - but others don't have such a common map- for example on ARM,
> there is a wild mix where RAM starts, and basicly every SoC defines
> his own mapping.

because, as you said, you want things to be deterministic.  when the sandbox 
starts up, it does mmap() and there's no guarantee that the address you get 
back is always going to be the same.  you cannot compare this to an SoC where 
the memory layout is always exactly the same for u-boot across runs.  thus we 
need the map call to adjust what the user sees (memory always starts at 0) vs 
what sandbox got back from the kernel (almost literally, any address).

> > Also I don't like the idea of different people writing test code with
> > different assumptions about the memory map, such that we can't run all
> > the tests with the same sandbox config.
> 
> Eventually introducing two variables like ramstart and ramend would
> solve 90% of the potential issues.
> 
> In any case, information returned by commands like bdinfo must be
> correct.

it was correct.  and then the change that made it correct was reverted.
-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/20120423/d8ecaafe/attachment.pgp>