Recently, several customers have reached out for support on using the PCA85073A Real-Time Clock (RTC) chip with the M core of NXP’s S32G2 processor. The S32G2 processor is highly regarded for its suitability in control and communication tasks across a variety of automotive applications, with its M core being especially adept at managing and controlling peripherals. The PCA85073A, provided by NXP Semiconductors, is an RTC chip featuring an I2C interface, designed for applications requiring precise timekeeping. This article provides a detailed introduction of how to use I2C communication on the M core of the S32G2 to perform effective data read and write operations for the PCA85073A. By following the steps provided in this d article, for users can view how to operate the PCA85073A device for the S32G2. Reference the attached PDF file for details.

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