public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] Sandbox question
Date: Mon, 23 Apr 2012 14:54:06 -0400	[thread overview]
Message-ID: <201204231454.08410.vapier@gentoo.org> (raw)
In-Reply-To: <20120423184000.008FD200261@gemini.denx.de>

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>

  reply	other threads:[~2012-04-23 18:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-23  6:41 [U-Boot] Sandbox question Wolfgang Denk
2012-04-23 15:41 ` Mike Frysinger
2012-04-23 17:32   ` Matthias Weisser
2012-04-23 17:39     ` Wolfgang Denk
2012-04-23 17:49       ` Matthias Weisser
2012-04-23 18:30         ` Wolfgang Denk
2012-04-24  9:25           ` Matthias Weißer
2012-04-23 17:58   ` Simon Glass
2012-04-23 18:39     ` Wolfgang Denk
2012-04-23 18:54       ` Mike Frysinger [this message]
2012-04-23 19:03       ` Mike Frysinger
2012-04-23 19:33         ` Wolfgang Denk
2012-04-23 20:57           ` Mike Frysinger
2012-04-23 21:16             ` Mike Frysinger
2012-04-23 21:17             ` Wolfgang Denk
2012-04-23 21:32               ` Mike Frysinger
2012-04-23 21:51 ` [U-Boot] Sandbox: auto exiting on pipe closure Mike Frysinger
2012-08-09 20:39   ` Wolfgang Denk
2012-08-10  0:47     ` Mike Frysinger
  -- strict thread matches above, loose matches on Subject: below --
2013-12-06 23:36 [U-Boot] [PATCH 0/8] Secure boot improvements and test on Beaglebone Black Simon Glass
2013-12-30  7:40 ` [U-Boot] sandbox question TigerLiu at viatech.com.cn
2013-12-31  0:42   ` TigerLiu at viatech.com.cn
2014-01-07 23:58     ` Simon Glass
2014-01-08  0:52       ` TigerLiu at viatech.com.cn
2014-01-08  3:46         ` Abraham Varricatt
2014-01-08 10:30           ` TigerLiu at viatech.com.cn
2011-12-01 16:35 [U-Boot] Sandbox question Andreas Bießmann
2011-12-01 18:13 ` Simon Glass
2011-12-01 19:21 ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201204231454.08410.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox