[dimerr]

On an FH8626V100 camera, the fullhan release U-Boot boots the fh8626v100_lite kernel, and the kernel then panics without mounting root:

U-Boot 2022.10-g880e79e0 (Oct 26 2026 - 08:45:35 +0000)
CPU:   Fullhan fh8626v100 (ID 18112301/38607)
...
[    0.000000] Machine: FH8626V100
[    0.000000] Ignoring unrecognised tag 0x41000601
[    0.000000] Kernel command line: mem=29M ... mtdparts=spi_flash:256k(u-boot),64k(env),2048k(kernel),5120k(rootfs),7168k@0x50000(firmware),-(rootfs_data)
...
[    0.557533] Creating 6 MTD partitions on "spi0.0":
[    0.561788] 0x000000000000-0x000000010000 : "bootstrap"
...
[    1.235273] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)

OpenIPC runs FH8626V100 on the 4.9.129 fullhan-fh8852v200 kernel (OpenIPC/linux#53), but this port gave it the 3.0.8 parts' flash name. mtdids defaulted to spi_flash, the 3.0.8 m25p80 platform data's name. Under 4.9 the flash is the SPI device spi0.0, so the kernel ignored mtdparts=, fell back to the board's built-in table, and found its kernel partition at mtdblock3.

• The default is now spi0.0.
• An environment that an earlier build saved with exactly spi_flash is corrected at boot, so cameras that already ran saveenv recover without a manual step. This applies to FH8626V100 only; no other value and no other SoC is touched.

FH_ATAG_PHYMODE is unchanged. The 4.9 kernel only logs Ignoring unrecognised tag 0x41000601 for it, and a 3.0.8 vendor kernel booted by this U-Boot needs the tag for RMII.

Until a camera has this build, the workaround is to run at the U-Boot prompt:

setenv mtdids spi0.0; saveenv; reset

Testing. qemu-hisilicon's fh8626v100 machine booted the fh8626v100_lite image from flash through U-Boot:

U-Boot	environment	kernel mtdparts=	result
fullhan release	blank	spi_flash	VFS panic (reproduces the camera)
this branch	blank	spi0.0	login prompt
this branch	after setenv mtdids spi_flash; saveenv; reset	spi0.0	login prompt, and again on the next boot

fh8852v200 and fh8852v100 still build. FH8626V100's image is 221568 bytes, with 40576 spare. This build has not run on the camera yet.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Fix FH8626V100 flash naming for its 4.9 kernel

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Use spi0.0 for FH8626V100 flash partitions so the 4.9 kernel can mount root.

Diagram

graph TD
  Default["SFC default"] --> Scan["Firmware scan"] --> Check{"Missing or stale?"} -->|yes| Set["Set spi0.0"] --> Parts["Build mtdparts"] --> Kernel["4.9 kernel"] --> Root["Mount rootfs"]
  Check -->|no| Parts
  Config["FH8626 config"] -->|omit PHY tag| Kernel

Loading

High-Level Assessment

The SoC-scoped default and exact-match correction address both blank and previously saved environments without replacing other custom IDs. Removing the PHY tag selection only for FH8626V100 preserves the 3.0.8 targets' behavior.

Files changed (3) +29 / -6

Bug fix (3) +29 / -6

KconfigStop selecting the legacy PHY-mode tag for FH8626V100 +0/-1

Stop selecting the legacy PHY-mode tag for FH8626V100

• Removes 'FH_ATAG_PHYMODE' from the FH8626 generation. Its 4.9 kernel does not recognize this 3.0.8 Ethernet-driver tag.

arch/arm/mach-fullhan/Kconfig

openipc.cCorrect stale flash IDs during firmware scanning +23/-2

Correct stale flash IDs during firmware scanning

• Both firmware-scan partition layouts now replace a missing flash ID or, on FH8626V100 only, the exact saved value 'spi_flash' with 'SFC'. The corrected ID is also placed in the runtime environment before 'mtdparts' is built.

common/openipc.c

openipc-common.hDefault FH8626V100 flash partitions to spi0.0 +6/-3

Default FH8626V100 flash partitions to spi0.0

• Includes FH8626V100 among targets whose OpenIPC kernel names SPI flash 'spi0.0'. This changes its default 'mtdids' and 'mtdparts' while retaining the 3.0.8 naming for other targets.

include/configs/openipc-common.h

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Older camera kernels lose Ethernet ✓ Resolved

Description

Removing FH_ATAG_PHYMODE from FULLHAN_8626 prevents setup_board_tags() from passing the RMII
mode to an FH8626V100 kernel. When this U-Boot boots the documented 3.0.8 vendor kernel, its
Ethernet driver defaults to MII even though the board is configured for RMII.

Code

arch/arm/mach-fullhan/Kconfig[98]

-	select FH_ATAG_PHYMODE

Evidence

The target selects FULLHAN_8626, and setup_board_tags emits the RMII tag only when FH_ATAG_PHYMODE
is enabled. The repository's kernel hand-off documentation identifies FH8626V100 as a 3.0.8 tag
recipient and states that the older Ethernet driver uses MII without it; the board's U-Boot setup
remains RMII.

arch/arm/mach-fullhan/Kconfig[60-64]
arch/arm/mach-fullhan/soc.c[149-164]
CLAUDE.md[185-193]
board/fullhan/fullhan/fullhan.c[391-393]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Removing the FH8626V100 PHY-mode tag avoids a warning from the 4.9 kernel but changes the Ethernet mode seen by the documented 3.0.8 kernel.
## Fix Focus Areas
- arch/arm/mach-fullhan/Kconfig[95-99]
- arch/arm/mach-fullhan/soc.c[149-164]
## Recommended Fix
Retain the tag selection for FH8626V100 if booting the older kernel remains supported. If the 4.9 warning must be avoided, provide a kernel-specific hand-off that still supplies RMII mode when booting 3.0.8.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can route each severity your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[dimerr]

Qodo's finding is right: dropping FH_ATAG_PHYMODE had nothing to do with the flash name and would cost a 3.0.8 vendor kernel its RMII mode. I have taken it out of this PR (force-pushed, still one commit). The 4.9 kernel's Ignoring unrecognised tag 0x41000601 is harmless.

Re-tested in qemu-hisilicon fh8626v100:

• blank environment: mtdparts=spi0.0, login prompt;
• after setenv mtdids spi_flash; saveenv; reset: mtdparts=spi0.0, login prompt.

[qodo-free-for-open-source-projects]

Qodo's finding is right: dropping FH_ATAG_PHYMODE had nothing to do with the flash name and would cost a 3.0.8 vendor kernel its RMII mode. I have taken it out of this PR (force-pushed, still one commit). The 4.9 kernel's Ignoring unrecognised tag 0x41000601 is harmless.

Re-tested in qemu-hisilicon fh8626v100:

• blank environment: mtdparts=spi0.0, login prompt;
• after setenv mtdids spi_flash; saveenv; reset: mtdparts=spi0.0, login prompt.

Thanks for confirming. finding 1 is addressed: FH_ATAG_PHYMODE remains available for the 3.0.8 vendor kernel, while the harmless 4.9 warning is accepted. Your mtdids regression test also confirms the stale spi_flash value is corrected to spi0.0.