agent: upload natively to gk7205v500/v510/v530 - #145
Merged
Merged
Conversation
The V500 bootrom has no SPL stage and these chips have no profile, so `defib agent upload` had no way onto them. It now builds a V500 boot image around the agent: key area, params and aux (DDR init) area from a donor OpenIPC u-boot-xmedia image (downloaded and cached, or -f), the agent in the boot-code slot, and the boot-code/total length fields patched. The bootrom runs that slot *in place* after a UART download, at 0x41000000 + 0x2000 key area + 0x5000 aux area = 0x41007000. The image's own entry field (0x40707000, where U-Boot's position-independent decompressor stub expects to end up) is not used on this path: a 144-byte probe in the slot printed pc=0x41007000, lr=0xad8 (bootrom). So the gk7205v500 agent links at 0x41007000, and wrap_v500_payload checks the link address against the donor's actual code offset. Getting READY also needed the GD5F1GM7 recognised as a SPI NAND. Only MX35LF was, so any other NAND fell through to the NOR path, and there flash_global_unlock() polled a NOR status register the NAND does not implement: on GD5F1GM7 (ID reads 00 C8 91) "WIP" never clears and the agent hung before READY. UART breadcrumbs placed through startup.S, main() and flash_init() pinned it there. nand_identify() now takes a table: MX35LF1GE4AB, W25N01GV (EF AA, third ID byte lost to the dummy byte), GD5F1GM7 3.3 V/1.8 V — all 1 Gbit / 2 KiB / 64-page blocks, the geometry flash_init already assumes. Verified on hardware: - GK7205V510 (chip ID 0x72050510) with GD5F1GM7 NAND and working vendor firmware, Tasmota-cycled: `defib agent upload -c gk7205v510 --power-cycle` -> READY; `agent info` JEDEC 00c891, 128 MiB, 128 KiB blocks; `agent read -a 0x10000000 -s 0x100` dumps the FMC registers (FMC_CFG 0x1821, version 0x100 at +0xBC). - hi3516ev300 with W25N01GV, previously reported as 16 MiB NOR: now 128 MiB NAND with 128 KiB blocks; `agent upload --power-cycle` + info. - The stock u-boot-gk7205v510-nor.bin donor RAM-boots on this board (System startup / DRAM 128 MiB / download mode); the gk7205v500 donor does not, so -c must name the actual chip.
PR Summary by QodoEnable native flash-agent upload on GK7205V500-family chips
AI Description
Diagram
High-Level Assessment
Files changed (10)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
Review (Qodo) of the V500 upload path: - Without --power-cycle the V500 handshake has no deadline of its own, so an unplugged board hung the CLI forever. The manual wait is now bounded (60 s) and reported as a handshake failure. - The serial transport was opened outside any cleanup scope, after RouterOS port discovery may already hold a session open; a port that failed to open leaked it. Opening is now covered and closes the power controller on failure. - The handshake reports the chip ID, but only .success was checked. A -c that names a different family member than the board picks a donor whose DDR init cannot bring the board up, and the failure then blamed the donor. The reply's chip ID is now compared with -c (unless -f gives an explicit donor) and a mismatch names the detected chip before anything is uploaded. 0x72050510 is from a real GK7205V510; the v500 and v530 IDs follow the pattern and are not yet seen on hardware — an unknown ID skips the check rather than block the upload. - -c GK7205V510 passed every lookup but built an uppercase donor asset name that does not exist; the name is now lowercased. Re-verified on the GK7205V510: `defib agent upload -c GK7205V510 --power-cycle` -> READY, 128 MiB NAND.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Phase 0 of the NAND ECC study for OpenIPC/firmware#2285 / #2519: get the flash agent onto the V500 family, which had no path at all (no SPL stage, no profile JSON by design).
How
agent upload -c gk7205v5x0builds a V500 boot image around the agent. The key area, params and aux (DDR-init) code come from a donor OpenIPC u-boot-xmedia image, auto-downloadedu-boot-<chip>-nor.binor-f. The agent goes in the boot-code slot, with the length fields patched (wrap_v500_payload).0x41007000(load address + 8 KiB key + 20 KiB aux). It does not use the header's entry field (0x40707000). A 144-byte probe in the slot printedpc=0x41007000 lr=0xad8. The newgk7205v500agent stanza therefore links there, and the wrap checks the link address against the donor's code offset.nand_identify()now uses a table: MX35LF, W25N01GV, and GD5F1GM7 (3.3 V / 1.8 V). An unknown NAND fell into the NOR path, which hung forever inflash_global_unlock()polling a NOR WIP bit that a NAND never clears. UART breadcrumbs placed through startup →main→flash_initpinned it down.--power-cycle/--poe-portgo through the shared helper from power: drive Tasmota plugs and HTTP relays; v500: continuous handshake #144 (proactive ordering).Verified on hardware
0x72050510, GD5F1GM7 NAND, working vendor firmware), Tasmota-cycled:defib agent upload -c gk7205v510 --power-cycle→ READY.agent inforeports JEDEC00c891, 128 MiB, 128 KiB blocks.agent read -a 0x10000000 -s 0x100dumps the FMC registers (FMC_CFG 0x1821, version0x100).-cmust name the actual chip.Checks: pytest 952 passed, ruff, mypy,
make -C agent test,all-socsplus cleangk7205v500/hi3516ev300builds, JS tests.