Pstore and ramoops on Verdin iMX8MP and ivy dev board

Hi,

I have enabled PSTORE in the Linux kernel and configured it to use RAM. I also enabled tracing with CONFIG_FTRACE=y. Next, I added the following section to our device tree:

reserved-memory {
	#address-cells = <2>;
	#size-cells = <2>;
	ranges;

	ramoops_region: ramoops@0x50000000 {
		compatible = "ramoops";
		reg = <0 0x50000000 0 0x00200000>; /* 2MB */
		record-size  = <0x20000>;   /* 128 KB per record */
		console-size = <0x40000>;  /* 256 KB for printk console */
		ftrace-size  = <0x40000>;   /* 256 KB for ftrace */
		pmsg-size    = <0x20000>;   /* 128 KB */
		ecc = <0>;                  /* ECC normally disabled */
		no-map;
	};
};

When I write a message to /dev/pmsg0, or when I trigger a crash using
echo c > /proc/sysrq-trigger, I don’t see anything appear in the directory where I mounted pstorefs (mount -t pstore pstore /sys/fs/pstore).

I’m wondering whether the physical address given for the ramoops region is correct, or whether I’m missing a configuration step.

Are there any instructions or recommendations for enabling pstore so the kernel log is preserved after a soft reboot?

Regards,
Bart T.

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


PSTORE/Ramoops Configuration for Toradex Modules

Your PSTORE configuration looks mostly correct, but there are a few key areas to verify. Let me walk you through the proper setup based on Toradex documentation.

1. Kernel Configuration Verification

First, ensure you have all the necessary kernel configurations enabled(1):

$ zcat /proc/config.gz |grep PSTORE
CONFIG_PSTORE=y
CONFIG_PSTORE_ZLIB_COMPRESS=y
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_PMSG=y
CONFIG_PSTORE_RAM=y

(1)

2. Memory Address Selection

The most critical aspect is selecting the correct physical memory address. You need to determine available memory space that won’t conflict with the kernel(1).

To check your system’s memory layout, run:

$ cat /proc/iomem

(1)

Look for the System RAM range and choose an address outside of the Kernel code and Kernel data regions(1). In the Toradex example, they used 0x30000000 for a 1MB region on an Apalis iMX6(1).

3. Device Tree Configuration

Your device tree configuration should be added to the appropriate location. For example, in arch/arm/boot/dts/imx6q.dtsi under the reserved-memory node(1):

reserved-memory {
    #address-cells = <2>;
    #size-cells = <2>;
    ranges;
    
    ramoops_region: ramoops@30000000 {
        compatible = "ramoops";
        reg = <0 0x30000000 0 0x100000>; /* 1MB */
        record-size = <0x20000>;
        console-size = <0x20000>;
        ftrace-size = <0x20000>;
        pmsg-size = <0x20000>;
        ecc = <0>;
        no-map;
    };
};

(1)

4. Verification Steps

After booting with your updated kernel and device tree, verify that ramoops is properly initialized:

$ dmesg | grep ramoops

(1)

You should see output similar to:

[ 0.071682] pstore: Registered ramoops as persistent store backend
[ 0.071707] ramoops: attached 0x100000@0x30000000, ecc: 0/0

(1)

5. Testing the Configuration

To test your setup:

  1. Set the system to reboot after kernel panic(1):
$ echo 1 > /proc/sys/kernel/panic

(1)

  1. Trigger a kernel panic(1):
$ echo c > /proc/sysrq-trigger

(1)

  1. After reboot, mount pstore and check for logs(1):
$ mkdir -p /home/root/pstore
$ mount -t pstore pstore /home/root/pstore
$ ls pstore/

(1)

Troubleshooting Tips

  • Address conflicts: Ensure your chosen memory address doesn’t conflict with existing memory mappings
  • Size alignment: Make sure your record sizes add up correctly within the total allocated space
  • Cold boot limitation: Remember that ramoops data is lost during power cycles, only preserved during soft reboots(1)

The key issue in your setup might be the memory address 0x50000000. Verify this address is available and doesn’t conflict with your system’s memory layout by checking /proc/iomem first.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Hi,

I assumed the address had to be in the system RAM region - which is “40000000-7fffffff : System RAM”. I changed it outside that region now (0x90000000), but still not OK.

Verifying the ramoops showed that it is being setup - some snippets from the kernel log:

[ 0.000000] OF: reserved mem: 0x0000000000900000..0x000000000096ffff (448 KiB) nomap non-reusable ocram@900000
[ 0.000000] OF: reserved mem: 0x0000000090000000..0x00000000901fffff (2048 KiB) nomap non-reusable ramoops@0x90000000
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.037372] printk: console [ramoops-1] enabled
[ 0.037927] pstore: Registered ramoops as persistent store backend
[ 0.037945] ramoops: using 0x200000@0x90000000, ecc: 0
[ 0.077075] Unpacking initramfs…

Regards,

Any idea’s?

I’d be glad to help! Could you let me know which OS and version you are using?

To provide the most accurate guidance for your PSTORE/ramoops configuration, I need to understand your specific setup. Could you please run the tdx-info command on your device and share the output? This will help me identify your exact hardware platform and OS version.

You can find more information about the tdx-info command at: Getting Device Information with Tdx-Info | Toradex Developer Center

The troubleshooting steps can vary significantly depending on whether you’re using:

  • SoM: Verdin i.MX8M Plus, Verdin AM62, Aquila AM69, Apalis i.MX8QP, Colibri i.MX8X, etc.
  • OS: Yocto 7.2.0, Torizon 6.8.2, Torizon OS 6, BSP 7, BSP 6, etc.
  • Carrier board: Ivy Carrier Board, Ixora Carrier Board, Mallow Carrier Board, Development Board, Custom Carrier Board, etc.

Once I know your specific platform, I can provide targeted guidance for your PSTORE configuration and help identify why the ramoops files aren’t appearing in /sys/fs/pstore despite the successful initialization you’re seeing in the kernel log.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Hi,

I’m using iMX8M Plus: Freescale i.MX8MP Lite[4] rev1.1 1600 MHz (running at 1200 MHz) - the Toradex Verdin iMX8M Plus Lite on a Ivy dev board.

The OS/distribution is custom build, created with BuildRoot. The kernel is: Linux imx8 6.6.101 #3 SMP PREEMPT Thu Dec 4 13:45:45 CET 2025 aarch64 GNU/Linux.

The tdx-info is unfortunately not available.

Regards,

BartT

Hello,

Was you successful here? I would say the ramoops is not working in imx8mp. I tried to write something directly via u-boot like:

u-boot=> mw.l 0x00900000 0xdeadbeef 4
u-boot=> md 0x00900000 0x10
00900000: deadbeef deadbeef deadbeef deadbeef …
00900010: 00000000 00000000 00000000 00000000 …
00900020: 00000000 00000000 00000000 00000000 …
00900030: 00000000 00000000 00000000 00000000 …
u-boot=> reset resetting …

When read the data back after reset, they have been gone. I tried different addresses like 55100000 and so on. So I would say, u-boot is initializing the DDR memory with zero-s or something like that in SPL. So maybe the only possible solution is to use CONFIG_PSTORE_BLK.

Can someone confirm my statement?

Thank you,
Andy

Hi Andy,

Nope, not successful. Still on the to-do list.

Good point though, checking the ram values in uboot. That indeed proves pstore to ram cannot work. Question is, is the ram cleared by uboot (spl) or by hardware at a reboot?

I believe the are no sources available for the SPL, right?

Bart

Hello Bartt,

As I can remember it was working fie on imx8qm, but not for mp. My feeling is that it has to be screwed-up during SPL where the RAM content is loaded.

No at all. Some stuff is available already as it’s a part of u-boot. What’s missing are the SPL parts for DDR. It just loads some .bin files.

Someone (probably from NXP) has to confirm if it’s doable or not at all for this machine.

BR,
Andy