VIM3 Armbian image?

sure but its not always possible !

for example if we have already writed uboot on emmc ! and start system from sd card there we can have problem

Yes, this is the problem…

i have find partial solution

mainline uboot can start legacy uboot ( chainloading ), but
legacy uboot cant start mainline ;( something going wrong and goto segfault and reboot

Can i get a mainline uboot which we can ship with manjaro images?
And will having legacy uboot on emmc while having mainline uboot on sd card read the sd card uboot or will it boot from legacy boot and cause green light issue.
Or can we just use uboot on spi fixed so it can do chainloading. As chainloading will again have issue depending which uboot is in emmc and which is on sd card.

i will fix some problems and share soon

OK mainline uboot images fixed!

Yes, there are commands that allow you to add u-boot to the SD card after writing the main image. This is described in the documentation on the Armbian forum in the corresponding topic. But I recommend restoring the regular firmware to eMMC and using the regular u-boot from it. This guarantees normal system operation and the ability to install Armbian in eMMC (while maintaining the ability to use regular tools for working with USB Burn Tool firmware in the future ).

I do not recommend using this option.

The problem of incorrect color has long been solved for Armbian and Libreelec, nothing needs to be deleted from eMMC. This is very bad advice to remove u-boot from eMMC.

Because from the factory, all samples come with a built-in u-boot in eMMC and with standard use (without idiotic tips for removing u-boot from eMMC), you can run Armbian and Libreelec from any external media (please note - including USB) without having to kill your device (remove u-boot). At the same time, you save the regular firmware in eMMC and at the first stage (when you evaluate all the features of new systems), you do not risk anything, just launch any system from an external media, study it, try its functionality. And only after you have found and completely checked all the functions you need on an external media, only after that, you start the automatic procedure for installing the system in eMMC (which itself will correctly install the system in eMMC). Why kill your system (remove u-boot from eMMC) if you don’t know if the new system is suitable for you or not (i.e. you are forced to kill your device just to look at new systems) ?

All Khadas products come with built-in u-boot in eMMC from the factory, and Armbian and Libreelec systems are ready for use on Khadas products, if users are not given stupid tips on removing the built -in u-boot.

And it will fail because these u-boot versions contain errors and cannot work properly with any media.

Wrong advice. The main core works fine with the correct colors with the regular u-boot in eMMC. You need to use the launch system correctly.

There are no problems (if you do everything correctly), this is confirmed by the work of Armbian and Libreelec

For all. Don’t give wrong advice if you don 't know how Armbian and LIbreelec work.

same 4u - Don’t give wrong advice…

send me link to armbian image i can check what wrong …

Are you Armbian or Libreelec developer ? It’s funny, a person who has nothing to do with the development of these systems tries to tell developers how their system works … :slight_smile:

i just check Armbian_20.02.0-rc1.037_Aml-s9xxx_buster_current_5.5.0-rc6_20200205.img.xz image

looks like works …

Armbian 20.02.0-rc1.037 Buster ttyAML0 
    _    __  __ _         ____  ___                   
   / \  |  \/  | |       / ___|/ _ \__  ____  ____  __
  / _ \ | |\/| | |   ____\___ \ (_) \ \/ /\ \/ /\ \/ /
 / ___ \| |  | | |__|_____|__) \__, |>  <  >  <  >  < 
/_/   \_\_|  |_|_____|   |____/  /_//_/\_\/_/\_\/_/\_\
Welcome to Armbian buster with Linux 5.5.0-rc6-aml-s9xxx

write to sd

xz -dc < Armbian_20.02.0-rc1.037_Aml-s9xxx_buster_current_5.5.0-rc6_20200205.img.xz | pv > /dev/mmcblk?

mount sd partition 1 & edit uEnv.txt
change FDT for your device for example my is VIM3L


same works with mainline uboot stored on emmc

u can check just write uboot to emmc via krescue

PS: i can prepare some Armbian images for Krescue soon - which can works out of box + easy installation to emmc for VIMx devices


Armbian images for Krescue would be much appreciated ;-)… especially emmc or nvme boot


I don’t allow such options to be made from my images . There are proven and correctly working installation options in eMMC. I don 't want to rake up heaps of problems and answer questions from users that will be due to improper use of the system with obscure questionable additions.


This is an Open Source platform so please respect each other’s work and not misuse concept of open source.

I would request everyone to respect each others decision and not push their solutions. Every developer have their own ways and I think we should respect their methods.
This is for everyone in the community not just one person.

So Cheer up :smiley:
Happy Coding and Development :smiley:


Hello Oleg,

I just checked your Armbian image Armbian_20.02.0-rc1.038_Aml-s9xxx_bullseye_current_5.5.0-rc6_20200205.img on VIM3. I have vendor u-boot on the eMMC, I got the green screen. For Android, it is the same too. So only mainline u-boot will boot Armbian(mainline kernel) well without color issue.

Hi Nick
It looks like you didn 't read the instructions and didn 't complete the important step of setting up the system. Look carefully at the first message of this topic, which indicates what needs to be done to make the system work with the correct colors with any u-boot from AML.

Fix for correct color to G12 (Amlogic S905X2 S922X)

1 Like

will be better to put all instruction directly to image with other boot scripts

btw: krescue already can install armbian to emmc without any additional user manipulation for all VIM1 VIM2 VIM3 VIM3L boards just for 1 min :wink:


All instructions are available on the official forum.

just simple embeded README file in image - can help solve many users questions, why not makeit ?!, its normal practice everywhere …


Information changes quickly, and this is an extra task for syncing.