[android-building] Re: Re\: \[android\-building\] Re\: android10.0.0_rxx \: lunch qemu_trusty_arm64\-userdebug fails
Hi, Small update although I haven't been able to hack on this for a while. It runs, and stays running, under the QEMU emulation AND under the KVM on a mobile phone. Mesa graphics stack is initialized and the android animation starts to rotate with virtio acceleration, but there is still something wrong with the appserver (probably an android build issue). What happens is that the 32bit variant of the appserver dies to following: F DEBUG : signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x700303da (*pc=0x4000e8bd) Since that is a 'illegal operation code' and it happens under the kvm as well as under the emulation, the given backtrace and the error code are probably broken. It claims that the error is here: /apex/com.android.art/javalib/arm/boot.oat (art_jni_trampoline+34) which translates to instruction 'add.wr12, sp, #4' that is prefectly fine, no way for that to generate a SIGILL as far as I know. Need to debug some more I guess. -- Janne On Thursday, 26 August 2021 at 20:49:14 UTC+3 Janne Karhunen wrote: > Hi, > > I'm getting pretty close with a legit config. The bootup log is almost > entirely clean. See this: > > https://github.com/jkrh/kvms/blob/master/scripts/run-qemu6-virt-android-super.sh > > If run with the CPU emulation it generates some SIGILLs from zygote (even > with the QEMU MAX cpu), but overall: > [0.856757] [drm] pci: virtio-gpu-pci detected at :00:02.0 > [0.857639] [drm] features: +virgl +edid > ... > 08-20 07:08:30.867 345 345 D libEGL : loaded > /vendor/lib64/egl/libEGL_mesa.so > 08-20 07:08:30.948 345 345 D libEGL : loaded > /vendor/lib64/egl/libGLESv1_CM_mesa.so > 08-20 07:08:31.133 345 345 D libEGL : loaded > /vendor/lib64/egl/libGLESv2_mesa.so > ... > 08-20 07:08:34.216 345 345 I RenderEngine: OpenGL ES informations: > 08-20 07:08:34.216 345 345 I RenderEngine: vendor: Mesa/X.org > 08-20 07:08:34.217 345 345 I RenderEngine: renderer : virgl > 08-20 07:08:34.217 345 345 I RenderEngine: version : OpenGL ES 3.1 > Mesa 21.2.0-devel > > I have the kvm support in there as well, so if you have a capable hardware > it might actually run. > > > -- > Janne > > On Wednesday, 30 June 2021 at 02:32:29 UTC+3 julien@gmail.com wrote: > >> Hi Felix, >> >> I took a look again into all my stuff to double check, using the >> described list of commands* (using Debian 11 x86_64 computer, but was also >> working on Debian 10) I obtained both "system.img" and "vendor.img" into >> the output folder. >> >> Commands*: >> >> source build/envsetup.sh >> lunch aosp_arm64-eng >> m -j $(nproc) >> >> Attached here is a tutorial I made myself about AOSP 11 (arm64) on QEMU: >> for now it works but not perfectly (only works using and arm64 KVM, >> unstable, but starting, and allowing to browse the main screen, menus, >> settings... looks like instability is related to swiftshader, according >> "tombstones" files - Janne Karhunen messages from few days ago may drive to >> something interesting to replace swiftshader by something more efficient on >> qemu!). In case you need to compare your results, here is a link about my >> today attempts following the attached tutorial: >> https://pix-server-sorel.luoss.fr/Manual/Android/qemu-kvm-aarch64-android-11.0.0_r38/ >> >> There is a kernel (today's 5.10.43 version), its .config file, and >> prepared filesystem images to boot android 11.0.0_r38 on arm64 qemu-kvm >> (using a RPi4 for example, at least, that's what I used, 8GB model to have >> plenty of RAM, but 4GB may be enough). Into the "build-output" sub-folder >> you'll find the "system.img" and "vendor.img" that landed into my >> "out/target/product/generic_arm64/" folder (before and after I used >> "simg2img" command to convert them into standard ext4 partitions images). >> >> Good luck ! >> >> Julien >> >> >> On 6/28/21 2:40 PM, Felix LeClair wrote: >> >> Hi Julien, I'm trying to replicate your method for building an arm64 >> build of android that can be run in native QEMU, and have built both AOSP >> and the 5.10 kernel to your specification. >> An issue however is that there seems to be no vendor img produced when >> done in a clean environment. are other steps needed prior to the ones below >> to generate vendor.img ? or should I instead be using files inside of some >> of the other images created by AOSP? >> Thanks, >> FelixCLC >> >> -- -- You received this message because you are subscribed to the "Android Building"
[android-building] Re: Re\: \[android\-building\] Re\: android10.0.0_rxx \: lunch qemu_trusty_arm64\-userdebug fails
Hi, I'm getting pretty close with a legit config. The bootup log is almost entirely clean. See this: https://github.com/jkrh/kvms/blob/master/scripts/run-qemu6-virt-android-super.sh If run with the CPU emulation it generates some SIGILLs from zygote (even with the QEMU MAX cpu), but overall: [0.856757] [drm] pci: virtio-gpu-pci detected at :00:02.0 [0.857639] [drm] features: +virgl +edid ... 08-20 07:08:30.867 345 345 D libEGL : loaded /vendor/lib64/egl/libEGL_mesa.so 08-20 07:08:30.948 345 345 D libEGL : loaded /vendor/lib64/egl/libGLESv1_CM_mesa.so 08-20 07:08:31.133 345 345 D libEGL : loaded /vendor/lib64/egl/libGLESv2_mesa.so ... 08-20 07:08:34.216 345 345 I RenderEngine: OpenGL ES informations: 08-20 07:08:34.216 345 345 I RenderEngine: vendor: Mesa/X.org 08-20 07:08:34.217 345 345 I RenderEngine: renderer : virgl 08-20 07:08:34.217 345 345 I RenderEngine: version : OpenGL ES 3.1 Mesa 21.2.0-devel I have the kvm support in there as well, so if you have a capable hardware it might actually run. -- Janne On Wednesday, 30 June 2021 at 02:32:29 UTC+3 julien@gmail.com wrote: > Hi Felix, > > I took a look again into all my stuff to double check, using the described > list of commands* (using Debian 11 x86_64 computer, but was also working on > Debian 10) I obtained both "system.img" and "vendor.img" into the output > folder. > > Commands*: > > source build/envsetup.sh > lunch aosp_arm64-eng > m -j $(nproc) > > Attached here is a tutorial I made myself about AOSP 11 (arm64) on QEMU: > for now it works but not perfectly (only works using and arm64 KVM, > unstable, but starting, and allowing to browse the main screen, menus, > settings... looks like instability is related to swiftshader, according > "tombstones" files - Janne Karhunen messages from few days ago may drive to > something interesting to replace swiftshader by something more efficient on > qemu!). In case you need to compare your results, here is a link about my > today attempts following the attached tutorial: > https://pix-server-sorel.luoss.fr/Manual/Android/qemu-kvm-aarch64-android-11.0.0_r38/ > > There is a kernel (today's 5.10.43 version), its .config file, and > prepared filesystem images to boot android 11.0.0_r38 on arm64 qemu-kvm > (using a RPi4 for example, at least, that's what I used, 8GB model to have > plenty of RAM, but 4GB may be enough). Into the "build-output" sub-folder > you'll find the "system.img" and "vendor.img" that landed into my > "out/target/product/generic_arm64/" folder (before and after I used > "simg2img" command to convert them into standard ext4 partitions images). > > Good luck ! > > Julien > > > On 6/28/21 2:40 PM, Felix LeClair wrote: > > Hi Julien, I'm trying to replicate your method for building an arm64 build > of android that can be run in native QEMU, and have built both AOSP and the > 5.10 kernel to your specification. > An issue however is that there seems to be no vendor img produced when > done in a clean environment. are other steps needed prior to the ones below > to generate vendor.img ? or should I instead be using files inside of some > of the other images created by AOSP? > Thanks, > FelixCLC > > -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to android-building@googlegroups.com To unsubscribe from this group, send email to android-building+unsubscr...@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-building+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/ad157141-7776-4191-9049-9065b0d3c454n%40googlegroups.com.
Re: [android-building] Re: android10.0.0_rxx : lunch qemu_trusty_arm64-userdebug fails
Hi, I might be wrong, but maybe the graphics pipeline from the guest to the host GPU with QEMU could look something like this: 1) virgl-gallium, https://gitlab.freedesktop.org/mesa/mesa. Android.mk: BOARD_GPU_DRIVERS=virgl 2) virtio-gpu (guest) 3) virtio-gpu (host) 4) virglrenderer (upstream version; not AVDVirglrenderer) 5) host drivers (via libhybris if not a bionic qemu) 6) QEMU display: -spice ...,gl=on Aka. pretty much the standard Linux way of doing things. Since QEMU is such a great development tool for almost all the imaginable targets out there, I'm really surprised Google does not enable this by default. Anyone tried above or is there an easier alternative? I think I'll give it a spin. That said, looks like I got the 'qemu.gltransport' wrong in the prior post. 'virtio-gpu' was the right answer. -- Janne On Wednesday, 23 June 2021 at 08:06:32 UTC+3 Janne Karhunen wrote: > Hi, > > I tried something like this out of interest on arm64 with my own > hypervisor (custom kvm, https://github.com/jkrh/kvms) and indeed I get > the android vm up. Thanks! > > In order to get the AOSP up I first started to port the 'ranchu' machine > to qemu6, but the 'android-emu' library I'd need to hack in the qemu6 main > loop just does not feel 'clean', so this remains unfinished in that regard: > > https://github.com/jkrh/kvms/blob/master/patches/0001-target-ranchu-add-support-for-android-ranchu-board.patch > > That being said, would be nice to make it do GPU too and I'm new to the > graphics pipeline. From the hypervisor point of view I'd need it to do > full VIRTIO since my hypervisor only opens the virtio channels between the > host and the guest. Besides, I'm not entirely sure what to think of the > 'pipe'. > > First attempt with that was to see if it would do 'gltransport=virtio': > KERNEL_OPTS="root=/dev/vda rootfstype=ext4 ro init=/init selinux=1 > checkreqprot=1 androidboot.selinux=permissive console=ttyAMA0 > androidboot.hardware=ranchu qemu.uirenderer=skiagl qemu.gltransport=virtio > qemu.gles=1 qemu.opengles.version=131072 qemu.dalvik.vm.heapsize=192m > loglevel=8" > > and then for the QEMU: > SCREEN="-nographic -device virtio-gpu-pci -spice > $SPICESOCK,disable-ticketing=on $VDAGENT" > > Thoughts if something like this is supposed to be supported? Certainly it > does not work: > > [ 36.445042] DEBUG: Build fingerprint: > 'Android/aosp_arm64/generic_arm64:10/QT/eng.jmk.20210614.160415:userdebug/test-keys' > [ 36.450901] DEBUG: Revision: '0' > [ 36.458537] DEBUG: ABI: 'arm64' > [ 36.462533] DEBUG: Timestamp: 2021-06-01 11:28:17+ > [ 36.465839] DEBUG: pid: 219, tid: 219, name: surfaceflinger >>> > /system/bin/surfaceflinger <<< > [ 36.468971] DEBUG: uid: 1000 > [ 36.474921] DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault > addr 0x10 > [ 36.476737] DEBUG: Cause: null pointer dereference > [ 36.481510] DEBUG: x0 x1 e23fdddf66c0 x2 > e23fd08b59f4 x3 e23fddcef5f8 > [ 36.484085] DEBUG: x4 0002 x5 x6 > x7 a000 > [ 36.490734] DEBUG: x8 e23fddeef0e0 x9 0001 x10 > e23fddeef060 x11 > [ 36.497538] DEBUG: x12 x13 x14 > 0020 x15 0200 > [ 36.502861] DEBUG: x16 e23fd081da70 x17 e23fd08b4168 x18 > e23fdf142000 x19 > [ 36.509025] DEBUG: x20 e23fddd192d0 x21 0001 x22 > x23 > [ 36.514828] DEBUG: x24 e23fddeef020 x25 e23fddd19280 x26 > x27 e23fddd9 > [ 36.520535] DEBUG: x28 e23fdc3b7070 x29 df3749e0 > [ 36.528408] DEBUG: sp df3749d0 lr e23fd0813464 pc > e23fd08b4178 > [ 36.610037] DEBUG: > [ 36.615637] DEBUG: backtrace: > [ 36.616452] DEBUG: #00 pc 5178 > /vendor/lib64/libOpenglSystemCommon.so (HostConnection::gl2Encoder()+16) > (BuildId: 8ca38ff3265c54f31e1f70e8a19c683f) > [ 36.618386] DEBUG: #01 pc 00013460 > /vendor/lib64/egl/libGLESv2_emulation.so (glGetString+24) (BuildId: > 1bc4a27ae3f25fffe3541af804629511) > [ 36.628225] DEBUG: #02 pc 00018d20 > /system/lib64/libEGL.so (android::egl_context_t::onMakeCurrent(void*, > void*)+112) (BuildId: 5abb3faa9d72952310ca01a9da8941e3) > [ 36.636811] DEBUG: #03 pc 00016450 > /system/lib64/libEGL.so > (android::egl_display_t::makeCurrent(android::egl_context_t*, > android::egl_context_t*, void*, void*, void*, void*, void*, void*)+268) > (BuildId: 5abb3faa9d72
Re: [android-building] Re: android10.0.0_rxx : lunch qemu_trusty_arm64-userdebug fails
Hi, I tried something like this out of interest on arm64 with my own hypervisor (custom kvm, https://github.com/jkrh/kvms) and indeed I get the android vm up. Thanks! In order to get the AOSP up I first started to port the 'ranchu' machine to qemu6, but the 'android-emu' library I'd need to hack in the qemu6 main loop just does not feel 'clean', so this remains unfinished in that regard: https://github.com/jkrh/kvms/blob/master/patches/0001-target-ranchu-add-support-for-android-ranchu-board.patch That being said, would be nice to make it do GPU too and I'm new to the graphics pipeline. From the hypervisor point of view I'd need it to do full VIRTIO since my hypervisor only opens the virtio channels between the host and the guest. Besides, I'm not entirely sure what to think of the 'pipe'. First attempt with that was to see if it would do 'gltransport=virtio': KERNEL_OPTS="root=/dev/vda rootfstype=ext4 ro init=/init selinux=1 checkreqprot=1 androidboot.selinux=permissive console=ttyAMA0 androidboot.hardware=ranchu qemu.uirenderer=skiagl qemu.gltransport=virtio qemu.gles=1 qemu.opengles.version=131072 qemu.dalvik.vm.heapsize=192m loglevel=8" and then for the QEMU: SCREEN="-nographic -device virtio-gpu-pci -spice $SPICESOCK,disable-ticketing=on $VDAGENT" Thoughts if something like this is supposed to be supported? Certainly it does not work: [ 36.445042] DEBUG: Build fingerprint: 'Android/aosp_arm64/generic_arm64:10/QT/eng.jmk.20210614.160415:userdebug/test-keys' [ 36.450901] DEBUG: Revision: '0' [ 36.458537] DEBUG: ABI: 'arm64' [ 36.462533] DEBUG: Timestamp: 2021-06-01 11:28:17+ [ 36.465839] DEBUG: pid: 219, tid: 219, name: surfaceflinger >>> /system/bin/surfaceflinger <<< [ 36.468971] DEBUG: uid: 1000 [ 36.474921] DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10 [ 36.476737] DEBUG: Cause: null pointer dereference [ 36.481510] DEBUG: x0 x1 e23fdddf66c0 x2 e23fd08b59f4 x3 e23fddcef5f8 [ 36.484085] DEBUG: x4 0002 x5 x6 x7 a000 [ 36.490734] DEBUG: x8 e23fddeef0e0 x9 0001 x10 e23fddeef060 x11 [ 36.497538] DEBUG: x12 x13 x14 0020 x15 0200 [ 36.502861] DEBUG: x16 e23fd081da70 x17 e23fd08b4168 x18 e23fdf142000 x19 [ 36.509025] DEBUG: x20 e23fddd192d0 x21 0001 x22 x23 [ 36.514828] DEBUG: x24 e23fddeef020 x25 e23fddd19280 x26 x27 e23fddd9 [ 36.520535] DEBUG: x28 e23fdc3b7070 x29 df3749e0 [ 36.528408] DEBUG: sp df3749d0 lr e23fd0813464 pc e23fd08b4178 [ 36.610037] DEBUG: [ 36.615637] DEBUG: backtrace: [ 36.616452] DEBUG: #00 pc 5178 /vendor/lib64/libOpenglSystemCommon.so (HostConnection::gl2Encoder()+16) (BuildId: 8ca38ff3265c54f31e1f70e8a19c683f) [ 36.618386] DEBUG: #01 pc 00013460 /vendor/lib64/egl/libGLESv2_emulation.so (glGetString+24) (BuildId: 1bc4a27ae3f25fffe3541af804629511) [ 36.628225] DEBUG: #02 pc 00018d20 /system/lib64/libEGL.so (android::egl_context_t::onMakeCurrent(void*, void*)+112) (BuildId: 5abb3faa9d72952310ca01a9da8941e3) [ 36.636811] DEBUG: #03 pc 00016450 /system/lib64/libEGL.so (android::egl_display_t::makeCurrent(android::egl_context_t*, android::egl_context_t*, void*, void*, void*, void*, void*, void*)+268) (BuildId: 5abb3faa9d72952310ca01a9da8941e3) [ 36.646320] DEBUG: #04 pc 0001ff94 /system/lib64/libEGL.so (android::eglMakeCurrentImpl(void*, void*, void*, void*)+384) (BuildId: 5abb3faa9d72952310ca01a9da8941e3) [ 36.660598] DEBUG: #05 pc 00113d58 /system/lib64/libsurfaceflinger.so (android::renderengine::gl::GLESRenderEngine::create(int, unsigned int, unsigned int)+380) (BuildId: becfe6218fde450840f4bc3f14cb68c5) [ 36.670297] DEBUG: #06 pc 00113aa4 /system/lib64/libsurfaceflinger.so (android::renderengine::RenderEngine::create(int, unsigned int, unsigned int)+164) (BuildId: becfe6218fde450840f4bc3f14cb68c5) [ 36.681625] DEBUG: #07 pc 000ce97c /system/lib64/libsurfaceflinger.so (android::SurfaceFlinger::init()+1164) (BuildId: becfe6218fde450840f4bc3f14cb68c5) [ 36.694419] DEBUG: #08 pc 31bc /system/bin/surfaceflinger (main+364) (BuildId: ff9215aa2c7b96de71b0a256004edc79) [ 36.703441] DEBUG: #09 pc 0007d798 /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+108) (BuildId: 676a709a0ee633ec9cf6ab05ec6410ae) -- Janne On Monday, 24 May 2021 at 21:14:44 UTC+3 julien@gmail.com wrote: > Hi again, > > Here is the AOSP 10 on ARM64 QEMU version of the procedure I follow. > Andoid 5.10 arm64 kernel build
