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

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

[Guenter Roeck]

Hi,

qemu supports a number of boards with Cortex-M3 CPU. One board supported
by both qemu and Linux is an385.

As part of my kernel testing effort, it would be great to be able to boot
a non-MMU kernel. However, nothing I tried works.

Is it possible to boot a Cortex-M3 Linux kernel with qemu ? If yes, does
anyone happen to know how to do it ?

Thanks,
Guenter

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

[Peter Maydell]

On 14 June 2018 at 22:54, Guenter Roeck <linux@roeck-us.net> wrote:
> qemu supports a number of boards with Cortex-M3 CPU. One board supported
> by both qemu and Linux is an385.
>
> As part of my kernel testing effort, it would be great to be able to boot
> a non-MMU kernel. However, nothing I tried works.
>
> Is it possible to boot a Cortex-M3 Linux kernel with qemu ? If yes, does
> anyone happen to know how to do it ?

I've never tried to boot Linux, only a few RTOS-ish things.
mps2-an385 is probably a reasonably good choice to start with.
Note that it is missing quite a lot of devices, so you might
need to configure Linux not to try to use them (and also
let us know which ones would be useful for us to implement...)
If you pass QEMU the command line -d unimp option it should log
accesses to ranges and devices we don't implement, which may
throw up some useful hints.

Also for M-profile I'd suggest always trying with the most
recent QEMU if you aren't already, since we've been working
actively on it recently.

thanks
-- PMM

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

[Guenter Roeck]

Hi Peter,

On 06/15/2018 02:16 AM, Peter Maydell wrote:
> On 14 June 2018 at 22:54, Guenter Roeck <linux@roeck-us.net> wrote:
>> qemu supports a number of boards with Cortex-M3 CPU. One board supported
>> by both qemu and Linux is an385.
>>
>> As part of my kernel testing effort, it would be great to be able to boot
>> a non-MMU kernel. However, nothing I tried works.
>>
>> Is it possible to boot a Cortex-M3 Linux kernel with qemu ? If yes, does
>> anyone happen to know how to do it ?
> 
> I've never tried to boot Linux, only a few RTOS-ish things.
> mps2-an385 is probably a reasonably good choice to start with.
> Note that it is missing quite a lot of devices, so you might
> need to configure Linux not to try to use them (and also
> let us know which ones would be useful for us to implement...)
> If you pass QEMU the command line -d unimp option it should log
> accesses to ranges and devices we don't implement, which may
> throw up some useful hints.
> 
> Also for M-profile I'd suggest always trying with the most
> recent QEMU if you aren't already, since we've been working
> actively on it recently.
> 

I tried various versions, but usually I am on the latest version
or even mainline (in this case it is v2.12).

Anyway, my problem is much more basic than device support. Whatever I try,
I always get

qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)

R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
XPSR=40000003 -Z-- A handler
FPSCR: 00000000

even when I use a toolchain specifically built for Cortex-M3 and thumb2,
and no matter which image I try to load. Presumably that means that it
tries to execute or jump to a non-thumb2 instruction, but that doesn't
really help me. Any idea, or should I just give up ?

Thanks,
Guenter

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

[Peter Maydell]

On 15 June 2018 at 14:30, Guenter Roeck <linux@roeck-us.net> wrote:
> Anyway, my problem is much more basic than device support. Whatever I try,
> I always get
>
> qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
>
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=00000000
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
> XPSR=40000003 -Z-- A handler
> FPSCR: 00000000
>
> even when I use a toolchain specifically built for Cortex-M3 and thumb2,
> and no matter which image I try to load. Presumably that means that it
> tries to execute or jump to a non-thumb2 instruction, but that doesn't
> really help me. Any idea, or should I just give up ?

Reading the runes that looks like an attempt to start an
image with no vector table in it: R15 is zero, R14 is the
magic "we just took an exception" number, R13 looks like
probably what you get if you started with a zero SP and
then pushed an exception frame.

Try running with -d in_asm,cpu,exec,int,unimp,guest_errors
which will print some logging which will tell you what it
tried to do. But I'm pretty sure what's happened is:

 * on reset, we read the initial PC and SP from the
   non-existent vector table; both are 0
 * in vector table entries, the LSB is the arm/thumb bit,
   so 0 means try to execute from 0 in arm mode
 * any attempt to execute in arm mode is an INVSTATE
   UsageFault
 * ...but at startup UsageFaults are disabled, so we
   escalate to HardFault
 * because SP was 0, the stack-frame setup for exception
   entry pushes it around to 0xffffffe0. This isn't RAM,
   so we take a derived BusFault on exception entry
   (which also escalates to HardFault)
 * we read the PC for the HardFault entry point from the
   vector table. This is 0...
 * ...so we again execute from 0 in arm mode, and fault
 * but because we're now in a HardFault handler we can't
   escalate our UsageFault to HardFault and instead must
   go into Lockup
 * QEMU doesn't implement the architectural lockup behaviour
   so we just abort().

Note that for M profile QEMU, the thing you pass to -kernel
must be be either (a) a raw image file which starts with a
vector table and is intended to be loaded at address zero,
or (b) be an ELF file which we will load at whatever address
it asks, but which must include a vector table at address
zero, because we don't honour the ELF entrypoint address
but instead always load the initial SP and PC from the
vector table.

thanks
-- PMM

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

[Guenter Roeck]

Hi Peter,

On Fri, Jun 15, 2018 at 02:54:33PM +0100, Peter Maydell wrote:
> 
> Note that for M profile QEMU, the thing you pass to -kernel
> must be be either (a) a raw image file which starts with a
> vector table and is intended to be loaded at address zero,
> or (b) be an ELF file which we will load at whatever address
> it asks, but which must include a vector table at address
> zero, because we don't honour the ELF entrypoint address
> but instead always load the initial SP and PC from the
> vector table.
> 
That was useful.

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.

Thanks,
Guenter

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

[Guenter Roeck]

On Fri, Jun 15, 2018 at 11:13:31AM -0700, Guenter Roeck wrote:
> Hi Peter,
> 
> On Fri, Jun 15, 2018 at 02:54:33PM +0100, Peter Maydell wrote:
> > 
> > Note that for M profile QEMU, the thing you pass to -kernel
> > must be be either (a) a raw image file which starts with a
> > vector table and is intended to be loaded at address zero,
> > or (b) be an ELF file which we will load at whatever address
> > it asks, but which must include a vector table at address
> > zero, because we don't honour the ELF entrypoint address
> > but instead always load the initial SP and PC from the
> > vector table.
> > 
> That was useful.
> 
> 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.
> 

So, I didn't find anything because it is not there. I was able to pass
the fdt in some hackish way. This is the end of the resulting log (with
-d exec):

Trace 0: 0x7fffcf797400 [00000000/210d2440/0x11280001] mps2_early_write
Trace 0: 0x7fffcf7975c0 [00000000/210d170a/0x11280001] uart_console_write
Linking TBs 0x7fffcf7975c0 [210d170a] index 0 -> 0x7fffcf797940 [210d171a]
Trace 0: 0x7fffcf797940 [00000000/210d171a/0x11280001] uart_console_write
Linking TBs 0x7fffcf797940 [210d171a] index 0 -> 0x7fffcf797ac0 [210d1728]
Trace 0: 0x7fffcf797ac0 [00000000/210d1728/0x11280001] uart_console_write
Trace 0: 0x7fffcf797c00 [00000000/210d2424/0x11280001] mps2_early_putchar
Linking TBs 0x7fffcf797c00 [210d2424] index 1 -> 0x7fffcf797e00 [210d2432]
Trace 0: 0x7fffcf797e00 [00000000/210d2432/0x11280001] mps2_early_putchar
Trace 0: 0x7fffcf797fc0 [00000000/210d1730/0x11280001] uart_console_write
Linking TBs 0x7fffcf797fc0 [210d1730] index 0 -> 0x7fffcf798080 [210d1714]
Trace 0: 0x7fffcf798080 [00000000/210d1714/0x11280001] uart_console_write
Linking TBs 0x7fffcf798080 [210d1714] index 0 -> 0x7fffcf797940 [210d171a]
Trace 0: 0x7fffcf797940 [00000000/210d171a/0x11280001] uart_console_write
Chain 0: 0x7fffcf797c00 [00000000/210d2424/0x11280001] mps2_early_putchar
Linking TBs 0x7fffcf797c00 [210d2424] index 0 -> 0x7fffcf7981c0 [210d243e]
Trace 0: 0x7fffcf7981c0 [00000000/210d243e/0x11280001] mps2_early_putchar
Linking TBs 0x7fffcf7981c0 [210d243e] index 0 -> 0x7fffcf797c00 [210d2424]
Trace 0: 0x7fffcf797c00 [00000000/210d2424/0x11280001] mps2_early_putchar

At this point it is stuck. I'll try to find out why.

Guenter

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

[Peter Maydell]

On 15 June 2018 at 19:13, Guenter Roeck <linux@roeck-us.net> 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.)

thanks
-- PMM

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 <linux@roeck-us.net> 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

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

[Peter Maydell]

On 16 June 2018 at 16:08, Guenter Roeck <linux@roeck-us.net> 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

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 <linux@roeck-us.net> 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

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

[Peter Maydell]

On 16 June 2018 at 19:53, Guenter Roeck <linux@roeck-us.net> wrote:
> On 06/16/2018 11:08 AM, Peter Maydell wrote:
>> 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.

Well, somebody has to write and maintain the code that deals
with the mismatch between how hardware starts up and how
the kernel wants to be started. The question seems to me
to be whether that should be in QEMU, in the kernel or a
standalone bit of code... I don't think the overall effort
required changes much. (Personally I'd put the code in the
kernel, since it's about a dozen lines of asm and a linker
script or two.)

You need a boot-wrapper bit of code to run the kernel on the
real hardware too. I haven't actually tested it but
I think it ought to work in QEMU too (and if it doesn't
that's a bug I'd like to fix):
 https://github.com/ARM-software/bootwrapper/tree/cortex-m-linux

thanks
-- PMM

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

[Guenter Roeck]

On Tue, Jun 19, 2018 at 01:41:06PM +0100, Peter Maydell wrote:
> On 16 June 2018 at 19:53, Guenter Roeck <linux@roeck-us.net> wrote:
> > On 06/16/2018 11:08 AM, Peter Maydell wrote:
> >> 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.
> 
> Well, somebody has to write and maintain the code that deals
> with the mismatch between how hardware starts up and how
> the kernel wants to be started. The question seems to me
> to be whether that should be in QEMU, in the kernel or a
> standalone bit of code... I don't think the overall effort
> required changes much. (Personally I'd put the code in the
> kernel, since it's about a dozen lines of asm and a linker
> script or two.)
> 
> You need a boot-wrapper bit of code to run the kernel on the
> real hardware too. I haven't actually tested it but
> I think it ought to work in QEMU too (and if it doesn't
> that's a bug I'd like to fix):
>  https://github.com/ARM-software/bootwrapper/tree/cortex-m-linux
> 

Thanks a lot for the link; that gave me enough information to find
a solution that is not too invasive and works for me.

I need to be able to run a single kernel image against multiple
devicetree files and root file systems. This doesn't work with
above solution since it bundles everything together (or, rather,
it would break my workflow). However, it was easy enough to tweak the
boot wrapper and load it using "-bios". I added support for "-bios",
"-initrd", and "-dtb" to mps2_common_init(). That change is simple
enough to carry in my private qemu branch.

Thanks,
Guenter

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

[Peter Maydell]

On 19 June 2018 at 18:43, Guenter Roeck <linux@roeck-us.net> wrote:
> Thanks a lot for the link; that gave me enough information to find
> a solution that is not too invasive and works for me.
>
> I need to be able to run a single kernel image against multiple
> devicetree files and root file systems. This doesn't work with
> above solution since it bundles everything together (or, rather,
> it would break my workflow). However, it was easy enough to tweak the
> boot wrapper and load it using "-bios". I added support for "-bios",
> "-initrd", and "-dtb" to mps2_common_init(). That change is simple
> enough to carry in my private qemu branch.

Glad you found something that works for you.

It is also possible to write a bootwrapper that loads a
kernel/initrd via the semihosting ABI (assuming you trust
your guest, since semihosting lets it read/write arbitrary
host files).
https://git.linaro.org/arm/models/boot-wrapper.git/
is an example of doing that for A-profile.

thanks
-- PMM

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

[Guenter Roeck]

Hi Peter,

On Wed, Jun 20, 2018 at 09:52:00AM +0100, Peter Maydell wrote:
> On 19 June 2018 at 18:43, Guenter Roeck <linux@roeck-us.net> wrote:
> > Thanks a lot for the link; that gave me enough information to find
> > a solution that is not too invasive and works for me.
> >
> > I need to be able to run a single kernel image against multiple
> > devicetree files and root file systems. This doesn't work with
> > above solution since it bundles everything together (or, rather,
> > it would break my workflow). However, it was easy enough to tweak the
> > boot wrapper and load it using "-bios". I added support for "-bios",
> > "-initrd", and "-dtb" to mps2_common_init(). That change is simple
> > enough to carry in my private qemu branch.
> 
> Glad you found something that works for you.
> 
> It is also possible to write a bootwrapper that loads a
> kernel/initrd via the semihosting ABI (assuming you trust
> your guest, since semihosting lets it read/write arbitrary
> host files).
> https://git.linaro.org/arm/models/boot-wrapper.git/
> is an example of doing that for A-profile.
> 

The simple bootloader does its job, and I prefer to have a uniform user
interface - it would really be nice to have consistent support for -bios,
-initrd, and -dtb in qemu. Getting it with ~70 LOC are worth it, even
if I'll have to carry the code along myself.

The last problem I had was that either uclibc-ng or Linux doesn't support
pthreads without MM. With pthreads disabled in buildroot (and with the
cmsdk-apb-timer fix I submitted), I am able to boot an-385 to shell.

Thanks,
Guenter