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

[Guenter Roeck]

On 06/16/2018 04:13 AM, Peter Maydell wrote:
> On 15 June 2018 at 19:13, Guenter Roeck <address@hidden> wrote:
> > After hacking qemu to accept the ELF start address and to set
> > initial_msp to 0 (a whopping 6-line patch), I get a bit further.
> > The boot now hangs because the devicetree blob is not recognized.
> > Does qemu load and pass the provided dtb file ? I didn't
> > immediately find any code doing it for armv7m/an385.
>
> As you've discovered, we don't. The assumption for M-profile
> is that you're just passing us an image file, we don't attempt
> to do anything with initrd or dtb. I'm not sure I really want
> to get QEMU into the business of being a boot loader for
> M-profile (there is enough of a mess with just doing that
> for A-profile cores, and most people running code on M-profile
> devices aren't running Linux, so there's less justification
> for special-casing Linux kernel boots). I would recommend
> arranging for the images you want to load to be self-contained
> with a vector table (either by having the kernel build process
> do that, or with a guest-code wrapper.)

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.

FYI, here is where I am:

- Added support for passing the entry point and the dtb start address.
- Added support for loading dtb.
- Added support for loading initdrd

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.

On the Linux side, the only change I had make was to enable the SIO -
the kernel assumed that it was enabled at start and ended up in an
endless loop waiting for space in the Tx FIFO.

Anyway, here is where I am.

...
Timer with delta zero, disabling
[    0.292470] sp805-wdt 40008000.watchdog: registration successful
Extra peripheral region @0x40020000: unimplemented device read (size 4, offset 
0x8000)
Extra peripheral region @0x40020000: unimplemented device write (size 4, value 
0x1, offset 0x8000)
[    0.294377] leds-syscon 40028000.fpgaio:led0: registered LED userled:0
Extra peripheral region @0x40020000: unimplemented device read (size 4, offset 
0x8000)
[    0.294816] leds-syscon 40028000.fpgaio:led1: registered LED userled:1
Extra peripheral region @0x40020000: unimplemented device read (size 4, offset 
0x8000)
Extra peripheral region @0x40020000: unimplemented device write (size 4, value 
0x1, offset 0x8000)
[    0.295647] ledtrig-cpu: registered to indicate activity on CPUs
[    0.296294] NET: Registered protocol family 17
[    0.296756] Key type dns_resolver registered
Timer with delta zero, disabling
[    0.305642] Freeing unused kernel memory: 80K
[    0.305915] This architecture does not have kernel memory protection.
Timer with delta zero, disabling
[    0.316536]
[    0.316536] Unhandled exception: IPSR = 00000006 LR = fffffff1
[    0.316836] CPU: 0 PID: 1 Comm: init Not tainted 
4.17.0-11928-g2837461dbe6f-dirty #4
[    0.317029] Hardware name: MPS2 (Device Tree Support)
[    0.317231] PC is at ret_fast_syscall+0x2/0x58
[    0.317350] LR is at tty_ioctl+0x2a5/0x528
[    0.317455] pc : [<21009002>]    lr : [<210d12f9>]    psr: 4000000b
[    0.317604] sp : 21825fa8  ip : 0000001c  fp : 21b17d86
[    0.317733] r10: 00000000  r9 : 21824000  r8 : 210091c0
[    0.317855] r7 : 00000036  r6 : 21b9cee0  r5 : 00000000  r4 : 21b9cf3c
[    0.318013] r3 : 00000000  r2 : 3d9adf25  r1 : 00000000  r0 : 00000000
[    0.318159] xPSR: 4000000b
[    0.318242] CPU: 0 PID: 1 Comm: init Not tainted 
4.17.0-11928-g2837461dbe6f-dirty #4
[    0.318417] Hardware name: MPS2 (Device Tree Support)
[    0.318985] [<2100bd8d>] (unwind_backtrace) from [<2100b13b>] 
(show_stack+0xb/0xc)
[    0.319228] [<2100b13b>] (show_stack) from [<2100b87b>] 
(__invalid_entry+0x4b/0x4c)
Timer with delta zero, disabling
qemu-system-arm: terminating on signal 2

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

Thanks,
Guenter