Recently, there are several customers who feel interests in developing applications in Linux user space to directly use the HSE, in order for behaving hardware based encryption and authentication. The customers need direct examples for their development reference, however, from the source code released in formal BSP, there are only simple encryption examples existed, they need other kinds of examples, for example, hash operations. This reference document describes access schemes to the HSE using the LIBHSE standard API. It shows a hash operation example of using LIBHSE to access the HSE under incorporation of the NXP Linux BSP software. A sample application is implemented taking use of the APIs provided by LibHSE:   Reference the attached PDF file for details.

This document provides a step-by-step guide to building the NXP Auto Linux Yocto BSP using WSL 2 (Windows Subsystem for Linux) instead of a full virtual machine or native Linux installation. This approach is especially useful for developers working in Windows environments who want a faster and more streamlined way to set up their development environment for platforms like the S32G-VNP-RDB3. The guide covers everything from installing WSL 2 and configuring system resources, to downloading the BSP, building it with Yocto, and flashing the image to an SD card. It also includes practical tips to help avoid common build issues.  

1. Introduction Since the CodeAurora shutdown,  in order to facilitate the build for older BSPs(versions prior to 34.0),  the method with necessary patches/scripts is provided by NXP to adapt the changes, for details, it could be accessed via the following link: https://community.nxp.com/t5/S32G-Knowledge-Base/How-to-build-older-Auto-Linux-BSPs/ta-p/1637516 (Note that the operation steps provided by this document could be used solely without referencing the document from previous link. This document could be treated as a supplement of the above link, since the operations would only workable upon the scripts provided from the original document, for diving into the internals, it is strongly suggested reading the document above)  However, recently the following errors may be found during the old BSP builds: ./migrate.sh --full --work_path ./BSP34 --release_branch release/bsp34.0 ===================================================================== WARNING: THIS SCRIPT WILL CHANGE MANIFEST AND YOCTO RECIPE FILES! SINCE CODE AURORA HAS BEEN SHUT DOWN, THIS SCRIPT IS NEEDED IN ORDER TO CHANGE THE CAF LINKS TO NXP/GITHUB CORRESPONDING LINKS. IT IS STRONGLY RECOMMENDED THAT USERS PROPERLY SAVE ALL THEIR LOCAL CHANGES IN REPOSITORES CLONED BY THE 'repo' TOOL BEFORE ATTEMPTING TO RUN THIS SCRIPT (VIA 'git commit' OR OTHER MEANS)!!! PROCEEDING FURTHER MEANS ACKNOWLEDGING THE RISKS INVOLVED AND PROPERLY SAVING ALL YOUR CHANGES! ===================================================================== Proceed further?(y/n) y [INFO] Preparing working directory ./BSP34/auto-bsp ... [INFO] Finished preparing working directory! [INFO] Performing repo init... [INFO] Using manifest " default.xml "... Downloading Repo source from https://gerrit.googlesource.com/git-repo remote: Counting objects: 162, done remote: Finding sources: 100% (27/27) remote: Total 27 (delta 4), reused 14 (delta 4) Unpacking objects: 100% (27/27), 64.67 KiB | 4.62 MiB/s, done. ...................... If you want to change this, please re-run 'repo init' with --config-name ........................ [INFO] Finished repo init! [INFO] Starting presync migration! [INFO] Done presync migration! [INFO] Performing repo sync... Fetching: 11% (1/9) 0:21 | 2 jobs | 0:21 meta-freescale @ sources/meta-freescale fatal: unable to access 'https://git.linaro.org/openembedded/meta-linaro/': The requested URL returned error: 403 meta-linaro: fatal: unable to access 'https://git.linaro.org/openembedded/meta-linaro/': The requested URL returned error: 403 meta-linaro: sleeping 4.0 seconds before retrying fatal: unable to access 'https://git.linaro.org/openembedded/meta-linaro/': The requested URL returned error: 403 error: Cannot fetch meta-linaro from https://git.linaro.org/openembedded/meta-linaro Fetching: 100% (9/9), done in 9m50.034s Fetching: 0% (0/1) 0:07 | 1 job | 0:07 meta-linaro @ sources/meta-linaro fatal: unable to access 'https://git.linaro.org/openembedded/meta-linaro/': The requested URL returned error: 403 meta-linaro: fatal: unable to access 'https://git.linaro.org/openembedded/meta-linaro/': The requested URL returned error: 403 meta-linaro: sleeping 4.0 seconds before retrying fatal: unable to access 'https://git.linaro.org/openembedded/meta-linaro/': The requested URL returned error: 403 error: Cannot fetch meta-linaro from https://git.linaro.org/openembedded/meta-linaro Fetching: 100% (1/1), done in 7.664s fatal: failed to unpack tree object HEAD error.GitError: Cannot checkout meta-linaro: Cannot initialize work tree for meta-linaro error: Cannot checkout meta-linaro Checking out: 88% (8/9), done in 0.680s Checking out: 11% (1/9), done in 0.031s error: Unable to fully sync the tree error: Downloading network changes failed. error: Checking out local projects failed. Failing repos: sources/meta-linaro Try re-running with "-j1 --fail-fast" to exit at the first error. ================================================================================ Repo command failed due to the following `SyncError` errors: GitCommandError: 'fetch --quiet --progress linaro --prune --recurse-submodules=no --tags +refs/heads/*:refs/remotes/linaro/* +refs/tags/*:refs/tags/*' on meta-linaro failed stdout: fatal: unable to access 'https://git.linaro.org/openembedded/meta-linaro/': The requested URL returned error: 403 GitCommandError: 'fetch --quiet --progress linaro --prune --recurse-submodules=no --tags +refs/heads/*:refs/remotes/linaro/* +refs/tags/*:refs/tags/*' on meta-linaro failed stdout: fatal: unable to access 'https://git.linaro.org/openembedded/meta-linaro/': The requested URL returned error: 403 Cannot initialize work tree for meta-linaro .......................... By investigating the issue, it is caused by the service changes from Linaro. 2. Additional Operations For fixing the issue met, the following new steps are suggested for the users who still want to utilize the older BSPs, taking BSP34.0 builds as an example below: Prepare the working scripts/patches mentioned in the previous link mentioned: git clone https://github.com/nxp-auto-linux/linux-bsp-utils.git cd linux-bsp-utils/codeaurora_migration/ Manually creating working directory and enter it, to start the repo init operation. mkdir BSP34/auto-bsp cd BSP34/auto-bsp​ repo init -u https://github.com/nxp-auto-linux/auto_yocto_bsp -b release/bsp34.0 Then apply the patch in BSP34/auto-bsp/.repo/manifests directory cd BSP34/auto-bsp/.repo/manifests patch -p1 < OldBSPs.patch Execute the script that downloaded from github in step 1 cd ../../../.. ./migrate.sh -s -p ./BSP34​ Enter the bitbake shell cd BSP34/auto-bsp source nxp-setup-alb.sh -m <target_machine>​ Start a build and then test the image built on the board bitbake <target-image>

This article introduced one way for solving the issue that met from several customers, which caused by lacking of necessary partition to hold the PFE FW. Recently, several customers have submitted similar requests via on-line technical support channel, although based on different platforms and scenarios, indicating a need for dealing with the issue that PFE FW could not be loaded correctly when they do not use the full SD booting image. Rather than directly flashing the full SD image onto the SD card, some customers prefer to utilize only the small booting image(fip.s32) to initiate board booting. They intend to launch their system with images (kernel, DTS, RootFS) independently built via TFTP service under U-Boot. However, this approach has proven unfeasible due to certain customers' specific designs not supporting GMAC, thus preventing image transfer to the board through TFTP. Therefore, it is essential to explore alternative methods for initializing PFE that align with these specific customer requirements. Looking into the default BSP implementation, the PFE firmware is stored in the first partition of the SD card, specifically for SD boot. During the U-Boot boot process, the PFE driver loads the firmware from this partition and proceeds to initialize the ports based on other configurations such as Serdes. Examining the default U-Boot code, the firmware loading process can be represented as the following block diagram:   The firmware loading process is quite complex due to routines that access the filesystem of the block device. The PFE firmware resides in a first partition. If the SD card lacks the partition, it's crucial to create one and install the PFE firmware before initializing the PFE ports. These two steps are essential based formal U-Boot code from BSP. To mitigate such issues, it is advantageous not to put the PFE FW into the SD partition, but otherwhere. It is possible to put it into on-board eMMC, QSPI flash, or even integrate it directly into U-Boot to avoid the issue described above. This document will focus on the implementation of the last method mentioned, this approach facilitates network connectivity while solely flashing the fip.s32 file. Such a feature is beneficial in meeting specific customer requirements. The technical details are described in the document, it simplified the FW loading process:   It is tested with BSP40 and PFE FW 1.8, the corresponding reference patch is attached together within the document. Please note that this is only a reference implementation, designed to offer an alternative method for loading PFE firmware in specific cases. It is not a formal patch intended for use in the BSP or for other product applications.  

Question   Answer  

L6 - S32G2 security subsystem overview, by Ankur(EN)/ Xuewei(CHN) part 1 - concept of security subsystem part 2 - NXP security subsystem introduction part 3 - S32G2 security architecture and HSE part 4 - security servces and platform security

Introduction In order to facilitate the build for older BSPs after CAF shutdown (versions prior to 34.0), we have implemented a bash script which is able to change the manifest and Yocto files by adapting the old CAF git repository links to corresponding NXP GitHub repository links. This will allow Yocto builds to be performed without the need to pull sources from CAF. The script and usage instructions below have also been uploaded to github: https://github.com/nxp-auto-linux/linux-bsp-utils/tree/master/codeaurora_migration However please feel free to use this article for reference as well as for comments. Script Usage Currently, there are 2 operating modes: RECOMMENDED: fully-automated mode in this mode, the user starts from scratch and the script will handle everything: cloning from upstream and adjusting sources to NXP GitHub how to use:  ./migrate.sh --full --work_path ./testfolder --release_branch release/bsp32.0​ inside the work_path given (e.g. "./testfolder") it will create the "fsl-image-auto-bsp" directory, and inside this directory it will start performing "repo init" and "repo sync" with adjusted URLs after the script has finished, you can go inside the project (e.g. ./testfolder/fsl-image-auto-bsp) and perform the normal steps for the yocto build: enter the bitbake shell source nxp-setup-alb.sh -m <target_machine>​ start a build bitbake <target-image>​ Customizing the script: Use a custom manifest: set the variable MANIFEST to the desired string. Examples: Fetching "meta-adas" requires using manifest "adas.xml": MANIFEST="adas.xml" ./migrate.sh --full --work_path ./bsp_23.1_adas --release_branch release/s32v_bsp23.1 Fetching "meta-vnp" requires using manifest "vnp.xml": MANIFEST="vnp.xml" ./migrate.sh --full --work_path ./bsp_22.0_vnp --release_branch release/bsp22.0 Use a custom name for the inner subdirectory "fsl-image-auto-bsp": override variable PROJECT_DIRNAME when running the script: PROJECT_DIRNAME="release" ./migrate.sh --full --work_path <path> --release_branch <branch> EXPERIMENTAL: postsync mode in this mode, the hypothesis is that the user already has all the repos cloned, and encountered the issue a while after they performed "repo sync" WARNING: ALL LOCAL REPO CHANGES SHOULD BE SAVED BEFORE STARTING IN THIS MODE!!! (e.g. via "git add" + "git commit" or other desired methods) how to use: ./migrate.sh --postsync --work_path ./testfolder ATTENTION: work_path expects a directory that contains the "fsl-image-auto-bsp" subdirectory inside. For example, if "fsl-image-auto-bsp" is inside "testfolder", we should launch the script from outside "testfolder" with the path relative to it. Also, if your "fsl-image-auto-bsp" directory is named otherwise, you should run the script "migrate.sh" with  rename it. This limitation will be addressed in the near future to facilitate other folder names as well. After running in postsync mode, you can resume by entering the bitbake shell and launching a build, as described in the previous section. Additionally, the help section of the script can be accessed via: ./migrate.sh --help   Workarounds There are some cases when additional manuals steps have to be performed after running the script "migrate.sh" and before running "bitbake" commands. These manual sets are requried due to some issues in some of the layers used by the Auto Linux BSP. Building images (via "bitbake") for QorIQ machines in some BSPs throw error: ERROR: No recipes in default available for: <recipe-full-path>.bbappend This happens because some .bbappend files were left is some layers after their base recipes have been removed from the product. Workaround in this case is to add to "conf/local.conf": BB_DANGLINGAPPENDS_WARNONLY = "1" Building images from layer "meta-vnp": There are issues in some recipes (with SRC_URI path or with installation file list) and there are two patches which need to be applied manually in this layer's root directory: "0001-meta-vnp-fix-azure-recipes.patch" and "0001-meta-vnp-fix-cmm-recipe-install.patch" (attached). Copy the two patches inside "meta-vnp" directory, open a shell in it, then run commands: git am 0001-meta-vnp-fix-azure-recipes.patch git am 0001-meta-vnp-fix-cmm-recipe-install.patch then run "nxp-setup-alb.sh" and/or "bitbake" commands as usual. Building images from "meta-adas": Running "migrate.sh" with manifest "adas.xml" normally does not require any workaround. However there are other SDKs which download the layer "meta-adas" and which are not the target of the script. In this case, one can manually apply the patch "0001-sm-drv-Update-SRC_URI-to-github.patch" (attached) to fix the fetch for the recipes in that layer. NOTE: If `git am <patch>` fails, the alternative is to use `patch`: patch --backup-if-mismatch -F 10 -u -p 1 -i <patch> Known Limitations Currently the script creates and uses the intermediate subdirectory which by default is named "fsl-image-auto-bsp".  

CHN L8 - S32G XRDC, by Danny(EN)/Peter(CHN) reference doc - AN13024: S32G2 Extended Resource Domain Controller (XRDC) – Application Note part 1 : XRDC Summary part 2 : XRDC MDAC part 3 : XRDC MRC and PAC part 4 : XRDC error handling part 5 : XRDC software enablement part 6 : XRDC wrap up questions

L10 - S32G2 FOTA demo instroduction, by Ross(EN)/Xuewei(CHN) ref info for this session: Uptane Specification – here AUTOSAR Update and Configuration Management - here AN12978 – S32G2 Support for Firmware Over-The-Air (FOTA) updates Airbiquity Video Demonstration – here   part 1 - FOTA recap part 2 - S32G2 FOTA demo quick view part 3 - S32G2 FOTA demo user guide walkthrough part 4 - S32G2 FOTA demo explained part 5 - S32G2 FOTA demo additional infomation part 6 - S32G2 FOTA demo live

S32G2 support guide (rev0.1, 070521) 1. If you have any technical issues encountered when using NXP S32G-VNP-RDB2 or S32G-VNP-GLDBOX, these can be discussed and covered on the S32G product forum. 2. You can also submit your ticket through the nxp.com website here 3. We also provide professional services and support as per cases beyond standard supports, please contact your NXP sales representative in your region for more options <The end>