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.w    r12, 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 0000: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/34abbf6d-1b04-4b61-a3a7-9840a6d3b9c3n%40googlegroups.com.

Reply via email to