Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu

[Peter Maydell]

On 16 June 2018 at 16:08, Guenter Roeck <address@hidden> wrote:
> I would tend to disagree. If we get it working, it would exercise
> both qemu and the Linux kernel quite significantly, thus helping
> both sides to improve functionality and stability. Also, the changes
> I needed to make are not really that invasive. Embedding everything
> on the build process or with a code wrapper would be much more complex
> and add complexity where I don't want it. I had tried that with some
> other targets, but it is just too fragile for automated testing,
> and I don't do it anymore. Your call, of course.

My general view is that where QEMU takes the path of "do what
the hardware does", that is straightforward and doesn't lead
us into future annoying deadends or misdesigns. Where QEMU
does things that are not what the hardware does, that is where
it's easy to go wrong. Real MPS2 hardware doesn't magically
load Linux kernels and DTBs (it boots whatever the firmware
image is).

> Adding support for an entry point and for the rest wasn't really
> that bad - I did it in armv7m_reset() and it's just a few lines
> of code. To load the dtb I leveraged the existing load_dtb()
> in hw/arm/boot.

The boot support for A profile was also very simple -- to start
with. Now it is a complex mess of support for 32-bit and 64-bit
and NUMA and autogenerating or editing DTBs and three or four
different image file formats and maybe booting in EL2 or EL3...

> From this point it only really makes sense to spend more time on it
> if there a path into upstream qemu. Let me know.

I think it's worth supporting Linux on this board, certainly
(and if your issues are due to "missing emulated device" or
"buggy emulated device" I definitely want to fix them).
I'm just not really convinced that it's worth making Linux
a special case that we go out of our way to deal with in
a way which we don't for any of the other 50 RTOSes and
other things you could boot on this.

thanks
-- PMM