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

Hi,

I also tried pstore_blk, but that didn’t work either. At this point I’m wondering whether there might be an issue in the pstore core itself.

BartT

Hi Andy,

May I ask which build you are using for your testing?

I’m currently using Buildroot to build our kernel and root filesystem. I was considering switching to the Toradex Yocto build, but if that’s what you’re already using, I may not need to go down that path.

Kind regards,
Bart

@ToradexAI Can you confirm whether ramoops is operational on the Verdin iMX8MP? Is there a known-good setup that anyone at Toradex has tested on this platform?

Also, can you confirm whether the DDR is preserved across a reboot (i.e. a soft reboot) on the Verdin iMX8MP?

I’m concerned that the DDR may be reset by hardware (for example, by the PMIC), which would prevent ramoops from working correctly.

Kind regards,

BartT

Based on the information available in the Toradex documentation, I cannot confirm specific ramoops testing or known-good configurations for the Verdin iMX8M Plus platform. The official documentation doesn’t contain specific ramoops implementation details or memory preservation behavior across soft reboots for this module (1).

Power Management and Reset Behavior

Looking at the Verdin iMX8M Plus V1.1 datasheet, the module includes several power management and reset control signals (2):

  • CTRL_RESET_MOCI#: Reset output for carrier board peripherals derived from the SoC reset on the module (2)
  • CTRL_PWR_BTN_MICO#: Controls module power states - long pull-down shuts down the module, short pull-down turns on module from off state (2)
  • CTRL_FORCE_OFF_MOCI#: Output for forcing the turning-off of the main power rail (2)

The datasheet notes that “during and after a sleep state, the CTRL_RESET_MOCI# does not get asserted” (2), which suggests different reset behaviors depending on the type of reset/reboot initiated.

Memory Architecture

The Verdin iMX8M Plus features different memory configurations depending on the variant (3):

  • DDR4 RAM ranging from 1GB to 8GB depending on the specific model (1)
  • The SoC includes various cache levels and memory management features (3)

Recommendations for Further Investigation

Since you’re using a custom BuildRoot setup rather than Toradex’s supported Linux distributions (Torizon OS or Yocto BSP), this may be contributing to the issue. The supported Toradex software platforms are:

  • Torizon OS - industrial Linux operating system with containerization (1)
  • Yocto Project Reference Images - reference images for custom Linux builds (1)

For definitive answers about DDR preservation across reboots and ramoops functionality, I’d recommend checking with NXP’s documentation for the i.MX8M Plus SoC, as this behavior is typically determined at the SoC and boot loader level rather than the module level.

You may also want to examine the U-Boot source code and SPL (Secondary Program Loader) initialization sequences, as Andy mentioned, since DDR initialization during boot could indeed be clearing the memory regions you’re trying to preserve.

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 BartT,

After long time I found a working solution. I had to touch 3 components (U-Boot, Kernel and ATF) to make it really working.

  • u-boot (DTB)
    •  &wdog1 {
      -	 fsl,ext-reset-output;
      +	 // fsl,ext-reset-output;
      	 pinctrl-names = "default";
      	 pinctrl-0 = <&pinctrl_wdog>;
      	 status = "okay";
      
  • kernel (DTB)
    • same change as in the u-boot +
    • / {
      	reserved-memory {
      		#address-cells = <2>;
      		#size-cells = <2>;
      		ranges;
      ...
      
  • ATF (platform_def.h)
    • - #define IMX_WDOG_B_RESET
      + // #define IMX_WDOG_B_RESET
      

Now the WARM boot should be used and pstore ramoops content will survive reboot.

BR,
Andy

Hi Andy,

Thanks for the update—glad to hear you got it working.

Unfortunately, it didn’t work for me, so my quest continues.

Regards,
BartT

Hi,

I got it fixed as well. The root cause was already mentioned by Toradex :wink: : “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.

I had to choose a memory inside the physical ram (System RAM) that was not reserved!

This device-tree snip made it work:

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

	ramoops_region: ramoops@0x41c00000 {
		compatible = "ramoops";
		reg = <0 0x41c00000 0 0x00100000>; /* 1MB */
		record-size  = <0x8000>;  /* 32 KB per record */
		console-size = <0x8000>;  /* 32 KB for printk console */
		ftrace-size  = <0x8000>;  /* 32 KB for ftrace */
		pmsg-size    = <0x8000>;  /* 32 KB */
		ecc = <0>;                 /* normally ECC is off */
		no-map;
	};
};	 

Regards,

BartT

Great to hear, that it works :slight_smile: . But was just the setting in DTB needed, or you have to do my steps as well? Because if not, that it doesn’t matter what you change in DTB if PMIC/WDT will do a COLD boot. Or am I wrong?

BR,
Andy

Hi Andy,

Your steps where indeed needed to get working. Just want to point to the fact that pstore RAM region is important as well ;).

Thanks again.

BartT

1 Like