memfault / interrupt

A community for embedded software makers.

Home Page:https://interrupt.memfault.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Emulating a Raspberry Pi in QEMU: Host Platform?

n1ai opened this issue · comments

commented

Googling gave me your article ( https://interrupt.memfault.com/blog/emulating-raspberry-pi-in-qemu ) as the first result in asking about emulating a pi with qemu, so good for you, you're getting noticed by the algorithm! Thanks for the article, I learned (or re-learned) a lot by reading it. I especially appreciate the links at the end.

Since you asked people to open issues, here I am!

In the article you write about the host platform:

Since I’m on a Mac, and the purpose is to get a working Docker image, I set up an Ubuntu 20.04 Virtual Machine in Parallels. If you want to follow along, I recommend you to do the same and get onto a fresh Ubuntu 20.04 with QEMU...

Ok, you're running on a Mac, but what CPU architecture is in that Mac? Intel or ARM / Apple Silicon?

I think it ends up being relevant because I ran into the problem described here:

https://forums.raspberrypi.com/viewtopic.php?t=361643#p2169817

where a person replies with:

I have also seen this message, have no answer, but it works. Although very slow cause all is emulated, so not really interesting. KVM does anyhow not work on real ARM CPU with those RPi kernels, so it is more to show that it can be done, but not for normal use-cases. Use generic virt machine and default Debian distro kernel.

And I found that article because it did not work on an ARM64 CPU. In my case the description of the platform was so open-ended I said, let's try doing it on a Pi 4. I mean, emulating a Pi running Bookworm on a Pi running Bookworm should work? Apparently, not.

So, overall, I think the article would be better if it specified which kind of Mac you used, and if you expect it to work on platforms running ARM CPUs especially Apples or Pis.

And a minor nit, but sudo umount /mnt/image should happen somewhere once you're done with the mounted image, since that really forces all pending writes to hit the disk and it cleans up the namespace for next time.

And a super-nit: Maybe go more into why mount doesn't work inside Docker whereas mtools does? Or if reference states why, put a link to the reference in that section of the article.

Again, this is all small beer. Overall the article is very useful and very well written!

Regards,
Dave, N1AI