Issue with "Suspend to RAM with GPIO as Wakeup Source" on S32G274A-RDB2

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Issue with "Suspend to RAM with GPIO as Wakeup Source" on S32G274A-RDB2

5,696 次查看
KavithaSasikumar
Contributor I

I’m trying to implement "Suspend to RAM with GPIO as Wakeup Source" on the S32G274A-RDB2 platform.

 Issues Encountered with Yocto Build:
 I tried editing the dtsi file directly in the Yocto project and then rebuilding the ARM Trusted Firmware.
 However, the build didn’t pick up the changes and seemed to be using the build cache instead.
 Is this because Yocto isn’t detecting the changes in the dtsi file? If so, how can I force a clean rebuild to reflect these changes?

Request for Guidance:
 How can I ensure the dtsi changes are correctly built into the final firmware?
 What could cause the boot process to fail with the modified dtb file?
 Are there additional resources or documentation for setting up Suspend to RAM with GPIO Wakeup on S32G274A-RDB2?

0 项奖励
回复
9 回复数

5,666 次查看
carlos_o
NXP TechSupport
NXP TechSupport

Hi @KavithaSasikumar

The IRQ being selected is the WKUP16, and the IOMUX sheet (attached inside the S32G2 RM) shows the following:

carlos_o_0-1735333403410.png

 PL_00 should be the pin selected for WKUP.

Also here is some documentation that you can review about this topic:

S32G: M kernel Standby demo and how to porting to Mcal

S32G M7 Standby Demo combined A53 Suspend to RAM Demo Setup Guide

S32G Linux Suspend to Ram and Customization

 

To ensure a clean build in yocto run the following commands.

# Delete sstate cache directory
$ rm -rf sstate-cache/

and 

# Delete tmp directory
$ rm -rf tmp/

after that you can do your clean build without problems. 

 

Can you share the output you get while trying to boot linux with the modified dtb?

I'm assuming that you are using BSP42 because you mentioned that user manual. Is that correct? 

Retry to do your build and share the output you get at the linux boot if it fails.

0 项奖励
回复

5,556 次查看
KavithaSasikumar
Contributor I

Issue with Rebuilding DTB After Removing sstate-cache

We were instructed to remove both the sstate-cache and tmp directories to rebuild the DTB. However, we noticed that the tmp directory contains the dtsi file, which we modified to build the updated dtb file. Therefore, we only removed the sstate-cache and proceeded with the rebuild.

Despite this, the DTB build date remains unchanged, suggesting that the build is still relying on cached data instead of regenerating from the modified dtsi file.

How can we ensure the DTB is rebuilt using the updated dtsi file without deleting the entire tmp directory?

 

0 项奖励
回复

5,536 次查看
carlos_o
NXP TechSupport
NXP TechSupport

Hi @KavithaSasikumar,

Did you clone the repository at the tmp directory?

It seems like that at the screenshots you share.

Try to clone it in another directory, clear the tmp folder and rebuild with your device tree changes.

0 项奖励
回复

5,509 次查看
KavithaSasikumar
Contributor I

Hi,

If we are building manually, we would have kept them in a separate directory. but this comes with tge build process. we don't have control over them.
if u check u can see that the linux kernal, uboot, arm trusted firmware are all residing inside the tmp directory. It seems to be automated.

0 项奖励
回复

5,470 次查看
carlos_o
NXP TechSupport
NXP TechSupport

Hi @KavithaSasikumar 

Can you share the build process you are following? This to have a better understanding of the issue. 

 

0 项奖励
回复

5,445 次查看
KavithaSasikumar
Contributor I

We followed the build process as outlined in the S32G2_LinuxBSP_42.0_User_Manual.pdf to regenerate the device tree blob (DTB) file. Below is a summary of the steps we took:

Host Preparation:
We initiated the process with the following command:

$ ./sources/meta-alb/scripts/host-prepare.sh

NXP Setup:
After preparing the host, we set up the environment for the S32G274ARDB2 platform with the following command:

$ source nxp-setup-alb.sh -m s32g274ardb2

Build Execution:
We then triggered the build using BitBake:

$ bitbake fsl-image-auto

The dtsi file was generated as part of the build process and can be found in the following directory:
./build_s32g274ardb2/tmp/work/s32g274ardb2-fsl-linux/arm-trusted-firmware/2.10-r0/git/fdts/s32cc.dtsi.

Following the instructions provided in the BSP42 manual (specifically on page 128), we made the necessary modifications to the s32cc.dtsi file. After making the changes, we proceeded to rebuild the project using the same commands mentioned above in order to regenerate the updated dtb file.

0 项奖励
回复

5,431 次查看
carlos_o
NXP TechSupport
NXP TechSupport

Hi @KavithaSasikumar

Delete the tmp directory and after that run 

$ source nxp-setup-alb.sh -m s32g274ardb2

After that put your changes at s32cc.dtsi

Once you have your modifications you can run 

$ bitbake fsl-image-auto

every time you run "source nxp-setup-alb.sh -m s32g274ardb2" it overwrites the s32cc.dtsi

0 项奖励
回复

5,364 次查看
KavithaSasikumar
Contributor I

Hi,

We followed the above process but the shortcomings we are facing are:

1. If we delete the tmp file...we cannot edit the s32cc.dtsi file since this .dtsi file is located in tmp.

KavithaSasikumar_0-1736491150159.png

2. Also, after adding the command suggested in the community forum         ".$ source nxp-setup-alb.sh -m s32g274ardb2" also,  there is no change.

KavithaSasikumar_1-1736491214537.png

So, kindly guide us further since its really critical for us to complete this STR process, by providing us with necessary reference or steps to follow.

Thank You.!

0 项奖励
回复

5,344 次查看
carlos_o
NXP TechSupport
NXP TechSupport

Hi @KavithaSasikumar 

Are you also updating the s32cc.dtsi at ./build_s32g274ardb2/tmp/work-shared/s32g274ardb2/kernel-source/arch/arm64/boot/dts/freescale/s32cc.dtsi? try updating both files. Another option can be updating the device tree alone with the manual compilation of the kernel instead of do it with yocto.

0 项奖励
回复