Which system do you use? Android, Ubuntu, OOWOW or others?
Android on Linux Ubuntu 22.04,
Here is the configuration:PLATFORM_VERSION_CODENAME=VanillaIceCream
PLATFORM_VERSION=VanillaIceCream
BUILD_ID=AP4A.250205.002
TARGET_PRODUCT=yukawa
TARGET_BUILD_VARIANT=userdebug
TARGET_ARCH=arm64
TARGET_ARCH_VARIANT=armv8-a
TARGET_CPU_VARIANT=cortex-a53
TARGET_2ND_ARCH=arm
TARGET_2ND_ARCH_VARIANT=armv8-a
TARGET_2ND_CPU_VARIANT=cortex-a53
HOST_OS=linux
HOST_OS_EXTRA=Linux-6.8.0-90-generic-x86_64-Ubuntu-22.04.5-LTS
HOST_CROSS_OS=windows
OUT_DIR=out
Which version of system do you use? Please provide the version of the system here:
VIM3 Pro
Please describe your issue below:
Hi everyone,
I’m facing an issue flashing a yukawa/mainline AOSP build on a Khadas VIM3 (A311D), and after investigation it appears to be caused by an old / legacy eMMC partition scheme on the board.
I have build the image based on the documentation Android — yukawa-android documentation
I have taken the base code from
repo init -u platform/manifest - Git at Google -b android-15.0.0_r14 --depth=1
I’m posting this to confirm my understanding and to document the issue for others.
Current state / diagnostics
Running the following command:
fastboot getvar all 2>&1 | grep -E ‘partition-size|partition-type|current-slot|super’
Produces:
(bootloader) partition-type:boot:raw
(bootloader) partition-size:boot:0000000001000000
(bootloader) partition-type:system:ext4
(bootloader) partition-size:system:0000000064000000
(bootloader) partition-type:vendor:ext4
(bootloader) partition-size:vendor:000000001c000000
(bootloader) partition-type:odm:ext4
(bootloader) partition-size:odm:0000000008000000
(bootloader) partition-type:data:ext4
(bootloader) partition-size:data:00000006599fc000
What this means
-
boot partition size is 16 MiB
- My generated boot.img is ~21 MiB → it cannot fit
-
There is no super partition
-
The device uses classic fixed ext4 partitions:
- system, vendor, odm, data
-
This indicates a pre-yukawa / legacy Khadas partition layout
However, the image I’m trying to flash is a yukawa mainline AOSP build, which expects:
A larger boot partition
Dynamic partitions
A super partition
Because of this mismatch, fastboot cannot safely flash the images.
Important clarification
-
Bootloader is unlocked
-
pyamlboot / boot-g12.py works
-
USB upgrade mode works
So this is not a fastboot, unlock, or USB issue — it is purely a partition table incompatibility.
Why flashing fails
With:
-
boot fixed at 16 MiB
-
No super partition
It is not possible to flash:
-
boot.img (too large)
-
super.img (partition does not exist)
This cannot be fixed using fastboot commands alone.
Correct path forward (as I understand it)
To move forward safely, the eMMC must be fully repartitioned to the yukawa layout.
That requires:
-
Using the official Khadas/Amlogic burn process (USB upgrade mode), e.g.:
-
Khadas official Android eMMC burn image
-
or BayLibre / yukawa base image
-
-
This process:
-
Rewrites the GPT
-
Enlarges the boot partition
-
Creates the super partition
-
Enables dynamic partitions
-
-
After the board boots once with the new base image and exposes the correct layout:
-
Unlock bootloader (once, if required)
-
Flash my own AOSP build using fastboot (boot, super, etc.)
-
Until this repartitioning is done, flashing a yukawa AOSP build on this board is not possible.
Summary
-
This is a legacy eMMC layout vs yukawa image mismatch
-
Fastboot alone cannot fix it
-
A full eMMC re-partition via Khadas burn tool is required first
-
After that, flashing custom AOSP builds should work as expected
I tried to flash my AOSP build on many prebuilt base images from Khadas dl.khadas.com - Index of /products/vim3/firmware/android/. But could not succeed.
If anyone has additional recommendations, confirmations, or preferred base images for this repartitioning step, I’d really appreciate the input.
Thanks in advance!