Repository navigation
lite <-> ultimate without a UART: sysupgrade on the 16 MB layout, ipctool on the 8 MB one - #599
Merged
Merged
Conversation
…tool on the 8 MB one A page, in English and Russian, for moving a 16 MB NOR camera between lite and ultimate and back over the network, keeping its settings. What to do depends on the flash layout the camera already has, read off /proc/mtd: - 16 MB layout: sysupgrade --url with the other variant. --force_ver is needed because a night's lite and ultimate carry the same version, and without it sysupgrade writes nothing. A device profile also needs --force_soc. - 8 MB layout on a 16 MB chip: ipctool upgrade with a --layout bundle, which repartitions in place, keeps the bootloader and carries the settings. Also covers a full-flash backup taken first, a rehearsal of the whole move on that backup in qemu-hisilicon, what ipctool refuses before touching anything, going back to lite, and what to send when something goes wrong.
Collaborator
Author
|
/review |
Code Review by Qodo
1. The guide exposes private internals
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
Comment on lines
+169
to
+176
| Before stopping anything it prints what it will do: | ||
|
|
||
| ``` | ||
| Keeping boot (256 KB) | ||
| Keeping env (64 KB) | ||
| Settings: 56 entries in 576 of 2752 KB | ||
| bootargs will be: ... mtdparts=hi_sfc:256k(boot),64k(env),3072k(kernel),10240k(rootfs),-(rootfs_data) ... | ||
| bootcmd will be: ... sf read ... 0x50000 0x300000 ... |
There was a problem hiding this comment.
1. The guide exposes private internals 📘 Rule violation ⛨ Security
The migration pages publish bootloader environment fields, flash-read command details, and verbatim diagnostic output instead of limiting the explanation to observable upgrade behaviour. Any reader of the public English or Russian page can use these internal names and exact messages to inspect implementation details that the checklist prohibits publishing.
Agent Prompt
## Issue description
The public migration guide includes internal bootloader fields, flash-read details, and verbatim diagnostic messages, which violates the requirement to document closed components through externally observable behaviour rather than implementation internals.
## Fix Focus Areas
- en/lite-ultimate-migration.md[62-66]
- en/lite-ultimate-migration.md[169-191]
- ru/lite-ultimate-migration.md[62-64]
- ru/lite-ultimate-migration.md[167-189]
## Recommended Fix
Rewrite the affected sections using user-observable outcomes and operator actions. Describe that the tool preserves required boot data and refuses unsupported layouts without naming bootloader variables or flash-read commands, and summarize refusal conditions without reproducing exact internal log lines.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Collaborator
Author
There was a problem hiding this comment.
Not changing this one, and here's why. That rule covers components developed in closed repositories, which this wiki documents by behaviour only. Everything this page names comes from open-source software whose interfaces are its user-facing behaviour:
bootargs,bootcmd,sf readandfw_printenvare U-Boot's, public and documented elsewhere in this wiki (help-uboot.md, u-boot-settings.md).- The quoted messages are what OpenIPC/ipctool prints on the operator's terminal; its source is public.
Same version, nothing to updateis what the firmware's sysupgrade prints.
Quoting them verbatim is deliberate: the refusal table only works if a reader can match the line on their screen to its meaning. No closed component is named or described here.
… the variant Three findings from review, in both languages: - The backup named five mtd devices, so a camera with another partition table got a short file and failed the size check the page asks for. It now reads every partition /proc/mtd lists, in order, as the backup page does. - The upgrade address survives a move. One that names the variant being left would bring it back on the next sysupgrade -k -r. The page now has the reader check fw_printenv upgrade and replace the address with -e when it is set, or with fw_setenv after a profile's sysupgrade. - Going back to lite showed the generic image even where it offered the route to device profiles, which need their own builder lite image.
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.
A page, in English and Russian, for moving a camera with 16 MB NOR between lite and ultimate and back, over the network, keeping its settings. Ultimate is where the CPU person detector ships, and object detection and PTZ Follow on NPU-less chips need it. Until now, moving a camera there meant a UART and a reflash.
What the page covers
Which case you're in, read off
/proc/mtd: chip size, then the size ofrootfs.16 MB layout already (
rootfs10 MB):sysupgrade --url=<the other variant> --force_ver.--force_vermatters: a night's lite and ultimate carry the same version, and without it sysupgrade prints Same version, nothing to update and reboots having written nothing.--force_socand its own builder image.8 MB layout on a 16 MB chip (
rootfs5 MB):ipctool upgradewith a bundle fromtools/upgrade_bundle.py --layout nor16m. It repartitions in place, keeps the bootloader and everything in front of the kernel, edits the bootloader environment, and carries/overlayacross. For device profiles,-e upgrade=points future upgrades at the right image.Before you start
Also: what ipctool refuses before touching anything, and what each message means;
--wipe-settingsand the unclaimed camera it leaves; going back to lite (nor8m); what to send if something goes wrong, keeping the backup private.Depends on
upgrade --layout.mtdparts=${mtdparts}andsf read ${baseaddr} .... Until it is merged, those cameras get a refusal with nothing written, so the 8 MB-layout path only works there afterwards.Tested
Every command path on the page was run:
/overlaywas byte-identical afterwards, except the two the firmware rewrites on every boot.sysupgrade --url ... --force_verfrom the GitHub releases, ultimate → lite → ultimate, settings kept. The run without--force_veris where the Same version trap was found.