Issue #1948
openDocument how to install and run Replicant in a virtual machine
0%
Description
Some development work, like bootloader hacking, is much easier to do when Replicant is running in a virtual machine rather than on a phone/tablet or a dev board.
There are likely also use cases for end users where knowing how to install and run Replicant in a virtual machine is useful as well.
There is a post here related to emulating Exynos 4210 BootROM (which is in the Replicant supported Galaxy S2) in QEMU: https://fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html
Here is the git repo for the Exynos 4210 BootROM in QUMU: https://github.com/frederic/qemu-exynos-bootrom
Three years ago it was reported that Replicant could be run in VirtualBox using Replicant's SDK: https://redmine.replicant.us/boards/3/topics/10341?r=12267#message-12267
Since we don't have a Replicant 6 SDK, those instructions can't be used directly by us for documentation.
Updated by Adonay Felipe Nogueira over 4 years ago
I noticed that the author of the first link and repository (second link) actually did an entire new QEMU. I don't know the reason for that, but I wonder if that was really needed.
In order to not ask meaningless question, I think that it's best to include the changes in QEMU (upstream), rather than fork. Was there an attempt to convince the author of the custom QEMU (second link) to contribute upstream?
Updated by Kurtis Hanna over 4 years ago
I think that you can optionally specify hardware in QEMU. This would be beneficial for bootloader hacking work especially. You do seem to be correct that the author of that i9100 QEMU code didn't upstream their work. I'm not seeing their commits here in the mainline repo here
I don't think that any of us have asked the code author to upstream their work based on the fact that I rarely hear any chatter within the project about working to get Replciant working on QEMU. We have been sharing that link around for a while though, so maybe someone reached out and asked him.
That being said, on the documentation side of things, it likely would be easier to start by providing directions on how to run Replicant in QEMU without specifying any hardware, like the i9100, for it to be running on, if that's possible.
Updated by Denis 'GNUtoo' Carikli over 4 years ago
- Target version deleted (
Any version)
I think it would be a really good idea but not necessarily for bootloader development.
For bootloader problem can be split in two:- A device specific part that may or may not benefit from being able to more or less completely a device. This doesn't require the full Replicant stack to be ported on that specific emulator to work on that bootloader part. Documenting and/or packaging emulator configuration for that would be very interesting.
- A more generic part which would consist of the interface between the bootloader and Replicant. In that case a bootloader would help a lot if the speed is decent enough not to slow down the work. This could accelerate work or testing to the same Replicant image work on multiple devices.
Being able to run Replicant on a fast emulator for testing would be very interesting. It would then probably make sense to target configurations that are as fast as possible, for instance by targeting common host architecture like x86 and taking advantage of virtio drivers. The Replicant 9 port would make that much more easier as it will be using kernels that are very close to upstream Linux.
Updated by Kurtis Hanna over 4 years ago
Here's a blog post from a few months ago written by a colleague of Fred, who wrote the Exynos 4210 blog post linked to above, about reverse-engineering the Samsung Exynos 9820 bootloader to get it running in QEMU: https://allsoftwaresucks.blogspot.com/2019/05/reverse-engineering-samsung-exynos-9820.html