CODEWITHSUNDEEP
linuxarmembeddedqemu
Alessandro Power
Alessandro Power

Reputation: 2472

Emulating an Arietta G25 board with QEMU

I am attempting to emulate an Arietta G25 board using QEMU but am having some difficulties.

I began by compiling Linux with patches to support Arietta, as described here. I then examined the list of supported machines with qemu-system-arm -M help and noticed that while the Arietta board was not listed, there was an option for versatileab and versatilepb which have the same processor as the Arietta.

Inside the kernel directory arch/arm/boot, I ran the command 

QEMU_AUDIO_DRV=none \
qemu-system-arm -M versatilepb \
                -m 256M \
                -kernel zImage \
                -dtb dts/acme-arietta.dtb \
                -nographic \
                -append "console=ttyAMA0"

I expected to see the kernel boot and immediately panic due to the absence of a root filesystem. However, no text was ever displayed on my console.

I tried playing around with the arguments to console (such as using ttyS0, adding rates, etc.) but that did not work.

Upvotes: 0

Views: 340

Answers (1)

Peter Maydell
Peter Maydell

Reputation: 11393

This is a very common point of confusion for people coming to the ARM embedded world who are used to x86. For x86, essentially every bit of hardware you buy will look like a standard PC -- the memory, serial port, etc will all be in exactly the same place and accessed the same way. So guest software will generally just work on any of these systems.

ARM is very different. Different embedded boards and SoCs will have different devices present, and put them at different addresses. Software running on them needs to be built to work with those devices, and trying to run low level software (like a kernel or bootloader or firmware image) on the wrong kind of device will not work. What is happening here is that you've said "boot a kernel built for Arietta and tell it that the UART is where the Arietta's UART lives", but you're running it on a piece of emulated hardware (versatilepb) that is very very different. The kernel will try to talk to hardware that doesn't exist and will just crash. It can't print anything either because it doesn't know where the versatilepb UART is.

Adding support for emulation of a new board model to QEMU is not a trivial process (think of it as about the same amount of work as adding support for that board to the Linux kernel), as you need to write device models for all the hardware that is on that board and which the guest kernel tries to use.

Upvotes: 2

Related Questions