hi3520dv200: rootfs squashfs mount fails on real hardware ("unable to read id index table") despite CI/QEMU success

[widgetii]

Summary

Latest openipc.hi3520dv200-nor-lite.tgz boots U-Boot and the kernel decompresses cleanly on real Hi3520Dv200 silicon, but mounting the squashfs rootfs fails with:

SQUASHFS error: unable to read id index table
List of all partitions:
1f00             256 mtdblock0  (driver?)
1f01              64 mtdblock1  (driver?)
1f02            2048 mtdblock2  (driver?)
1f03            5120 mtdblock3  (driver?)
1f04           25280 mtdblock4  (driver?)
f000             256 romblock0  (driver?)
…
No filesystem could mount root, tried:  squashfs
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)

The kernel sees the squashfs magic at mtdblock3 (so the MTD partition layout is correct and the read path basically works) but the squashfs driver bails reading the ID index table near the end of the image. Then panic=20 reboots in 20 s and the loop repeats.

Affected artifacts

Pulled from https://github.com/OpenIPC/firmware/releases/tag/latest today (2026-05-12):

File	Size	md5	sha256
u-boot-hi3520dv200-universal.bin	154 116	matches release	ddad7bf29c9d40a9f8c0d49957d3665fa366ba64be3e0316a0dc1557c22e4280
uImage.hi3520dv200	1 821 476	1867871900bafec0e8a40e2961e9caf6 (matches .md5sum)	identifies as Linux-3.0.8-hi3520dv200
rootfs.squashfs.hi3520dv200	3 915 776	09b6eff3cb1f150244323f74517af53f (matches .md5sum)	XZ-compressed squashfs v4.0

Hardware

• SoC: Hi3520Dv200 (Cortex-A9, single core)
• NOR: Macronix MX25L25635E 32 MiB on CS1 (controller is HISFC350 at 0x10010000, mem-mapped read window at 0x58000000)
• Board boots vendor bootcmd = sf probe 0;sf read 0x82000000 0x50000 0x180000;bootm 0x82000000 cleanly with vendor U-Boot 2010.06 from the SDK image, so the chip and HISFC350 path are healthy.

Procedure

Flashed the artifacts in the layout the kernel's hardcoded mtd_partition[] expects (matches OpenIPC u-boot's mtdpartsnor8m env macro):

Partition	Flash offset	Size	Source
boot	0x000000	256 K	u-boot-hi3520dv200-universal.bin
env	0x040000	64 K	left erased (u-boot uses compiled defaults)
kernel	0x050000	2 M	uImage.hi3520dv200
rootfs	0x250000	5 M	rootfs.squashfs.hi3520dv200
rootfs_data	0x750000	rest	erased

Programming was done with a bare-metal flash agent (defib's agent, openipc/defib#96) and CRC32 of every byte written matches the source file — flash content is bit-perfect. After power-cycle u-boot loads the kernel, the kernel decompresses, prints its banner, sets up the MTD partitions, and panics as above.

Diagnostics that should rule things out

• md5sum match: both uImage and rootfs.squashfs checksums match the .md5sum files OpenIPC ships → not a download corruption issue.
• Squashfs superblock parses cleanly: magic hsqs, compression=4 (XZ), block_log=17 (128 KiB blocks), no_ids=2, bytes_used=0x3BB44B, id_table_start=0x3BB443 — all sane.
• Kernel config (br-ext-chip-hisilicon/board/hi3520dv200/hi3520dv200.generic.config) has CONFIG_SQUASHFS=y, CONFIG_SQUASHFS_XZ=y, CONFIG_XZ_DEC=y, all XZ_DEC_* BCJ filters, and CONFIG_MTD_CMDLINE_PARTS=y — squashfs decompression should be available.
• Flash content verified post-boot: re-read of mtdblock3 content via the agent at 0x250000 + N is byte-identical to the rootfs file (CRC32 = 0x7813D04E over 3 915 776 B).
• Partition layout matches what kernel reports: mtdblock3 = 5120 KiB, exactly the OpenIPC u-boot mtdpartsnor8m 5120k(rootfs) slot.

So the bytes are right, the partition is right, and the kernel says it has SQUASHFS+XZ. Yet the squashfs driver can't read the ID index table.

Suspect: real-hardware path differs from QEMU path

Both PRs that enabled CONFIG_SQUASHFS (#2077 for 4.9, #2082 for 3.0.8) say "verified in QEMU" — but on real silicon the id_table_start read still fails. QEMU emulates HISFC350 in a way that may not exercise the same DMA / read-window path the real kernel hi_sfc driver hits at high in-partition offsets.

A few hypotheses worth ruling in/out:

1. hi_sfc driver page-cache / DMA bug at offsets near the end of mtdblock3 — the failure point (id_table_start = 0x3BB443) is ~3.7 MiB into a 5 MiB partition. Earlier reads (superblock at offset 0, inode/directory tables in the middle) all succeed, since the kernel announces the partition without an earlier complaint and squashfs reaches the ID step.
2. A fragment / id table block straddles a page boundary the driver doesn't handle.
3. XZ_DEC build issue — the kernel says CONFIG_XZ_DEC=y in the .generic.config, but maybe the actual compiled artifact in the published nor-lite build dropped it. Hard to verify without the kernel symbol map.

Reproduction

1. Get any Hi3520Dv200 board (vendor SDK U-Boot recommended for fastboot bring-up).
2. Flash partitions per the table above (any tool — vendor sf from U-Boot, openipc/defib agent, etc.). Verify CRCs match the source files.
3. Power-cycle, let bootcmd run.
4. Watch console=ttyAMA0,115200 for the SQUASHFS error → reboot loop.

Workaround for users hitting this

Restore vendor boot/kernel/rfs from a stock dump until this is fixed. The bricked state is fully recoverable through bootrom + fastboot.

Repo cross-link

The flash agent used to write the partitions is at OpenIPC/defib#96 — same byte-by-byte CRC verification approach. Happy to attach the dumps/hi3520dv200-…-postjffs2cleanmarkers-…bin raw flash dump if useful.

[widgetii]

Retraction — bug is in the flashing tool, not OpenIPC firmware

@WMRamadan / OpenIPC team — apologies for the noise. The QEMU reproduction confirmed:

• Run A (my flash dump): SQUASHFS panic, identical to real hardware
• Run B (same dump but rootfs+uImage replaced with today's published artifacts): boots cleanly to openipc-hi3520dv200 login:

So OpenIPC's nor-lite build is fine. The bug is in my flashing pipeline (defib agent, OpenIPC/defib#96):

The dump's rootfs partition has only the first 1 MiB of valid squashfs followed by 3.75 MiB of 0xFF. Tracing my install procedure:

1. First wrote rootfs to wrong offset 0x350000 (defib's _NOR32M_LAYOUT)
2. Realized kernel uses hardcoded 8M layout, wrote rootfs again at 0x250000 — verified bit-perfect via CRC32 immediately after
3. Then erased "the old location" 0x350000 + 3.74 MiB — without checking that the new rootfs (0x250000..0x60BC00) overlaps with this range by 2.74 MiB

The erase wiped 2.74 MiB of the freshly-verified rootfs, leaving only the first 1 MiB at 0x250000..0x350000 intact. The kernel's squashfs driver reads the superblock fine (declares bytes_used=0x3BB44B, id_table_start=0x3BB443), but those offsets land in the wiped 0xFF region → panic.

This is an operator error in the script that calls the agent, not in the agent's primitives themselves (which were verified end-to-end at OpenIPC/defib#96 via U-Boot CRC32 cross-check). The agent's individual erase/write/CRC calls are bit-perfect; my driver script forgot to subtract the new write's footprint from the "old location" cleanup.

Re-flashing the rootfs without the overlapping erase right now. Will close this issue once the board boots OpenIPC. Apologies again for the false alarm — your QEMU repro setup made the diagnosis trivial.

[widgetii]

Closing — confirmed bug in my flashing pipeline (relocation script erased a region that overlapped with the freshly-written new rootfs). OpenIPC firmware boots cleanly. Re-flashing now without the overlapping erase. Thanks for the QEMU repro setup that made this trivial to diagnose.