# Running PinePhone Images in QEMU **URL:** \ **Category:** Genode and Sculpt OS\ **Created:** [November 25, 2024, 7:27am UTC](https://genode.discourse.group/t/running-pinephone-images-in-qemu/111 "2024-11-25T07:27:33Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![hamed](https://avatars.discourse-cdn.com/v4/letter/h/d6d6ee/32.png) [@hamed](https://genode.discourse.group/u/hamed)\ **Post date:** [November 25, 2024, 7:27am UTC](https://genode.discourse.group/t/running-pinephone-images-in-qemu/111/1 "2024-11-25T07:27:33Z")
Hi While exploring GPU-related topics and bottleneck routing, I came across the PinePhone, which I found quite intriguing. I also watched Norman Feske’s FOSDEM 2024 session, which was very insightful. Although I don’t own a PinePhone, I attempted to run the provided images in QEMU using the following command but didn’t get any meaningful output. Is it possible to simulate a graphical or serial environment for PinePhone in QEMU? ```bash qemu-system-aarch64 -m 2048 -M \ virt,virtualization=true,gic-version=3 -cpu cortex-a53 -smp 4 \ -global virtio-mmio.force-legacy=false \ -device virtio-net-device,bus=virtio-mmio-bus.0,netdev=net0 \ -device virtio-mouse-device -device virtio-keyboard-device \ -device virtio-gpu-device -netdev user,id=net0 \ -drive file=sculpt-pinephone-2024-11-21.img,format=raw,if=sd,cache=writeback,if=virtio \ -serial mon:stdio -display sdl ``` ---
**Author:** ![nfeske](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/nfeske/32/6_2.png) [@nfeske](https://genode.discourse.group/u/nfeske)\ **Post date:** [November 26, 2024, 11:10am UTC](https://genode.discourse.group/t/running-pinephone-images-in-qemu/111/2 "2024-11-26T11:10:47Z")
The system image expects PinePhone hardware. It would of course be executable on emulated hardware but Qemu does neither contain device models for the peripherals of the PinePhone nor its system-control processor. That said, the graphical environment is not strictly coupled to the PinePhone. In fact, most of the development is done by running (a kind of mockup) of it via Genode/Linux. If you are familiar with Genode’s build system and want to test-drive the UI, let me invite you trying the following: ```auto build/x86_64$ make run/sculpt_test KERNEL=linux BOARD=linux SCULPT=phone ``` You may resize the window into a phone-like shape and use the mouse to interact. For further experimentation/customization, you can find the definition of this flavor of Sculpt OS at genode/repos/gems/sculpt/phone-linux.sculpt. ---
**Author:** ![hamed](https://avatars.discourse-cdn.com/v4/letter/h/d6d6ee/32.png) [@hamed](https://genode.discourse.group/u/hamed)\ **Post date:** [November 27, 2024, 9:48am UTC](https://genode.discourse.group/t/running-pinephone-images-in-qemu/111/3 "2024-11-27T09:48:45Z")
Thank you for the instructions. I followed the command, and it ran successfully. It’s truly fascinating to experience a glimpse of what it would feel like to have a fully custom operating system on a mobile phone. I’m curious about the hardware challenges that cannot be simulated. How do you overcome these challenges? Is it necessary to regularly test on the actual hardware, or are there alternative approaches to mitigate this dependency? ---
**Author:** ![nfeske](https://dub1.discourse-cdn.com/flex006/user_avatar/genode.discourse.group/nfeske/32/6_2.png) [@nfeske](https://genode.discourse.group/u/nfeske)\ **Post date:** [November 27, 2024, 11:07am UTC](https://genode.discourse.group/t/running-pinephone-images-in-qemu/111/4 "2024-11-27T11:07:47Z")
Thank you for giving the command a try! I’m glad that it worked for you. > [@hamed](#): > > How do you overcome these challenges? Is it necessary to regularly test on the actual hardware, or are there alternative approaches to mitigate this dependency? Your question about the challenges requires a long answer. So I wrote a book. The [Genode Platforms](https://genode.org/documentation/genode-platforms-23-05.pdf) book takes you on the ride though this line of work. You will see that most of the efforts needed are concerned about operating the actual hardware (drivers, power management, modem, etc.). That said, once the drivers for a specific hardware are in place, the Sculpt OS base system abstracts the hardware peculiarities away. So almost all interesting components (like the user interface and deployed scenarios) are device-agnostic. Testing on the hardware is needed whenever working on driver-related topics, to assess the performance of the overall system (including power draw), or when working on connectivity (modem, interplay with SIM cards). This development-test workflow is pretty much [streamlined](http://genodians.org/nfeske/2021-09-20-pine-fun-pinephone-boot) for the PinePhone. While working on user-facing topics, I usually work without hardware for days (using Genode/Linux), and test the final result on the device once I feel that most of my work is done. At this point, when switching to the PinePhone hardware, I usually encounter cosmetic issues that come to attention only on a real device (depending on display resolution, touch behavior, cramped use of the on-screen keyboard). For example, in contrast to a using a mouse as I do on Genode/Linux, there is no notion of “hovering” on a touch screen. So to attain a decent touch-screen user experience, those differences must be taken into account. The ability to seamlessly switch between Genode/Linux/x86\_64 and Genode/PinePhone during development has become a second nature.