how can I boot completely from sd and get rid of the green screen. I want to use mandjaro. When the green screen problem is completely resolved. Please detailed instructions, I just do not know English well and it’s hard for me to understand the firmware
1 Like
Hello.
Here are some options I have posted.
which Android should I use?
From here
1 Like
You either need to use mainline u-boot or chainload mainline u-boot from the vendor u-boot; this is done via the boot autoscript files and a new (mainline) u-boot file.
Hi @chewitt i have question 4u maybe u can know solution 
some times ago i have test it and …
- i can boot vendor u-boot from mainline u-boot by chainloading via
go addrOK - i can boot mainline u-boot from mainline u-boot by chainloading via
go addrOK - but i cant boot mainline u-boot from vendor u-boot its freezed …
kvim3l#ver
U-Boot 2015.01-g6ab671a0b4-dirty (Jan 04 2020 - 13:03:09)
aarch64-none-elf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.11 - Linaro GCC 2013.10) 4.8.3 20131111 (prerelease)
GNU ld (crosstool-NG linaro-1.13.1-4.8-2013.11 - Linaro GCC 2013.10) 2.23.2.20130610 Linaro 2013.10-4
kvim3l#load mmc 0 $loadaddr u-boot.ml.bin
reading u-boot.ml.bin
kvim3l#go $loadaddr
696103 bytes read in 43 ms (15.4 MiB/s)
## Starting application at 0x01080000 ...
.......FREEEEEZZZZ..............
1 Like
checked again today on VIM2! same fail if we try load mainline uboot from vendor !!! may be smbdy have some ideas about it
kvim2#load mmc 0 $loadaddr u-boot.vim2.bin && go $loadaddr
reading u-boot.vim2.bin
664369 bytes read in 41 ms (15.5 MiB/s)
## Starting application at 0x01080000 ...
initcall sequence 00000000010e6410 failed at call 0000000001015550 (err=16864592)
### ERROR ### Please RESET the board ###
PS: but chainload vendor uboot from mainline still works !
IMHO chainloading is not required on any Khadas board because mainline u-boot supports all of your boards. Just write an image with mainline u-boot direct to the eMMC, boot using a simple extlinux.conf and avoid all the autoscript and multi-boot complexity. If people want to run another distro … go write that image (with appopriate u-boot) to eMMC instead. I’m not entirely surprised things don’t work from vendor u-boot.
1 Like
mainline uboot supported all boards but with many limits
for example spifc - like many other things not work
So what’s your plan to add spifc support to mainline u-boot?
yes ! i will try to do it soon
what other items are not working?
am getting Green screen on Manjaro, KDE Plasma
using latest Android PIE on the emmc
any workaround or just have to live with it
use the earliest version of Android on emmc and download from a cd card, take the image of Android 190809 from here: https://docs.khadas.com/vim3/FirmwareAndroid.html
1 Like
problem solved very easy just write single mainline uboot to emmc https://dl.khadas.com/Firmware/uboot/mainline
1 Like
Does this problem solved for installation on sd card only?
If I try with mainline u-boot or android u-boot I have cyan screen for Manjaro 20.06 and 20.10 on emmc
Yes it is fixed but I need to understand what you have on emmc and what you trying to boot from sd-card.
There is a chainloader file called u-boot.sd and u-boot.emmc in Boot partition, you have to rename anyone to u-boot.ext depending on where you booting from.
I made something opposite, but it works now…
I renamed u-boot.sd to u-boot.ext when it was color problem while booting from sd. After moving to emmc color issue returned.
There were no u-boot.emmc file so I just made a cp /boot/u-boot.ext /boot/u-boot.emmc and now it works with correct colors.
In any case thank you
1 Like
Bumping up this thread.
I see Neil have pushed a patch to fix the green screen issue here
I started testing it by moving back to the old boot scripts which I have been using from balbes work but now I am stuck with text_offset so after doing some more search I found that text_offset patch is still being maintained by Khadas team here
Chainloader method shared above have been used since then but it does not fulfil all the use case of booting like if image is flashed to emmc then it cannot boot over emmc and in some case if USB drive is connected then it fails to boot over sd card.
Is there any other way to fix text_offset ? As I think with green screen issue fixed we should be able to move back to old boot script method.
Stuck with this
reading Image
31267328 bytes read in 1710 ms (17.4 MiB/s)
reading uInitrd
8139419 bytes read in 442 ms (17.6 MiB/s)
reading uEnv.ini
268 bytes read in 2 ms (130.9 KiB/s)
reading /dtbs/amlogic/meson-gxm-khadas-vim2.dtb
41606 bytes read in 11 ms (3.6 MiB/s)
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
[rsvmem] fdt get prop fail.
## Loading init Ramdisk from Legacy Image at 04080000 ...
Image Name: uInitrd Image
Image Type: AArch64 Linux RAMDisk Image (uncompressed)
Data Size: 8139355 Bytes = 7.8 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
load dtb from 0x20000000 ......
ERROR: Did not find a cmdline Flattened Device Tree
load dtb from 0x0 ......
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
Please advice @hyphop @chewitt
Update I updated the boot script by following the odroid method and now it gets stuck while loading the kernel.
# Flattened Device Tree blob at 20000000
Booting using the fdt blob at 0x20000000
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
[rsvmem] fdt get prop fail.
Loading Ramdisk to b36fb000, end b3ebe25b ... OK
Loading Device Tree to 000000001fff2000, end 000000001ffff285 ... OK
fdt_instaboot: no instaboot image
Starting kernel ...
uboot time: 104587001 us
[ 0.769378] hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
domain-0 init dvfs: 4
domain-1 init dvfs: 4
Both ways it is not able to load dtb.
my suggestion forget about chainloads and scripts just use simple standard
pxe/syslinux menu
1 Like