Closed dsd closed 5 years ago
Hi Daniel,
Unfortunately HDMI boot is missing pre-uboot logs that could possibly help debug that.
I just tried to dd the gxl-boot.bin from the archive that was not bootable for you but it completely worked for me. So I don't think there is a u-boot encryption problem.
Hmm, sorry for the noise there. Indeed, upon reinserting the card, I observed that the written data had been corrupted at sector 1792. It's weird because the next partition definitely starts at sector 2048, beyond the end of the flashed data. That was being auto-mounted though, which appeared to be causing the corruption. Either something very wrong with my system, or more likely, a dying SD card. Thanks for your help.
Thanks for your work on this tool @repk !
Unfortunately I'm struggling to make it work reliably on libretech_cc.
I'm working with the u-boot binary from debian experimental 2019.07+dfsg-1 u-boot-amlogic package
/usr/lib/u-boot/libretech-cc/u-boot.bin
. Here is a direct copy - apologies for zipping these attachments, github won't accept them otherwise. u-boot.zipThis u-boot does have hdmi support so it's nice and easy to see when it's booting or not.
make image UBOOT=/path/to/u-boot.bin
produces this output: build.zip and the resultantgxl-boot.bin
is not bootable - black screen.I ran one of the final commands from that build process again:
./gxlimg -t fip --bl2 build/fip/gxl/bl2.bin.enc --bl30 build/fip/gxl/bl30.bin.enc --bl31 build/fip/gxl/bl31.bin.enc --bl33 build/fip/gxl/u-boot.bin.enc build/gxl-boot.bin
and reflashed, still not booting.Ran that command once more, reflashed, still not booting. So 3 out of 3 failures in that specific experiment.
Then I took the same original u-boot.bin from Debian and encrypted it with the vendor tool
aml_encrypt_gxl --bl3enc
. The output is here: bl33.bin.zipThen I modified the final gxlimg command to use that one instead:
./gxlimg -t fip --bl2 build/fip/gxl/bl2.bin.enc --bl30 build/fip/gxl/bl30.bin.enc --bl31 build/fip/gxl/bl31.bin.enc --bl33 ~/projects/u-boot/fip/bl33.bin.enc build/gxl-boot.bin
Reflashed, and now it boots.
Ran that command again, and reflashed, and it still boots. Then did it once again, and it still boots. 3 out of 3 passes. Here is one of the resultant working boot images. gxl-boot.zip
So it looks like there may be a problem with the u-boot binary encryption not working right. But I think it might be an intermittent problem relating to random data, different timestamps or different keys, as gxlimg definitely did work the first time I tried it with this same exact u-boot binary.