S32Gのトピックs32g3 kernel configuration item clarification.

s32g3 kernel configuration item clarification.

acarmina — Fri, 17 Oct 2025 07:56:52 GMT

During the process of enabling the S32G3 in our Linux environment, I encountered the following configuration within the BSP:

CONFIG_CMA_SIZE_MBYTES=256

I noticed that if this option is not specified, the system fails to boot.

I investigated the issue and found that no code appears to be utilizing the Contiguous Memory Allocator (CMA) subsystem. However, the system still fails to boot without the option set.

Upon further investigation, I surmised that the CMA configuration itself might not be the critical factor, but rather that the kernel is attempting to use the 256MB memory region starting at 0xf0000000. I was able to successfully run the kernel by explicitly reserving this memory region in the Device Tree with the following entry:

DummyUnknown: memory@f0000000 {
        compatible = "reserved-memory";
        reg = <0x0 0xf0000000 0x0 0x010000000>;
        no-map;
};

While this allows me to proceed without knowing the precise cause, I noted that when using the BSP firmware (ATF + U-Boot) with EFIBOOT, the kernel again fails to boot. Looking at U-Boot's memory usage, I discovered that EFI variables and SMI data are situated in this region at 0xfa000000, which leads me to believe this is one of the reasons for the unsuccessful boot.

By trying to restrict the reservation, I was able to narrow the required memory area to a 16MB region starting at 0xfb000000, which also allows the kernel to run successfully in EFI mode.

I've conducted various experiments on this area and established that its relevance is only during early boot, where failing to reserve it leads to a silent kernel hang. Before or after the kernel has fully started, the area can be overwritten by any data without visible consequences.

I have analyzed both the ATF and U-Boot BSP codebases without finding any explicit reference to this critical area.

Since my use case is aimed at the functional safety domain, and the underlying reasons behind this malfunction are not yet fully understood, I am requesting clarification on the original CONFIG_CMA_SIZE_MBYTES=256 statement in the kernel configuration and how it relates to my findings.

Re: s32g3 kernel configuration item clarification.

Joey_z — Fri, 17 Oct 2025 13:48:03 GMT

hi,acarmina

Thank you for contacting us and the information.

Which the version of BSP are you using?

Joey

Re: s32g3 kernel configuration item clarification.

acarmina — Fri, 17 Oct 2025 16:20:47 GMT

the current firmware is bsp41, (atf+u-boot).
i'm trying to switch to the bsp44, but I'm having troubles since the bl2 to the bl31 hangs on the eret, when it run the new imagenot sure why, currently under investigation.
```
NOTICE: Reset status: Power-On Reset
INFO:    Switch to 50 MHz SD frequency (High Speed Mode)
INFO:    BL2: FIP offset = 0x100000
NOTICE: BL2: v2.10.14(debug):bsp44.0-2.10.14
NOTICE: BL2: Built : 11:58:50, Oct 17 2025
INFO:    BL2: Loading image id 39
VERBOSE: FIP header looks OK.
INFO:    Loading image id=39 at address 0x343ec000
INFO:    Image id=39 loaded: 0x343ec000 - 0x343fe570
INFO:    BL2: Loading image id 3
VERBOSE: FIP header looks OK.
INFO:    Loading image id=3 at address 0xff600000
INFO:    Image id=3 loaded: 0xff600000 - 0xff647065
INFO:    BL2: Loading image id 5
VERBOSE: FIP header looks OK.
INFO:    Loading image id=5 at address 0xff8a0000
INFO:    Image id=5 loaded: 0xff8a0000 - 0xff970168
NOTICE: BL2: Booting BL31
INFO:    Entry point address = 0xff600000
INFO:    SPSR = 0x3cd
VERBOSE: Argument #0 = 0x34339418
VERBOSE: Argument #1 = 0x0
VERBOSE: Argument #2 = 0x0
VERBOSE: Argument #3 = 0x0
VERBOSE: Argument #4 = 0x0
VERBOSE: Argument #5 = 0x0
VERBOSE: Argument #6 = 0x0
VERBOSE: Argument #7 = 0x0
```

Re: s32g3 kernel configuration item clarification.

Joey_z — Mon, 20 Oct 2025 02:38:11 GMT

hi,acarmina

Thank you for your reply.

The kernel allows the creation of default CMA through Kconfig, kernel parameters, and DT. Once created successfully, a chunk of contiguous physical memory will be reserved and not participate in the general allocation, thereby avoiding early stampedes.
Under your EFI path, the EFI subsystem of U-Boot places EFI variables /SMI and other structures in the 0xFA000000 area. If Linux considers this piece available without seeing any reserved tags, it may overwrite these structures, leading to an early silent freeze.

Joey