On Thu, Jan 3, 2019 at 1:07 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > 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".)
Happy New Year! That makes sense. I will send a patch. Stefan
