Re: Raspberry PI emulation - "state of the art"

[Peter Maydell]

On Mon, 7 Nov 2022 at 14:08, Filipe Pinto <fpinto@filipe-pinto.com> wrote:
> Since I'm new to the emulation of ARM processors, the following questions 
> popped into my mind:
>
> why is emulation of an accurate representation of a RPI physical
> SoC is so complex?

The answer to this is "because a modern physical SoC is complex".
The rpi SoC contains many devices, many of which are seriously
complicated pieces of hardware in their own right (for instance
the USB controller, or the graphics related hardware). To run
guest code which interacts with that hardware, QEMU needs to have
a model of the hardware. And every vendor's SoC is different:
even if, say, the Broadcom SoC in the rpi and a Samsung SoC
both have a serial port controller (UART), the two UARTs are
typically different hardware with different registers, etc.

The CPU itself is certainly pretty complicated to emulate, but
because all Arm-based SoCs are the same architecture we can have
one CPU emulation that works in all of them (with some feature
flags to define exactly how it behaves). The problem with the
devices is that because they're all different, the work we might
do on one SoC doesn't carry across to help with a different SoC.

> what is the most recent known successful RPI emulation? Is it RPI 3?
> using open source would be ideal (e.g.,QEMU), but would you recommend
> against it since my ultimate objective is to enter the Hyperledger
> identity stack?

I couldn't find anything in a quick search that said what
this piece of software is, but assuming it is "some guest software
that wants to run on an Arm Linux system", I would suggest
using QEMU's "virt" board to boot Linux and then run the software
on that, rather than trying to use the raspberry pi model.
The 'virt' board is much better suited for "just run a kernel",
and has more useful peripherals. QEMU's rpi board models are not
actively being developed, and they have various missing peripherals
and awkward qualities (like not having networking unless you can
make network-over-usb work). You'll spend more time messing around
trying to deal with the emulation than actually getting on with
what you want to be investigating.

PS: be aware that performance characteristics of an emulator
are wildly different from those of real hardware. Don't expect
to be able to get any useful info about performance of the
software by running an emulator. For that you need real h/w.

> is there any article that you  know of that explains in detail
> the differences between "physical SoC" versus "processor" emulations?

You don't need an article for that. The "processor", ie the CPU,
is the thing that executes instructions. The "SoC" is "the CPU
plus a whole lot of other stuff" -- from the point of guest
software, the "other stuff" is basically "lots and lots of devices".
If you run guest code that wants to touch the devices, you need
to emulate those devices. If the guest code you're interested in
is abstracted from the real hardware (eg because it runs in Linux
userspace) then you don't have to emulate that exact SoC and all
its devices, because you can emulate something else that the
kernel (the abstraction layer) will run on.

thanks
-- PMM