Hi Expert
This is the urgent case from Ceer - Hirain. They failed to enable the kernel image authentication in BSP42.0.
Customer's issue status:
1. The customer used the ATF from the Foxconn's codebase and the board from Foxconn. They followed the chapter 10 of S32G2 BSP42.0 UM to enable the authentication of both ATF and kernel image. Their detailed steps are attached. The test log showed the kernel image can not be found after executing the "bootm 0x80000000", while the iminfo command showed the kernel image can not be getted.
2. I asked the customer to write the re-generated ATF binary after step9 into the SD card using this command :
dd if=fip.s32 of=/dev/sdb seek=512 skip=512 iflag=skip_bytes oflag=seek_bytes conv=notrunc,fsync
I think this step is missed in the BSP42.0 UM. But the customer reported the BL31 failed to be boot if they write the regenerated ATF into the SDcard.
3. I also asked the customer to use the released ATF from NXP in github, the ATF reported some error as below.
What I did:
1. I only followed the steps of chapter 10.6.2 of S32G2 BSP42.0 UM to enable the kernel authentication of RDB2. See the attached detailed steps.
2.I also write the regenerated the ATF into the Sdcard
3. The test log showed the kernel image and dtb file were verified successfully, but an system reset was triggered after loading kernel image.
My analysis:
Since the customer used the test board and ATF from the third part(Foxccon), I suspect
the Foxccon might did some modification in ATF and BSP to apply to their board. Writing the
generated ATF will cause the boot failure of BL31 on customer side, the regenerated fip.s32 including the DTB with the extra signed hash value(using mkimage tool to sign kernel and fdt), so I guess the BL31 memory may be overwrite by the extra signed hash value.
1.Would you please check my steps and analysis why the system reset is triggered ?
2.For the customer's issue, would you please check the customer's steps and provide some hints ? Could we check some configurations ?
Customer provided the main modification for ATF
Yes, this is not mentioned but I thought it is implied. Yet, I can add this detail if needed.
We do however, provide an itb configuration example and with that it works. Also, verifiedboot is automatized under yocto, so verififedboot can be made faster with yocto, without following so many manual steps.
Just make a build with DISTRO_FEATURES:append = " verifiedboot"
Hello,
When loading the ITB with fatload at 0x80000000 for example, you need to ensure that there is enough space from 0x80000000 to make ITB fit. Then, you need to ensure, that the values configured in ITB at Load: allow enough space for kernel unpacking from the ITB to new memory location. In this case specifically, the kernel is unpacked from ITB at the same memory address when ITB was loaded ( 0x80000000 ) which results in a corruption and bootloader reboots the board. In order to work, the recommendation is to either change the Load instead of 0x80000000 to be 0x82000000 ( in ITS/ITB configuration ) or load ITB at a different memory location.
Regards,
Mihai
Yes, as I mentioned in the email, I also found this detail in my later experiment, but in the BSP UM, this detailed is not mentioned
Hi Mihai
I asked the customer to try to use the Yocto to enable the secure feature automatically, they reported they encountered the same issue that the ATF failed to boot BL31 or BL33 as below.
As I mentioned in the email, the customer also followed my shared steps to enable the kernel image authentication manually, which has been proved to work on my side, but they also encountered the same issue.
The issue focuses on the two below factors:
1.The customer used the modified dtb file to rebuild the ATF, this dtb file includes an additional public key used for kernel image authentication. If they use the unmodified dtb file to build ATF, the ATF boot fine.
2.The ATF has been modified by the customer, see the attached patch file of ATF in my previous comments.
I asked the customer to debug the ATF code to find the stuck point, they are working for this process. There may be some online debug meeting with customer in the future. I am not the expert of ATF and hope the software team could also participate in the meeting. The attached files are the customer's ATF dtb and fip.bin which can not boot fine
BTW, does the software team needs more extra information from customer and provide more suggestions to investigate the root cause ?
Hi Arthur,
please tell them to convert the resulted dtb back to dts and use meld to check the input vs the output dtb when running step 8 from UM. ( since is working without it but not with it )
I have a feeling is a build issue and there is one good input dtb but the result is a different dtb not matching their hw after running step 8.
Thanks and regards,
Mihai