S32GのトピックRe: Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

lihongjun — Mon, 23 Oct 2023 09:40:09 GMT

Dear NXP,

I have built the Linux BSP, the IPCF_Example_multi_instance_S32G399_M7_x demos and a S32G3 M7 bootloader. Now I am trying to deploy them onto the S32G-VNP-RDB3 Board.

As AN13750 says, and take care of the modifications on S32G3, I think I must use C:\NXP\S32DS.3.5\S32DS\tools\S32FlashTool\GUI\s32ft.exe to burn the images. But I can't find the fip.bin file on my Ubuntu VM, although there are 2 files named fip.s32-qspi and fip.s32-sdcard exist in the Linux BSP output folder. So my questions are:

1) Is the fip.32-qspi file play the same role as fip.bin file in AN13750?

2) If not, how can I build the fip.bin file for S32G3?

3) Are the write addresses of the images just the same as S32G2?

Thanks.

Re: Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

Daniel-Aguirre — Mon, 23 Oct 2023 22:21:21 GMT

Hi,

For the information you are providing, you are using yocto project, is this correct? If so, we are not obtaining the image from yocto project, but from manually building both u-boot and ATF (as described under the AN13750).

Below will be some comments on regards of your questions:

A1 >> They are not the same. Seeing the contents of both fip.bin and fip.s32-qspi, fip.bin is the binary for the fip itself, while fip.s32-qspi contains both the fip itself and the whole IVT structure which can be flashed directly to the QSPI. As seen on the image below, the offset of the image is different from the *.bin (no offset) to the *.s32-qspi (offset):

Again, the offset is due to the IVT structure under the *.s32-qspi file.

A2 >> Can be obtained by manually building both u-boot/ATF. This is described under the "Manually building Linux BSP components" under the respective BSP User Manual, or under the AN13750 itself.

As a note, codeaurora link is not available anymore, the new link should be the one from github itself:

https://github.com/nxp-auto-linux

As for yocto, should be located under the following path:

A3 >> On regards of the RAM pointers under the IVT, they are not the same. The addresses are the following:

This can be confirmed by looking into the *.map file from the Bootloader.bin.

Please, let us know.

Re: Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

lihongjun — Tue, 24 Oct 2023 01:43:32 GMT

Dear Daniel,

For question 1 and 2, as you told, I can build the arm-trusted file manually according to the steps introduced in section 3.2.4 of document Linux BSP 35.0 User Manual for S32G3 platforms. But since a fip.bin file already exist in /fsl-auto-yocto-bsp/build_s32g399ardb3/tmp/work/s32g399ardb3-fsl-linux/arm-trusted-firmware/2.5-r0/build/s32g399ardb3/release folder after the yocto building for Linux BSP is completed, I can use it directly. Is this procedure correct?

For question 3, the addresses I meant is the burning target address of the binaries to the QSPI flash memory as mentioned by step 9~13 in section 6 of document AN13750. Please clarify for me.

Thanks.

Re: Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

lihongjun — Tue, 24 Oct 2023 09:14:07 GMT

Another question is, since I have finish yocto BSP building, and the boot image fip.bin has been generated, is there any way that I can find the log messages such as IVT location, load address and entry point, or I have to manually build ATF to get them?

Thanks.

Re: Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

Daniel-Aguirre — Tue, 24 Oct 2023 20:43:25 GMT

Hi,

We have not used the "fip.bin" file created by yocto, but looking into the folder we shared it seems that the structure is the same, hence it should work.

As for the log, we are not finding the exact log that it is printed (as shown under the AN13750), but you should be able to find the "Entry Point" by looking into the *.map file for BL2:

Regarding the "Load Address", this is calculated with the following formula:

For which, BL2_BASE should be the Entry Point and the FIP_HDR_SIZE and DTB_SIZE are available under the same folder as the "fip.bin" file:

With them, you should be able to obtain the "Load Address".

As for the QSPI addresses, these can remain the same.

Please, let us know.

Re: Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

lihongjun_01 — Wed, 25 Oct 2023 02:50:39 GMT

Does the formula mean LOAD_ADDRESS = BL2_BASE + FIP_HDR_SIZE + DTB_SIZE?

Or could please tell me a simple mathematics form of the formula?

Thanks.

Re: Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

lihongjun_01 — Wed, 25 Oct 2023 07:53:21 GMT

Dear Daniel,

I checked the map file in bl2.map, dtb_size and fip_hdr_size and got

bl2_entrypoint = 0x34302000
dtb_size = 0x7000
fip_hdr_size = 0xe0

So I got a load address = 0x342FAF20 using the formula you told, and config bootloader in EB as follow:

But error messages appeared when I try to generate project:

Invalid value for node "/AUTOSAR/TOP-LEVEL-PACKAGES/Bootloader/ELEMENTS/Bootloader/BootSources/linux_bsp_atf/ImageFragments/ImageFragments_0/LoadAddressRam": The load RAM address is invalid. If you use CRC over DMA transfer, the start address must be multiple of 8 If you don't use CRC over DMA transfer, the start address must be multiple of 64

What shall I do to make the ATF load RAM address OK?

Thanks.

Re: Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

Daniel-Aguirre — Wed, 25 Oct 2023 18:36:56 GMT

Hi,

This error message has appeared before to us since there is a restriction over the alignment of the FIP image:

Did you modify the FIP_ALIGN variable to be 64? This is also told under the AN13750. Once we modified the alignment, the error disappeared from our build.

The calculation for the load address is as follow:

Please, let us know.

Re: Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

lihongjun — Thu, 26 Oct 2023 11:57:41 GMT

Dear Daniel,

I tried to build the ATF for G3 manually. The first step is u-boot building. After I cloned the source code and executed make command, it shows:

YACC scripts/kconfig/zconf.tab.c
/bin/sh: 1: bison: not found
scripts/Makefile.lib:226: recipe for target 'scripts/kconfig/zconf.tab.c' failed
make[1]: *** [scripts/kconfig/zconf.tab.c] Error 127
Makefile:539: recipe for target 's32g399ardb3_defconfig' failed
make: *** [s32g399ardb3_defconfig] Error 2

I don't know why this happen.

So I temporarily skip this step and jump to ATF build directly (I don't know if this is applicable). I set the BL33=$(home)/fsl-auto-yocto-bsp/build_s32g399ardb3/tmp/work/s32g399ardb3-fsl-linux/u-boot-s32/2020.04-r0/build/s32g399ardb3_defconfig/u-boot-nodtb.bin i.e. the u-boot built during yocto BSP.

But when I execute make command it shows:

CC lib/libfdt/fdt.c
CC lib/libfdt/fdt_addresses.c
CC lib/libfdt/fdt_empty_tree.c
CC lib/libfdt/fdt_ro.c
CC lib/libfdt/fdt_rw.c
CC lib/libfdt/fdt_strerror.c
CC lib/libfdt/fdt_sw.c
CC lib/libfdt/fdt_wip.c
AR /home/lhj/fsl-auto-yocto-bsp/arm-trusted-firmware/build/s32g3xxaevb/release/lib/libfdt.a
dtc version must be 1.4.6 or above
plat/nxp/s32/s32_common.mk:174: recipe for target 'check_dtc_version' failed
make: *** [check_dtc_version] Error 1

When I try to upgrade dtc, it says:

Reading package lists... Done
Building dependency tree
Reading state information... Done
device-tree-compiler is already the newest version (1.4.5-3).
0 upgraded, 0 newly installed, 0 to remove and 51 not upgraded.

Please tell me how to solve the above problems.

Thanks.

Re: Some Questions about Employment M7 Boot Image on S32G-VNP-RDB3 Board

Daniel-Aguirre — Thu, 26 Oct 2023 16:06:23 GMT

Hi,

For the first error, you require to install "bison", we have it installed under our setup as follows:

For ATF, you require do require for u-boot compilation, since it uses the u-boot binaries for the ATF compilation stage.

As for the DTC version, we do have one version greater than the one being specified:

Could be a problem with the packages that you have installed.

Please, let us know.