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
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:
However please feel free to use this article for reference as well as for comments.
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:
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:
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>
Currently the script creates and uses the intermediate subdirectory which by default is named "fsl-image-auto-bsp".