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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

Jump to solution
4,369 Views
lihongjun
Contributor III

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.

0 Kudos
Reply
1 Solution
4,308 Views
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

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

DanielAguirre_0-1698258674211.png

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:

DanielAguirre_1-1698258964687.png

Please, let us know.

View solution in original post

0 Kudos
Reply
9 Replies
4,354 Views
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

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):

DanielAguirre_0-1698088309267.png

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:

DanielAguirre_0-1698099654463.png

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

DanielAguirre_1-1698088606286.png

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

Please, let us know.

0 Kudos
Reply
4,341 Views
lihongjun
Contributor III

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. 

0 Kudos
Reply
4,336 Views
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

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:

DanielAguirre_0-1698179903436.png

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

DanielAguirre_1-1698179956064.png

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:

DanielAguirre_2-1698180040718.png

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.

0 Kudos
Reply
4,285 Views
lihongjun
Contributor III

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.

0 Kudos
Reply
4,281 Views
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

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

DanielAguirre_0-1698336225159.png

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:

DanielAguirre_1-1698336331718.png

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

Please, let us know.

0 Kudos
Reply
4,324 Views
lihongjun_01
Contributor I

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:

lihongjun_01_0-1698218752985.png

lihongjun_01_1-1698218869759.png

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/...": 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. 

0 Kudos
Reply
4,309 Views
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

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

DanielAguirre_0-1698258674211.png

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:

DanielAguirre_1-1698258964687.png

Please, let us know.

0 Kudos
Reply
4,330 Views
lihongjun_01
Contributor I

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.

0 Kudos
Reply
4,346 Views
lihongjun
Contributor III

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.

0 Kudos
Reply