hexdump0815 / u-boot-misc

• usb support is in by default now
• hdmi clk init for kernel hdmi is in
• based on https://github.com/apritzel/arm-trusted-firmware/tree/h616-v1 and https://github.com/apritzel/u-boot/tree/h616-usb

• do not use this one on emmc! it is ment ot be used on sd cards only for now - i had some strange hangs in the spl if emmc was set first in spl boot order with an empty emmc
• mmc order and boot order (spl and u-boot) cleanup up and set to sd=0 first and emmc=1 second
• u-boot version v2020.10 with atf v2.3
• mainline tpl+spl+atf+u-boot
• legacy ddr.bin+spl+atf+u-boot (ddr.bin is v1.15 333mhz is it seems to work very well and stable with tv boxes plus a hacked version of it set to 666mhz)
• legacy ddr.bin+legacy atf+legacy trust.img+u-boot (two examples for rk3318 and rk3328)
• rk3288-u-boot.bin for potential chain loading
• u-boot-rk3328.img for inserting into legacy boot blocks

this is the legacy u-boot from the orangepi zero 2 tree with some fixes to use the dtb and bootargs provided in the extlinux.conf file instead of its default to only use the dtb compiled into u-boot and the bootargs from that dtb ... it is provided in multiple versions for some tv box types and the orange pi zero 2 - not all of them are tested ... please keep in mind that legacy u-boot can only boot legacy kernels and mainline u-boot only mainline kernels properly (the legacy u-boot can partially boot mainline kernels). the .dd files below are supposed to be written to an sd card via: "dd if=boot.dd of=/dev/sdcard bs=512 seek=1 skip=1" and they are 40960 512 byte blocks long, i.e. longer than the usual mainline u-boots - so make sure that your first partition does not start before 40960 to not overwrite anything!

• this is very much work in progress based on a special development tree
• it boots well on different tv boxes (x96q h313 and tx6s h616)
• t95 - has working sd card card detection (works on the x96q too)
• tx6s - has sd card detection disabled as it seems to not be working (at least on my box)
• only 3gb ram detected by u-boot even on 4gb boxes is a current software limitation, which will go one day

raspberry pi u-boot v2020.10

• rk3318 and rk3328 are using the same u-boot now
• u-boot version v2020.10 with atf v2.3
• different versions built (u-boot and atf below always refers to mainline if not mentioned otherwise):
  • mainline tpl+spl+atf+u-boot
  • legacy ddr.bin+spl+atf+u-boot (ddr.bin is v1.15 333mhz is it seems to work very well and stable with tv boxes)
  • legacy ddr.bin+legacy atf+legacy trust.img+u-boot (two examples for rk3318 and rk3328)
  • rk3288-u-boot.bin for potential chain loading
  • u-boot-rk3328.img for inserting into legacy boot blocks

some experiments to get native (i.e. not chainloaded) mainline u-boot working on some amlogic tv boxes ... all wip progress and the content might change ... using this stuff is completely on your own risk - i'm not responsible if you brick your box! ... tested to work so far with a serial console (for file with a "serial" named one and another the serial one is for serial console and the other for hdmi/usbkbd) a nexbox a1 (2g/16g - s912/gxm), on a x96 max (2g/16g), a t95q (4g/32g) and a h96 max x2 (4g/32g) - all three s905x2/g12a and on a x96 air (2g/16g) and a h96 max x3 (4g/32g) - both s905x3/sm1 ... the boot-xyz.dd file should be written (after a gunzip of course) via "dd if=boot-xyz.dd of=/dev/target-disk bs=512 seek=1 skip=1 status=progress" ... the s905l2 files are the usb boot (search for pyamlboot) tpl file (the bl2 file can be taken from libretech-cc from the pyamlboot repo) and boot blocks with mainline atf+u-boot and hdmi/usbkbd support for a x7-5g tv box with a s905l2 soc (the box only has 1/8gb instead of the 4/32gb of its fake spec and no sd card slot) - the s905l2 seems to be something like a s905w with only 2 pp cores instead of 3 in its mali450 and maybe other lowered specs and thus absolut low end hardware ... the rk3318/rk3328 files are legacy boot blocks enriched by a mainline u-boot ...

this version has odroid x support added - tested on an odroid x and an odroid u3 ... i think it should work on x2 too (as it is supported too and i think someone was using my images with an x2 already) and maybe even on odroid u2 (hopefully detecting it as u3 or x2) and maybe even on odroid u too (hopefully detecting it as x)