Hello,
I am working on a custom board based on the LS1046A and I am experiencing a boot issue with a Debian image generated using FlexBuild.
As a first step, I built the default LS1046AFRWY BSP without making any modifications and tested it on my custom board. During kernel boot, the system always hangs after printing:
psci: probing for conduit method from DT.
There is no kernel panic or exception; the system simply stops at this point.
I found the following NXP forum thread describing a very similar issue:
https://community.nxp.com/t5/Layerscape/LS1043A-RDB-Linux-Hangs-At-PSCI/td-p/750075
As a temporary workaround, I can boot Linux manually from U-Boot using the following commands. However, the kernel only boots successfully when I limit the available memory to 1982 MB using the "mem=" boot argument. If I increase this value, the kernel hangs again (sometimes at different points during boot).
mmc dev 0
part uuid mmc 0:3 partuuidr
load mmc 0:1 0x81000000 Image
load mmc 0:1 0x90000000 fsl-ls1046a-frwy-sdk.dtb
setenv bootargs "console=ttyS0,115200 earlycon=uart8250,mmio,0x21c0500 root=PARTUUID=${partuuidr} rw rootwait mem=1982M"
booti 0x81000000 - 0x90000000
Test environment:
To rule out a FlexBuild-specific issue, I also built a completely new BSP using Yocto (YP 6.0 / lf-6.18.20) and tested it on the same hardware.
The result is exactly the same. The kernel again hangs after printing:
psci: probing for conduit method from DT.
The relevant part of the bdinfo output is shown below:
DRAM bank 0
DRAM bank 1
LMB memory regions:
memory[0] : 0x80000000 - 0xfbdfffff
memory[1] : 0x880000000 - 0x8ffffffff
reserved[0] : 0xfac154c0 - 0xfbdfffff
reserved[1] : 0x8ffff5000 - 0x8ffffffff
Has anyone encountered a similar issue or have any suggestions on what I should investigate next?
Any advice would be greatly appreciated.
Hello,
The LS1046A boot flow is:
Boot ROM → BL2 (DDR Init) → BL31 (stays resident in DRAM) → U-Boot → Linux
BL31 remains permanently resident in DRAM and handles all SMC calls (PSCI: psci_get_version, CPU on/off, etc.). Its typical placement is near top-of-RAM minus ~10 MiB, with a size of up to 2 MiB.
When Linux boots with the full 4 GB DDR map, it allocates pages that physically overlap BL31's region. The first PSCI SMC call (psci_get_version) jumps into now-corrupted memory and the system hangs — with no panic, no exception, just silence.
Your bdinfo output confirms the exact pattern — DDR Bank 1 ends at 0x8FFFFFFFF, and BL31 is at approximately RAM_END - 10 MiB = 0x8FF600000:
| DDR Bank | Start | End | Notes |
|---|---|---|---|
| Bank 0 | 0x80000000 |
0xFBDFFFFF |
~1982 MiB — your working mem= limit |
| Bank 1 | 0x880000000 |
0x8FFFFFFFF |
2 GB high bank — BL31 lives here |
The mem=1982M workaround keeps Linux within Bank 0, never touching Bank 1 where BL31 resides — which is precisely why it works.
The correct permanent fix is to add a reserved-memory node to your DTS marking BL31's region as off-limits to the Linux memory allocator.
Check your ATF build configuration (plat/nxp/soc-ls1046a/.../platform_def.h) for BL31_BASE and BL31_SIZE. For LSDK/lf-6.x with the FRWY BSP, the typical placement is:
BL31_BASE = 0x8FF80000 (top of high DDR bank minus ~512 KB to 2 MB)
BL31_SIZE = max 2 MiB
You can confirm at runtime by checking U-Boot output or the ATF build log for BL31: v2.x... Entry point address = ....
In your board DTS file (based on fsl-ls1046a-frwy-sdk.dts), add:
/ {
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
/* Reserve BL31 runtime region — adjust addresses to match your ATF build */
bl31_reserved: bl31@8ff600000 {
reg = <0x8 0xff600000 0x0 0x00200000>; /* 2 MiB at RAM_END - 10 MiB */
no-map;
};
};
};
Adjust
0x8ff600000and size0x200000to match your actual BL31 load address from the ATF build.
After adding the reservation, rebuild the DTB and boot without the mem= workaround. The kernel will skip that region, BL31 remains intact, and PSCI will function correctly.
Regards