[S32G] Going through the s32g hard/soft platform
最后更新于
最后更新于
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
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.
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
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
Integration Reference Examples Cortex-A53 Cortex-M7
S32G Board Diagnostic Tests
Increased key count
IDPS capability
IPsec
Customization services
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.
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
Download BSP
NOTE,
Build All
Build YOCTO
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.
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
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
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
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.
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
OPTEE_Example
Build the Host Application of hello_world example:
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:
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:
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.
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).
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.
Run the following commands to copy the necessary binaries onto an SD Card:
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
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.
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.
The reference board quick guide is shown in the link:
Including Config Tools
Host PC Real-Time Debugging Tool
Cortex®-A53
Cortex®-A53
Cortex-M7
Cortex-M7
Cortex-M7
Cortex-M7 Including EB tresos Studio
Cortex-M7
Cortex-A53 Cortex-M7
NDA required
NDA required
Cortex-A53 Cortex-M7 Safety concept implementation
Cortex-A53
For more information about the BSP, please refer to the link
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.
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 .
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:
Please refer to the link
