android10.0.0_rxx : lunch qemu_trusty_arm64-userdebug fails
Julien Robin
[ 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?
Julien Robin
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 waitinit: 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 loopHowever I'm still not sure to proceed correctly, as I'm doing everything alone with no documentation (I may have missed it?)
Dan Willemsen
--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
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 android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/a30c5a05-6134-43a5-8f3b-32313e32bac0%40googlegroups.com.
Matthew Maurer
* It does not have a GUI
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.
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
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 android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/CAGSQo01HoD%2B8b1LdOrqaqmnQK5Fa1Ys9REVZ9Rt-85E4WrYRaw%40mail.gmail.com.
郁进
I tried to lunch aosp_arm64-eng project, run with android emulator, with qemu args:
在 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 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 <dwill...@google.com> 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
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 android-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/a30c5a05-6134-43a5-8f3b-32313e32bac0%40googlegroups.com.
--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
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 android-...@googlegroups.com.
Julien Robin
郁进
在 2020年7月4日星期六 UTC+8上午12:35:32，Julien Robin写道：
Victor
Victor
Victor
Julien ROBIN
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 supportCONFIG_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
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 android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/a52e9878-7432-4b28-b011-3e58d706491cn%40googlegroups.com.
v..@gmail.com
Julien Robin
repo sync
source build/envsetup.sh
lunch aosp_x86_64-eng
m -j $(nproc)
# out/target/product/generic_x86_64/system.img
# out/target/product/generic_x86_64/vendor.img
Create (and ext4 format) the partition image files that we will use with QEMU:
qemu-img create rootfs.img 5G
qemu-img create userdata.img 1G
qemu-img create cache.img 500M
losetup /dev/loop0 rootfs.img
losetup /dev/loop1 userdata.img
losetup /dev/loop2 cache.img
mkfs -t ext4 /dev/loop0
mkfs -t ext4 /dev/loop1
mkfs -t ext4 /dev/loop2
losetup -d /dev/loop1
losetup -d /dev/loop2
Mouting the rootfs partition
mount -t ext4 /dev/loop0 /where/you/want
The content of system.img may be copied inside a folder which is named like the mount point. Move everything 1 folder back.
cp -a [vendor.img mount point] [rootfs/mount/point]
If the name of the "vendor.img" mount point is "vendor", everything should now be inside the "/vendor" folder of the rootfs mount point. If not, you have to move it to the /vendor folder
Delete :
/vendor/lib64/hw/camera.ranchu.so
/vendor/lib/hw/camera.ranchu.so
/vendor/lib64/hw/camera.ranchu.jpeg.so
/vendor/lib/hw/camera.ranchu.jpeg.so
/vendor/lib64/hw/gralloc.ranchu.so
/vendor/lib/hw/gralloc.ranchu.so
/vendor/lib64/hw/hwcomposer.ranchu.so
/vendor/lib/hw/hwcomposer.ranchu.so
/vendor/lib64/hw/vulkan.ranchu.so
/vendor/lib/hw/vulkan.ranchu.so
Change /vendor/etc/fstab.ranchu, those 2 lines should be enough:
/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
setprop ro.hardware.egl emulation
to
setprop ro.hardware.egl swiftshader
Manufacturing an up to date 5.10 Android kernel:
git clone https://android.googlesource.com/kernel/configs
/!\ From configs/android-5.10/android-recommended.config, if you want to use a mouse, remove the following line : # CONFIG_INPUT_MOUSE is not set
git clone https://android.googlesource.com/kernel/common -b android12-5.10
Start from copying "arch/x86/configs/x86_64_defconfig" file to the root of the kernel tree, name it ".config", and append to it:
CONFIG_NETFILTER_ADVANCED=y
Content of configs/android-5.10/android-base.config
Content of configs/android-5.10/android-recommended.config
Content of configs/android-5.10/android-recommended-x86.config
make menuconfig, exit, save: yes.
By looking with some tools, some of the things included into x86_64_defconfig, android-base.config, android-recommended.config are not included into the resulting ".config".
It works anyway, but it would be nice to know why theese option aren't enabling.
Still missing from x86_64_defconfig
CONFIG_SYSVIPC=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_ROOT_NFS=y
Still missing from android-base.config:
CONFIG_INET_DIAG_DESTROY=y
CONFIG_INET_UDP_DIAG=y
CONFIG_TRACE_GPU_MEM=y
Still missing from android-recommended.config:
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_ENABLE_DEFAULT_TRACERS=y
CONFIG_REFCOUNT_FULL=y
CONFIG_SDCARD_FS=y
Now, 3 options that are still disabled, but should be enabled according to android-base-conditional.xml:
CONFIG_KFENCE=y
CONFIG_USERFAULTFD=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_AIO and CONFIG_ANDROID_BINDERFS options (from android-base.config) are causing early reboot without explanations. Would be nice to know why, to keep them enabled and have something running... Until so, disable them by adding at the end of .config:
# CONFIG_AIO is not set
# CONFIG_ANDROID_BINDERFS is not set
Adding VirtIO things:
CONFIG_VIRTIO=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_LEGACY=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_INPUT=y
CONFIG_VIRTIO_MMIO=y
CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
CONFIG_VIRTIO_DMA_SHARED_BUFFER=y
CONFIG_BLK_MQ_VIRTIO=y
CONFIG_MEMORY_BALLOON=y
CONFIG_BALLOON_COMPACTION=y
CONFIG_PAGE_REPORTING=y
CONFIG_DRM_GEM_SHMEM_HELPER=y
CONFIG_DRM_VIRTIO_GPU=y
Above options are enough if you use "-vga virtio" option into QEMU/KVM command line.
If wanting to use "-vga std" instead, in order to have the display initializing itself, I had to add:
CONFIG_DRM_BOCHS=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
make menuconfig, exit, save: yes.
make -j $(nproc)
make INSTALL_MOD_PATH=/home/user/Desktop/ INSTALL_MOD_STRIP=1 modules_install
Place the content of /home/user/Desktop/lib/modules/5.10.37+/ into /vendor/lib/modules/
Unmount rootfs.img:
umount /its/mount/point
losetup -d /dev/loop0
Ready to go: from where the "rootfs.img", "userdata.img" and "cache.img", and "bzImage" files are located, type:
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=rootfs.img -drive format=raw,file=userdata.img -drive format=raw,file=cache.img -vga virtio
Julien Robin
repo sync
source build/envsetup.sh
lunch
# out/target/product/generic_arm64/system.img
# out/target/product/generic_arm64/vendor.img
Create and ext4 format the partition image files:
qemu-img create rootfs.img 5G
qemu-img create userdata.img 1G
qemu-img create cache.img 500M
losetup /dev/loop0 rootfs.img
losetup /dev/loop1 userdata.img
losetup /dev/loop2 cache.img
mkfs -t ext4 /dev/loop0
mkfs -t ext4 /dev/loop1
mkfs -t ext4 /dev/loop2
losetup -d /dev/loop1
losetup -d /dev/loop2
Mouting the rootfs partition
mount -t ext4 /dev/loop0 /where/you/want
cp -a [vendor.img mount point] [rootfs/mount/point]
Delete these files:
/vendor/lib/hw/camera.ranchu.so
/vendor/lib/hw64/camera.ranchu.so
/vendor/lib/hw/camera.ranchu.jpeg.so
/vendor/lib/hw64/camera.ranchu.jpeg.so
/vendor/lib/hw/vendor/lib/hw/gralloc.ranchu
/vendor/lib/hw64/gralloc.ranchu
/vendor/lib/hw/hwcomposer.ranchu
/vendor/lib/hw64/hwcomposer.ranchu
/vendor/lib/hw/vulkan.ranchu.so
/vendor/lib/hw64/vulkan.ranchu.so
/vendor/etc/init/rild.rc
Change /vendor/etc/fstab.ranchu, those 2 lines should be enough:
/dev/block/vdc /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,check,quota,reservedsize=128M,first_stage_mount
Change /vendor/etc/init/hw/init.ranchu.rc by changing this line:
setprop ro.hardware.egl emulation
to
setprop ro.hardware.egl swiftshader
Manufacturing an up to date 5.10 ARM64 Android kernel:
git clone https://android.googlesource.com/kernel/configs
/!\ From configs/android-5.10/android-recommended.config, if you want to use a mouse, remove the following line : # CONFIG_INPUT_MOUSE is not set
git clone https://android.googlesource.com/kernel/common -b android12-5.10
CONFIG_NETFILTER_ADVANCED=y
Content of configs/android-5.10/android-base.config
Content of configs/android-5.10/android-recommended.config
make ARCH=arm64 menuconfig, exit, save: yes.
By looking with some tools, some of the things included into x86_64_defconfig, android-base.config, android-recommended.config are not included into the resulting ".config".
It works anyway, but it would be nice to know why theese option aren't enabling.
CONFIG_SYSVIPC=y
CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_KSM=y
CONFIG_IP6_NF_NAT=m
CONFIG_IP6_NF_TARGET_MASQUERADE=m
CONFIG_LEGACY_PTY_COUNT=16
CONFIG_POWER_AVS=y
CONFIG_BACKLIGHT_GENERIC=m
CONFIG_QCOM_IOMMU=y
CONFIG_NFS_FS=y
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
CONFIG_ROOT_NFS=y
Still missing from android-base.config:
Still missing from android-recommended.config:
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_SDCARD_FS=y
Now, some options that are still disabled, but should be enabled according to android-base-conditional.xml:
CONFIG_ARMV8_DEPRECATED=y
CONFIG_CP15_BARRIER_EMULATION=y
CONFIG_SETEND_EMULATION=y
CONFIG_SHADOW_CALL_STACK=y
CONFIG_SWP_EMULATION=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_KFENCE=y
CONFIG_USERFAULTFD=y
CONFIG_AIO and CONFIG_ANDROID_BINDERFS options (from android-base.config) are causing early reboot without explanations. Would be nice to know why, to keep them enabled and have something running... Until so, disable them by adding at the end of .config:
# CONFIG_AIO is not set
# CONFIG_ANDROID_BINDERFS is not set
Adding VirtIO things:
CONFIG_VIRTIO=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_LEGACY=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_INPUT=y
CONFIG_VIRTIO_MMIO=y
CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
CONFIG_VIRTIO_DMA_SHARED_BUFFER=y
CONFIG_BLK_MQ_VIRTIO=y
CONFIG_MEMORY_BALLOON=y
CONFIG_BALLOON_COMPACTION=y
CONFIG_PAGE_REPORTING=y
CONFIG_DRM_GEM_SHMEM_HELPER=y
CONFIG_DRM_VIRTIO_GPU=y
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j $(nproc)
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_MOD_PATH=/home/user/Desktop/ INSTALL_MOD_STRIP=1 modules_install
Place the the arch/arm64/boot/Image.gz file at the same place as the rootfs.img, userdata.img and cache.img files
Place the content of /home/user/Desktop/lib/modules/5.10.37+/ into /vendor/lib/modules/
Unmount rootfs.img
umount /its/mount/point
losetup -d /dev/loop0
Ready to go:
qemu-system-aarch64 -M virt -cpu cortex-a72 -accel tcg,thread=multi -smp 4 -m 2048 -kernel Image.gz -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 -device nec-usb-xhci -device usb-kbd -device usb-mouse -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -drive format=raw,file=rootfs.img -drive format=raw,file=userdata.img -drive format=raw,file=cache.img
If you are lucky enough to have an arm64 machine with KVM available on it, and enough RAM, into the above command line, remplace:
qemu-system-aarch64 -M virt -cpu cortex-a72 -accel tcg,thread=multi -smp 4 -m 2048
by
kvm -M virt -cpu host -accel kvm -smp 4 -m 2048
In summary, from an arm64 computer :
kvm -M virt -cpu host -accel kvm -smp 4 -m 2048 -kernel Image.gz -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 -device nec-usb-xhci -device usb-kbd -device usb-mouse -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -drive format=raw,file=rootfs.img -drive format=raw,file=userdata.img -drive format=raw,file=cache.img
Bits of additionnal information:
Having ARM64 AOSP running on QEMU from x86_64, even with "-accel tcg,thread=multi" which makes things much better, you still need to wait 30 seconds before having "android" boot logo (on an AMD 3700X) and 350 seconds (almost 6 minutes) on first boot before having the android main screen with icons and all stuff (2 minutes at the following boots).
There are some repeated messages about camera 2.4 stuff and radio@1.0. You may remove the /vendor/etc/init/android.hardware...@2.4-service.rc, but messages about "android.hardware.camera.provider@2.4" will still appear, so you may remove the associated entries (camera and radio) from /vendor/manifext.xml. Then no more messages about it.
In case of need to debug, you may type "logcat" in the console: this give way too much informations but you may spot information on what you are looking for, or few lines above some service crashing (sometimes some messages contains usefull information to tell you why it is going to crash just after). Into the "userdata.img" partition you may also find "/tombstones" folder, containing crash logs of services.
Janne Karhunen
Janne Karhunen
FCLC
First of all thank you for provinding the detailed documentation- I'm in the process of attempting to replicate it for my own needs.
An issue/concern of mine is the generation of vendor.img after having executed m/make within AOSP and it not creating a vendor.img file.
Per the AOSP documentation, a vendor image is normally only created via proprietary binaries that aren't a part of AOSP.
I think I might be missing something but I'm not sure what.
Jake Brown
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j $(nproc)
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_MOD_PATH=/home/user/Desktop/ INSTALL_MOD_STRIP=1 modules_install
Jake Brown
- System
- Vendor
- Product
- /dev/block/vdb
- /dev/block/vdc
Julien Robin
Hi Jake,
In order for everybody to compare what differs in case of problems, I uploaded here the results (for both AOSP 10 from today and 11 from yesterday)
- https://pix-server-sorel.luoss.fr/Manual/Android/qemu-kvm-aarch64-android-10.0.0_r47/
- https://pix-server-sorel.luoss.fr/Manual/Android/qemu-kvm-aarch64-android-11.0.0_r38/
Kernel included (with .config file)
Looks like the kernel panic says that the "/init" executable file (stated into the kernel parameters "root=/dev/vda rootfstype=ext4 ro init=/init") wasn't found by the kernel (so the kernel was unable to start the actual operating once ready). It can be because it didn't find the "/dev/vda " disk, because it failed to mount it as "ext4" or because the "/init" file (or link) isn't at the right place.
Here's attached a screen capture to show how I placed my files
into the rootfs.img partition (sometimes pictures are easier to
understand than my complicated explanations 😁). "/init" is a
symbolic link that drives to "/system/bin/init", which is an
android tailored init executable (completely configured by
"/system/etc/init/hw/init.rc" file, which itself includes a lot of
others *.rc files addresses). Just for comparison, on most Linux
distributions, the init process is a link to "systemd" executable
which will start all the services.
For the "defconfig" file copied as ".config" file, I place it at the root of the kernel tree, for example I have "/home/user/Desktop/work/kernel-src/arch/arm64/configs/defconfig" copied here : "/home/user/Desktop/work/kernel-src/.config"
Running menuconfig and saving, is taking into account and
automatically mixing the parameters sets that have been placed
into the ".config" files, in a way that gives the same results as
when using the "scripts/kconfig/merge_config.sh" method described
here https://source.android.com/devices/architecture/kernel/config
(if you prefer using only files and command lines instead of
editing .config manually, this other approach is interesting).
During my attempts, I firstly ran menuconfig after having appended together the content of defconfig, CONFIG_NETFILTER_ADVANCED=y, android base and recommended configs files to .config. Then I ran it a second time after having added the things from android-base-conditional.xml, virtio things and removed the 2 options (CONFIG_AIO and ANDROID_BINDERFS) that were causing trouble on android's boot; but I wouldn't be too surprised to see the same results if running menuconfig only once after everything has been added.
Without the "menuconfig" steps (or the use of merge_config.sh
script), the build process would be asking an almost endless
stream of "yes/no" questions. After menuconfig if only asks few
questions before starting to work.
Hope this will help!
Good luck and have a nice day
Julien
--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
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 android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/d58fe95b-040a-4b9e-a145-b650b438e323n%40googlegroups.com.
