Green screen. Manjaro

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

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 :wink: some times ago i have test it and …

  • i can boot vendor u-boot from mainline u-boot by chainloading via go addr OK
  • i can boot mainline u-boot from mainline u-boot by chainloading via go addr OK
  • but i cant boot mainline u-boot from vendor u-boot its freezed …
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) Linaro 2013.10-4

kvim3l#load mmc 0 $loadaddr 

kvim3l#go $loadaddr
696103 bytes read in 43 ms (15.4 MiB/s)
## Starting application at 0x01080000 ...
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 :wink:

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 :wink:
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:

1 Like

problem solved very easy just write single mainline uboot to emmc

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 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 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