Repository navigation
ambarella: S3L machine, so ipctool and load_ambarella run without the camera - #233
Conversation
… camera An `s3l` machine for the Amcrest IP4M-1026E / Dahua IPC-HFW1430SN: a Cortex-A9 with the Ambarella VIC, timers, RCT and IDC I2C, the map from the vendor kernel's ambarella-s3l.dtsi. With -kernel the machine generates the device tree, including /iavmem. There is no video. The point is testing software nobody here has the hardware for: a kernel built from OpenIPC/linux boots to userspace, ipctool reports what the camera in OpenIPC/ipctool#266 reported (S3L, total 512M, media 392M, OV4689 on bus 0 at 0x6c), and the firmware's load_ambarella loads the shipped modules through modules.dep and makes /dev/iav and /dev/ucode. The PLLs reset to that camera's rates. On S3L the kernel takes interrupts from one scratchpad register, and all ones there means none. iav.ko oopses without an /iav/vinc0 node, and the UART driver refuses to probe with no default pin state. test-ambarella.py drives the models over qtest in CI. It found a timer that re-armed at the same instant for ever, which the boot did not hit. test-s3l-boot.sh needs a kernel build and a firmware tree, so it does not run in CI.
PR Summary by QodoAdd an Ambarella S3L QEMU machine for ipctool and module testing
AI Description
Diagram
High-Level Assessment
Files changed (13)
|
Code Review by Qodo
1.
|
|
Hold this please, I want to test, and I have many of the offsets and registers already investigated, so I can audit. |
|
Cross-checked against the IP4M-1026E with the s3l_lite toolchain image (#2764): the RAM split, clocks and the 0600 device nodes match. One difference: on the board, the OV4689 doesn't answer I2C at boot because XSHUTDN (GPIO 107, active low) holds it in reset, so load_ambarella reports no sensor detected. The emulated sensor answers immediately, so this test passes where the hardware currently fails. Modelling the sensor as held in reset until the VIN reset GPIO is released (and adding that GPIO to /iav/vinc0) would let the bench catch it. |
A write under a tick after the last no longer loses the part tick already counted, so a guest that keeps writing cannot hold an expiry off. A reloading timer repeats no faster than 1 us, so RELOAD 0, the reset value, cannot pin the host. A guest reset lowers the VIC's outputs. -m is refused above where the peripherals start. The machine registers through DEFINE_MACHINE_EXTENDED like the others. test-s3l-boot.sh now reads the second load_ambarella's exit status, which it never did. With --cc it builds the firmware's load_ucode and runs it against the real dsp.ko with made-up microcode: offsets, the version back through the driver, and bad sets leaving the window as it was.
|
Qodo's findings are addressed in the new commit, with one exception:
|
On the IP4M-1026E the OV4689's XSHUTDN is GPIO 107, active low, and nothing drives it at boot, so it does not answer on I2C and load_ambarella finds no sensor. The machine answered at once, so the boot test passed where the board fails. amb-gpio models the four banks, with a pinctrl node and vinrst-gpios in the device tree. I2C0 now acknowledges nothing until GPIO 107 is an output driven high. sensor-reset=off is a board with no such line. test-s3l-boot.sh boots as the camera first: no sensor, then found once GPIO 107 is released from sysfs. The rest of its checks need sensor-reset=off, because nothing in the firmware releases the line at boot yet.
|
Holding this as you asked, and I won't merge until you've finished your audit. Please do flag any offsets or registers that disagree with your findings. Thanks for the cross-check. Your result is the most useful one so far, so I've made the bench reproduce it. What changed in the latest commit:
That's because the firmware problem itself is still open. As far as I can tell from the driver, Questions, since you have the hardware:
|
iav.ko takes the flag as the level it resets with, so a line held low has flag 0, whatever OF_GPIO_ACTIVE_LOW suggests. The boot test now has load_ambarella release the sensor from the device tree, with the firmware change that does that.
|
Thanks for adding the reset modelling. Here are answers from the hardware (IP4M-1026E, current OpenIPC build, netbooted): 2. Does anything drive GPIO 107 before the first VIN mode set? Yes: the sensor module does, when it loads. From So it isn't iav waiting for a VIN mode: 1. How I plan to release it. The board DTS carries 3. Audit. After boot, 107 reads low as an input (claimed, not driven). 105 and 106 are outputs driven low. Stock drives 105/106/107 high, but only 107 gates the sensor. With it low, For the bench, modelling "107 follows the sensor module's insert/remove" instead of a sysfs write would reproduce the real sequence. The second boot could then use |
Measured on the IP4M-1026E: loading ov4689_mipi drives GPIO 107 high and removing it drives it low, with no VIN mode set, which corrects what the docs said. The bench did not do that because the driver binds to an ambvin0@01 node under I2C0, and without one it loads and never probes. test-s3l-boot.sh's second boot now sets sensor= in the environment, as a board profile will, instead of sensor-reset=off, so the real driver releases the line.
|
Thanks, that's exactly what I needed, and it corrects me. I'd said The bench now reproduces your sequence with the real driver, and there's no sysfs step: It didn't work before because the driver binds to Your DTS value, This stays on hold until you've finished your audit. One question for OpenIPC/firmware#2768: does a sensor answer I2C if 107 is driven high with no module loaded, for example by exporting the pin in sysfs? Your note reads that way, and it decides whether that PR's probe path is worth having alongside your |
On hold at the reporter's request, while they audit the offsets and registers against their own work.
Adds an
s3lmachine for the Amcrest IP4M-1026E / Dahua IPC-HFW1430SN, so the Ambarella work in OpenIPC/ipctool#266 and OpenIPC/firmware#2764 can be tested without the reporter's hardware.It's a Cortex-A9 with the Ambarella VIC, timers, RCT and IDC I2C, at the addresses in the vendor kernel's
ambarella-s3l.dtsi. With-kernel, the machine generates the device tree, including/iavmem. There is no video: nothing models the DSP, VIN or encoder.Tested with a kernel built from
OpenIPC/linuxbranchambarella-s3land firmware'ss3l.generic.config:-M s3lipctoolchipAmbarella/S3Ltotal: 512M,media: 392M0x6c/proc/ambarella/clockThe firmware's real
load_ambarellaalso ran here with the shipped modules, which stubs couldn't cover.modprobe iavresolved its dependencies throughmodules.dep,ov4689_mipiloaded,/dev/iavand/dev/ucodeappeared as248:0and248:1with mode 600, and the script logged that no microcode is present. A second run was harmless.Checks:
qemu/tests/test-ambarella.pydrives the models over qtest and runs in CI. It found a real bug: a timer could re-arm at the same instant for ever, which the boot never hit.qemu-boot/test-s3l-boot.shpasses all 15 checks locally. It needs a kernel build and a firmware tree, so it doesn't run in CI.test-sigmastar.pyandtest-gk710x.pystill pass, since the sensor catalogue changed.What this doesn't prove:
/proc/device-tree, so ipctool reads the boot log there. Only the reporter has run that.s3l_litetoolchain, thoughload_ucodeis built with that toolchain. A fulls3l_liteimage did boot on this machine separately.load_ambarellasensor checks run withsensor-reset=off, because nothing in the firmware releases GPIO 107 at boot yet.setup.shfrom a clean tree isn't proven locally, because it hits the documented GCC 15libfdtfailure on this machine. CI's build is the check for that.-mmust be over 120 MiB, so the-m 64Msmoke test inCLAUDE.mdneeds its default RAM for this machine.