Telling a camera about its own hardware: the settings route and the device-profile route - #551
Merged
Merged
Conversation
A mainline image is built for an SoC family, so it knows nothing about where a particular camera's IR-cut filter is wired or which pad powers its SD card. Three files supply that, and none of them were documented anywhere: a reader could find en/gpio-settings.md listing a board's pin numbers and had no page telling them where those numbers are supposed to go. The consequence shows up in review. Somebody with a new camera writes a fresh init script with the pin numbers typed into it, or drops a customizer.sh into the shared firmware overlay where it reaches every camera of every vendor, because nothing pointed at the seam that already exists. That is not a mistake a contributor can be expected to avoid unaided. The page covers what runs when -- customizer.sh once behind /etc/custom.ok, muxes.sh on every boot because pad multiplexing does not survive a power cycle, gpio.conf sourced rather than executed -- what belongs in each, and why they live in OpenIPC/builder under the device's own directory rather than in the firmware tree. It ends with a worked example and the four things that actually go wrong, including the one that catches everyone: a factory reset clears the overlay and with it /etc/custom.ok, so the device re-applies its defaults from scratch on the next boot. Figures in the page were counted from builder as it stands: 96 devices ship a customizer.sh, 18 a gpio.conf, 15 a muxes.sh, and seven pin names appear in every one of those gpio.conf files. Cross-linked both ways with gpio-settings.md and finding-a-gpio.md, which are where a reader arrives with a pin number and no idea what to do with it.
PR Summary by QodoDocument per-device board settings and boot lifecycle
AI Description
Diagram
High-Level Assessment
Files changed (4)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
…rity The page presented device profiles as the way to tell a camera about its hardware, with the web interface mentioned only in passing. That is backwards for most readers: somebody with one camera in front of them sets the IR-cut pins on Settings -> Day / Night and declares a pad on Settings -> Pins, and never writes a file at all. The three profile files are for the person who wants the hundredth unit of a model to come up right with nobody there. Both now get a section of their own, with a table up front so a reader can tell in one glance which one they want. The honest framing is that they are not alternatives: a profile mostly consists of the very writes the interface would have made. The one real difference is worth its own row and its own troubleshooting entry, because it catches people -- a factory reset clears the overlay, so settings made on the camera do not come back and settings carried by a profile do. Retitled accordingly, since "customizer.sh, muxes.sh and gpio.conf" no longer describes half of what the page covers, and relinked from the table of contents and the two GPIO pages. The bot review caught a real contradiction: the gpio.conf snippet drove mmc_pwr low as "power enable" while the worked example drove the same named rail high. Both were copied from real devices, so the fix is not to pick one -- polarity is board-specific and gpio.conf records which pad, never which level. Said so, with both examples now labelled which way their board goes. Also removed a duplicated warning about cli -s silently accepting a mistyped path; it belongs with the settings route, and the profile section now points back at it with the reason it is worse there -- nobody is at the interface to notice the switch did nothing.
openipc-ai
changed the title
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.
Problem
An OpenIPC image is built for an SoC family, so it ships no knowledge of where a
particular camera's IR-cut filter is wired, which pad powers its SD card, or where it
should fetch its next firmware from.
There are two ways to tell it, and the wiki documented neither in one place:
clioverSSH. This is how most people actually do it, and
en/finding-a-gpio.mdexplains howto find a pin without ever saying where the answer goes.
customizer.sh,muxes.shandgpio.confinOpenIPC/builder, so every unit of a model comes
up right with nobody there. These three files were documented nowhere at all.
The gap has a visible cost.
en/gpio-settings.mdlists pin numbers for dozens of boardsand never says where they go, so somebody bringing up a new camera writes a fresh init
script with the pins typed into it, or drops a
customizer.shinto the shared firmwareoverlay — where it reaches every camera of every vendor. That came up again on
OpenIPC/firmware#2446, which did both.
What the page covers
Both routes get a section of their own, with a comparison table up front so a reader can
tell in one glance which one they want. The honest framing is that they are not
alternatives: a device profile mostly consists of the very writes the web interface
would have made, made before you ever open it.
The difference that actually matters gets its own table row and its own troubleshooting
entry, because it catches people: a factory reset clears the overlay, so settings
made on the camera do not come back and settings carried by a profile do.
On the profile side: when each file runs and why they differ (
customizer.shoncebehind
/etc/custom.ok;muxes.shon every boot, because pad multiplexing is aregister that does not survive a power cycle;
gpio.confnever — it is sourced), whereS30customizersits in the boot order, what belongs in each, why they live in builder,a worked example, and the four things that go wrong.
Accuracy
Every figure was counted from OpenIPC/builder and OpenIPC/firmware as they stand rather
than recalled: 96 devices ship a
customizer.sh, 18 agpio.conf, 15 amuxes.sh; thefw_setenvfrequencies are per-variable counts across those 96; and seven pin names(
button,ircut1,ircut2,led1,led2,light_ir,mmc_pwr) appear in all 18gpio.conffiles, with six more on 16–17.Three things I had written were wrong and were removed rather than shipped: a
gpio_buttonenvironment variable (set by no device and read by nothing — the resetbutton is
buttoningpio.conf); a claim that all thirteen common pin names appear onall 18 devices; and a statement about when a kept pin choice is re-applied, which I
could not support from anything a reader can observe, so the page now describes only
Try / Keep and that a kept choice is saved.
Review
The bot review found a real contradiction: the
gpio.confsnippet drovemmc_pwrlowas "power enable" while the worked example drove the same named rail high. Both were
copied from real devices, so making them agree would have been consistent and still
wrong for half the boards. The page now states that polarity is board-specific and that
gpio.confrecords which pad, never which level, with both examples labelled.Checks
All five cross-page links resolve, and all four in-page anchors match a heading. Added to
the table of contents and cross-linked both ways with
gpio-settings.mdandfinding-a-gpio.md, which are where a reader arrives holding a pin number with nothingto do with it.