-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aml_encrypt_g12b functionality #7
Comments
@angerman - i guess this issue resulted in https://github.com/angerman/meson64-tools in the end? - i just tried to use that to try to build a native mainline u-boot for s905x2 (g12a) and s905x3 (sm1) tv boxes (https://github.com/hexdump0815/u-boot-misc/blob/gxm-experiments/readme.gxy#L53-L76) and i was able to at least assemble a boot image without any errors which started to boot, but sadly failed during the memory training with all the ddr firmwares i was able to find (most of them seem to be the same anyway) - here is btw. the boot output of trying to boot my assembled boot image: https://github.com/hexdump0815/u-boot-misc/blob/gxm-experiments/misc.gxy/debug-info/sm1-non-working-ddr.txt and in comparison the output of the original android boot: https://github.com/hexdump0815/u-boot-misc/blob/gxm-experiments/misc.gxy/debug-info/sm1-working-ddr.txt ... so i guess the only option to make this work would be to extract the blobs from the original boot blocks like gxlimg makes it possible with the "-e" option and which helped to make a native u-boot working perfectly fine on gxl and gxm. would any of you two be willing to write such an extraction option, so either to extend gxlimg's "-e" to also support g12a, g12b and sm1 or to add something like an "unmkboot" to the meson64-tools? sadly my skills are not good enough to get this solved myself. in case you would need some original boot blocks to experiment with - here is one for g12a and one for sm1 ready for "gxlimg -e", i.e. with the first 512 bytes stripped: https://github.com/hexdump0815/u-boot-misc/tree/gxm-experiments/misc.gxy/dump-in.dd @angerman - the logs above are from my sm1 testing, i also tested on g12a and there it did not even boot - i guess there is maybe some magic number different for g12a which is created properly for sm1 only with the meson64-tools? - see: https://github.com/hexdump0815/u-boot-misc/blob/gxm-experiments/misc.gxy/debug-info/g12a-non-working-boot.txt a lot of thanks in advance and best wishes - hexdump |
just a little update: i have mainline u-boot and atf now working on a s905x3 = sm1 tv box without having to disassemble the orignal boot blocks - the available blobs are working well, i only had to extract the ddr memory timings from /dev/mmcblkXboot0 ... more info: https://freenode.irclog.whitequark.org/linux-amlogic/2020-09-26#28000408 update: regarding my above g12a tests - those most probably failed as the box i tried them with seems to have a locked boot loader - i guess that the meson64-tools will most probably work well for g12a - will test that soon ... |
I've added an initial implementation in #16 |
since #16 has been merged: can this be closed? |
Hi, this looks great! I've got a HardKernel N2 here with a S922X chip, packaging the boot image is terrible, and
aml_encrypt_g12b
being only available as ax86_64
binary blob doesn't make it much better.Here's what the somewhat loosely available only documentation provides for building the images
Looking at the README.g12b,
gxlimg
should be suitable to get most of this done. Assuming we have thebl30_new.bin
andbl2_new.bin
constructed with theblx_fip.sh
, thesegxlimg
commands should yield the same resultsOf course the
bl33.bin.enc
won't belz4
compressed, but the--bootmk
step is missing. I believe this is the-t fib
instruction, however we are missing all theddr
arguments? This leaves me with some questions:(a) the
--level 3
argument seems mostly unused?(b) does not compressing
bl33
pose an issue? Do we know if the compression is run before or after the signing?(c) would it be hard to add the
-ddrXXX
flags? I seegi_fip_create
just learned aboutbl301
.(d) with respect to (c), does that mean we can sign
bl30
andbl301
separately and ignore the firstblx_fip.sh
step?The text was updated successfully, but these errors were encountered: