[dimerr]

test-fullhan-boot.sh gives any SoC name ending in v100 the 3.0.8 kernels' spi_flash MTD id. FH8626V100's kernel is 4.9.129 (OpenIPC/linux fullhan-fh8852v200, OpenIPC/linux#53), and there the flash is spi0.0. The mtdparts= was therefore ignored, the board's built-in partitions were used, and no root was mounted (VFS: Unable to mount root fs on unknown-block(31,3)).

With this change, an OpenIPC fh8626v100_lite image passes all five checks on the fh8626v100 machine. The 3.0.8 boards (fh8852v100, fh8856v100, fh8833v100) still get spi_flash.

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

PR Summary by Qodo

Use spi0.0 for FH8626V100 QEMU boot partitions

🐞 Bug fix 🕐 Less than 10 minutes

AI Description

• Select FH8626V100’s kernel MTD ID so its flash partition layout is recognized.
• Preserve spi_flash for the 3.0.8 v100 boards.

Diagram

graph TD
  SOC["SoC name"] --> FH{"FH8626V100?"} -->|Yes| SPI["spi0.0"] --> PARTS["mtdparts argument"]
  FH -->|No| V100{"Other v100?"} -->|Yes| LEGACY["spi_flash"] --> PARTS
  V100 -->|No| SPI

Loading

High-Level Assessment

The exact-match override is the smallest appropriate fix for this boot test: it corrects FH8626V100 without changing the legacy v100 selection. Sharing MTD-ID selection with the separate flash-image script would broaden this PR’s scope.

Files changed (1) +1 / -0

Bug fix (1) +1 / -0

test-fullhan-boot.shSelect spi0.0 for FH8626V100 +1/-0

Select spi0.0 for FH8626V100

• Adds an exact SoC match ahead of the v100 suffix rule, so FH8626V100 passes its kernel’s spi0.0 MTD ID in mtdparts. Other v100 boards retain spi_flash.

qemu-boot/test-fullhan-boot.sh

[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. Generated FH8626V100 images miss their root partition ✓ Resolved

Description

The new fh8626v100 selection passes spi0.0, but fh-openipc-flash.sh still embeds spi_flash
in generated image boot arguments for every *v100 SOC. Booting a generated FH8626V100 image
through its stored bootargs therefore uses the wrong MTD master, leaving the intended partitions
unavailable to root=/dev/mtdblock3.

Code

qemu-boot/test-fullhan-boot.sh[48]

+    fh8626v100) MTDID=spi0.0 ;;        # 4.9.129, despite the suffix

Evidence

The changed script selects spi0.0 specifically for FH8626V100, while the companion image builder
independently generates mtdparts using spi_flash for all V100 SOCs. That builder's boot
arguments are consumed when the generated image is booted, so the new exception is not propagated to
a directly related path.

qemu-boot/fh-openipc-flash.sh[58-65]
qemu-boot/test-fullhan-boot.sh[48-54]
.github/workflows/ci.yml[1287-1311]
docs/fullhan.md[150-155]

Agent prompt

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

## Issue description
The boot test now treats `fh8626v100` as a 4.9 kernel whose flash MTD name is `spi0.0`, but `qemu-boot/fh-openipc-flash.sh` still maps every `*v100` SOC to `spi_flash`. Images generated for FH8626V100 retain the wrong `mtdparts` boot argument and can fail to mount the intended root partition.
## Fix Focus Areas
- qemu-boot/fh-openipc-flash.sh[59-62]
- qemu-boot/test-fullhan-boot.sh[48-50]
## Recommended Fix
Apply the same exact-match exception in `fh-openipc-flash.sh` before its wildcard `*v100` case, selecting `spi0.0` for `fh8626v100` and retaining `spi_flash` for the 3.0.8 V100 boards. Update the related comments and documentation to record the exception, and add FH8626V100 to the boot-test CI matrix so the generated-image and synthetic-kernel paths are validated.

ⓘ 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 turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[dimerr]

Qodo's finding is right, and the fix is in 4fe304c: fh-openipc-flash.sh gets the same fh8626v100 → spi0.0 arm ahead of *v100. I have not added it to boot-fullhan's matrix: that job boots the published openipc.<soc>-nor-lite.tgz, and there is none for fh8626v100 until OpenIPC/firmware#2714 is merged and released.

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

Qodo's finding is right, and the fix is in 4fe304c: fh-openipc-flash.sh gets the same fh8626v100 → spi0.0 arm ahead of *v100. I have not added it to boot-fullhan's matrix: that job boots the published openipc.<soc>-nor-lite.tgz, and there is none for fh8626v100 until OpenIPC/firmware#2714 is merged and released.

Understood. Finding 1 is resolved by commit 4fe304c, which adds the fh8626v100 → spi0.0 exception in fh-openipc-flash.sh. Leaving fh8626v100 out of the boot-fullhan matrix is reasonable until openipc.fh8626v100-nor-lite.tgz is published after OpenIPC/firmware#2714.