SM1 (S905X3) doesn't boot with gxlimg

[matwey]

Hi,

I am trying to use gxlimg to make bootable image for Odroid-C4 board.
I've successfully used https://github.com/angerman/meson64-tools to make bootable image following this instruction.
However, when I try to substitute meson64-tools with glximg, then I obtain unbootable result:

...
Load FIP HDR from SD, src: 0x00010200, des: 0x01700000, size: 0x00004000, part: 0
Load BL3X from SD, src: 0x00078200, des: 0x01768000, size: 0x0010c000, part: 0
BL31 CHK: 0x00000027 ADDR 01776400
reset...
SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;0.0;CHK:0;

Only bl2 seems to be running fine.

I've not found what is the reason yet. Now I see that bl30_new.bin.enc is little shorter for gxlimg because meson64-tools pads the file with 0 up to 512(?) bytes.

[matwey]

If I generate bl31.img.enc and the final image by meson64-tools then the system boots fine.

[matwey]

I've found that

gxlimg -t bl3x -s bl31.img bl31.img.sig.enc

and

aml_encrypt --bl3sig --input bl31.img --output bl31.img.enc --level v3 --type bl3

produce substantially different result.
I use this as an input: https://github.com/hardkernel/u-boot/blob/odroidg12-v2015.01/fip/g12a/bl31.img

[repk]

Hello,

Have you tried using --rev v3 option for generating final binary blop as suggest in README.g12a ?

Thanks

[matwey]

The command was as the following:

gxlimg -t fip --bl2 fip/g12a/bl2.n.bin.sig --bl30 fip/g12a/bl30_new.bin.enc --bl31 fip/g12a/bl31.img.enc --bl33 fip/g12a/bl33.bin.enc --ddrfw fip/g12a/ddr4_1d.fw --ddrfw fip/g12a/ddr4_2d.fw --ddrfw fip/g12a/ddr3_1d.fw --ddrfw fip/g12a/piei.fw --ddrfw fip/g12a/lpddr4_1d.fw --ddrfw fip/g12a/lpddr4_2d.fw --ddrfw fip/g12a/diag_lpddr4.fw --ddrfw fip/g12a/aml_ddr.fw --ddrfw fip/g12a/lpddr3_1d.fw --rev v3 fip/g12a/u-boot.bin

[ensc]

Difference seems to be that working bl31.img.sig.enc images contain a

00000000: 424c 3358 2d48 4452 0000 0000 0001 0000  BL3X-HDR........
00000010: 0000 1005 0000 0000 0000 0005 0000 0000  ................
00000020: 0000 1005 0000 0000 0000 3000 0000 2000  ..........0... .
00000030: 6587 3412 204e 0000 0000 1005 0000 0000  e.4. N..........
00000040: 0000 0005 0000 0000 0000 3000 0000 0000  ..........0.....
00000050: 0000 1005 0000 0000 0000 2000 0000 0000  .......... .....
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 404b 4559 3000 0000 0100 3000 0000 0000  @KEY0.....0.....

header while the broken ones are missing the first 0x100 bytes (BL3X-HDR) and start immediately with a @KEY0 section

[ensc]

Difference seems to be that working bl31.img.sig.enc images contain a BL3X-HDR...

This seems to be some marker used by meson64-tools. glximg seems to check the img header during -t fip. But there goes something wrong.

When extracting the images with -e, the working ones (generated by meson64-tool) do not contain a bl31.dat file. Those from glximg have such a file.

See https://gitlab.com/ensc-groups/bpi-router/de.ensc.bpi-router/-/blob/1c9beec23c282426cfa64c3615d4d21342cf3426/meta-core/recipes-uboot/u-boot/u-boot-target_meson.inc

X0/:    (ok)
total 900
-rw-r-----. 1 ensc ensc   1128 Apr 10 13:20 bl2.dat
-rw-r-----. 1 ensc ensc  65536 Apr 10 13:20 bl2.sign
-rw-r-----. 1 ensc ensc   1128 Apr 10 13:20 bl30.dat
-rw-r-----. 1 ensc ensc  58368 Apr 10 13:20 bl30.enc
-rw-r-----. 1 ensc ensc 177152 Apr 10 13:20 bl31.enc
-rw-r-----. 1 ensc ensc   1128 Apr 10 13:20 bl32.dat
-rw-r-----. 1 ensc ensc      0 Apr 10 13:20 bl32.enc
-rw-r-----. 1 ensc ensc   1128 Apr 10 13:20 bl33.dat
-rw-r-----. 1 ensc ensc 598016 Apr 10 13:20 bl33.enc

X1/:   (broken)
total 904
-rw-r-----. 1 ensc ensc   1128 Apr 10 13:20 bl2.dat
-rw-r-----. 1 ensc ensc  65536 Apr 10 13:20 bl2.sign
-rw-r-----. 1 ensc ensc   1128 Apr 10 13:20 bl30.dat
-rw-r-----. 1 ensc ensc  58368 Apr 10 13:20 bl30.enc
-rw-r-----. 1 ensc ensc   1128 Apr 10 13:20 bl31.dat     <<<<<<<<<
-rw-r-----. 1 ensc ensc 176784 Apr 10 13:20 bl31.enc
-rw-r-----. 1 ensc ensc   1128 Apr 10 13:20 bl32.dat
-rw-r-----. 1 ensc ensc      0 Apr 10 13:20 bl32.enc
-rw-r-----. 1 ensc ensc   1128 Apr 10 13:20 bl33.dat
-rw-r-----. 1 ensc ensc 598016 Apr 10 13:20 bl33.enc

[xdarklight]

I agree with @ensc - it seems the extra BL3X-HDR is missing in gxlimg.
The relevant meson64-tools code seems to be: https://github.com/angerman/meson64-tools/blob/master/bl3sig.c#L80-L95

@ensc as you seem to be able to write code - did you try to port the code from meson64-tools to gxlimg?