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>