imx8mp U-boot ramoops memory

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

imx8mp U-boot ramoops memory

Jump to solution
1,061 Views
andrej_valek
Contributor V

Dear support!

What I wanted to achieve is to get the persistent memory which could be used for ramoops storage. So I did some testing in U-boot, but each of the memory address which I used was "scrambled" after reset. I tried reset or reset -w commands, but nothing helped. Here is the example of my test:

u-boot=> mw 55100000 10
u-boot=> md 55100000
55100000: 00000010 ffffffff ffffffff ffffffff ................
55100010: ffffffff ffffffff ffffffff ffffffff ................
...
u-boot=> reset
resetting ...
U-Boot SPL 2024.04-4fa57eaf6dd (Feb 19 2026 - 12:49:01 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0: RNG instantiated
Normal Boot
Trying to boot from BOOTROM
Boot Stage: Primary boot Find img info 0x48025a00, size 888
Need continue download 1024
NOTICE: Do not release JR0 to NS as it can be used by HAB
NOTICE: BL31: v2.10.0 (release):android-14.0.0_2.2.0-rc2-0-g7c64d4e86
NOTICE: BL31: Built : 10:35:32, Aug 29 2024

U-Boot 2024.04-4fa57eaf6dd (Feb 19 2026 - 12:49:01 +0000)
CPU: i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 60C
Reset cause: POR
DRAM: 4 GiB
...
u-boot=> md 55100000
55100000: ffffffff ffffffff ffffffff ffffffff ................
55100010: ffffffff ffffffff ffffffff ffffffff ................
...

Who/where the memory "scrambled" then? ATF, SPL, PMIC or? Which address could be used? Is it even possible to do it on imx8mp machine?

Many thanks,
Andy

Tags (4)
0 Kudos
Reply
1 Solution
577 Views
andrej_valek
Contributor V

Ok, will answer it by myself.

Three components (U-Boot, Kernel and ATF) have to touched to make it really working.

  • U-boot + Kernel (DTB)
 &wdog1 {
-	 fsl,ext-reset-output;
+	 // fsl,ext-reset-output;
	 pinctrl-names = "default";
	 pinctrl-0 = <&pinctrl_wdog>;
	 status = "okay";
  • ATF (platform_def.h) 
- #define IMX_WDOG_B_RESET
+ // #define IMX_WDOG_B_RESET

After that, ramoops should survive the reboot.

BR,
Andy

View solution in original post

0 Kudos
Reply
5 Replies
578 Views
andrej_valek
Contributor V

Ok, will answer it by myself.

Three components (U-Boot, Kernel and ATF) have to touched to make it really working.

  • U-boot + Kernel (DTB)
 &wdog1 {
-	 fsl,ext-reset-output;
+	 // fsl,ext-reset-output;
	 pinctrl-names = "default";
	 pinctrl-0 = <&pinctrl_wdog>;
	 status = "okay";
  • ATF (platform_def.h) 
- #define IMX_WDOG_B_RESET
+ // #define IMX_WDOG_B_RESET

After that, ramoops should survive the reboot.

BR,
Andy

0 Kudos
Reply
1,042 Views
Oswalag
NXP TechSupport
NXP TechSupport

Hello,

Did you add the .dts node for that? please refer to the following example of implementation:  

https://embear.ch/posts/using-ramoops/ 

0 Kudos
Reply
1,023 Views
andrej_valek
Contributor V

Hello,

Sure, I started with using it with correct way via DTB in Linux. But when I rebooted the board, nothing has been written into this section. So I was thinking someone has to "scramble" the memory. So I moved one level down into U-boot. There I also tried to define the "reserved-memory", but it didn't help. As I said, I tried multiple memory addresses (55110000, 944400000, ...) based on:

3d800000-3dbfffff : 3d800000.ddr-pmu ddr-pmu@3d800000
40000000-54ffffff : System RAM
  48210000-4975ffff : Kernel code
  49760000-49adffff : reserved
  49ae0000-49d1ffff : Kernel data
  4ffed000-4fffcfff : reserved
55000000-5510ffff : reserved
55110000-553fffff : System RAM
55400000-554fffff : reserved
55500000-7fffffff : System RAM
80000000-80ffffff : reserved
81000000-923fffff : System RAM
92400000-943fffff : reserved
94400000-ffffffff : System RAM
  c0000000-ffffffff : reserved
100000000-10fffffff : reserved
  100000000-10fffffff : gcContMem
110000000-13fffffff : System RAM
  13b0ec000-13f7fffff : reserved
  13f827000-13f827fff : reserved
  13f82a000-13f82cfff : reserved
  13f82d000-13f841fff : reserved
  13f842000-13f88ffff : reserved
  13f890000-13fffffff : reserved
reserved-memory {
	#address-cells = <2>;
	#size-cells = <2>;
	ranges;

	ramoops: ramoops@94400000 {
		compatible = "ramoops";
		reg = <0 0x94400000 0 0x00100000>; // 1MB at 0x94400000
		record-size = <0x10000>; // 64kB per record
		console-size = <0x10000>; // 64kB for console
		ftrace-size = <0x40000>; // 256kB for ftrace output
		pmsg-size = <0x10000>; // 64kB for user messages
	};
};

I would say the problem has to be somewhere deeper, that the memory is reset, maybe PMIC? If yes, where/how to configure it to not do a DRAM power cycle.

BR,
Andy

0 Kudos
Reply
971 Views
Oswalag
NXP TechSupport
NXP TechSupport

Hello,

 

I understand, unfortunately ramoops is not implemented in our BSP, toradex did it so it would be better if you ask them for the implementation on their BSP.  

0 Kudos
Reply
948 Views
andrej_valek
Contributor V

Hello,

not sure if this a Toradex' related problem, while it could be somewhere in ATF or... which is a NXP part. On the other hand someone else was asking the same there https://community.toradex.com/t/pstore-and-ramoops-on-verdin-imx8mp-and-ivy-dev-board/29567/6 but no response... . Do you know where they did it then?

Thanks,
Andy

0 Kudos
Reply