LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from DT.

[muslum11]

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:

• SoC: LS1046A
• DDR: IS43/46QR16512A (4 GB DDR4)
• Boot media: SD Card
• BSP: FlexBuild (LSDK 25.12)

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

• Start: 0x80000000
• Size : 0x7be00000

DRAM bank 1

• Start: 0x880000000
• Size : 0x80000000

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.

[Bio_TICFSL]

Hello,

Root Cause — BL31 Memory Collision

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.

---

Fix — Reserve BL31 Memory in the Device Tree

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.

Step 1: Find where BL31 is loaded

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 = ....

Step 2: Add the reserved-memory node to your DTS

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;
        };
    };
};

dts

Adjust 0x8ff600000 and size 0x200000 to match your actual BL31 load address from the ATF build.

Step 3: Rebuild and test with full memory

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

---

[muslum11]

Hello,

I tried the suggested solution, but unfortunately it did not resolve the issue.

First, I verified the BL31 address from the TF-A (ATF) build:

- BL31_BASE = 0xFBE00000
- BL31_SIZE = 0x200000 (2 MiB)

Next, I added a "reserved-memory" node to the Device Tree to reserve the BL31 runtime region and rebuilt the DTB.

After that, I booted the system again without the "mem=1982M" boot parameter. However, the system still hangs at the same point.