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
Here are some options I have posted.
which Android should I use?
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
- i can boot mainline u-boot from mainline u-boot by chainloading via
- 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) 184.108.40.20630610 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..............
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.
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
problem solved very easy just write single mainline uboot to emmc https://dl.khadas.com/Firmware/uboot/mainline
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
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