@Jimibob Yes,just vim3. vim3l was not released.
1 Like
Thanks.
I’ve tried compiling for vim3l and cannot burn it. Parse error every time.
Will you be releasing a vim3l img soon?
Vim3l has a serious bug,all USB can’t work, it will be released after fix it.
3 Likes
When I flash this build on Ubuntu all I receive is a double blinking white light, and the screen does not turn on?
Anyone else having this issue? How do you resolve it?
I downloaded the VIM3_R ROM, and the flash tools
Running the tool on windows does not work because it gets stuck at < waiting for any device >
Switching to ubuntu since the provided updated.exe only works for windows I downloaded the current version of android AOSP following this guide.
I follow this guide to flash the board making sure to update -uboot_kbim3_noab.bin in the AOSP directory with the one provided in the release.
And flashing all of the images provided.
Everything goes successfully, however after restarting the board, it simply double blinks the status light about every second with no screen output.
Is it possible the update tool provided by the current version of AOSP is broken? Is there something wrong with my board? I really need Android 11 on the board.
I hope that helps!
Thanks!
I test the ROM was OK on VIM3/VIM3 Pro board.
Can you check your HDMI is OK?
Flash Android P,check your VIM3 board is OK?
Can you check adb is OK?
If adb is OK,you can input this commad
adb root && adb shell dmesg > dmesg.txt
is there a newer version of the rom than 210604 I had memory problems with my Vim3 Pro on that version.
Thanx
I flashed VIM3_Pie_V210527 on the VIM3 Pro successfully using the windows burn tool.
I have Android R(11) V210604 installed in one of my VIM3 Pro 32g devices.
I have memory errors.
only shows 16g ram not 32
shows SD card corrupted, cache corrupted etc.
Android 9 works fine, device is ok.
1 Like
just saw something on the yukawa tree master updates and it looks like there was something that was confusing the built in storage manager that was just removed
yukawa: fstab: remove */block/mmcblk2 entry
The internal emmc (mmcblk2) should not need to be managed by vold.
This entry confuses StorageManagerService as observeable in logcat:W StorageManagerService: Reporting public:179,6 unmounted due to system locked
W StorageManagerService: Reporting public:179,7 unmounted due to system locked
W StorageManagerService: Reporting public:179,8 unmounted due to system locked
W StorageManagerService: Reporting public:179,9 unmounted due to system locked
W StorageManagerService: Reporting emulated;0 unmounted due to system locked
W StorageManagerService: Reporting public:179,10 unmounted due to system locked
W StorageManagerService: Reporting public:179,1 unmounted due to system locked
W StorageManagerService: Reporting public:179,2 unmounted due to system locked
W StorageManagerService: Reporting public:179,3 unmounted due to system lockedChange the wildcard to mmcblk[0-1] instead.
Note: this also removes the “Issue with SD card” popups from the UI.
im going to give it a test in a little bit as soon as i add the changes to the source on my system. as for the 16gb of storage instead of 32, its cause the bootloader they are using is the one thats from baylibre and would need to be recompiled to use the full storage. i will see what i can do there
3 Likes
the allocated size issue (to baylibre, it doesnt seem to be an issue) was and still is in the master branch as well and before where the user partition was set to a static size, i had to recompile the bootloader with some changes to get the full nand size. right now it looks like they have provisioned the remainder is used for a root dir that is i think to be used for gki development on the kernel side, but as far as i know, the current kernels are still the traditional type and the gki kernel has to be built from source from the mainline kernel source for android.
1 Like
这个版本是64位的android吗？什么时候提供SDK？我觉得你们移植过程中的一些坑也可以做成wiki
so i added the changes and it did indeed get rid of the issue of memory being displayed as corrupted.
first i would like to say, if anything here is confusing in any way, its better to save yourself the headache and do nothing less you brick something, thought khadas devices are VERY hard to brick. still though better safe than sorry.
i compiled a new bootloader based on the latest one from the master branch with the changes for the userdata partition to take up the remainder of the storage and for rootfs to be a static 1GB. this may cause space problems on the vim3 basic that only has 16GB of storage so i dont recommend flashing on that device. i am not sure how much space is remaining for the rootfs to take up, or how much it needs so i just put it at a gig to not have issues. the userdata image is scaled up ~2x or 25GB for testing purposes so again should only be used on the pro version.
for those wanting to make changes to the bootloader to get a more optimal rootfs size you only need to change the config file {WORKINGDIR}>include>configs>khadas-vim3_android.h to the quoted below with size being where you make your changes:
#if defined(CONFIG_CMD_AB_SELECT)
#define PARTS_DEFAULT
“uuid_disk=${uuid_gpt_disk};”
“name=logo,start=512K,size=2M,uuid=” LOGO_UUID
“name=misc,size=512K,uuid=${uuid_gpt_misc};”
“name=dtbo_a,size=8M,uuid=${uuid_gpt_dtbo_a};”
“name=dtbo_b,size=8M,uuid=${uuid_gpt_dtbo_b};”
“name=vbmeta_a,size=512K,uuid=${uuid_gpt_vbmeta_a};”
“name=vbmeta_b,size=512K,uuid=${uuid_gpt_vbmeta_b};”
“name=boot_a,size=32M,bootable,uuid=${uuid_gpt_boot_a};”
“name=boot_b,size=32M,bootable,uuid=${uuid_gpt_boot_b};”
“name=super,size=3072M,uuid=${uuid_gpt_super};”
“name=rootfs,size={SIZE}M,uuid=” ROOT_UUID
“name=userdata,size=-,uuid=${uuid_gpt_userdata};”#else
#define PARTS_DEFAULT
“uuid_disk=${uuid_gpt_disk};”
“name=logo,start=512K,size=2M,uuid=” LOGO_UUID
“name=misc,size=512K,uuid=${uuid_gpt_misc};”
“name=dtbo,size=8M,uuid=${uuid_gpt_dtbo};”
“name=vbmeta,size=512K,uuid=${uuid_gpt_vbmeta};”
“name=boot,size=32M,bootable,uuid=${uuid_gpt_boot};”
“name=recovery,size=32M,uuid=${uuid_gpt_recovery};”
“name=cache,size=256M,uuid=${uuid_gpt_cache};”
“name=super,size=1792M,uuid=${uuid_gpt_super};”
“name=rootfs,size={SIZE}M,uuid=” ROOT_UUID
“name=userdata,size=-,uuid=${uuid_gpt_userdata};”#endif
the source code for this and compile instructions can be found here or in the device source bootloader folder. hope this helps others
1 Like
Just wondering if anyone has a working Windows driver? I’ve tried every ADB driver I could find but nothing sticks. Is there a specific driver that recognizes the VIM3 board? Can’t get passed “USB download gadget”.