Hi Julien, Wow, that's awesome! Thank you very much for the detailed info and description! It'll be a very useful reference for us when trying this out!
Again, thanks! Br On Wednesday, May 19, 2021 at 5:48:56 AM UTC+9 [email protected] wrote: > Hi Victor, > > Indeed yes I succeeded in running AOSP 10, then AOSP 11 few time after it > was made available, on upstream QEMU (at least on Debian 10's QEMU). I > succeeded in both x86_64 and arm64. Here's some information I kept and > remember from this work. > > - For AOSP 10, using "lunch aosp_x86_64-eng" or "lunch aosp_arm64-eng" > can build something that, once having its files tweaked enough, will run > on > QEMU. Swiftshader library is built-in and can be used fine. > - For AOSP 11, before building, the "goldfish" specific build > configuration files used by "aosp_x86_64" and "aosp_arm64" have to be > modified* (so it's a little more complicated compared with AOSP 10). > Modified* or duplicated, renamed, edited so that you can create a proper / > separated set of configuration files ;) I ended up doing so. > > In both case, aosp_xxxxx builds are really "emulator specific". Emulator > which is called ranchu, but was previously called goldfish in its previous > versions, so this is why we will use and tweak ranchu and goldfish files in > the process. > > > Let's start from AOSP 10 (aosp_x86_64-eng) > > - lunch aosp_x86_64-eng > - after having mounted "system.img", using "cp -a", place the content > of "system.img" into a partition image file, let's say "rootfs.img" > (created with qemu-img create rootfs.img 5G for example, and mounted with > losetup /dev/loop0 rootfs.img for example) > - after having mounted "vendor.img", using "cp -a", place the content > of "vendor.img" into the /vendor folder of the same rootfs partition > > > - tweak the fstab file : If using "android-x86" kernel, userdata and > cache (/cache and /data mount points) can be mounted as tmpfs. If using a > more standard android kernel, cache.img and data.img file images should be > created and ext4 formatted if I remember. Android x86 kernel is modified > because if I remember well, on standard kernels, sqlitedb writes are > encountering errors if userdata or cache are mounted as tmpfs > > > - my fstab.ranchu for tmpfs using android-x86 kernel > > none /cache tmpfs nosuid,nodev,noatime defaults > none /data tmpfs nosuid,nodev,noatime defaults > > /devices/*/block/sr* auto auto defaults > voldmanaged=cdrom:auto > /devices/*/usb*/* auto auto defaults > voldmanaged=usb:auto,encryptable=userdata > /devices/*/mmc0:a*/* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > /devices/*/*sdmmc*/* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > /devices/*/80860F14:01/mmc_* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > /devices/*/80860F14:02/mmc_* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > /devices/*/80860F16:00/mmc_* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > /devices/*/PNP0FFF:00/mmc_* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > > > - my fstab.ranchu for a more standard android kernel (beware of sdb > and sdc, it will depend on which order you put your disk images in your > QEMU command line) > > /dev/block/sdb /data ext4 > noatime,nosuid,nodev,nomblk_io_submit,errors=panic > wait,check,quota,reservedsize=128M,first_stage_mount > /dev/block/sdc /cache ext4 > noatime,nosuid,nodev,nomblk_io_submit,errors=panic > wait,check,quota,reservedsize=128M,first_stage_mount > > /devices/*/block/sr* auto auto defaults > voldmanaged=cdrom:auto > /devices/*/usb*/* auto auto defaults > voldmanaged=usb:auto,encryptable=userdata > /devices/*/mmc0:a*/* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > /devices/*/*sdmmc*/* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > /devices/*/80860F14:01/mmc_* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > /devices/*/80860F14:02/mmc_* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > /devices/*/80860F16:00/mmc_* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > /devices/*/PNP0FFF:00/mmc_* auto auto defaults > voldmanaged=sdcard1:auto,encryptable=userdata > > > - By using "androidboot.hardware=ranchu" in the kernel command line, > there are things that are needed for running Android on QEMU that will be > automatically loaded (like the soft gatekeeper, gatekeeper.ranchu), but > also others that aren't working with QEMU. I searched for files containing > vulkan.ranchu, gralloc.ranchu, hwcomposer.ranchu in their name and deleted > those files from the rootfs > > > - Edit init.ranchu.rc to use "swiftshader". > > on boot > setprop ro.hardware.egl *swiftshader* > setprop debug.hwui.renderer opengl > setprop debug.hwui.renderer ${ro.kernel.qemu.uirenderer} > setprop ro.opengles.version ${ro.kernel.qemu.opengles.version} > setprop ro.zygote.disable_gl_preload 1 > [...] > > > - The QEMU line I used to run the thing was > > kvm -m 4096 -smp 4 -kernel bzImage -append "root=/dev/sda rootfstype=ext4 > ro init=/init selinux=1 checkreqprot=1 androidboot.selinux=permissive > console=ttyS0 androidboot.hardware=ranchu loglevel=8" -serial mon:stdio > -drive format=raw,file=system.img -vga std > > > - The "bzImage" file was, in this example, a 5.4 kernel taken from > android-x86 source, built using x86_64_defconfig + android config > additions > from https://android.googlesource.com/kernel/configs/, apart from > CONFIG_AIO, which was causing troubles by just rebooting almost as soon as > "init" was executed, without giving any explanation. It was maybe related > to > > https://source.android.com/devices/tech/ota/apex#kernel_command_line_parameter_requirements > > but I believe I never took the time to check that. > > Using a kernel built from > https://android.googlesource.com/kernel/common turned to be possible > by just adding -drive format=raw,file=userdata.img and -drive > format=raw,file=cache.img (of course after having created them, > formatted ext4, and using the right lines into fstab.ranchu) > > At that time I was disabling "CONFIG_MODULES" so that everything was > embedded into the kernel. But if building modules separated from bzImage > file, I believe they simply have to be placed into /vendor/lib/modules/ > without using a 5.4.xx/ subfolder for example. So unlike in most Linux > based OS on which modules are placed into /lib/modules/$(uname -a) > > I'm not using any initramfs : everything is into the rootfs (init and > its configuration files), so the kernel needs to succeed to access > /dev/sda > on its own before being able to reach the loadable modules. If not, needed > modules (SATA and Ext4 related) should be built with "y" (in kernel > menuconfig it's *) instead of "m". > > Also, there is requirement about SELinux, which should be enabled, and > kernel cmdline parameters like selinux=1 checkreqprot=1 > androidboot.selinux=permissive should be taken into account (I > remember that when using the wrong build option, init may early fail and > reboot). > > I marked some more menuconfig notes, into some files, and .config > options, probably because I needed them (I don't remember very well), so > here it is: > > Add CONFIG_NETFILTER_ADVANCED=y before adding "android-base" config options > > Device Drivers ---> > Virtio drivers (check everything just in case), > Graphics support > Cirrus driver for QEMU emulated device > DRM Support for bochs dispi vga interface (qemu stdvga) > Virtio GPU driver > > Console display driver support > Framebuffer Console support > > CONFIG_INPUT_MOUSE=y > CONFIG_MOUSE_PS2=y > CONFIG_MOUSE_PS2_ALPS=y > CONFIG_MOUSE_PS2_BYD=y > CONFIG_MOUSE_PS2_LOGIPS2PP=y > CONFIG_MOUSE_PS2_SYNAPTICS=y > CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y > CONFIG_MOUSE_PS2_CYPRESS=y > CONFIG_MOUSE_PS2_LIFEBOOK=y > CONFIG_MOUSE_PS2_TRACKPOINT=y > CONFIG_MOUSE_PS2_FOCALTECH=y > CONFIG_MOUSE_PS2_SMBUS=y > > > CONFIG_VT=y > CONFIG_CONSOLE_TRANSLATIONS=y > CONFIG_VT_CONSOLE=y > CONFIG_VT_CONSOLE_SLEEP=y > CONFIG_HW_CONSOLE=y > CONFIG_VT_HW_CONSOLE_BINDING=y > > *ARM64* > > For AOSP 10 using aosp_arm64, I believe it was exactly the same approach, > but I had to remove some services that were failing in loop during the > android boot logo, and possibly remove them from "manifest.xml" so that > Android doesn't try (and fail) to find them. I don't remember which ones, > as I'm not finding back my notes about that. The command line I used to run > it was different from x86_64 kvm one : > > qemu-system-aarch64 -M virt -cpu cortex-a72 -accel tcg,thread=multi -smp 4 > -m 4096 -kernel Image.gz.ax86 -monitor none -parallel none -append > "root=/dev/vda rootfstype=ext4 ro init=/init selinux=1 checkreqprot=1 > androidboot.selinux=permissive console=ttyAMA0 androidboot.hardware=ranchu > loglevel=8" -serial mon:stdio -vga std -device ramfb -drive > format=raw,file=system.img -device nec-usb-xhci -device usb-kbd -device > usb-mouse -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd > > And from an arm64 machine with enough RAM, using kvm as arm64 : > > kvm -M virt -cpu host -accel kvm -smp 4 -m 4096 -kernel Image.gz.ax86 > -monitor none -parallel none -append "root=/dev/vda rootfstype=ext4 ro > init=/init selinux=1 checkreqprot=1 androidboot.selinux=permissive > console=ttyAMA0 androidboot.hardware=ranchu loglevel=8" -serial mon:stdio > -vga std -device ramfb -drive format=raw,file=system.img -device > nec-usb-xhci -device usb-kbd -device usb-mouse -bios > /usr/share/qemu-efi-aarch64/QEMU_EFI.fd > > At that time I was using the android-x86 kernel (which can be built for > arm64 too) and my fstab.ranchu file was > > none /cache tmpfs nosuid,nodev,noatime defaults > none /data tmpfs nosuid,nodev,noatime defaults > > If building a kernel from standard android kernel code, and using ext4 > partitions files for these, beware, it's not sda sdb sdc anymore, but vda > vdb vdc... > > > *AOSP 11 *: I clearly need to play again with QEMU and AOSP 11 and look > into all my files with Meld in order to be able to give you a > working/verified list of everything to do in order to have AOSP 11 running > on QEMU (x86_64 and arm64), I'll have some time tomorrow to do that! I'm > sure enough swiftshader related things aren't included anymore into AOSP 11 > Goldfish/ranchu build configuration files (so those things should be added). > > Recently while playing with Glodroid, Pinephone and RPi 4, Swiftshader > then real Mesa, I noticed that some things related to Goldfish and Audio > suddenly changed on AOSP 11, requiring some more modifications compared to > when AOSP 11 was made available. > > > Best regards, > > Julien > > > On 5/16/21 1:48 PM, Victor wrote: > > Hi Julien, 郁进, > > Did either of you manage to run AOSP on upstream QEMU? > > Thanks > > On Saturday, July 25, 2020 at 12:21:35 AM UTC+9 [email protected] wrote: > >> This is tremendously helpful. Thanks a lot. >> >> My work is focusing on kernel, base on arm architecture, I want have >> whole view of the running kernel. >> >> With qemu & qemu monitor & gdb & crash tools, I can stop kernel anywhere, >> read phy/virt address, registers even system register(with last qemu >> release). >> >> Thanks for sharing your experience, It does greate help. >> >> Hope to hear that you successfully run last AOSP on upstream QEMU. >> >> 在 2020年7月4日星期六 UTC+8上午12:35:32，Julien Robin写道： >> >>> Hi 郁进, >>> >>> Recently I focused on making the untouched Android code base working >>> with standard/upstream QEMU (which is a little bit different from the >>> AOSP's emulator, which is a QEMU derivative), focusing on x86_64 builds and >>> "android-x86" project build configurations; the work is still in progress. >>> But from what I know : >>> >>> When building aosp_XXXX-eng project, the "emulator" command line is made >>> available so that just typing "emulator" into your terminal is (normally) >>> enough to get it starting with the correct parameters set. Most of the time >>> I use "emulator -verbose -show-kernel -no-snapshot" when running the AOSP's >>> emulator. So that you have all the default parameters shown into your >>> terminal, then kernel debug information, then Android's "init" output into >>> your terminal. The kernel used to run those builds is called >>> "kernel-ranchu" : it's a customised and prebuilt version of the 4.14 >>> kernel, intended for use with the aosp's emulator virtual hardware and >>> drivers (called goldfish in its original version, then ranchu). >>> >>> If you build aosp then close the terminal window, and you want the >>> "emulator" command to be available again, you should just type "source >>> build/envsetup.sh && lunch" commands again (no need to rebuild everything). >>> >>> But for arm64 builds its horribly slow, like several minutes for booting >>> (upstream qemu is making the following option "-accel tcg,thread=multi" >>> available so that the performance using an AMD 3700X is almost similar to >>> using KVM on a native arm64 Raspberry Pi 4. But unfortunately this accel >>> option does not seem to be used by the "emulator" command, and seems not to >>> work on AOSP's emulator, at least last time I tried). Be aware that >>> emulator is a derivative of QEMU, recognizing some AOSP specific commands, >>> and not recognizing some orginal QEMU commands. >>> >>> *About having the kernel finding and starting "init" :* >>> >>> Lot of things can be confusing about having your emulator or qemu >>> finding and running "init" process. I will give you everything I discovered >>> so that hopefully you will be able to understand and debug anything that >>> happens to you >>> >>> On really old versions of Android, "init" executable was only available >>> into the ramdisk, and "system" partition was just containing the /system >>> subfolder (this is the opposite of "system as root"). In this case, Linux >>> kernel absolutely needed to load the ramdisk, because init was into this >>> ramdisk. I guess fstab file was into the ramdisk too, in order to find and >>> mount partitions once init started. >>> >>> Some more recent version of android using "system as root" (8 or 9 >>> maybe) gave some ramdisk file as parameter to the emulator, despite the >>> fact this ramdisk wasn't actually used anymore by the emulator : the >>> content of the ramdisk was already into system.img. And the kernel was >>> already able to access the system.img partition without the need of >>> anything into the ramdisk - so the ramdisk wasn't used anymore. "init" file >>> was at the root of the system.img partition image. In this case, you should >>> ensure your machine and kernel are able to find your ext4 root (when in >>> trouble, look into the kernel messages to find an ext4 file system at >>> /dev/sda, or /dev/vda, or even sda1, vda1, etc, so that you can be sure >>> about the kernel ability to see the partition you need). >>> >>> But Android 10 introduced a new partition/image format that can be >>> dynamically expanded and physically fragmented (so that devices sold with a >>> too small system partition for being updated, can be updated anyway). This >>> is cool feature, but a little bit more complex to handle. When using this >>> kind of system images, android requires a brand new specific ramdisk with a >>> specific "init" executable in order to read and mount this new system >>> partition format created by android. I believe emulator is using it with >>> Android 10 (to be confirmed). But in order to focus on my work, I'm still >>> using the previous way : an ext4 system.img with everything into it ;) so >>> that qemu boots it directly. >>> >>> >>> For example, on my x86_64 custom builds using "system as root", and >>> having the vendor files included into system.img, as a standard ext4 image, >>> I run the following command to start it using QEMU : >>> >>> kvm -m 4096 -smp 4 -kernel bzImage -append "root=/dev/sda >>> rootfstype=ext4 ro init=/init selinux=1 checkreqprot=1 >>> androidboot.selinux=permissive console=ttyS0 androidboot.hardware=luoss >>> loglevel=8" -serial mon:stdio -drive format=raw,file=system.img -vga std >>> -m 4096 ask for 4GB RAM >>> bzImage is a custom 5.4 kernel >>> root=/dev/sda rootfstype=ext4 ro init=/init is telling my kernel to >>> mount what it sees as "/dev/sda" and to run the "init" executable which is >>> located into it >>> selinux=1 checkreqprot=1 androidboot.selinux=permissive are selinux >>> parameters : when you want to disable selinux, you can't (init absolutely >>> wants your kernel to have selinux running) but you set it to >>> androidboot.selinux=permissive, so that no operation is actually blocked. >>> console=ttyS0 ask the kernel to print its messages into the serial port >>> androidboot.hardware=HW_NAME is used to tell init process to load >>> init.HW_NAME.rc configuration file (that should be into /init.HW_NAME.rc >>> or /vendor/etc/init/hw/init.HW_NAME.rc). For aosp emulator builds, it is >>> /vendor/etc/init/hw/init.ranchu.rc >>> loglevel=8 ask for the kernel, then init, to be as verbose as possible >>> >>> -serial mon:stdio is a qemu parameter I use to redirect the virtual >>> serial port (on which the kernel talks) to the terminal in which qemu is >>> running. So that I can use this terminal as a read/write terminal with the >>> virtual machine. >>> >>> >>> The system image i'm using to do so is an ext4 partition image, on which >>> i placed everything needed, and an init.luoss.rc and fstab.luoss files - >>> mainly just to mount a /data tmpfs instead of using a real userdata.img >>> partiton - yes, I'm cheating ;) normally system.img is not enough, and in >>> most case, /vendor subfolder is into a vendor.img partition. >>> >>> I guess that when I'll be trying to run arm64 builds on qemu, some >>> parameters will need to be changed. >>> >>> I hope that all this information will help you to successfully dig, >>> understand and solve your issues! >>> >>> Best regards >>> >>> Julien >>> >>> Le lundi 29 juin 2020 06:41:01 UTC+2, 郁进 a écrit : >>>> >>>> Hi, >>>> >>>> I found another tickets you submitted to run arm64 android via qemu. >>>> >>>> I tried to lunch aosp_arm64-eng project, run with android emulator, >>>> with qemu args: >>>> >>>> emulator -kernel >>>> ../Android_kernel/out/android-mainline/common/arch/arm64/boot/Image >>>> -system >>>> xxx ...... *-qemu **--monitor tcp:127.0.0.1:2222 >>>> <http://127.0.0.1:2222>,server,nowait -gdb tcp::4444 -S* >>>> >>>> But the Android kernel panic occurred since no init found, and I try to >>>> dump guest memory via qemu monitor, can't parsed by crash tools. >>>> >>>> Have you build and run arm64 android via qemu successfully? How ? >>>> >>>> Looking forward to your reply, many thanks. >>>> >>>> >>>> 在 2020年3月3日星期二 UTC+8下午11:18:37，Julien ROBIN写道： >>>>> >>>>> Many thanks for your answers >>>>> >>>>> In fact what I'm trying to do is using QEMU files into AOSP source >>>>> code to get Android (with GUI) built and running on a standard/upstream >>>>> QEMU version. >>>>> >>>>> This would give the ability of running Android and its future releases >>>>> without real "porting", on any device running a Linux kernel (be it >>>>> upstream or not) and having KVM working on it. Which would be extremely >>>>> interesting. >>>>> >>>>> From what you write, it seems qemu-trusty-arm64 is not really for me. >>>>> So what I'm trying to do is probably more about using >>>>> device/generic/qemu/qemu_arm64.mk (and others archs) files included >>>>> into AOSP. So I'll continue into this other subject : >>>>> https://groups.google.com/forum/?hl=bn#!topic/android-building/kbiEg5OxBGU >>>>> >>>>> >>>>> While talking with you, I noticed that AVD Emulator is different from >>>>> upstream QEMU, probably about goldfish and ranchu related things. Things >>>>> working fine with the emulator (aosp_x86_64-eng for example and >>>>> android-goldfish-4.14-dev which seems mandatory to get Android 10 working >>>>> with AVD Emulator) does not seems to be working with upstream QEMU (at >>>>> least I can't get the GUI). Therefore the documentation about AVD >>>>> Emulator >>>>> builds https://source.android.com/setup/create/avd didn't really help >>>>> me for upstream QEMU. >>>>> >>>>> Can you confirm it's possible to use modern versions of AOSP on >>>>> upstream QEMU? Someone did succeed in the past with Android 6 / untouched >>>>> AOSP and a extended compatibility kernel (I have one based on >>>>> android-goldfish-4.14-dev), this is why I'm trying with newer versions of >>>>> AOSP. This was documented here, but it's not up to date anymore : >>>>> https://www.collabora.com/news-and-blog/blog/2016/09/02/building-android-for-qemu-a-step-by-step-guide/ >>>>> >>>>> Thank you in advance >>>>> >>>>> Julien >>>>> >>>>> >>>>> On 3/2/20 10:51 PM, 'Matthew Maurer' via Android Building wrote: >>>>> >>>>> This target is a testing target used for evaluating our reference >>>>> TrustZone implementation. "storageproxyd" is continuously resetting there >>>>> because it is not being launched by our test script >>>>> <https://android.googlesource.com/trusty/device/arm/generic-arm64/+/refs/heads/master/project/qemu/qemu.py> >>>>> which >>>>> would attach a virtual RPMB resource. >>>>> >>>>> A few notes about this target: >>>>> * It does not have a GUI >>>>> * Running Java is not supported and unlikely to work >>>>> * It requires a custom EL3 and Trusty running alongside it to work >>>>> >>>>> The manifest for these components is at >>>>> https://android.googlesource.com/trusty/manifest, and that manifest >>>>> contains a checked in prebuilt of the qemu_trusty_arm64-userdebug target >>>>> that we are currently testing against. >>>>> >>>>> If you tell me more about what you're trying to make the target do, I >>>>> may be able to give you further help with getting it to do what you want. >>>>> If you aren't trying to use or inspect the Trusty TZ implementation, this >>>>> target probably isn't the one you're looking for. >>>>> >>>>> On Mon, Mar 2, 2020 at 1:34 PM Dan Willemsen <[email protected]> >>>>> wrote: >>>>> >>>>>> +Matthew Maurer Do we have any documentation on this target? I think >>>>>> the last time we talked about this target it was only minimally >>>>>> functional. >>>>>> >>>>>> - Dan >>>>>> >>>>>> On Mon, Mar 2, 2020 at 12:51 PM Julien Robin <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I succeeded to find a workaround for the issue I signaled here, >>>>>>> editing device/generic/trusty/BoardConfig.mk and putting >>>>>>> BUILD_QEMU_IMAGES >>>>>>> to false, which still gives vendor.img, system.img and userdata.img >>>>>>> >>>>>>> I then found this kernel >>>>>>> https://android.googlesource.com/kernel/common/+/refs/heads/android-trusty-4.19, >>>>>>> >>>>>>> and using arch/arm64/configs/trusty_qemu_defconfig, I successfully >>>>>>> built it. >>>>>>> >>>>>>> Also, I'm able to start most of this Android build on Debian 10 >>>>>>> provided qemu-system-aarch64 the following way : >>>>>>> >>>>>>> qemu-system-aarch64 >>>>>>> -M virt >>>>>>> -cpu cortex-a57 >>>>>>> -smp 1 >>>>>>> -m 2048 >>>>>>> -monitor none >>>>>>> -parallel none >>>>>>> -serial mon:stdio >>>>>>> -kernel Image -append "root=/dev/vda rootfstype=ext4 ro >>>>>>> init=/init loglevel=8 selinux=1 checkreqprot=1 >>>>>>> androidboot.selinux=permissive androidboot.hardware=qemu_trusty >>>>>>> console=ttyAMA0" >>>>>>> -device virtio-gpu-pci >>>>>>> -drive format=raw,file=system-custom.img >>>>>>> -drive format=raw,file=userdata-custom.img >>>>>>> >>>>>>> userdata-custom.img is just a bigger userdata.img (1024MB instead of >>>>>>> 4) in which I used resize2fs, system-custom.img is just a system.img in >>>>>>> which the placeholder folder "vendor" now embeds the content of >>>>>>> vendor.img, >>>>>>> copied by "cp -a". Finally, still into system-custom.img, >>>>>>> fstab.qemu_trusty >>>>>>> only contains >>>>>>> LABEL=data /data ext4 noatime,nosuid >>>>>>> ,nodev,errors=panic wait >>>>>>> So that /data (available at /dev/vdb) is mounted by its label, while >>>>>>> system-custom.img embeding root system and vendor is already mounted by >>>>>>> kernel cmdline (by /dev/vda). ramdisk.img is not used as system.img >>>>>>> already >>>>>>> contains everything needed to start init. >>>>>>> >>>>>>> However, I guess I should use a slightly modified version of qemu, >>>>>>> available here >>>>>>> https://android.googlesource.com/trusty/external/qemu/+/refs/heads/master >>>>>>> Because using Debian 10 qemu version, I get the following output, >>>>>>> and no display : >>>>>>> >>>>>>> init: init first stage started! >>>>>>> [...] >>>>>>> init: Loading SELinux policy >>>>>>> [...] >>>>>>> selinux: SELinux: Loaded policy from /vendor/etc/selinux/ >>>>>>> precompiled_sepolicy >>>>>>> >>>>>>> selinux: SELinux: Loaded file_contexts >>>>>>> >>>>>>> random: init: uninitialized urandom read (40 bytes read) >>>>>>> random: init: uninitialized urandom read (40 bytes read) >>>>>>> init: init second stage started! >>>>>>> [...] >>>>>>> ueventd: Coldboot took 1.344 seconds >>>>>>> [...] >>>>>>> init: starting service 'storageproxyd'... >>>>>>> libprocessgroup: CgroupMap::FindController called for [1] failed, >>>>>>> RC file was not initialized properly >>>>>>> libprocessgroup: Failed to make and chown /uid_0: Read-only file >>>>>>> system >>>>>>> libprocessgroup: CgroupMap::FindController called for [829] failed, >>>>>>> RC file was not initialized properly >>>>>>> init: createProcessGroup(0, 829) failed for service 'storageproxyd': >>>>>>> Read-only file system >>>>>>> init: cpuset cgroup controller is not mounted! >>>>>>> init: Service 'storageproxyd' (pid 829) exited with status 1 >>>>>>> init: Sending signal 9 to service 'storageproxyd' (pid 829) process >>>>>>> group... >>>>>>> libprocessgroup: CgroupMap::FindController called for [1] failed, >>>>>>> RC file was not initialized properly >>>>>>> libprocessgroup: CgroupMap::FindController called for [1] failed, >>>>>>> RC file was not initialized properly >>>>>>> >>>>>>> >>>>>>> init: starting service 'storageproxyd'... >>>>>>> libprocessgroup: CgroupMap::FindController called for [1] failed, >>>>>>> RC file was not initialized properly >>>>>>> libprocessgroup: Failed to make and chown /uid_0: Read-only file >>>>>>> system >>>>>>> init: createProcessGroup(0, 830) failed for service 'storageproxyd': >>>>>>> Read-only file system >>>>>>> libprocessgroup: CgroupMap::FindController called for [830] failed, >>>>>>> RC file was not initialized properly >>>>>>> init: cpuset cgroup controller is not mounted! >>>>>>> init: Service 'storageproxyd' (pid 830) exited with status 1 >>>>>>> init: Sending signal 9 to service 'storageproxyd' (pid 830) process >>>>>>> group... >>>>>>> >>>>>>> ...and so on in loop >>>>>>> >>>>>>> However I'm still not sure to proceed correctly, as I'm doing >>>>>>> everything alone with no documentation (I may have missed it?) >>>>>>> >>>>>>> Is here some documentation available? If there isn't, is someone >>>>>>> able to provide an example of working qemu command line (even old or >>>>>>> unoptimized), or just few explanations so that I can be placed on the >>>>>>> right >>>>>>> track? >>>>>>> >>>>>>> Thank you very much in advance >>>>>>> >>>>>>> >>>>>>> On 3/1/20 2:14 PM, Julien Robin wrote: >>>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> I see that starting from branch android-10.0.0_r1, lunch offers a >>>>>>>> choice called qemu_trusty_arm64-userdebug, in which I'm interested >>>>>>>> >>>>>>>> However, I got the following error, no matter which OS I'm using >>>>>>>> for building (be it Ubuntu 18.048 or Debian 10). I have this error on >>>>>>>> r1, >>>>>>>> r20 and r29. >>>>>>>> >>>>>>>> [ 62% 16150/26047] Create system-qemu.img now >>>>>>>> FAILED: out/target/product/trusty/system-qemu.img >>>>>>>> /bin/bash -c "(export SGDISK=out/host/linux-x86/bin/sgdisk >>>>>>>> SIMG2IMG=out/host/linux-x86/bin/simg2img; >>>>>>>> device/generic/goldfish/tools/mk_combined_img.py -i >>>>>>>> out/target/product/trusty/system-qemu-config.txt -o >>>>>>>> out/target/product/trusty/system-qemu.img)" >>>>>>>> 1+0 records in >>>>>>>> 2048+0 records out >>>>>>>> 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0063128 s, 166 MB/s >>>>>>>> Traceback (most recent call last): >>>>>>>> File "device/generic/goldfish/tools/mk_combined_img.py", line 163 >>>>>>>> , in <module> >>>>>>>> main() >>>>>>>> File "device/generic/goldfish/tools/mk_combined_img.py", line 135 >>>>>>>> , in main >>>>>>>> if check_sparse(partition["path"]): >>>>>>>> File "device/generic/goldfish/tools/mk_combined_img.py", line 12, >>>>>>>> in check_sparse >>>>>>>> with open(filename, 'rb') as i: >>>>>>>> IOError: [Errno 2] No such file or directory: >>>>>>>> 'out/target/product/trusty/vbmeta.img' >>>>>>>> 13:44:11 ninja failed with: exit status 1 >>>>>>>> >>>>>>>> #### failed to build some targets (19:41 (mm:ss)) #### >>>>>>>> >>>>>>>> What should I do to get qemu_trusty_arm64-userdebug building >>>>>>>> successfully? >>>>>>>> >>>>>>>> Thank you in advance! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Julien ROBIN >>>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> You received this message because you are subscribed to the "Android >>>>>>> Building" mailing list. >>>>>>> To post to this group, send email to [email protected] >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected] >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/android-building?hl=en >>>>>>> >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Android Building" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/android-building/a30c5a05-6134-43a5-8f3b-32313e32bac0%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/android-building/a30c5a05-6134-43a5-8f3b-32313e32bac0%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> -- >>>>> You received this message because you are subscribed to the "Android >>>>> Building" mailing list. >>>>> To post to this group, send email to [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/android-building?hl=en >>>>> >>>>> --- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "Android Building" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/android-building/fY-gdZQ-67M/unsubscribe >>>>> . >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/android-building/CAGSQo01HoD%2B8b1LdOrqaqmnQK5Fa1Ys9REVZ9Rt-85E4WrYRaw%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/android-building/CAGSQo01HoD%2B8b1LdOrqaqmnQK5Fa1Ys9REVZ9Rt-85E4WrYRaw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> -- > -- > You received this message because you are subscribed to the "Android > Building" mailing list. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > > [email protected] > > > For more options, visit this group at > http://groups.google.com/group/android-building?hl=en > > --- > You received this message because you are subscribed to a topic in the > Google Groups "Android Building" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/android-building/fY-gdZQ-67M/unsubscribe > . > > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/android-building/a52e9878-7432-4b28-b011-3e58d706491cn%40googlegroups.com > > <https://groups.google.com/d/msgid/android-building/a52e9878-7432-4b28-b011-3e58d706491cn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/c2c53b24-6432-4d95-87c8-7f73a4ec5d00n%40googlegroups.com.
