From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 07 Apr 2015 15:00:01 -0600 Subject: [U-Boot] [PATCH v2 3/8] sandbox: Add support for bootz In-Reply-To: References: <1428354148-1511-1-git-send-email-sjoerd.simons@collabora.co.uk> <1428354148-1511-4-git-send-email-sjoerd.simons@collabora.co.uk> <5522FD49.1070705@wwwdotorg.org> <1428393360.4333.30.camel@collabora.co.uk> Message-ID: <55244551.8040901@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/07/2015 02:40 PM, Simon Glass wrote: > Hi Sjoerd, > > On 7 April 2015 at 01:56, Sjoerd Simons 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?