TF-A Exception on boot-up

[user_ABCD]

I have a custom board built upon the stm32mp157f. (Therefore, have custom device trees.)

I currently am seeing an exception in TF-A that I cannot explain.

INFO: Reset reason (0x14):
INFO: Pad Reset from NRST
INFO: PMIC version = 0x21
INFO: FCONF: Reading TB_FW firmware configuration file from: 0x2ffe3000
INFO: FCONF: Reading firmware configuration information for: stm32mp_io
INFO: Using EMMC
INFO: Instance 2
INFO: Boot used partition fsbl1
NOTICE: BL2: v2.4-r1.0(debug):v2.4-dirty
NOTICE: BL2: Built : 16:43:51, Nov 17 2020
INFO: BL2: Doing platform setup
INFO: RAM: DDR3-DDR3L 16bits 533000Khz
WARNING: Couldn't find property st,phy-cal in dtb
INFO: Memory size = 0x20000000 (512 MB)
ASSERT: drivers/partition/gpt.c:24

After the initial flashing of the eMMC with the STMCubeProgrammer, it boots fine the first time. Every boot thereafter (cold or warm), I get the above exception.

Any idea what this means, how to debug or solve it?

[Olivier GALLIEN]

Hi @user_ABCD​ ,

Looks like you eMMC has not been properly programmed or can not be read by TF-A.

Could you please share the tsv you used + complete log of CubeProg + Console during programming ?

Olivier

[user_ABCD]

I will have to get the logs next week when I can program a board. Below is my tsv, I don't use the extra partitions (bootfs,vendorfs,userfs) that OpenSTLinux uses.

[Olivier GALLIEN]

Hi @user_ABCD​ ,

Ok then assumption is a corruption of GPT partitioning at first boot.

Could you share the complete first boot trace on which you get linux prompt ?

Are you observing some filesystem decompression steps?

Once you get linux prompt, could you then try to access and check emmc partitioning ?

evaluate Linux file system size ?

Else fist time I see usage of single image.ext4 instead of legacy OSTL partitioning ?

What rational behind ?

May you have opportunity to try with the OSTL partitioning ?

Olivier

[Erwan SZYMANSKI]

Hello @user_ABCD​ ,

Indeed I do not see something strange in the first boot, moreover it seems to well write the GPT partition the first time.

As @Community member​ said, this specific assert means that TF-A is not able to read a null partition name on eMMC and so stop the boot.

Can you check at the first boot, when you are in Linux, if you can well find the GPT table with doing the following command: "gdisk -l /dev/mmcblk0" ?

This is just to check if the GPT table is still well known before making a reboot.

Then, I would advise to put some logs in TF-A drivers to see if we can print the different partitions name that it is able to find or not, with INFO(...) macro. It could be done in drivers/partition/gpt.c in both functions, "unicode_to_ascii()" and "parse_gpt_entry()".

It could also be interesting to have a trace in drivers/partition/partition.c in the function "verify_partition_gpt()" to check the number of partition that TF-A find (list.entry_count).

Maybe this information can be a first step for us to help at debug.

Kind regards.

Erwan.

[user_ABCD]

@Erwan SZYMANSKI​ 

The issue appears to be that there is no "Name" on the bad image. On a good image, the "Name" appears as rootfs.

I am trying to follow some of the latest stuff on the ST Wiki. Is the PARTUUID possibly causing me issues? I have not used that in the past and unsure of the implications other than I am currently doing nothing with it.

From the ST Wiki - "The partition named "rootfs" has a specific PARTUUID."

STM32CubeProgrammer flashlayout - stm32mpu

[Erwan SZYMANSKI]

@user_ABCD​ ,

As a first test, can you try to make your rootfs partition a System type instead of a Filesystem type ? I do not know if it as an impact on TF-A's reading capability but I just want to be sure before going further.

Regards.

Erwan