All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/8] sandbox: Add support for bootz
Date: Tue, 07 Apr 2015 15:00:01 -0600	[thread overview]
Message-ID: <55244551.8040901@wwwdotorg.org> (raw)
In-Reply-To: <CAPnjgZ1wnugW+3zZM8iDWkP1x8QtZ2r+4Ph2VA8rJeu7EwXOTQ@mail.gmail.com>

On 04/07/2015 02:40 PM, Simon Glass wrote:
> Hi Sjoerd,
>
> On 7 April 2015 at 01:56, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
>> On Mon, 2015-04-06 at 15:40 -0600, Stephen Warren wrote:
>>> On 04/06/2015 03:02 PM, Sjoerd Simons wrote:
>>>> Add dummy bootz_setup implementation allowing the u-boot sandbox to
>>>> run bootz. This recognizes both ARM and x86 zImages to validate a
>>>> valid zImage was loaded.
>>>
>>>> diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c
>>>
>>>> +int bootz_setup(ulong image, ulong *start, ulong *end)
>>>
>>>> +   *start = 0xdead;
>>>> +   *end = 0xbeef;
>>>> +   return 0;
>>>
>>> Isn't that going to cause the rest of bootz to access or jump to some
>>> bogus address and crash?
>>
>> A very good question. I hadn't actually double-checked what these values
>> are used for as things just worked and i got distracted by fixing other
>> bits & pieces.
>>
>> Looking through the code, these values are only used to add an LMB
>> region directly after the kernel entry load address. As the sandbox
>> architecture doesn't define either arch_lmb_reserve nor
>> board_lmb_reserve these bogus values don't cause any issues (as they
>> don't seem to make the generic lmb code blow-up thatis), but it's
>> definitely not pretty.
>
> In the future we may want to emulate this with sandbox. Do you think
> instead of this we should read out the correct values from the image
> file? It seems odd to use fake values.
>
> In fact I wonder if this should use a common function with ARM, or
> perhaps part of it should be common?

I wonder if sandbox could somehow exec the loaded image (presumably it'd 
only support native executables then, not ARM/x86 zImages), or keep a 
handle to the file the data was loaded from and fdexec() if such an API 
exists?

  reply	other threads:[~2015-04-07 21:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-06 21:02 [U-Boot] [PATCH v2 0/8] Allow sandbox to use config_distro_bootcmd Sjoerd Simons
2015-04-06 21:02 ` [U-Boot] [PATCH v2 1/8] sandbox: only do sandboxfs for hostfs interface Sjoerd Simons
2015-04-07 20:40   ` Simon Glass
2015-04-06 21:02 ` [U-Boot] [PATCH v2 2/8] sandbox: Split bootm code out into lib/bootm Sjoerd Simons
2015-04-07 20:40   ` Simon Glass
2015-04-06 21:02 ` [U-Boot] [PATCH v2 3/8] sandbox: Add support for bootz Sjoerd Simons
2015-04-06 21:40   ` Stephen Warren
2015-04-07  7:56     ` Sjoerd Simons
2015-04-07 20:40       ` Simon Glass
2015-04-07 21:00         ` Stephen Warren [this message]
2015-04-07 22:31           ` Simon Glass
2015-04-06 21:02 ` [U-Boot] [PATCH v2 4/8] sandbox: Renamed sb command to host Sjoerd Simons
2015-04-07 20:40   ` Simon Glass
2015-04-06 21:02 ` [U-Boot] [PATCH v2 5/8] sandbox: Implement host dev [device] Sjoerd Simons
2015-04-07 20:40   ` Simon Glass
2015-04-06 21:02 ` [U-Boot] [PATCH v2 6/8] config_distro_bootcmd.h: Add shared block definition for the host interface Sjoerd Simons
2015-04-07 20:40   ` Simon Glass
2015-04-06 21:02 ` [U-Boot] [PATCH v2 7/8] pxe: Ensure all memory access is to mapped memory Sjoerd Simons
2015-04-07 20:41   ` Simon Glass
2015-04-06 21:02 ` [U-Boot] [PATCH v2 8/8] sandbox: add config_distro_defaults and config_distro_bootcmd Sjoerd Simons
2015-04-07 20:41   ` Simon Glass

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=55244551.8040901@wwwdotorg.org \
    --to=swarren@wwwdotorg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.