qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] microbit: make -kernel optional


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] microbit: make -kernel optional
Date: Thu, 3 Jan 2019 13:06:43 +0000

On Fri, 14 Dec 2018 at 14:51, Stefan Hajnoczi <address@hidden> wrote:
>
> ARMv7M machine types support -kernel for ELF and raw image files.
> Microbit programs are typically in Intel HEX (.hex) format.  The generic
> loader supports .hex files but it doesn't work as expected:
>
>   $ qemu-system-arm -M microbit -device loader,file=microbit.hex
>   Guest image must be specified (using -kernel)
>
> This error comes from armv7m_load_kernel() but we don't have -kernel in
> this case.
>
> This patch makes -kernel optional since most of the time we'll want to
> use -device loader instead.
>
> Note that we need to register the reset handler that
> armv7m_load_kernel() used to register for us.
>
> Signed-off-by: Stefan Hajnoczi <address@hidden>

Hi, Stefan. (Happy new year :-))

Looking at this, I think I'd prefer it if we handled
this in the armv7m_load_kernel() code, since having to register
your own reset handler to reset the CPU is a weird thing for
board level code to have to do. That then means the M-profile
kernel load code is in line with the A-profile load code, which
if it has no kernel to load will still register the reset handler,
and let the machine run however it ends up running.

I think this basically amounts to "remove the 'insist that
kernel_filename is not NULL' check from armv7m_load_kernel()",
aka "revert commit 01fd41ab3fb69971". That commit's commit
message is correct that the behaviour if the user didn't
specify anything to run is a bit unhelpful, but it predates
the generic loader so it's no longer necessarily true that
a kernel must be specified, either for this or for any other
M-profile machine. (There's also the case of "board has a
flash device that was populated via a -pflash or -drive
option".)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]