Device Mapper Verity Error

[satvikaggarwal]

I am working on S32G2 Microprocessor. And recently I downgraded my LPDDR-RAM from 4GB to 2GB. As I want a secure Yocto Image, I am using a fork of BSP37 provided by NXP. I made changes in my U-boot and ATF so that the board boots up with my Yocto image. But then I am facing a kernel Panic due to device-mapper verity. First I thought, it may be key mismatch but later after debugging I discovered that the kernel is trying to access a RAM location which doesnt exist. I am attaching logs for reference.
How can I fix this issue??

root@s32g2intfevb:~# hse-secboot -s -d /dev/mtd0 -k rsa2048_public.pem
[INFO] Setting up secure boot
hse: device initialized, status 0x0920
[INFO] Retrieving IVT from device /dev/mtd0
[INFO] Enabling MUs
[INFO] Did not find previous SYSIMG, formatting NVM and RAM key catalogs
[INFO] Importing RSA public key into NVM key catalog
[INFO] Generating Secure Memory Region entry
[INFO] Generating Core Reset Entry
[INFO] Retrieving SYSIMG size
[INFO] Publishing SYSIMG
[INFO] Writing SYSIMG to /dev/mtd0


NOTICE: Reset status: Error
NOTICE: BL2: v2.5(release):bsp37.0-2.5-dirty
NOTICE: BL2: Built : 10:21:03, Oct 17 2025
NOTICE: BL2: Booting BL31


U-Boot 2020.04+g156b168010 (Oct 17 2025 - 10:12:54 +0530)

CPU: NXP S32G233A rev. 2.1
Model: NXP S32G2INTERFEVB
DRAM: 1.8 GiB
MMC: FSL_SDHC: 0
Loading Environment from SPI Flash... SF: Detected s25fl129p1 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

In: serial@401c8000
Out: serial@401c8000
Err: serial@401c8000
Board revision: INTFEVB Revision B
Net: No ethernet found.
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0(part 0) is current device
15437838 bytes read in 106 ms (138.9 MiB/s)
Booting from mmc ...
## Loading kernel from FIT Image at 90000000 ...
Using 'conf-freescale_s32g2intfevb.dtb' configuration
Verifying Hash Integrity ... OK
Trying 'kernel-1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x900000e8
Data Size: 15386702 Bytes = 14.7 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x80000000
Entry Point: 0x80000000
Hash algo: sha256
Hash value: a13e8f0dd7855b74b336c26ec1d357b2c0c0e1ec342770a81b161f413ab1fb56
Sign algo: sha256,rsa2048:boot_key
Sign value: 587d67e53c90c8ea8f8c53bccd467935073d6bdc7f215453477d54dd6ee9a69f4f84552ff577dbeee3b18f85c7702c9f44868b02cbebb1cbfc2c270adc89456b275f0b97cda1f97630517d12af5b638e6e50d3517d7b2939abcaadd1317f021b
Verifying Hash Integrity ... sha256,rsa2048:boot_key+ sha256+ OK
## Loading fdt from FIT Image at 90000000 ...
Using 'conf-freescale_s32g2intfevb.dtb' configuration
Verifying Hash Integrity ... OK
Trying 'fdt-freescale_s32g2intfevb.dtb' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x90eacbe0
Data Size: 48902 Bytes = 47.8 KiB
Architecture: AArch64
Load Address: 0x83000000
Hash algo: sha256
Hash value: 5e24d283b104fabebb0e25010b61c7b5699860f227cb1c32fa979ea44bc11ded
Sign algo: sha256,rsa2048:boot_key
Sign value: 8ea79b6eb3b7467274bae35b33c5e04f6e56f1589912f4fd452659ff429891840622f73cab81ed86db57307fdd150f941eeaa31bff8c93261ee3c95954facc5ee424bb38dec79d5e3eeaa4ffac4f1c885c208d9ff4874f7e4f8e48f40d840d61
Verifying Hash Integrity ... sha256,rsa2048:boot_key+ sha256+ OK
Loading fdt from 0x90eacbe0 to 0x83000000
Booting using the fdt blob at 0x83000000
Uncompressing Kernel Image
Using Device Tree in place at 0000000083000000, end 000000008300ef05

Starting kernel ...

unable to select a mode
device_remove: Device '[email protected]' failed to remove, but children are gone
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 5.15.96-rt61+gf2b25660adcf (oe-user@oe-host) (aarch64-fsl-linux-gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.38.20220708) #1 SMP PREEMPT Fri Jun 16 07:22:24 UTC 2023
[ 0.000000] Machine model: NXP S32G2INTFEVB
[ 0.000000] earlycon: linflex0 at MMIO 0x00000000401c8000 (options '115200n8')
[ 0.000000] printk: bootconsole [linflex0] enabled
[ 0.000000] Reserved memory: created DMA memory pool at 0x0000000083200000, size 3 MiB
[ 0.000000] OF: reserved mem: initialized node pfebufs@83200000, compatible id shared-dma-pool
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000080000000-0x00000000efffffff]
[ 0.000000] DMA32 empty
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080000000-0x00000000831fffff]
[ 0.000000] node 0: [mem 0x0000000083200000-0x00000000835dffff]
[ 0.000000] node 0: [mem 0x00000000835e0000-0x0000000083ffffff]
[ 0.000000] node 0: [mem 0x0000000084000000-0x00000000849fffff]
[ 0.000000] node 0: [mem 0x0000000084a00000-0x0000000084ffffff]
[ 0.000000] node 0: [mem 0x0000000085000000-0x0000000085000fff]
[ 0.000000] node 0: [mem 0x0000000085001000-0x00000000bfffffff]
[ 0.000000] node 0: [mem 0x00000000c0000000-0x00000000c07fffff]
[ 0.000000] node 0: [mem 0x00000000c0800000-0x00000000cfffffff]
[ 0.000000] node 0: [mem 0x00000000d0001000-0x00000000efffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000000efffffff]
[ 0.000000] On node 0, zone DMA: 1 pages in unavailable ranges
[ 0.000000] cma: Reserved 256 MiB at 0x00000000ddc00000
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.2
[ 0.000000] /cpus/cpu@1: missing reg property
[ 0.000000] /cpus/cpu@101: missing reg property
[ 0.000000] percpu: Embedded 18 pages/cpu s32792 r8192 d32744 u73728
[ 0.000000] pcpu-alloc: s32792 r8192 d32744 u73728 alloc=18*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 2
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] CPU features: detected: GIC system register CPU interface
[ 0.000000] CPU features: detected: ARM erratum 845719
[ 0.000000] CPU features: detected: NXP erratum ERR050481 (TLBI handled incorrectly)
[ 0.000000] CPU features: detected: ARM errata 1165522, 1319367, 1530923, or 1530924
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 452479
[ 0.000000] Kernel command line: console=ttyLF0,115200 root=/dev/mmcblk0p2 rootwait rw earlycon
[ 0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[ 0.000000] mem auto-init: stackff, heap allocff, heap freeff
[ 0.000000] Memory: 1478324K/1835004K available (8896K kernel code, 624K rwdata, 2968K rodata, 23296K init, 213K bss, 94536K reserved, 262144K cma-reserved)
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=3.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=3
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] GICv3: 544 SPIs implemented
[ 0.000000] GICv3: 0 Extended SPIs implemented
[ 0.000000] GICv3: Distributor has no Range Selector support
[ 0.000000] GICv3: MBI range [167:182]
[ 0.000000] GICv3: Using MBI frame 0x0000000050800000
[ 0.000000] Root IRQ handler: gic_handle_irq
[ 0.000000] GICv3: 16 PPIs implemented
[ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000050880000
[ 0.000000] ITS: No ITS available, not enabling LPIs
[ 0.000000] arch_timer: cp15 timer(s) running at 5.00MHz (virt).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x127350b88, max_idle_ns: 440795202120 ns
[ 0.000001] sched_clock: 56 bits at 5MHz, resolution 200ns, wraps every 4398046511100ns
[ 0.008632] Console: colour dummy device 80x25
[ 0.008680] Calibrating delay loop (skipped), value calculated using timer frequency.. 10.00 BogoMIPS (lpj=20000)
[ 0.022946] pid_max: default: 32768 minimum: 301
[ 0.027751] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[ 0.034932] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[ 0.043744] CPU node for /cpus/cpu@1 exist but the possible cpu range is :0,2
[ 0.050503] CPU node for /cpus/cpu@101 exist but the possible cpu range is :0,2
[ 0.058654] rcu: Hierarchical SRCU implementation.
[ 0.063954] smp: Bringing up secondary CPUs ...
[ 0.068953] Detected VIPT I-cache on CPU2
[ 0.072581] GICv3: CPU2: found redistributor 100 region 0:0x00000000508c0000
[ 0.079630] CPU2: Booted secondary processor 0x0000000100 [0x410fd034]
[ 0.086254] smp: Brought up 1 node, 2 CPUs
[ 0.090197] SMP: Total of 2 processors activated.
[ 0.094854] CPU features: detected: 32-bit EL0 Support
[ 0.100000] CPU features: detected: CRC32 instructions
[ 0.118417] CPU: All CPU(s) started at EL1
[ 0.122110] alternatives: patching kernel code
[ 0.128139] devtmpfs: initialized
[ 0.139114] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.148461] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[ 0.167170] pinctrl core: initialized pinctrl subsystem
[ 0.173137] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.180286] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations
[ 0.187071] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[ 0.194806] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[ 0.203045] thermal_sys: Registered thermal governor 'step_wise'
[ 0.203636] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[ 0.216056] ASID allocator initialised with 65536 entries
[ 0.221462] Serial: AMBA PL011 UART driver
[ 0.226628] arm-scmi firmware:scmi: Enabled polling mode TX channel - prot_id:16
[ 0.233794] arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
[ 0.240176] arm-scmi firmware:scmi: SCMI Protocol v2.0 'NXP:S32G274A' Firmware version 0x0
[ 0.269068] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[ 0.275407] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[ 0.282050] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[ 0.288746] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[ 0.305174] vgaarb: loaded
[ 0.307737] SCSI subsystem initialized
[ 0.311397] usbcore: registered new interface driver usbfs
[ 0.316724] usbcore: registered new interface driver hub
[ 0.321999] usbcore: registered new device driver usb
[ 0.327516] pps_core: LinuxPPS API ver. 1 registered
[ 0.332049] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[email protected]>
[ 0.341176] PTP clock support registered
[ 0.346355] clocksource: Switched to clocksource arch_sys_counter
[ 0.358816] NET: Registered PF_INET protocol family
[ 0.363508] IP idents hash table entries: 32768 (order: 6, 262144 bytes, linear)
[ 0.371997] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear)
[ 0.380140] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.387830] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear)
[ 0.395863] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear)
[ 0.403462] TCP: Hash tables configured (established 16384 bind 16384)
[ 0.409692] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear)
[ 0.416340] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear)
[ 0.423597] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 0.429631] RPC: Registered named UNIX socket transport module.
[ 0.435128] RPC: Registered udp transport module.
[ 0.439808] RPC: Registered tcp transport module.
[ 0.444494] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.450943] PCI: CLS 0 bytes, default 64
[ 0.467021] hw perfevents: enabled with armv8_pmuv3 PMU driver, 7 counters available
[ 0.478480] workingset: timestamp_bits=62 max_order=19 bucket_order=0
[ 0.490777] fuse: init (API version 7.34)
[ 0.494704] NET: Registered PF_ALG protocol family
[ 0.499231] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[ 0.506542] io scheduler mq-deadline registered
[ 0.511036] io scheduler kyber registered
[ 0.518217] s32g-siul2-pinctrl 4009c240.siul2-pinctrl: Initialized s32cc pinctrl driver
[ 0.527776] gpio-345 (sja1110-rst-phy-t1): hogged as output/low
[ 0.533302] gpio-402 (sja1110-rst-core): hogged as output/low
�[ 0.551147] printk: console [ttyLF0] enabledx401c8000 (irq = 35, base_baud = 7812500) is a FSL_LINFLEX
[ 0.551147] printk: console [ttyLF0] enabled
[ 0.559853] printk: bootconsole [linflex0] disabled
[ 0.559853] printk: bootconsole [linflex0] disabled
[ 0.570182] 401cc000.serial: ttyLF1 at MMIO 0x401cc000 (irq = 36, base_baud = 7812500) is a FSL_LINFLEX
[ 0.580117] 402bc000.serial: ttyLF2 at MMIO 0x402bc000 (irq = 54, base_baud = 7812500) is a FSL_LINFLEX
[ 0.591115] s32cc_fccu 4030c000.fccu: FCCU status is 0 (normal)
[ 0.602030] e100: Intel(R) PRO/100 Network Driver
[ 0.606896] e100: Copyright(c) 1999-2006 Intel Corporation
[ 0.612551] e1000: Intel(R) PRO/1000 Network Driver
[ 0.617533] e1000: Copyright (c) 1999-2006 Intel Corporation.
[ 0.623438] e1000e: Intel(R) PRO/1000 Network Driver
[ 0.628502] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 0.634570] igb: Intel(R) Gigabit Ethernet Network Driver
[ 0.640077] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 0.647023] hse-uio 40210000.mu0b: successfully registered device
[ 0.653487] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.660152] ehci-pci: EHCI PCI platform driver
[ 0.664877] usbcore: registered new interface driver uas
[ 0.670359] usbcore: registered new interface driver usb-storage
[ 0.678106] s32cc-rtc 40060000.rtc: registered as rtc0
[ 0.683391] s32cc-rtc 40060000.rtc: setting system clock to 1970-01-01T00:00:00 UTC (0)
[ 0.691665] i2c_dev: i2c /dev entries driver
[ 0.696449] s32cc-wdt 4010c000.watchdog: S32CC Watchdog Timer Registered. timeout=30s (nowayout=0)
[ 0.705764] s32cc-wdt 40200000.watchdog: S32CC Watchdog Timer Registered. timeout=30s (nowayout=0)
[ 0.715069] s32cc-wdt 40204000.watchdog: S32CC Watchdog Timer Registered. timeout=30s (nowayout=0)
[ 0.724370] s32cc-wdt 40208000.watchdog: S32CC Watchdog Timer Registered. timeout=30s (nowayout=0)
[ 0.733786] device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: [email protected]
[ 0.742806] sdhci: Secure Digital Host Controller Interface driver
[ 0.749124] sdhci: Copyright(c) Pierre Ossman
[ 0.753569] sdhci-pltfm: SDHCI platform and OF driver helper
[ 0.759585] arm-scmi firmware:scmi: Failed. SCMI protocol 17 not active.
[ 0.760449] mmc0: CQHCI version 5.10
[ 0.766475] SMCCC: SOC_ID: ARCH_SOC_ID not implemented, skipping ....
[ 0.777309] hse 40211000.mu1b: standard firmware, version 0.0.0
[ 0.783661] hse 40211000.mu1b: registered algs sha1,hmac(sha1)
[ 0.789859] hse 40211000.mu1b: registered algs sha224,hmac(sha224)
[ 0.796432] hse 40211000.mu1b: registered algs sha256,hmac(sha256)
[ 0.802982] hse 40211000.mu1b: registered algs sha384,hmac(sha384)
[ 0.806369] mmc0: SDHCI controller on 402f0000.mmc [402f0000.mmc] using ADMA
[ 0.816695] hse 40211000.mu1b: registered algs sha512,hmac(sha512)
[ 0.823254] hse 40211000.mu1b: registered alg ctr(aes)
[ 0.828664] hse 40211000.mu1b: registered alg cbc(aes)
[ 0.834042] hse 40211000.mu1b: registered alg ecb(aes)
[ 0.839452] hse 40211000.mu1b: registered alg cfb(aes)
[ 0.844862] hse 40211000.mu1b: registered alg ofb(aes)
[ 0.850274] hse 40211000.mu1b: registered alg gcm(aes)
[ 0.855681] hse 40211000.mu1b: registered hwrng-hse
[ 0.860712] hse 40211000.mu1b: device ready, status 0x4F20
[ 0.867082] usbcore: registered new interface driver usbhid
[ 0.872824] usbhid: USB HID core driver
[ 0.877061] nxp_s32cc_ddr_perf 403e0000.ddr-perf: probing device
[ 0.883663] nxp_s32cc_ddr_perf 403e0000.ddr-perf: device initialized successfully
[ 0.891746] s32-siul2-nvmem 4009c000.nvram: Initialized s32cc siul2 nvmem driver
[ 0.899448] s32-siul2-nvmem 44010000.nvram: Initialized s32cc siul2 nvmem driver
[ 0.907885] NET: Registered PF_INET6 protocol family
[ 0.913990] Segment Routing with IPv6
[ 0.917797] In-situ OAM (IOAM) with IPv6
[ 0.921865] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 0.928465] NET: Registered PF_PACKET protocol family
[ 0.934070] printk: console [ttyLF0]: printing thread started
[ 0.947594] i2c i2c-4: using pinctrl states for GPIO recovery
[ 0.947702] i2c i2c-4: using generic GPIOs for recovery
[ 0.947790] i2c i2c-4: IMX I2C adapter registered
[ 0.947852] i2c i2c-4: using dma1chan18 (tx) and dma1chan19 (rx) for DMA transfers
[ 0.968839] Freeing unused kernel memory: 23296K
[ 0.969032] Run /init as init process
[ 0.994416] mmc0: Command Queue Engine enabled
[ 0.994465] mmc0: new HS400 Enhanced strobe MMC card at address 0001
[ 0.995355] mmcblk0: mmc0:0001 G1M15L 23.6 GiB
[ 1.002482] mmcblk0: p1 p2 p3 < p5 p6 p7 p8 p9 >
[ 1.004039] mmcblk0boot0: mmc0:0001 G1M15L 31.5 MiB
[ 1.005328] mmcblk0boot1: mmc0:0001 G1M15L 31.5 MiB
[ 1.017026] mmcblk0rpmb: mmc0:0001 G1M15L 4.00 MiB, chardev (242:0)
[ 1.053900] random: crng init done
Starting version 250.5+
realpath: /dev/disk/by-partuuid//dev/mmcblk0p2: No such file or directory
Primary!!
Signature Verified Successfully
0
[ 2.773069] device-mapper: verity: sha256 using implementation "sha256-hse"
[ 2.792677] device-mapper: verity: 179:2: metadata block 151553 is corrupted
[ 2.801210] device-mapper: verity: 179:2: metadata block 151553 is corrupted
[ 2.801271] Buffer I/O error on dev dm-0, logical block 151536, async page read
Verity device detected corruption after activat[ 2.846016] device-mapper: verity: 179:2: metadata block 151553 is corrupted
io[ 2.846915] device-mapper: verity: 179:2: metadata block 151553 is corrupted
n.
[ 2.846970] Buffer I/O error on dev dm-0, logical block 151536, async page read
[ 2.850696] device-mapper: verity: 179:2: metadata block 151553 is corrupted
[ 2.851636] device-mapper: verity: 179:2: metadata block 151553 is corrupted
[ 2.851687] Buffer I/O error on dev dm-0, logical block 151536, async page read
[ 2.861547] device-mapper: verity: 179:2: metadata block 151553 is corrupted
[ 2.862783] device-mapper: verity: 179:2: metadata block 151553 is corrupted
[ 2.862846] Buffer I/O error on dev dm-0, logical block 151536, async page read
[ 2.866669] device-mapper: verity: 179:2: metadata block 151553 is corrupted
[ 2.867592] device-mapper: verity: 179:2: metadata block 151553 is corrupted
[ 2.867643] Buffer I/O error on dev dm-0, logical block 151536, async page read
[ 2.872952] Buffer I/O error on dev dm-0, logical block 151536, async page read
[ 2.882509] Buffer I/O error on dev dm-0, logical block 151536, async page read
[ 2.892360] Buffer I/O error on dev dm-0, logical block 151536, async page read
r[ 2.899293] Buffer I/O error on dev dm-0, logical block 151536, async page read
e[ 2.912517] Buffer I/O error on dev dm-0, logical block 151536, async page read
alpath: /dev/disk/by-partuuid//dev/mmcblk0p6: No such file or directory
[ 3.107977] device-mapper: verity: 179:2: reached maximum errors
Signature Verified Successfully
[ 4.045144] device-mapper: verity: sha256 using implementation "sha256-hse"
Verity device detected corruption after activation.
mount: /roo[ 4.121697] EXT4-fs (dm-1): unable to read superblock
tfs: [ 4.122707] Kernel panic - not syncing:
ca[ 4.122715] Attempted to kill init! exitcode=0x00000200
n't read superblock on /dev/mapper/rootfsp6.
[ 4.230398] SMP: stopping secondary CPUs
[ 4.233915] Kernel Offset: disabled
[ 4.237373] CPU features: 0x1,20002001,20000842
[ 4.241887] Memory Limit: none
[ 4.244931] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000200 ]---

 

[f33dm3bits]

Is this a singleboard setup that you are using because it doesn't look like anything familiar to main stream Linux distributions? The only thing I'm noticing is I/O errors and that usually indicates that failure of a disk in this case, so maybe your disk is dying?

 

[satvikaggarwal]

Is this a singleboard setup that you are using because it doesn't look like anything familiar to main stream Linux distributions? The only thing I'm noticing is I/O errors and that usually indicates that failure of a disk in this case, so maybe your disk is dying?

its not a mainstream linux distribution. its a yocto linux for embedded systems. specifically provided by NXP. the disk and hardware around it itself is running fine. im getting this problem when im securing the suystem using hse. on a 4GB DDR board, it works fine but on a 2GB one im entering into a kernel panic. my guess is that im missing some configuration which needs to be modified on the kernel side but im not sure what.

 

[f33dm3bits]

its not a mainstream linux distribution. its a yocto linux for embedded systems.

I'll move it then to SBC since it seems more fitting there.

 

[Suryashankar Dasgupta]

Any update?

 

[Trml]

it works fine but on a 2GB one im entering into a kernel panic.

The errors in your dmesg have nothing to do with RAM, but the SD-card. If your modifications incurred changing any file to boot the Linux on disk or you changed disk partitioning, this will invalidate an already setup dm-verity hash. That's its purpose.
dm-verity has an option "ignore_corruption" you can perhaps look into. Once it booted, you can regenerate the hashes.

Have a look at https://en.hwlibre.com/How-to-use-DM-Verity-on-Linux:-A-complete-and-practical-guide/

 

[satvikaggarwal]

The errors in your dmesg have nothing to do with RAM, but the SD-card. If your modifications incurred changing any file to boot the Linux on disk or you changed disk partitioning, this will invalidate an already setup dm-verity hash. That's its purpose.
dm-verity has an option "ignore_corruption" you can perhaps look into. Once it booted, you can regenerate the hashes.

Have a look at https://en.hwlibre.com/How-to-use-DM-Verity-on-Linux:-A-complete-and-practical-guide/

i was able to debug further and got to this logs... something related to block_size. it not being 4096 is causing my kernel to panic... i think the error is related to this block size... what can be done to fix this?


Starting version 250.5+
[ 1.850110] EXT4-fs (mmcblk0p1): VFS: Can't find ext4 filesystem
WARNING: DATA_BLOCK_SIZE=1024 (not 4096). Falling back to plain RO mount of /dev/mmcblk0p2 at /rootfs.
[ 1.913187] EXT4-fs (mmcblk0p2): mounting ext3 file system using the ext4 subsystem
[ 1.923518] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
[ 1.936405] EXT4-fs (mmcblk0p1): VFS: Can't find ext4 filesystem
WARNING: DATA_BLOCK_SIZE=1024 (not 4096). Falling back to plain RO mount of /dev/mmcblk0p2 at /rootfs.
mount: /rootfs: /dev/mmcblk0p2 already mounted on /rootfs.
[ 2.192165] systemd[1]: System time before build time, advancing clock.
[ 2.216158] systemd[1]: systemd 250.5+ running in system mode (+PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP -GCRYPT -GNUTLS -OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD -LIBCRYPT)
[ 2.216624] systemd[1]: Detected architecture arm64.

Welcome to Auto Linux BSP 37.0 (kirkstone)!

 

[Trml]

something related to block_size. it not being 4096 is causing my kernel to panic

A warning is a warning, not a panic. That's the wrong track.

 

[dos2unix]

https://en.hwlibre.com/How-to-use-DM-Verity-on-Linux%3A-A-complete-and-practical-guide/

Your rootfs partition (/dev/mmcblk0p2) was formatted with an ext(3/4) block size of 1024 bytes.
Your dm‑verity metadata (Merkle tree) was generated assuming 4096‑byte data blocks (the usual default), and your init/verity script seems to hard‑assume 4096 as well:
WARNING: DATA_BLOCK_SIZE=1024 (not 4096). Falling back to plain RO mount...

That mismatch means the kernel calculates the wrong hash tree layout and tries to read wrong locations—which shows up as:
device-mapper: verity: 179:2: metadata block 151553 is corrupted
Buffer I/O error on dev dm-0...
EXT4-fs (dm-1): unable to read superblock
Kernel panic - not syncing: Attempted to kill init!

So the panic is caused by dm‑verity thinking the metadata is corrupt (because its block size assumptions don’t match the filesystem).

The fixes (pick one)
Option A — Make everything 4 KiB (recommended)

Force the rootfs to be formatted with 4KiB blocks.
Regenerate the dm‑verity hash tree with 4KiB data and hash block sizes.
Update your verity configuration (kernel dm= table or /etc/veritytab) so everything aligns to 4K.

This is the typical configuration on AArch64 (4K page size) and avoids edge cases with 1K filesystems on eMMC.
How (Yocto/WIC):

In your .wks (WIC) file, force 4K when creating the rootfs partition:
Shellpart / --source rootfs --fstype=ext4 --label rootfs \ --fsoptions "-b 4096 -I 256"Show more lines

-b 4096 sets the block size; -I 256 inode size is customary but optional.

Ensure the verity step also uses 4K. If you generate verity outside WIC:
Shell# On your build host:veritysetup format /dev/mmcblk0p2 /dev/mmcblk0p6 \ --hash sha256 \ --data-block-size 4096 \ --hash-block-size 4096 \ --salt "$(openssl rand -hex 32)"Show more lines
Capture the printed root hash and salt.

Wire it up at boot:

If you use /etc/veritytab (systemd-veritysetup):
rootfs UUID=<data-uuid> UUID=<hash-uuid> sha256 <root_hash> <salt> \
data-block-size=4096 hash-block-size=4096

If you pass dm table via kernel cmdline (dm="..."):
Make sure both data_block_size and hash_block_size are 4096, and <#blocks> matches the data device size in 4096‑byte blocks.

Rebuild/flash and boot.

Option B — Keep 1 KiB rootfs and make verity match it

Regenerate the dm‑verity tree with 1024‑byte data and hash blocks.
Update your init/verity script (and/or /etc/veritytab) to not hardcode 4096.

How:
Shellveritysetup dump /dev/mmcblk0p6# verify what’s currently recorded; you’ll likely see 4096# Recreate with 1K block sizes:veritysetup format /dev/mmcblk0p2 /dev/mmcblk0p6 \ --hash sha256 \ --data-block-size 1024 \ --hash-block-size 1024 \ --salt "$(openssl rand -hex 32)"Show more lines
Then:

/etc/veritytab:
rootfs UUID=<data-uuid> UUID=<hash-uuid> sha256 <root_hash> <salt> \
data-block-size=1024 hash-block-size=1024

Or fix your init script to read the block size from the filesystem (e.g., dumpe2fs -h /dev/mmcblk0p2 | awk '/Block size:/ {print $3}') and pass that to veritysetup open.

If your current initramfs script falls back when the block size isn’t 4096, you’ll need to remove that guard or add 1024 as allowed.

Immediate workaround (to get a booting shell)
If you just need to get in and check other things (e.g., confirm the RAM change didn’t break anything else):

Temporarily disable dm‑verity setup in your initramfs script (comment out the veritysetup open / systemd-veritysetup steps) and mount the raw rootfs read‑only:
Shellmount -o ro /dev/mmcblk0p2 /rootfsShow more lines

Or pass an appropriate kernel parameter to avoid panic on verity errors:

dm-verity.error_behavior=continue (if supported by your kernel)
As a last resort/test, remove dm= from your cmdline and set root=/dev/mmcblk0p2 ro rootwait.

Only for debug—restore verity for your “secure image” requirement.

How to verify and prove the mismatch
On a dev box (or on target in an initramfs shell):
Shell# 1) See the filesystem block sizedumpe2fs -h /dev/mmcblk0p2 | grep -i 'Block size'# 2) Look at the verity metadata the kernel is trying to useveritysetup dump /dev/mmcblk0p6# 3) Sanity-check partitioninglsblk -o NAME,SIZE,TYPE,FSTYPE,LABEL,PARTUUIDblkid# 4) Confirm what the initramfs is doingcat /proc/cmdlinedmesg | grep -i verityShow more lines
If dumpe2fs says Block size: 1024 but veritysetup dump shows 4096 for Data block size, that’s your smoking gun.

Notes about the RAM downgrade (2GB → 2GB usable)

Your logs show the kernel sees ~1.8 GiB available and carves out CMA 256 MiB, so the DDR configuration and DT memory map look sane:
DRAM: 1.8 GiB
Memory: 1478324K/1835004K available ... cma: Reserved 256 MiB ...

The verity “metadata block N is corrupted” is consistent with a block‑size mismatch, not with a DRAM boundary error. The panic is caused by init failing to mount a valid root, not by bad RAM addressing.

(Still, if you changed U‑Boot/ATF/DT for RAM, double‑check reserved‑memory regions do not exceed your 2 GiB map. But that’s separate from this verity issue.)

Yocto/BSP tips (BSP37 on kirkstone)

Prefer driving this via WIC so the same block size flag is used for both mkfs.ext4 and the verity plugin/class that generates the Merkle tree.
If you’re using /etc/veritytab with systemd‑veritysetup, ensure your image includes it and that the UUIDs match what ends up on the device after flashing.
If an internal script prints:
WARNING: DATA_BLOCK_SIZE=1024 (not 4096). Falling back to plain RO mount...

review that script and make the block size dynamic (read from FS superblock) or enforce 4K during image build.

Common checklist

mkfs.ext[34] made a 1K block FS (force -b 4096 if you want 4K).
veritysetup format used the wrong --data-block-size/--hash-block-size.
/etc/veritytab (or kernel dm= table) has the blocks/UUIDs swapped or stale root hash/salt.
Initramfs script assumes 4096; adapt it or rebuild FS as 4096.
Re‑signed artifacts are out of sync (if you sign your verity metadata). Always regenerate and re‑sign after changing block size.

 

[satvikaggarwal]

https://en.hwlibre.com/How-to-use-DM-Verity-on-Linux%3A-A-complete-and-practical-guide/

Your rootfs partition (/dev/mmcblk0p2) was formatted with an ext(3/4) block size of 1024 bytes.
Your dm‑verity metadata (Merkle tree) was generated assuming 4096‑byte data blocks (the usual default), and your init/verity script seems to hard‑assume 4096 as well:
WARNING: DATA_BLOCK_SIZE=1024 (not 4096). Falling back to plain RO mount...

That mismatch means the kernel calculates the wrong hash tree layout and tries to read wrong locations—which shows up as:
device-mapper: verity: 179:2: metadata block 151553 is corrupted
Buffer I/O error on dev dm-0...
EXT4-fs (dm-1): unable to read superblock
Kernel panic - not syncing: Attempted to kill init!

So the panic is caused by dm‑verity thinking the metadata is corrupt (because its block size assumptions don’t match the filesystem).

The fixes (pick one)
Option A — Make everything 4 KiB (recommended)

Force the rootfs to be formatted with 4KiB blocks.
Regenerate the dm‑verity hash tree with 4KiB data and hash block sizes.
Update your verity configuration (kernel dm= table or /etc/veritytab) so everything aligns to 4K.

This is the typical configuration on AArch64 (4K page size) and avoids edge cases with 1K filesystems on eMMC.
How (Yocto/WIC):

In your .wks (WIC) file, force 4K when creating the rootfs partition:
Shellpart / --source rootfs --fstype=ext4 --label rootfs \ --fsoptions "-b 4096 -I 256"Show more lines

-b 4096 sets the block size; -I 256 inode size is customary but optional.

Ensure the verity step also uses 4K. If you generate verity outside WIC:
Shell# On your build host:veritysetup format /dev/mmcblk0p2 /dev/mmcblk0p6 \ --hash sha256 \ --data-block-size 4096 \ --hash-block-size 4096 \ --salt "$(openssl rand -hex 32)"Show more lines
Capture the printed root hash and salt.

Wire it up at boot:

If you use /etc/veritytab (systemd-veritysetup):
rootfs UUID=<data-uuid> UUID=<hash-uuid> sha256 <root_hash> <salt> \
data-block-size=4096 hash-block-size=4096

If you pass dm table via kernel cmdline (dm="..."):
Make sure both data_block_size and hash_block_size are 4096, and <#blocks> matches the data device size in 4096‑byte blocks.

Rebuild/flash and boot.

Option B — Keep 1 KiB rootfs and make verity match it

Regenerate the dm‑verity tree with 1024‑byte data and hash blocks.
Update your init/verity script (and/or /etc/veritytab) to not hardcode 4096.

How:
Shellveritysetup dump /dev/mmcblk0p6# verify what’s currently recorded; you’ll likely see 4096# Recreate with 1K block sizes:veritysetup format /dev/mmcblk0p2 /dev/mmcblk0p6 \ --hash sha256 \ --data-block-size 1024 \ --hash-block-size 1024 \ --salt "$(openssl rand -hex 32)"Show more lines
Then:

/etc/veritytab:
rootfs UUID=<data-uuid> UUID=<hash-uuid> sha256 <root_hash> <salt> \
data-block-size=1024 hash-block-size=1024

Or fix your init script to read the block size from the filesystem (e.g., dumpe2fs -h /dev/mmcblk0p2 | awk '/Block size:/ {print $3}') and pass that to veritysetup open.

If your current initramfs script falls back when the block size isn’t 4096, you’ll need to remove that guard or add 1024 as allowed.

Immediate workaround (to get a booting shell)
If you just need to get in and check other things (e.g., confirm the RAM change didn’t break anything else):

Temporarily disable dm‑verity setup in your initramfs script (comment out the veritysetup open / systemd-veritysetup steps) and mount the raw rootfs read‑only:
Shellmount -o ro /dev/mmcblk0p2 /rootfsShow more lines

Or pass an appropriate kernel parameter to avoid panic on verity errors:

dm-verity.error_behavior=continue (if supported by your kernel)
As a last resort/test, remove dm= from your cmdline and set root=/dev/mmcblk0p2 ro rootwait.

Only for debug—restore verity for your “secure image” requirement.

How to verify and prove the mismatch
On a dev box (or on target in an initramfs shell):
Shell# 1) See the filesystem block sizedumpe2fs -h /dev/mmcblk0p2 | grep -i 'Block size'# 2) Look at the verity metadata the kernel is trying to useveritysetup dump /dev/mmcblk0p6# 3) Sanity-check partitioninglsblk -o NAME,SIZE,TYPE,FSTYPE,LABEL,PARTUUIDblkid# 4) Confirm what the initramfs is doingcat /proc/cmdlinedmesg | grep -i verityShow more lines
If dumpe2fs says Block size: 1024 but veritysetup dump shows 4096 for Data block size, that’s your smoking gun.

Notes about the RAM downgrade (2GB → 2GB usable)

Your logs show the kernel sees ~1.8 GiB available and carves out CMA 256 MiB, so the DDR configuration and DT memory map look sane:
DRAM: 1.8 GiB
Memory: 1478324K/1835004K available ... cma: Reserved 256 MiB ...

The verity “metadata block N is corrupted” is consistent with a block‑size mismatch, not with a DRAM boundary error. The panic is caused by init failing to mount a valid root, not by bad RAM addressing.

(Still, if you changed U‑Boot/ATF/DT for RAM, double‑check reserved‑memory regions do not exceed your 2 GiB map. But that’s separate from this verity issue.)

Yocto/BSP tips (BSP37 on kirkstone)

Prefer driving this via WIC so the same block size flag is used for both mkfs.ext4 and the verity plugin/class that generates the Merkle tree.
If you’re using /etc/veritytab with systemd‑veritysetup, ensure your image includes it and that the UUIDs match what ends up on the device after flashing.
If an internal script prints:
WARNING: DATA_BLOCK_SIZE=1024 (not 4096). Falling back to plain RO mount...

review that script and make the block size dynamic (read from FS superblock) or enforce 4K during image build.

Common checklist

mkfs.ext[34] made a 1K block FS (force -b 4096 if you want 4K).
veritysetup format used the wrong --data-block-size/--hash-block-size.
/etc/veritytab (or kernel dm= table) has the blocks/UUIDs swapped or stale root hash/salt.
Initramfs script assumes 4096; adapt it or rebuild FS as 4096.
Re‑signed artifacts are out of sync (if you sign your verity metadata). Always regenerate and re‑sign after changing block size.

i have two files in my yocto environment which are handling dm-verity implementation on my target device. Ive been tinkering with these files to perform OPTION A i.e turn datablock size to 4096 in "dm-verity-image.bbclass". I also tried tinkering with the dmverity script but no progress. I am attaching both the files (dmverity and dm-verity-img.bbclass) for your reference (changing extension to .txt for it to uplaod). If there is any change you can recommend, that'd be great!

 

[Suryashankar Dasgupta]

To add on to the issue:

• Further investigation points that the partition size of 2GB board is much higher.

• While the P2 (primary slot) contains 317938 blocks, the block configured in DM verity is 152576.
  
  
• We also tried creating new signed root-hash with block size 152576; then the corruption moves to 152577. While we created signed root-hash for 152577, the corruption moves to block 152578 and so onà Which means creating a new roothash with updated block size resolves that particular block corruption; but the next block gets corrupted.

Looking forward to the advices/ideas.