On Fri, 14 Dec 2018 at 14:51, Stefan Hajnoczi <stefa...@redhat.com> 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 <stefa...@redhat.com>
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
