just share a information that new atf was released, and you can base on it to enable pstore/ramoops in both uboot and openwrt environment.
arm-trusted-firmware-mediatek: update to git HEAD
uboot-mediaktek: add support for PSTORE and check it on boot
thanks for the information
what is pstore/ramoops for?
i see mt7622-support is now splitted into multiple commits, is it already upstream?
ramoops is used to store crash log to dram before system reboot, and then user can dump log in uboot/linux in 2nd boot. if you have already used mtk atf from https://github.com/mtk-openwrt/arm-trusted-firmware.git and 2021.04 uboot. you can simply enable it in uboot/openwrt menuconfig, thanks.
File systems --> Miscellaneous filesystems
<*> Persistent store support
< > DEFLATE (ZLIB) compression
< > LZO compression (NEW)
< > LZ4 compression (NEW)
< > LZ4HC compression (NEW)
[ ] 842 compression (NEW)
[ ] zstd compression (NEW)
[*] Log kernel console messages
[*] Log user space messages
<*> Log panic/oops to a RAM buffer
Command line interface --> Misc commands
[*] pstore
(0x42ff0000) Memory Address
(0x10000) Memory size
(0x1000) Dump record size (NEW)
(0x1000) Kernel console log size (NEW)
(0x1000) FTrace log size (NEW)
(0x1000) User space message log size (NEW)
(0) ECC size (NEW)This looks useful… Can this be used with Debian, too?
Sure, this is a generic Linux feature, all needed is to set it up in device tree and make sure the bootchain doesn’t corrupt the RAM (ie. if you use recent enough ARM Trusted Firmware based bootchain it works). I guess @frank-w has made the changes needed for that for the SD card image for Debian as well, so it should just work. Try
echo c > /proc/sysrq-trigger
After the reboot you should see the previous kernel log in /sys/fs/pstore/.
I have not added pstore related changes. If you point me to needed changes i can add them
@moore summarized it in [bpi-r64] support pstore/ramoops
Let me explain the details:
- You need to use ARM Trusted Firmware DDR initialization blob which was updated to support keeping DRAM content:
- It’s nice to have some PSTORE support in U-Boot as well (but it’s not strictly needed for it to work in Linux, as long as you take care not to overwrite the RAM content in the area used for PSTORE (e.g. by just adding
reservedmemory node in DTS):
- Last but not least, add
ramoopsnode to DTS used by Linux (U-Boot will also do that for you if it has PSTORE support, however, for some boards with MT7622 supported by OpenWrt we use the vendor loader and hence cannot rely in U-Boot features to be present):
1 Like
Oh, just realized this thread is about the R64… I only have a R2. Big sad face here…
Maybe it is possible with r2 too,but we have no preloader source and currently no information about it on mt7623
edit: added now pstore to u-boot and linux 5.17
build uboot and used it in my ATF branch mtksoc which is basicly on same state as the one you’ve mentioned
@dangowrt: tried to use it, but bl2 brings some strange errors and does not find fip-partition
NOTICE: BL2: v2.4(release):v2.4-415-g7a2fc1857bde-dirty
NOTICE: BL2: Built : 12:38:35, Jan 30 2022
ERROR: Cannot find any pass-window
ERROR: no DATLAT taps pass, DATLAT calibration fail!
ERROR: DATLAT calibration fail, write back to 20!
ERROR: EMI: Failed to detect rank size
ERROR: EMI: complex R/W mem test failed: -2
ERROR: Partition 'fip' not found
PANIC at PC : 0x000000000020478c
i remembered that i tried the mtksoc branch and it was not bootable so left the older tree as default
maybe @moore has an idea too?
The error looks like you forgot to set DDR3_FLYBY=1 to include the correct DDR calibration binary for boards with 2 RAM chips (and hence fly-by).
at least no error, but bl31 now hangs at
NOTICE: BL2: v2.4(release):v2.4-416-g64e90e1a9628-dirty
NOTICE: BL2: Built : 13:45:46, Jan 30 2022
NOTICE: BL2: Booting BL31
NOTICE: BL31: v2.4(release):v2.4-416-g64e90e1a9628-dirty
NOTICE: BL31: Built : 13:45:48, Jan 30 2022
Is there anything special in uboot bootup?
i used u-boot.bin i build here: https://github.com/frank-w/u-boot/commits/2022-01-bpi This is how i build fip: https://github.com/frank-w/BPI-R64-ATF/blob/mtksoc/build.sh#L48
Maybe i can use a binary build by atf in uboot like i do for r2pro. There uboot fip is build with atf binaries. For r64 i need to copy uboot.bin to atf repo and build the resulting binary there (checked filesize of the fip.bin…it is 654kbyte, so uboot seems to be still included)
btw. patch in uboot cause this
arch/arm/dts/mt7622-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7622-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
DTC arch/arm/dts/mt7629-rfb.dtb
DTC arch/arm/dts/mt8183-pumpkin.dtb
arch/arm/dts/mt7622-bananapi-bpi-r64.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7622-bananapi-bpi-r64.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
i changed the address/size-cells to 1 each and the warning is gone
Kernel patch had a 0x too much which caused a warning
Edit: seems build-order has changed: openwrt includes atf in uboot now instead of atf including u-boot.bin. this is better as atf does not change so oftens as uboot.
Have not found the fiptool,but i guess it’s a binary…i want to avoid it if possible and try building uboot with bl31 like for r2pro
Hope this way works for r64 too (without bl32 and mkimage).
if including the blx into uboot i used the bl31.elf for r2pro, this file is for r64 500k in size, is this right? do i need any config-option in uboot for including the bl31? found none for r2pro, only for spl, we don’t need for r64, right? only CONFIG_FIT is maybe needed
edit: tried to include bl31 and build u-boot.itb
ln -sf files/bpi-r64/bl31.elf bl31.elf #the file from bl31 folder
make ${CFLAGS} u-boot.itb
sudo dd of=/dev/sdb if=u-boot.itb bs=512 seek=2048
but i get now:
NOTICE: BL2: v2.4(release):v2.4-416-g64e90e1a9628-dirty
NOTICE: BL2: Built : 13:45:46, Jan 30 2022
ERROR: BL2: Failed to load image id 3 (-2)
Maybe @moore or @hackpascal can help
You could try to raise log level, maybe you get more info:
PLAT=mt7622 DDR3_FLYBY=1 LOG_LEVEL=40
got it…i accidentally built a 32bit uboot-binary for r64 (had forgotten to enable the arch=arm64 in build.conf)
but i see this error in uboot (seems to come from my env loading which loads to loadaddr=0x44000000):
ERROR: reserving fdt memory region failed (addr=0 size=43000000 flags=4)
maybe because uboot tries to allocate memory in region already blocked by kernel fdt?
and on running this:
echo c > /proc/sysrq-trigger
i get a stacktrace:
root@bpi-r64:~# echo c > /proc/sysrq-trigger
[ 236.402700] sysrq: Trigger a crash
[ 236.406121] Kernel panic - not syncing: sysrq triggered crash
[ 236.411863] CPU: 0 PID: 298 Comm: bash Tainted: G S 5.17.0-rc1-bpi-r64-r64 #1
[ 236.420298] Hardware name: Bananapi BPI-R64 (DT)
[ 236.424910] Call trace:
[ 236.427350] dump_backtrace+0xe0/0x114
[ 236.431105] show_stack+0x18/0x64
[ 236.434419] dump_stack_lvl+0x68/0x84
[ 236.438081] dump_stack+0x18/0x34
[ 236.441393] panic+0x130/0x2e8
[ 236.444445] sysrq_reset_seq_param_set+0x0/0x94
[ 236.448977] __handle_sysrq+0xc0/0x174
[ 236.452724] write_sysrq_trigger+0x9c/0xf8
[ 236.456819] proc_reg_write+0x8c/0xa4
[ 236.460479] vfs_write+0x90/0x108
[ 236.463792] ksys_write+0x70/0xdc
[ 236.467105] __arm64_sys_write+0x18/0x24
[ 236.471024] invoke_syscall+0x6c/0xf8
[ 236.474685] el0_svc_common.constprop.0+0xb0/0xdc
[ 236.479387] do_el0_svc+0x44/0x74
[ 236.482700] el0_svc+0x20/0x4c
[ 236.485752] el0t_64_sync_handler+0xcc/0x154
[ 236.490018] el0t_64_sync+0x1a0/0x1a4
[ 236.493679] SMP: stopping secondary CPUs
[ 236.497607] Kernel Offset: disabled
[ 236.501088] CPU features: 0x0,00006002,00000842
[ 236.505613] Memory Limit: none
[ 236.508663] ---[ end Kernel panic - not syncing: sysrq triggered crash ]---
source: u-boot and linux 5.17
based on dts change i guess i need the CONFIG_ARM_PSCI_CPUIDLE_DOMAIN in kernel, right (currently set to “n”)?
but still the crash…
root@bpi-r64:~# zgrep 'PSTORE' /proc/config.gz
CONFIG_PSTORE=y
CONFIG_PSTORE_DEFAULT_KMSG_BYTES=10240
CONFIG_PSTORE_DEFLATE_COMPRESS=y
# CONFIG_PSTORE_LZO_COMPRESS is not set
# CONFIG_PSTORE_LZ4_COMPRESS is not set
# CONFIG_PSTORE_LZ4HC_COMPRESS is not set
# CONFIG_PSTORE_842_COMPRESS is not set
# CONFIG_PSTORE_ZSTD_COMPRESS is not set
CONFIG_PSTORE_COMPRESS=y
CONFIG_PSTORE_DEFLATE_COMPRESS_DEFAULT=y
CONFIG_PSTORE_COMPRESS_DEFAULT="deflate"
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_PMSG=y
CONFIG_PSTORE_RAM=y
# CONFIG_PSTORE_BLK is not set
root@bpi-r64:~# zgrep 'IDLE' /proc/config.gz
CONFIG_NO_HZ_IDLE=y
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y
# CONFIG_CPU_IDLE_GOV_LADDER is not set
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_CPU_IDLE_GOV_TEO is not set
CONFIG_DT_IDLE_STATES=y
# CONFIG_ARM_CPUIDLE is not set
CONFIG_ARM_PSCI_CPUIDLE=y
CONFIG_ARM_PSCI_CPUIDLE_DOMAIN=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
# CONFIG_IDLE_PAGE_TRACKING is not set
# CONFIG_NETFILTER_XT_TARGET_IDLETIMER is not set
or is this as intended (c=crash)?
sysrq: Trigger a crash
but i have nothing in the /sys/fs/pstore/ dir
root@bpi-r64:~# mount -t pstore pstore /sys/fs/pstore
mount: /sys/fs/pstore: pstore already mounted on /sys/fs/pstore.
root@bpi-r64:~# ls /sys/fs/pstore/
root@bpi-r64:~#
looks like in uboot there is something in pstore
BPI-R64> pstore display
Compressed buffer, display not available
BPI-R64>
but in linux still empty
root@bpi-r64:~# dmesg | grep -i pstore
[ 0.015542] pstore: Registered ramoops as persistent store backend
[ 1.582087] pstore: Using crash dump compression: deflate
root@bpi-r64:~#
root@bpi-r64:~# ls /sys/fs/pstore/
root@bpi-r64:~#
after reboot (without power-loss) pstore in uboot is empty again
so i disabled compression in linux and i can see content in uboot…
BPI-R64> pstore display
**** Dump
Panic#1 Part1
<7>[ 7.500652] mt7615e 0000:01:00.0: enabling bus mastering
<7>[ 7.500835] mtk-pcie 1a143000.pcie: msi#0 address_hi 0x0 address_lo 0x410b50c0
...
<6>[ 57.450520] sysrq: Trigger a crash
<0>[ 57.453941] Kernel panic - not syncing: sysrq triggered crash
<7>[ 57.459684] CPU: 1 PID: 292 Comm: bash Tainted: G S 5.17.0-rc1-bpi-r64-r64 #4
<7>[ 57.468118] Hardware name: Bananapi BPI-R64 (DT)
<7>[ 57.472729] Call trace:
<7>[ 57.475168] dump_backtrace+0xe0/0x114
so pstore seems to work across boot (wait after crash for reboot), so after display the pstore in uboot booting into same linux kernel again…but pstore there is empty again
is this feature available for r4/mt7988 too? is the reserved ram same as for mt7986?
+ /* 64 KiB reserved for ramoops/pstore */
+ ramoops@42ff0000 {
+ compatible = "ramoops";
+ reg = <0 0x42ff0000 0 0x10000>;
+ record-size = <0x1000>;
+ };
any idea about the uboot-issue on compressed pstore? looks like pstore does not need additional patches except dts, right? driver is mainline so far (no mtk specific implementation needed)?
Why was pstore in linux empty then? Should stacktrace available in linux after software reboot?
if i add uboot-patch for reserved memory i get these warnings:
DTC arch/arm/dts/mt7986a-rfb.dtb
arch/arm/dts/mt7986a-bpi-r3-sd.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7986a-bpi-r3-sd.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
DTC arch/arm/dts/mt7986b-rfb.dtb
arch/arm/dts/mt7986a-bpi-r3-emmc.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7986a-bpi-r3-emmc.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
DTC arch/arm/dts/mt7986a-sd-rfb.dtb
arch/arm/dts/mt7986a-bpi-r3-mini.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7986a-bpi-r3-mini.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
DTC arch/arm/dts/mt7986b-sd-rfb.dtb
arch/arm/dts/mt7986a-rfb.dtb: Warning (ranges_format): /reserved-memory DTC arch/arm/dts/mt7986a-emmc-rfb.dtb
:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7986a-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
DTC arch/arm/dts/mt7986b-emmc-rfb.dtb
arch/arm/dts/mt7986b-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7986b-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
arch/arm/dts/mt7986a-sd-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7986a-sd-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
DTC arch/arm/dts/mt8183-pumpkin.dtb
arch/arm/dts/mt7986b-sd-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7986b-sd-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
arch/arm/dts/mt7986a-emmc-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7986a-emmc-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
DTC arch/arm/dts/mt8512-bm1-emmc.dtb
DTC arch/arm/dts/mt8516-pumpkin.dtb
arch/arm/dts/mt7986b-emmc-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7986b-emmc-rfb.dtb: Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
imho in uboot for mt7986 i can change address-cells and size-cells to 1 and drop the zeros in the regs below, right?
so basicly this way:
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* 64 KiB reserved for ramoops/pstore */
ramoops@42ff0000 {
compatible = "ramoops";
reg = <0x42ff0000 0x10000>;
record-size = <0x1000>;
};
/* 192 KiB reserved for ARM Trusted Firmware (BL31) */
secmon_reserved: secmon@43000000 {
reg = <0x43000000 0x30000>;
no-map;
};
wmcpu_emi: wmcpu-reserved@4fc00000 {
no-map;
reg = <0x4fc00000 0x00100000>;
};
};
for mt7622 i had not removed the zeros, which maybe caused that the pstore was overridden while booting linux?
dts:
ramoops: ramoops@42ff0000{
compatible = "ramoops";
reg = <0x0 0x42ff0000 0x0 0x10000>;
record-size = <0x2000>;
console-size = <0x2000>;
pmsg-size = <0x2000>;
};
kernel option:
# CONFIG_PSTORE_842_COMPRESS is not set
CONFIG_PSTORE_CONSOLE=y
# CONFIG_PSTORE_DEFLATE_COMPRESS is not set
# CONFIG_PSTORE_LZ4HC_COMPRESS is not set
# CONFIG_PSTORE_LZ4_COMPRESS is not set
# CONFIG_PSTORE_LZO_COMPRESS is not set
CONFIG_PSTORE_PMSG=y
CONFIG_PSTORE_RAM=y
# CONFIG_PSTORE_ZSTD_COMPRESS is not set
uboot option:
CONFIG_CMD_PSTORE=y
CONFIG_CMD_PSTORE_MEM_ADDR=0x42ff0000
CONFIG_CMD_PSTORE_RECORD_SIZE=0x2000
CONFIG_CMD_PSTORE_CONSOLE_SIZE=0x2000
CONFIG_CMD_PSTORE_FTRACE_SIZE=0x0
CONFIG_CMD_PSTORE_PMSG_SIZE=0x2000
1 Like
Thx seems same except console/pmsg-size…and size is twice 0x2000 instead of 0x1000
i see you disabled deflate compress too,i guess because of uboot not supporting compress,right?
any idea on dtc errors for mt7622/mt7986? Is my solution right.
does uboot need the dts-node? it looks like all options are defined via config
at least i have got it working on r3mini 
both uboot and linux works
echo c > /proc/sysrq-trigger
uboot (still shows compressed, but can display the log):
BPI-R3M> pstore display
Compressed buffer, display not available
**** Console
000
[ 2.676459] xhci-mtk 11200000.usb: xHCI Host Controller
[ 2.681682] xhci-mtk 11200000.usb: new USB bus registered, assigned bus number 2
[ 2.689069] xhci-mtk 11200000.usb: Host supports USB 3.2 Enhanced SuperSpeed
[ 2.696589] hub 1-0:1.0: USB hub found
[ 2.700362] hub 1-0:1.0: 2 ports detected
[ 2.704698] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 2.713182] hub 2-0:1.0: USB hub found
[ 2.716960] hub 2-0:1.0: 1 port detected
[ 2.722592] clk: Disabling unused clocks
[ 2.750826] Freeing unused kernel memory: 4480K
[ 2.821100] Run /init as init process
[ 2.824765] with arguments:
[ 2.827723] /init
...
[ 87.975360] sysrq: Trigger a crash
[ 87.978784] Kernel panic - not syncing: sysrq triggered crash
[ 87.984518] CPU: 2 PID: 1472 Comm: sh Not tainted 6.6.0-bpi-r3-r3mini #1
[ 87.991205] Hardware name: Bananapi BPI-R3 Mini (DT)
[ 87.996156] Call trace:
[ 87.998592] dump_backtrace+0x94/0x114
[ 88.002339] show_stack+0x18/0x24
[ 88.005644] dump_stack_lvl+0x48/0x60
[ 88.009298] dump_stack+0x18/0x24
[ 88.012604] panic+0x2fc/0x358
[ 88.015651] sysrq_reset_seq_param_set+0x0/0x8c
[ 88.020173] __handle_sysrq+0xb4/0x1d8
[ 88.023914] write_sysrq_trigger+0xcc/0x138
[ 88.028087] proc_reg_write+0x9c/0xf0
[ 88.031739] vfs_write+0xc4/0x390
[ 88.035045] ksys_write+0x68/0xf4
[ 88.038350] __arm64_sys_write+0x1c/0x28
[ 88.042261] invoke_syscall+0x48/0x114
[ 88.046002] el0_svc_common.constprop.0+0x40/0xe8
[ 88.050695] do_el0_svc+0x20/0x2c
[ 88.054001] el0_svc+0x40/0xf4
[ 88.057048] el0t_64_sync_handler+0x13c/0x158
[ 88.061395] el0t_64_sync+0x194/0x198
[ 88.065048] SMP: stopping secondary CPUs
[ 88.068962] Kernel Offset: disabled
[ 88.072437] CPU features: 0x0,00000008,00020000,1000420b
[ 88.077737] Memory Limit: none
[ 88.084439] pstore: backend (ramoops) writing error (-28)
[ 88.089829] Rebooting in 1 seconds..
BPI-R3M>
# mount -t pstore pstore /sys/fs/pstore
# tail -30 /sys/fs/pstore/dmesg-ramoops-0
<4>[ 9.445497] sd 0:0:0:0: [sda] Assuming drive cache: write through
<6>[ 9.453699] sda: sda1 sda2
<5>[ 9.456801] sd 0:0:0:0: [sda] Attached SCSI removable disk
<6>[ 25.434855] sysrq: Trigger a crash
<0>[ 25.438273] Kernel panic - not syncing: sysrq triggered crash
<7>[ 25.444005] CPU: 0 PID: 1481 Comm: sh Not tainted 6.6.25-bpi-r3-main #2
<7>[ 25.450604] Hardware name: Bananapi BPI-R3 Mini (DT)
<7>[ 25.455553] Call trace:
<7>[ 25.457987] dump_backtrace+0x94/0x114
<7>[ 25.461731] show_stack+0x18/0x24
<7>[ 25.465034] dump_stack_lvl+0x48/0x60
<7>[ 25.468688] dump_stack+0x18/0x24
<7>[ 25.471992] panic+0x2fc/0x358
<7>[ 25.475038] sysrq_reset_seq_param_set+0x0/0x8c
<7>[ 25.479558] __handle_sysrq+0xb4/0x1d8
<7>[ 25.483295] write_sysrq_trigger+0xcc/0x138
<7>[ 25.487466] proc_reg_write+0x9c/0xf0
<7>[ 25.491117] vfs_write+0xc4/0x390
<7>[ 25.494422] ksys_write+0x68/0xf4
<7>[ 25.497725] __arm64_sys_write+0x1c/0x28
<7>[ 25.501636] invoke_syscall+0x48/0x114
<7>[ 25.505375] el0_svc_common.constprop.0+0x40/0xe8
<7>[ 25.510066] do_el0_svc+0x20/0x2c
<7>[ 25.513371] el0_svc+0x40/0xf4
<7>[ 25.516417] el0t_64_sync_handler+0x13c/0x158
<7>[ 25.520761] el0t_64_sync+0x194/0x198
<2>[ 25.524412] SMP: stopping secondary CPUs
<0>[ 25.528324] Kernel Offset: disabled
<0>[ 25.531798] CPU features: 0x0,00000008,00020000,1000420b
<0>[ 25.537094] Memory Limit: none
#
original trace shows this (and in console-ramoops-0 file if present):
[ 25.537094] Memory Limit: none
[ 25.541979] pstore: backend (ramoops) writing error (-28)
[ 25.547366] Rebooting in 1 seconds..
wonder about the writing error in log and the compressed buffer message in uboot…but it seems compress is set by default
# zgrep -i pstore /proc/config.gz
CONFIG_EFI_VARS_PSTORE=y
# CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE is not set
CONFIG_PSTORE=y
CONFIG_PSTORE_DEFAULT_KMSG_BYTES=10240
CONFIG_PSTORE_COMPRESS=y
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_PMSG=y
CONFIG_PSTORE_RAM=y
# CONFIG_PSTORE_BLK is not set
#
fixed last by explicit setting compress to “n”…still wonder about the writing error…but crashdump is available in uboot
verified on r4 too (where i have not added the dts-part in uboot)…works well, only the same writing error (“pstore: backend (ramoops) writing error (-28”))
err 28 seems to be ENOSPC (no space left on device), so maybe buffer is not large enough to hold full dmesg, right? but as far the trace is visible all is good, just noted the message
Thanks,
only wonder why daniel added dts nodes in uboot for mt7622/mt7986 and you have “only” config options set for pstore. Imho this is redundant and maybe not needed…i guess one is enough? Pstore config could take information from dts. Or does this not work and dts is needed in uboot to prevent ram range can be overidden?
Also it looks like setting recordsize is enough (+pstore+memaddr) and consolesize and pmsg will be set to same value as recordsize.
This is true, one of them would be enough. The thing is that in OpenWrt we do not always build U-Boot for every device, many times we rely on vendor U-Boot which may not have support for pstore. Making sure the memory range is defined in DT makes it work even with those vendor bootloaders.
you mean the linux-dt, right? thats clear…i talk about uboot dt