Re: rk3568 boot fail with TF-A binary

[Ahmad Fatoum <a.fatoum@pengutronix.de>]

Hello Alexander,

On 28.06.24 11:39, Alexander Shiyan wrote:
> Hello All.
> 
> I'm trying to use the open source TF-A implementation for the Rockchip
> rk3568 CPU:
> https://github.com/ARM-software/arm-trusted-firmware/commit/9fd9f1d024872b440e3906eded28037330b6f422

Nice, didn't know that there is upstream support now.

> The barebox starts to launch, but an error occurs, the meaning of
> which I don’t know how to interpret.
> If I use Rockchip's RKBIN binary this doesn't happen.
> 
> Has anyone tried running something like this?
> What does this error mean?

We still use the blob at Pengutronix, but would be interested
to switch to upstream TF-A, now that this is available.

> 
> <DDR initialization part skipped>
> rockchip-dmc: rockchip_sdram_size(reg2=1000ea01, reg3=30000031)
> rockchip-dmc: rank 2 cs0_col 10 cs1_col 10 bk 3 cs0_row 17 cs1_row 17
> bw 2 row_3_4 0
> rockchip-dmc: rk3568_ram0_size() = 4026531840
> Loading phdr 0 to 0x0000000000040000 (98526 bytes)
> Loading phdr 1 to 0x00000000fdcd0000 (112 bytes)
> Loading phdr 2 to 0x0000000000000000 (0 bytes)
> NOTICE:  BL31: v2.11.0(release):v2.11.0-136-ga6e01be25
> NOTICE:  BL31: Built : 06:28:20, Jun 18 2024
> NOTICE:  BL31: Rockchip release version: v1.0
>> rockchip-dmc: rockchip_sdram_size(reg2=1000ea01, reg3=30000031)
> rockchip-dmc: rank 2 cs0_col 10 cs1_col 10 bk 3 cs0_row 17 cs1_row 17
> bw 2 row_3_4 0
> rockchip-dmc: rk3568_ram0_size() = 4026531840
> uncompress.c: memory at 0x00a00000, size 0xef600000
> mmu: enabling MMU, ttb @ 0xeffe0000
> uncompress.c: uncompressing barebox binary at 0x0000000000b55ce0 (size
> 0x000800a8) to 0xefd00000 (uncompressed size: 0x00106310)
> uncompress.c: jumping to uncompressed image at 0x00000000efd00000
> deep-probe: supported due to diasom,ds-rk3568-evb
> Switch to console [cs0]
> 
> barebox 2024.04.0-00177-gce195ae78894-dirty #22 Tue Jun 25 21:09:41 MSK 2024
> 
> Board: Diasom DS-RK3568-EVB
> deep-probe: supported due to diasom,ds-rk3568-evb
> rockchip-dmc memory-controller.of: Detected memory size: 0x0000000200000000
> netconsole: registered as netconsole-1
> rk808 rk8090: chip id: 0x8090
> vdd_npu: Bringing 500000uV into 850000-850000uV
> vdda0v9_image: Bringing 600000uV into 900000-900000uV
> vcca1v8_image: Bringing 600000uV into 1800000-1800000uV
> rockchip_saradc fe720000.saradc@fe720000.of: registered as aiodev0
> Boot source: usb, instance 0
> psci psci.of: detected version 1.1
> xHCI xHCI0: USB XHCI 1.10
> mdio_bus: miibus0: probed
> dw_mmc fe2b0000.mmc@fe2b0000.of: registered as mmc0
> rk3568-dwcmshc-sdhci fe310000.mmc@fe310000.of: registered as mmc1
> mmc1: detected MMC card version 5.1
> mmc1: registered mmc1.boot0
> mmc1: registered mmc1.boot1
> mmc1: registered mmc1
> mdio_bus: miibus1: probed
> Setup Machine ID from EMMC serial: 30948368

Nice! I think this would be cool to have upstream in barebox:
If the SD/eMMC is the boot medium and there is no SoC machine ID, take the
boot medium machine id.

> Unknown/Uncategorized exception (ESR 0x02000000) at 0xbf96b728aba34bf1
> elr: 00000000efd7da48 lr : 00000000efd7d7e0
> x0 : 00000000afdc1b10 x1 : 00000000afdc1b70
> x2 : 0000000000000000 x3 : 0000000000000020
> x4 : 0000000000000000 x5 : 00000000efff7dd8
> x6 : 00000000ca62c1d6 x7 : 0000000000000000
> x8 : 00000000afdc1b68 x9 : 0000000000000000
> x10: 0000000000000000 x11: 00000000fffffff6
> x12: 00000000fffffff6 x13: 0000000000000020
> x14: 0000000000000000 x15: 0000000000000003
> x16: 00000000efff7968 x17: 0000000000000003
> x18: 00000000efff7ef0 x19: 0000000000000001
> x20: 00000000afdc1b30 x21: 00000000afdc1b10
> x22: 00000000afdc1b30 x23: 00000000ef600000
> x24: 0000000000b35a40 x25: 00000000000800a8
> x26: 0000000000106310 x27: 00000000effe0000
> x28: 0000000000000000 x29: 00000000efff7e40
> 
> Call trace:
> [<efd7da48>] (cmd_parted_help+0xefce25ef/0xefd00281) from [<efd7d8b0>]
> (cmd_parted_help+0xefce2457/0xefd00281)
> [<efd7d8b0>] (cmd_parted_help+0xefce2457/0xefd00281) from [<efd0297c>]
> (machine_id_set_globalvar+0x7c/0x100)

These are completely bogus as one can see from the absurdly large offsets.

> [<efd0297c>] (machine_id_set_globalvar+0x7c/0x100) from [<efd01adc>]
> (start_barebox+0x60/0x8c)
> [<efd01adc>] (start_barebox+0x60/0x8c) from [<efd7bf1c>]
> (cmd_parted_help+0xefce0ac3/0xefd00281)
> [<efd7bf1c>] (cmd_parted_help+0xefce0ac3/0xefd00281) from [<efd0000c>]
> (__bare_init_start+0x0/0x14)
> [<efd0000c>] (__bare_init_start+0x0/0x14) from [<00b01d8c>] (0xb01d8c)
> [<00b01d8c>] (0xb01d8c) from [<00b01640>] (0xb01640)
> panic: unhandled exception
> ### ERROR ### Please RESET the board ###

Assuming this stack trace is accurate, it looks like the crypto extensions
use may upset the CPU? Do you have CONFIG_DIGEST_SHA256_ARM64_CE enabled?
Does this issue happen when you disable it?

Did you call rk3588_lowlevel_init() in your entry point?

Cheers,
Ahmad

> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |