[S32G] Going through the s32g hard/soft platform

1. Hardware

1.1 Components layout

1.1.1 S32G274RDB2

The reference board quick guide is shown in the link: https://www.nxp.com/document/guide/getting-started-with-the-s32g-reference-design-board-2-for-vehicle-network-processing:GS-S32G-VNP-RDB2.

1.1.2 S32G274EVB

The reference board quick guide is shown in the link: https://www.nxp.com/document/guide/get-started-with-the-s32g-vehicle-network-processing-evaluation-board-3:GS-S32G-VNP-EVB3

When the S32G-PROCEVB3-S is stacked on the S32GRV-PLATEVB: Jumper J96 on the S32G-PROCEVB3-S should be in position 1-2, Only the S32GRVPLATEVB needs to be powered. Connect the power supply to the 12 V power jack P3 on S32GRV-PLATEVB.

1. Open Minicom on Linux Host. 2. Select the serial port to which the micro USB J58 of the S32G-PROCEVB3-S is connected and click OK. 3. Switch on the power switch SW1 on the S32GRV-PLATEVB and power switch SW10 on the S32G-PROCEVB3-S.

Booting from the SD card using serial RCON mode

2. Software

S32G2 vehicle network processors combine ASIL D safety, hardware security, high-performance real-time and application processing, and network acceleration. S32G2 supports the needs of new vehicle architectures: service-oriented gateways, domain controllers, zonal processors, safety processors, and more.

2.1 Software Arch

Quad Arm® Cortex®-A53 cores with Arm Neon™ technology are organized in two clusters of two cores with optional cluster lockstep for applications and services. Triple Arm Cortex-M7 lockstep cores for real-time applications. Hardware Security Engine (HSE) for secure boot and accelerated security services

2.2 Tools

Offered software support enables the S32G2 features running on the Arm Cortex-M7 and Cortex-A53, plus the accelerators. Explore the vast available software solutions to help users build their applications.

Tools

Reference Software

Standard Software

Premium Software

S32 Design Studio for S32 Platform Including Config Tools

FreeMASTER Run-Time Debugging Tool Host PC Real-Time Debugging Tool

Linux BSP Cortex®-A53

FreeRTOSTM Cortex®-A53

Integration Reference Examples Cortex-A53 Cortex-M7

USB Stack Cortex-M7

TCP/IP Stack Cortex-M7

SDHC Stack Cortex-M7

S32G Board Diagnostic Tests

S32 Real-Time Drivers (RTD) Cortex-M7 Including EB tresos Studio

Safety Peripheral Drivers (SPD) Cortex-M7

Inter-Platform Comm Framework (IPCF) Cortex-A53 Cortex-M7

PFE Driver + Standard Firmware

LLCE Driver + Firmware

HSE Standard Firmware

S32 Security NDA required

  • Increased key count

  • IDPS capability

  • IPsec

  • Customization services

S32 Safety NDA required

2.3 Linux BSP Build

NXP Automotive Linux BSP follows the general layout of a BSP, containing bootloaders, Linux kernel and root file system, which can include various libraries and middleware, and sample applications. The objective is to enable more hardware platforms, to build on top of the NXP Automotive Linux BSP in order to add additional components like drivers, middleware or applications.

For more information about the BSP, please refer to the link https://www.nxp.com/docs/en/product-brief/S32LINUXPB.pdf

2.3.1 Components

This section contains a description of the NXP Automotive Linux BSP features covered by the following main components:

  • Firmware: Non-open-source firmware binaries - prerequisites for S32 accelerators support

    • PFE Firmware

    • HSE Firmware

    • LLCE Firmware

  • Bootloader

    • Arm Trusted Firmware

    • U-Boot

  • Linux Kernel

  • Root file system

  • Technologies

    • Virtualization

    • Power Management

    • Crypto, Security, and OP-TEE

  • Yocto Project-based distribution

    • Yocto root file system and Ubuntu-compatible root file system

    • Middleware and Stacks

    • Adaptive AUTOSAR Platform Demonstrator

2.3.2 BSP compiling

Download BSP

You can get the Linux BSP from the https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/bsp-for-s32-microcontrollers-and-processors:BSP-S32. The NXP official website provides documents, a BSP project tarball, and a license, which can be downloaded freely.

NOTE,

NXP’s code center https://source.codeaurora.org/ has been dropped. All the bsp code is hosted on the github https://github.com/nxp-auto-linux/auto_yocto_bsp/tree/release/bsp36.0. Please note that the newest NXP’s BSP user manual still use the codeaurora.org.

$: mkdir ~/bin
$: curl http://commondatastorage.googleapis.com/git-repo-downloads/repo  > ~/bin/repo
$: chmod a+x ~/bin/repo
$: PATH=${PATH}:~/bin
$: mkdir fsl-auto-yocto-bsp
$: cd fsl-auto-yocto-bsp
$: repo init -u https://github.com/nxp-auto-linux/auto_yocto_bsp.git -b release/bsp36.0
$: repo sync -j16

Build All

Build YOCTO

$: ./sources/meta-alb/scripts/host-prepare.sh
$: source nxp-setup-alb.sh -m <machine>  # s32g274aevb,s32g254aevb,s32g233aevb,s32g274ardb2;
$: bitbake fsl-image-base

When this is done, a bitbake <imagename>, e.g. would be enough to completely build U-Boot, kernel, modules, the TF-A and a rootfs ready to be deployed. Look for a build result in <builddirectory>/tmp/deploy/images/. (Note, no optee-os in default). The user root with no password.

$: ./sources/meta-alb/scripts/host-prepare.sh
$: source nxp-setup-alb.sh -m s32g274aevbubuntu # s32g274aevbubuntu,s32g274ardb2ubuntu,s32g254aevbubuntu,s32g233aevbubuntu;
$: bitbake fsl-image-ubuntu-base

If targeting Ubuntu-18.04 images, add the following line in <builddirectory>/conf/local.conf. After deploying a Ubuntu image and booting the platform, please use the following credentials to log in:

  • user: bluebox

  • password: bluebox

Building OP-TEE OS Image

OP-TEE can be built and deployed by editing <builddirectory>/conf/local.conf and appending the following line:

DISTRO_FEATURES_append += "optee"

Building Images with M7 as Boot Target

Cortex-M7 booting flow is provided as an example for enabling lockstep operation mode. It is enabled by editing <builddirectory>/conf/local.conf and appending the following line

DISTRO_FEATURES_append += "m7boot"

When Cortex-M7 booting flow is enabled, the generated SD card or flash images can be used in the same way as for the default Cortex-A53 booting flow. These images include all the needed changes:

  • Image Vector Table (IVT) updates (In case IVT files needs to be deployed manually)

  • addition of Cortex-M7 software

when Cortex-M7 booting flow is enabled the files with .m7 (e.g. fip.m7) extensions should be used.

Manually Build Components

Toolchains

This Linux BSP has been built and tested using GCC 10.2 toolchain. The link for GCC 10.2.0 toolchain, as delivered by Arm at: https://developer.arm.com/-/media/Files/downloads/gnu-a/10.2-2020.11/binrel/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu.tar.xz?revision=972019b5-912f-4ae6-864a-f61f570e2e7e&la=en&hash=B8618949E6095C87E4C9FFA1648CAA67D4997D88

Once you have downloaded the toolchain package, in order to install it, you just need to untar it in a directory of your choice.

U-Boot

https://github.com/nxp-auto-linux/u-boot/tree/release/bsp36.0-2022.04

git clone git@github.com:nxp-auto-linux/u-boot.git
cd u-boot
git checkout bsp36.0-2022.04
ls
make CROSS_COMPILE=/path/to/your/toolchain/dir/bin/aarch64-none-linux-gnu- <board>_defconfig
make CROSS_COMPILE=/path/to/your/toolchain/dir/bin/aarch64-none-linux-gnu-

The values of <board> are given as in the following:

  • s32g274aevb using Memory Card, board is s32g2xxaevb

  • s32g274aevb using QSPI, board is s32g2xxaevb_qspi

  • s32g274ardb2 using Memory Card, board is s32g274ardb2

  • s32g274ardb2 using QSPI, board is s32g274ardb2_qspi

These commands should generate the U-Boot image with Program data (u-boot-nodtb.bin).

For OPTEE-OS:

While building U-Boot, one must make sure that CONFIG_OPTEE=y is set.

For s32g274aevb memory card, vim configs/s32g2xxaevb_defconfig

Linux Kernel

git clone git@github.com:nxp-auto-linux/linux.git
cd linux 
git checkout bsp36.0-5.15.85-rt
ls
make ARCH=arm64 CROSS_COMPILE=/path/to/your/toolchain/dir/bin/aarch64-none-linux-gnu- s32cc_defconfig
make ARCH=arm64 CROSS_COMPILE=/path/to/your/toolchain/dir/bin/aarch64-none-linux-gnu- -j16

For s32g274aevb, s32g254aevb, s32g233aevb, s32g274ardb2: s32gen1_defconfig.

This command should generate the kernel binary (Image) in arch/arm64/boot and the board device tree blobs (e.g.`32g2xx-evb.dtb` ...) in arch/arm64/boot/dts/freescale/

For OPTEE-OS:

Building Linux requires to be set.

CONFIG_TEE=y 
CONFIG_OPTEE=y
CONFIG_OPTEE_SHM_NUM_PRIV_PAGES=256
CONFIG_HAVE_ARM_SMCCC=y

OP-TEE

Certain configurations must be enabled for both U-Boot and Linux so that OP-TEE can communicate with Linux and allow user space applications to call for TAs execution.

Prerequisites:

sudo apt-get install python3-pip

pip3 install pyelftools pycryptodomex

Follow these steps to build optee_os:

git clone git@github.com:nxp-auto-linux/optee_os.git cd optee_os git checkout bsp36.0-3.18 make CROSS_COMPILE64=/path/to/your/toolchain/dir/bin/aarch64-none-linux-gnu- PLATFORM=s32 \PLATFORM_FLAVOR=s32g2

The above steps should create the following two binary images:

  • out/arm-plat-s32/core/tee-header_v2.bin

  • out/arm-plat-s32/core/tee-pager_v2.bin

Since OP-TEE can only boot with TF-A support, these two binaries must be included in the FIP image generated when building the TF-A. For the FIP image, please refer to the next section.

OPTEE_Client

$ git clone git@github.com:OP-TEE/optee_client.git
$ cmake -DCMAKE_C_COMPILER=aarch64-none-linux-gnu-gcc -DCMAKE_INSTALL_PREFIX=`pwd`/out
$ make
$ make install

OPTEE_Example

Build the Host Application of hello_world example:

$ git clone https://github.com/linaro-swg/optee_examples.git
$ cd optee_examples/hello_world/host
 make CROSS_COMPILE=aarch64-linux-gnu- \
      TEEC_EXPORT=$(OPTEE_PATH)/optee_client/out/ \
      --no-builtin-variables
$ make install

After build completed, the Host Application image “optee_example_hello_world” can be found in “hello_world/host” folder.

Build the Trusted Application of hello_world example:

$ cd optee_examples/hello_world/ta
$ make CROSS_COMPILE=aarch64-linux-gnu- \
       TA_DEV_KIT_DIR=$(OPTEE_PATH)/optee_os/out/arm-plat-nuvoton/exportta_arm64

After build completed, the Trusted Application image “8aaaf200-2450-11e4-abe2-0002a5d5c51b.ta” can be found in “hello_world/ta” folder. “8aaaf200-2450-11e4-abe2-0002a5d5c51b” is the UUID of hello_world Trusted Application. The UUID is defined in “hello_world/ta/hello_world_ta.h”. When running Host Application, it can use this UUID to request OP-TEE to launch this TA.

To run an OP-TEE application, besides have the running OP-TEE OS, you should have teesupplication, the Trusted Application, and the Host Application. The Trusted Application will be loaded by tee-supplicant, and the default path is “rootfs/lib/optee_armtz” folder.

Do the following steps. First, copy the tee-supplicant to rootfs:

$ cp $(OPTEE_PATH)/optee_client/out/tee-supplicant/tee-supplicant rootfs/usr/bin

Copy the Host Application to rootfs:

$ cp $(OPTEE_PATH)/optee_examples/hello_world/host/optee_example_hello_world rootfs/usr/bin

Copy the Trusted Application to tee-supplicant known default folder:

$ cp $(OPTEE_PATH)/optee_examples/hello_world/ optee_examples/hello_world/ta/8aaaf200-2450-11e4-abe2-0002a5d5c51b.ta rootfs/lib/optee_armtz

Copy the OP-TEE client API library to rootfs:

$ cp $(OPTEE_PATH)/optee_client/out/export/usr/lib/libteec.so.1 rootfs/lib

Above should include all necessary components to run the OP-TEE application. Before running the OP-TEE application, you should have the tee-supplicant running in background. Such that, it can help OP-TEE to load the Trusted Application from “rootfs/lib/optee_armtz” folder.

$ /usr/bin/tee-supplicant &

Finally, you can run the hello_world example:

$ /usr/bin/optee_example_hello_world

ARM Trusted Firmware

sudo apt-get install libssl-dev openssl

dtc --version shall be more than 1.4.6

sudo apt-get install device-tree-compiler

Before building the TF-A, please note: The TF-A blob being built is a FIP image that contains both the TF-A boot stages and the U-Boot binary. Because of that, the TF-A build process depends on U-Boot being available and optionally optee_os. To that end, the BL33 parameter to the make command-line must be the path to the u-boot-nodtb.bin located in the directory where U-Boot has been built as part of the prerequisites. BL32 must be the path to the tee-header_v2.bin and BL32_EXTRA1 must be the path to the tee-pager_v2.bin, both located in the directory where optee_os has been built as part of the prerequisites.

Follow these steps to build the TF-A:

git clone git@github.com:nxp-auto-linux/arm-trusted-firmware.git
cd arm-trusted-firmware
git checkout bsp36.0-2.5
# For default TF-A FIP image (without OPTEE-os)
make CROSS_COMPILE=/path/to/your/toolchain/dir/bin/aarch64-none-linux-gnu- \
ARCH=aarch64 PLAT=<plat> BL33=<path-to-u-boot-nodtb.bin>

# For OPTEE-OIS & TF-A image
make CROSS_COMPILE=/path/to/your/toolchain/dir/bin/aarch64-none-linux-gnu- \
ARCH=aarch64 PLAT=<plat> BL33=<path-to-u-boot-nodtb.bin> \
BL32=<path-to-tee-header_v2.bin> \
BL32_EXTRA1=<path-to-tee-pager_v2.bin> SPD=opteed

Depending on the target board, <plat> must be replaced with:

  • s32g274aevb: <plat> is s32g2xxaevb

  • s32g274ardb2: <plat> is s32g274ardb2

Deploy build//release/fip.s32 to the sdcard.

# Skip the partition table from the SD card and copy the rest of the fip image
# (TF-A and U-Boot).
# Presumably, if you are doing these steps, you are using a pre-partitioned SD card
# on which you are only replacing the TF-A and/or U-Boot image which you have manually built.
sudo dd if=<path/to/fip.s32> of=/dev/<sdcard_dev> skip=512 seek=512 \
        iflag=skip_bytes oflag=seek_bytes conv=fsync,notrunc

Note, if the boot target is M7, TF-A can be configured for a different memory layout. TF-A can read FIP image from a configurable location. For more information, please refer to the BSP user manual (3.2.4.1 Custom Build Parameters).

2.3.3 BSP burning

This chapter describes the steps to prepare an SD/MMC card and boot up for S32G2 EVB and S32G274A RDB2 boards. The boot modes of above boards are controlled by the boot configuration DIP switches and jumpers on the board.

2.3.3.1 Image Layout

The space between 0x0 and 0x1d_3000 is occupied by some or all of the following components:

  • IVT

  • QSPI Parameters

  • DCD

  • HSE_FW

  • SYS_IMG

  • Application Boot Code Header

  • TF-A FIP image

For SD/eMMC the partitioned space begins at 0x1d_3000.

For QSPI, the region after 0x1d_3000 is organized as follows:

  • Kernel [0x01f_0000 : 0x0ef_ffff]

  • FDT [0x0ff_0000 : 0x10e_ffff]

  • Ramdisk [0x10f_0000 : 0x2ff_ffff]

  • PFE Firmware [0x300_0000 : ]

2.3.3.2 SD Burning

Information found here describes the steps to prepare an SD/MMC card to boot up for S32G2 EVB and S32G274A RDB2 boards. The supported SD classes for SD are 4 and 10.

sudo dd if=./fsl-image-base-s32g274aevb.sdcard of=${DEVSD} bs=1M && syn

2.3.3.3 manually copy BSP binaries into the SD Card

Our SD Card will be split into two main partitions:

  • One for the kernel and board device tree blob;

  • Another for the root file system that will run on the board.

sudo mkfs.vfat -n boot ${DEVSD}1
sudo mkfs.ext3 -L rootfs ${DEVSD}2

Run the following commands to copy the necessary binaries onto an SD Card:

export SD_MOUNT_POINT=/media/public
cd <builddirectory>/tmp/deploy/images/<board_name>
sudo dd if=fip.s32 of=${DEVSD} conv=notrunc,fsync seek=512 skip=512 oflag=seek_bytes iflag=skip_bytes
sudo cp Image ${SD_MOUNT_POINT}/boot/
sudo cp <dtb_file> ${SD_MOUNT_POINT}/boot/<dtb_file>
sudo tar xf <rootfs> -C ${SD_MOUNT_POINT}/rootfs
sync

Unmount the file systems and eject cleanly the SD card.

Please note:

For some old EVB boards. there is a bit diff offset layout in the fip.s32:

  • Fixing offset by:

sudo dd if=fip.s32 of=fip_no_ivt.s32 bs=1 skip=4096 seek=0 count=256 conv=notrunc

  • Burning offset:

sudo dd if=fip_no_ivt.s32 of=/dev/sda conv=notrunc,fsync seek=0 bs=256 count=1 && sync && sudo dd if=fip_no_ivt.s32 of=/dev/sda conv=notrunc,fsync seek=1 bs=512 skip=1 && sync

2.4 Boot Flow

he secure boot is enabled in the default configuration of the Bootloader. For the First time boot after image deployment on S32G2, the secure boot is not enabled, it means, the BOOT_SEQ in the IVT is set to zero. When the bootloader runs for the first time, it detect this condition and configures the HSE for secure boot and then set BOOT_SEQ=1. After setting BOOT_SEQ=1, the bootloader issues a functional reset. For every following boot, secure boot is enabled.

The following figures show S32G2 boot flow examples for both non-secure and secure boot.

2.4.1 IVT image

The Image Vector Table (IVT) image is a set of pointers to other images which are required by the BootROM. It typically contains the following images, though not all are required to create a valid IVT image:

  • DCD

  • Self-Test DCD

  • HSE

  • Application Bootloader

The IVT Tool enables the configuration and generation of the IVT image as specified in the BootROM reference manual.

Please refer to the link https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/HOWTO-Use-IVT-Tool-To-Create-A-Blob-Image/ta-p/1108863

上一页S32G_Documents下一页[S32G] S32g247's Secure Boot using HSE firmware

最后更新于