Hi, I'd really love to be able to send commands via adb from the host to the guest, but when I run *adb devices*
it says *emulator-5554 offline* Any ideas? A lot of what I've come across mentions to turn on USB debugging, but I'm not sure how to do that given our environment Julien walked through. I've tried forwarding tcp traffic and usb connectivity by adding the following lines to the kvm command. I know the forwarding works as the emulator adbd can be seen by the host adb server, but I can't seem to start it or figure out USB debugging. I've also tried *adb reconnect offline* and it just says *reconnecting emulator-5554 *but isn't actually able to turn it on. I have a netdev argument in my qemu command that is set up: *-device e1000,netdev=net0 \* *-netdev user,id=net0,hostfwd=tcp::5555-:5555* >From my understanding this forwards tcp traffic on port 5555 between host and guest. I also have a usb device added to your qemu command *-device usb-ehci,id=ehci \* *-device usb-host,bus=ehci.0,vendorid=0x0bda,productid=0x5411 * (vendorid and productid from running *lsub*) I have another issue that came up in my pursuit of figuring this out, I noticed I can't run any services inside the guest such as *pm* (package install) it says *cmd: Can't find service: package* I'm not sure what is going on here, any ideas with this? I'd like to try and get python installed on this device 2.7 or 3 would be fine which is why I was trying to get pm working. Thanks! Jake On Wednesday, June 30, 2021 at 4:36:52 PM UTC-4 [email protected] wrote: > 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 > On 6/28/21 9:58 PM, Jake Brown wrote: > > Hi Julien, > > Just joining this conversation and I have some questions. > > I actually do have a physical arm64 device that I am trying to act as a > hypervisor to run multiple androids on. I am running Ubuntu 20.04 on the > aarch64 host and I believe what you have outlined is of great help, but I > am running into some issues.... > > Here's what I've done to recap > - Generated the empty userdata.img and cache.img > - Generated rootfs.img and placed the contents of /vendor and /system into > the block that were generated from running lunch from AOSP 10 arm64 > - I moved contents of /system to be on the same level as /vendor within > rootfs > - I made the /vendor/etc/fstab.ranchu to include only the two lines you > mention above removing any defaults > - combined the defconfig, android-base, recommended and recommended-arm64 > config files. > - created a directory in /vendor/lib called /modules and added all the > modules.* files and kernel directory that was generated from running the > following commands > > > *make ARCH=arm64 menuconfig, exit, save: yes. 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* > - Made the Image.gz, rootfs.img, userdata.img, cache.img all be > incorporated into the kvm command which is identical to what you have. I > didn't change anything regarding the qemu command. > > > So I think I followed the instructions but I am getting a *"Kernel panic > - not syncing: Requested init /init failed"* error when I try and boot. > > > A few questions regarding the section on "*Manufacturing an up to date > 5.10 ARM64 Android kernel" * > > - When you said "root" of the kernel file tree, did you mean to place the* > '.config'* file in *'arch/arm64/configs/'*? or in root of the project > where the .config file gets generated after running make > - Do I need to append the configs you mention that are missing before I > run *'make ARCH=arm64 menuconfig'*? I assume so since it generates a new > .config file. > > From my understanding from reading previous conversation about "init", > it's not able to find it that executable so how can I work through this > issue? > > Appreciate any help anyone can provide, > > Thanks! > > > > > > On Monday, May 24, 2021 at 2:14:44 PM UTC-4 [email protected] wrote: > >> Hi again, >> >> Here is the AOSP 10 on ARM64 QEMU version of the procedure I follow. >> Andoid 5.10 arm64 kernel build included, like for x86_64. >> Appart from using "vdb" and "vdc" into fstab instead of sdb and sdc, and >> removing some "rild.rc" file, the approach is the same. With some >> additionnal information at the end >> >> repo init -u https://android.googlesource.com/platform/manifest -b >> android-10.0.0_r47 >> repo sync >> source build/envsetup.sh >> lunch >> m -j $(nproc) >> >> # 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 [system.img mount point] [rootfs/mount/point] >> The content of system.img may be copied inside a folder which is named >> like the mount point. Move everything 1 folder above. >> >> >> 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. If not, you have >> to move it to /vendor folder >> >> >> 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/vdb /data ext4 >> noatime,nosuid,nodev,nomblk_io_submit,errors=panic >> wait,check,quota,reservedsize=128M,first_stage_mount >> /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 >> >> Start from copying "arch/arm64/configs/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-arm64.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. >> >> Still missing from arm64/configs/defconfig >> 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: >> CONFIG_TRACE_GPU_MEM=y >> >> Still missing from android-recommended.config: >> CONFIG_BACKLIGHT_LCD_SUPPORT=y >> CONFIG_REFCOUNT_FULL=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 menuconfig, exit, save: yes. >> 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 >> >> *"Installing" the kernel:* >> 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:* >> >> From an x86_64 computer: >> 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 [email protected]. >> You may remove the /vendor/etc/init/[email protected], but >> messages about "[email protected]" 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. >> >> In order to cleanly poweroff your emulated system you can type "reboot >> -p" so that the "userdata.img" is kept as clean as possible. >> > -- > > -- > 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/d58fe95b-040a-4b9e-a145-b650b438e323n%40googlegroups.com > > <https://groups.google.com/d/msgid/android-building/d58fe95b-040a-4b9e-a145-b650b438e323n%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/ed161820-c28c-4d0a-ae8c-ceb5af4b9bf1n%40googlegroups.com.
