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

[Guenter Roeck]

On 06/16/2018 11:08 AM, Peter Maydell wrote:
> 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).

... while mine is that I have no trouble running Linux test images
in qemu when it supports options such as -dtb and -initrd, while it
is a pain to run and maintain if I have to have a secondary loader
that isn't part of qemu. Guess we just have different perspectives.

> > 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.

I don't think the lack of led emulation is the problem. The problem
is most likely in Linux; it seems to jump to ret_fast_syscall+2
instead of ret_fast_syscall. But then I am not familiar enough with
the code to be sure.

Either case, I'll let this go. It is not worth arguing with you
about qemu integration, nor with the kernel community about
creating a special Linux image, nor spending the time to write
(and subsequently maintain) a front-end bootloader myself.

Thanks,
Guenter