target/arm: armv7m_load_kernel() improvements

[PATCH 0/2] target/arm: armv7m_load_kernel() improvements

Peter Maydell posted 2 patches 1 year, 8 months ago

Download series mbox

Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20220823160417.3858216-1-peter.maydell@linaro.org

Maintainers: Peter Maydell <peter.maydell@linaro.org>, "Cédric Le Goater" <clg@kaod.org>, Andrew Jeffery <andrew@aj.id.au>, Joel Stanley <joel@jms.id.au>, Subbaraya Sundeep <sundeep.lkml@gmail.com>, Alistair Francis <alistair@alistair23.me>, Alexandre Iooss <erdnaxe@crans.org>

include/hw/arm/boot.h     |  5 ++++-
hw/arm/armv7m.c           | 14 ++++----------
hw/arm/aspeed.c           |  1 +
hw/arm/microbit.c         |  2 +-
hw/arm/mps2-tz.c          |  2 +-
hw/arm/mps2.c             |  2 +-
hw/arm/msf2-som.c         |  2 +-
hw/arm/musca.c            |  3 ++-
hw/arm/netduino2.c        |  2 +-
hw/arm/netduinoplus2.c    |  2 +-
hw/arm/stellaris.c        |  2 +-
hw/arm/stm32vldiscovery.c |  2 +-
12 files changed, 19 insertions(+), 20 deletions(-)

Expand all Fold all

[PATCH 0/2] target/arm: armv7m_load_kernel() improvements

Posted by Peter Maydell 1 year, 8 months ago

Two small patches to armv7m_load_kernel().  The first is just getting
rid of some dead code, that I noticed while working on the function. 
The second is to make boards pass armv7m_load_kernel() the base
address for loading guest (non-ELF) binaries.  At the moment we
assume all M-profile boards start at address 0; this happens to be
true for all the ones we implement right now, but it's not true in
general.  In particular the Teeny board has its ROM at 0x0020_0000.

I thought about having armv7m_load_kernel() be "clever" and ask the
CPU what init-svtor/init-nsvtor were set to, but that seems like it
might have unanticipated consequences[*].  "Just pass the base address"
is simpler and is how A-profile does it (though for A-profile it's
the loader_start field in struct arm_boot_info rather than an extra
argument).

[*] eg where the board has the rom/flash aliased at both address
0 and some other address, and init-svtor points at an alias;
also Secure vs NonSecure address spaces and loading...

thanks
-- PMM

Peter Maydell (2):
  target/arm: Remove useless TARGET_BIG_ENDIAN check in
    armv7m_load_kernel()
  target/arm: Make boards pass base address to armv7m_load_kernel()

 include/hw/arm/boot.h     |  5 ++++-
 hw/arm/armv7m.c           | 14 ++++----------
 hw/arm/aspeed.c           |  1 +
 hw/arm/microbit.c         |  2 +-
 hw/arm/mps2-tz.c          |  2 +-
 hw/arm/mps2.c             |  2 +-
 hw/arm/msf2-som.c         |  2 +-
 hw/arm/musca.c            |  3 ++-
 hw/arm/netduino2.c        |  2 +-
 hw/arm/netduinoplus2.c    |  2 +-
 hw/arm/stellaris.c        |  2 +-
 hw/arm/stm32vldiscovery.c |  2 +-
 12 files changed, 19 insertions(+), 20 deletions(-)

-- 
2.25.1

Re: [PATCH 0/2] target/arm: armv7m_load_kernel() improvements

Posted by Richard Henderson 1 year, 8 months ago

On 8/23/22 09:04, Peter Maydell wrote:
> Two small patches to armv7m_load_kernel().  The first is just getting
> rid of some dead code, that I noticed while working on the function.
> The second is to make boards pass armv7m_load_kernel() the base
> address for loading guest (non-ELF) binaries.  At the moment we
> assume all M-profile boards start at address 0; this happens to be
> true for all the ones we implement right now, but it's not true in
> general.  In particular the Teeny board has its ROM at 0x0020_0000.
> 
> I thought about having armv7m_load_kernel() be "clever" and ask the
> CPU what init-svtor/init-nsvtor were set to, but that seems like it
> might have unanticipated consequences[*].  "Just pass the base address"
> is simpler and is how A-profile does it (though for A-profile it's
> the loader_start field in struct arm_boot_info rather than an extra
> argument).
> 
> [*] eg where the board has the rom/flash aliased at both address
> 0 and some other address, and init-svtor points at an alias;
> also Secure vs NonSecure address spaces and loading...

Thanks, queued to target-arm.next.


r~