[Top][All Lists]

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

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

From: Guenter Roeck
Subject: Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu
Date: Sat, 16 Jun 2018 11:53:45 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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.


reply via email to

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