On 9/2/24 13:20, Pierrick Bouvier wrote:
On 9/2/24 12:53, Mario Marietto wrote:
Hello Pierrick.

With Cuttlefish can I emulate Android 14 for arm64 ? I ask because in
your script I read :

"|/home/user/.work/qemu/build/qemu-system-x86_64", so,I suspect that you
have emulated Android x64 bit,but I need arm64. |


Yes, it works for both architecture. The only thing I didn't try is an
arm64 vm accelerated with kvm (I don't have this a linux-aarch64
machine), but it should work.

And of course, if you want to write a custom wrapper for qemu, name it qemu-system-aarch64, and call the same binary instead of x86_64 variants.


I also read "for aarch64 images: select
|aosp_cf_arm64_only_phone-trunk_staging-userdebug" : I'm not able to
download this kind of images. I don't understand how the Branch Grid
works. Can you explain to me a little bit more ?
|

You have a link just next to it ("Branch grid") on the wiki page.
Once on ci android page, click on filter button (three bars, inverted
pyramid), and select aosp_cf_arm64_only_phone-trunk_staging-userdebug.
Then go to artifacts, and download image and cvd_host_x86_64 package, as
wiki mentions.

Don't hesitate to ask more questions on this. I imagine this topic might
interest some people who try to do the same thing.

Pierrick

|
|


On Mon, Sep 2, 2024 at 8:47 PM Pierrick Bouvier
<pierrick.bouv...@linaro.org <mailto:pierrick.bouv...@linaro.org>> wrote:

     Hello Mario,

     very recently, I had to investigate booting time of Android when using
     QEMU. You can probably manage to boot this with only QEMU alone, but in
     my experience, using Cuttlefish tooling is an easier approach.

     If you really want to use only QEMU, you can use Cuttlefish to get
     exact
     command line used (which disk goes where), and iterate from that.

     Instructions:
     
https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29464068097/Run+Android+using+QEMU
 
<https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29464068097/Run+Android+using+QEMU>

     As you'll see, I could not get a direct graphic output, but using
     scrcpy, it worked well for me. Hope it can fit your use case.

     Regards,
     Pierrick

     On 9/2/24 06:49, Mario Marietto wrote:
      > Hello.
      >
      > I would like to emulate Android 14 on my Ubuntu 24.04 OS X64 bit
     using
      > qemu-system-aarch64. I tried using the following parameters :
      >
      > qemu-system-aarch64 \
      >          -smp 4 \
      >          -m 2048 \
      >          -cpu cortex-a72 \
      >          -M virt \
      >          -device virtio-gpu-pci,xres=1024,yres=768 \
      >          -display sdl,gl=on \
      >          -device usb-ehci \
      >          -device usb-kbd \
      >          -device virtio-tablet-pci \
      >          -usb \
      >          -serial stdio \
      >          -kernel /mnt/zroot-133/_OS/Android/rpi4/Image \
      >          -initrd /mnt/zroot-133/_OS/Android/rpi4/ramdisk.img \
      >          -drive
      >
     index=0,if=none,id=system,file=/mnt/zroot-133/_OS/Android/rpi4/boot.img \
      >          -device virtio-blk-pci,drive=boot \
      >          -drive
      >
     index=1,if=none,id=system,file=/mnt/zroot-133/_OS/Android/rpi4/system.img \
      >          -device virtio-blk-pci,drive=system \
      >          -drive
      >
     index=2,if=none,id=vendor,file=/mnt/zroot-133/_OS/Android/rpi4/vendor.img \
      >          -device virtio-blk-pci,drive=vendor \
      > -append "console=ttyAMA0,38400 drm.debug=0x0 rootwait rootdelay=5
      > root=/dev/mmcblk0p2 androidboot.hardware=rpi4
      > androidboot.selinux=permissive security=selinux selinux=1
      > androidboot.qemu.hw.mainkeys=0 androidboot.lcd.density=160"
      >
      > The error I get in short is :
      >
      > [ 1.993668] init: bool
      >
     android::init::BlockDevInitializer::InitDevices(std::set<std::string>):
      > partition(s) not found in /sys, waiting for their uevent(s):
     mmcblk0p2,
      > mmcblk0p3
      >
      >
      > One user suggested to :
      >
      >
      >
      >
      >
      > Hi!!! The "/sys" is a "dynamic fs" created at ram from the
     kernel, to
      > export a lot of things...so most of the files only exist at runtime.
      > Normally, the partitions from the block device have a symlink at
      > /sys/<something>/<...> that points to /dev/ block node. It seems
     that
      > there are no such files under /sys according to what init is looking
      > for. You can double check this at init source code to check the
     exact
      > path but I'm guessing that you'll have to change the qemu arguments
      > regarding the block device.
      >
      > About userdata.img I think it's normal since in the old days, the
     image
      > was a "empty sparse image", that means, at the first flashing
     process,
      > there isn't userdata information, we're just "flashing the
     partition"
      > with empty data.
      > Tks!!!
      >
      >
      >
      > So,in short I should change the qemu arguments regarding the block
      > device. I tried in this way :
      >
      >
      > qemu-system-aarch64 \
      >          -smp 4 \
      >          -m 2048 \
      >          -cpu cortex-a72 \
      >          -M virt \
      >          -device virtio-gpu-pci,xres=1024,yres=768 \
      >          -display sdl,gl=on \
      >          -device usb-ehci \
      >          -device usb-kbd \
      >          -device virtio-tablet-pci \
      >          -usb \
      >          -serial stdio \
      >          -kernel /mnt/zroot-133/_OS/Android/rpi4/Image \
      >          -initrd /mnt/zroot-133/_OS/Android/rpi4/ramdisk.img \
      >          -hda /mnt/zroot-133/_OS/Android/rpi4/boot.img \
      >          -hdb /mnt/zroot-133/_OS/Android/rpi4/system.img \
      >          -hdc /mnt/zroot-133/_OS/Android/rpi4/vendor.img \
      >        -append "console=ttyAMA0,38400 drm.debug=0x0 rootwait
     rootdelay=5
      > root=/dev/mmcblk0p2 androidboot.hardware=rpi4
      > androidboot.selinux=permissive security=selinux selinux=1
      > androidboot.qemu.hw.mainkeys=0 androidboot.lcd.density=160"
      >
      >
      > but the error is still there. Do you know some different alternative
      > block devices to try ? thanks.
      >
      >
      > --
      > Mario.



--
Mario.

Reply via email to