Fimeg/SouveraineOS
Watch
1
0
Fork
You've already forked SouveraineOS
 0
Code Releases Activity

task-46: rear IMX363 NACKs at 0x10, moved to 0x1a

Browse source 
And the lesson that cost the front camera: camss creates all sensor->csiphy
links in the async notifier's .complete, which needs every declared subdev to
bind. One non-probing sensor leaves the working front pair registered with zero
links. Never leave a failing sensor node enabled; a rear-disabled DTB is parked
on the device for one-cp recovery.
This commit is contained in:
Fimeg 2026-08-01 13:57:05 -04:00
commit 11668f097f
1 changed files with 32 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

39
docs/tasks/46-camera-imx363.md
View file

@ -90,15 +90,38 @@ ones trustworthy:
Verified by compiling the DTB: 117,471 bytes, no new warnings, every phandle
and lane value correct in the decompiled output.
## The one guess in it
## The one guess in it — ANSWERED 2026-08-01, and it cost the front camera
**The slave address.** 0x10, which is what Xiaomi beryllium uses for the same
IMX363. If it NACKs, try **0x1a** — the front pair on CCI1 sits at 0x10/0x1a,
and the rear is alone on its bus so the default is likely. The vendor's own
`com.qti.sensor.imx363.so` was extracted from `vendor.img` looking for the
authoritative value; the address is not in it (10 KB wrapper) and the
`sensormodule` bin holds only a name table. Not worth more archaeology — dmesg
answers it in one boot.
**The slave address.** 0x10 was Xiaomi beryllium's for the same IMX363, and the
address is in neither the downstream DTBO nor the eeprom node `cam-sensor@0`
points at (`qcom,eeprom@1`, phandle 0x25, `cci-master = <0x00>` — confirms CCI0,
carries no `slave-addr`). On glass, `0x10` NACKs:
```
imx363: 4 lanes
imx363 16-0010: Error reading reg 0x0016: -6
imx363 16-0010: failed to read chip id 363
```
`-ENXIO`, and `imx363_probe()` calls `imx363_power_on()` *before*
`imx363_identify_module()`, so the rail, reset and MCLK were all exercised and
nothing answered. Moved to **0x1a** (`8fc7623a3`), the remaining candidate.
**The expensive lesson is what a failed sensor probe does to the others.**
`camss_subdev_notifier_complete()` creates every sensor→csiphy link, and
`.complete` only fires once *all* declared async subdevs have bound. The rear
sensor never bound, so the notifier never completed, so **no** sensor links were
created — the front pair stayed registered (`entity 235/237`) with **0 links**
each, and the working front camera stopped working. Adding a broken sensor is
not a contained failure on this driver.
Practical consequence: never leave a non-probing sensor node enabled. A DTB with
the rear `status = "disabled"` is kept on the device as
`/boot/dtbs/sdm845-google-blueline.dtb.rear-off` for exactly this — it restores
the front camera in one `cp` and a reboot.
The DTB is loaded separately by extlinux (`fdt /boot/dtbs/...`), so testing an
address costs a DTB build and a reboot, not a kernel rebuild.
## Acceptance