# \[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: .
#### 1.1.2 S32G274EVB
The reference board quick guide is shown in the link:
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
S32G2 Processors for Vehicle Networking Block Diagram
S32G2 Processors for Vehicle Networking Software Ecosystem Block Diagram
### 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 | |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
### 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.
BSP arch
For more information about the BSP, please refer to the link
#### 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 . The NXP official website provides documents, a BSP project tarball, and a license, which can be downloaded freely.
**NOTE,**
NXP’s code center has been dropped. All the bsp code is hosted on the github . Please note that the newest NXP’s BSP user manual still use the [codeaurora.org](http://codeaurora.org).
```sh
$: mkdir ~/bin
$: curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$: chmod a+x ~/bin/repo
$: PATH=${PATH}:~/bin
```
```sh
$: 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**
```sh
$: ./sources/meta-alb/scripts/host-prepare.sh
$: source nxp-setup-alb.sh -m # s32g274aevb,s32g254aevb,s32g233aevb,s32g274ardb2;
$: bitbake fsl-image-base
```
When this is done, a bitbake \, 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 `/tmp/deploy/images/`. (Note, no optee-os in default). The user root with no password.
```sh
$: ./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 `/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 `/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 l**ockstep operation mode**. It is enabled by editing `/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:
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**](https://github.com/nxp-auto-linux/u-boot/tree/release/bsp36.0-2022.04)
```sh
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- _defconfig
make CROSS_COMPILE=/path/to/your/toolchain/dir/bin/aarch64-none-linux-gnu-
```
The values of `` 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**
{% @github-files/github-code-block %}
```sh
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**
{% @github-files/github-code-block url="" %}
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**
```sh
$ 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:
```sh
$ 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:
```sh
$ 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`
{% embed url="" %}
**ARM Trusted Firmware**
{% @github-files/github-code-block url="" %}
`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:
```sh
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= BL33=
# For OPTEE-OIS & TF-A image
make CROSS_COMPILE=/path/to/your/toolchain/dir/bin/aarch64-none-linux-gnu- \
ARCH=aarch64 PLAT= BL33= \
BL32= \
BL32_EXTRA1= SPD=opteed
```
Depending on the target board, \ must be replaced with:
* s32g274aevb: \ is s32g2xxaevb
* s32g274ardb2: \ is s32g274ardb2
Deploy build//release/fip.s32 to the sdcard.
```sh
# 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= of=/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:
```sh
export SD_MOUNT_POINT=/media/public
cd /tmp/deploy/images/
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 ${SD_MOUNT_POINT}/boot/
sudo tar xf -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
