Repository navigation
Add s3l_ultimate_amcrest-ip4m1026e (Ambarella S3L, OV4689) - #228
DeathCamel58 wants to merge 1 commit into
Conversation
PR Summary by QodoAdd Amcrest IP4M-1026E Ambarella S3L device profile
AI Description
Diagram
High-Level Assessment
Files changed (7)
|
Code Review by Qodo
1. Image uses the larger flavor without a size reason
|
openipc-ai
left a comment
openipc-ai
left a comment
There was a problem hiding this comment.
Nice work. The layout and the boot-counter handling are well reasoned, and the testing is thorough. I checked:
- Offsets. 768k + 128k + 64k =
0xf0000for the kernel, then 2048k + 8192k + 15872k puts the end ofrootfs_dataat0x1a70000, so the counter byte at0x1a80000sits inside the read-onlydahuapartition. - Slot sizes.
FLASH_SIZE="32"takes firmware's ≥16 MBrepackbranch: the same 2048K / 8192K slots asmtdparts. - Excludes name.
s3l_ultimate.listmatches the${OPENIPC_SOC_MODEL}_${OPENIPC_VARIANT}lookup inrootfs_script.sh. - Customizer. It runs once (gated on
/etc/custom.ok), andsysbackupis in the U-Boot env, so it survivesfirstboot. - Defconfig. It diverges from firmware's
s3l_ultimateonly where it should: 32 MB, no UBI, no WiFi or motors, and the fragment.
A few things before merge:
- An OpenIPC-to-OpenIPC upgrade. All the flashing so far went through the Dahua U-Boot's TFTP path. Every owner will update with
sysupgrade, using the URL the customizer sets, and this layout puts the kernel at0xf0000rather than the usual0x50000. Could you run onesysupgradeon the camera (local files are fine, e.g.sysupgrade --kernel=... --rootfs=...) and paste the output, plus the boot that follows? BR2_LINUX_KERNEL_UIMAGE_LOADADDR="0x00208000". Firmware'ss3l_ultimatedoesn't set it. Please add a one-line comment saying why this board needs it (I assume it's where the Dahua U-Boot's bootcmd loads the kernel).sysbackupfailure mode, FYI rather than a request.S30customizertouchescustom.okwhatever the script's exit status, so iffw_setenv sysbackup 0ever failed it would not be retried. The counter would keep running and the camera would drop to Dahua's backup system after ~4 boots. It worked on your camera, so this is low risk; just noting that it has no retry.- Nits: a double blank line in the kernel fragment, and a stray
#and blank line beforeexit 0incustomizer.sh.
The Amcrest IP4M-1026E (Dahua IPC-HFW1430SN): S3L, OV4689 over MIPI, 32 MiB SPI-NOR, Ethernet only, IR-cut and IR LEDs with an ADC light sensor. - s3l_ultimate with this board's kernel fragment: the SPI-NOR controller, the board DTB appended to the uImage (the Dahua U-Boot passes ATAGs), and a command line whose layout keeps the Dahua boot area, its environment and partition table, puts the kernel at 0xf0000 where its U-Boot reads it, and ends rootfs_data at 0x1a70000. The flash after that stays stock (dahua, ro): the Dahua U-Boot writes a boot-state record into the stock updateflag partition there on every boot. - Majestic as the streamer, with its fonts and web UI, as s3l_ultimate has them. - The customizer names the sensor (it is held in reset until its driver loads), sets the upgrade URL, sets sysbackup=0 in the Dahua U-Boot env, and sets up Majestic's night mode: IR-cut 113/111, IR LEDs on 5, and day/night from the light sensor on ADC channel 1 (which reads higher in light, hence adcInvert). - gpio.conf for the button, IR-cut, IR LEDs and light sensor. - Excludes drop the sensor and video-out modules this board can't use. Tested on the IP4M-1026E with firmware master (35c75dc3): the NOR build fits (uImage 1604K/2048K, rootfs 5072K/8192K) with only ov4689_mipi left of the sensor drivers; netbooted, the customizer writes Majestic's night-mode settings, and /night/on and /night/off move the IR-cut filter and IR LEDs. With Majestic master+f2fa260, it starts preview from a fresh boot and streams H.265 2688x1512 at 30 fps with its 3A; it reads the light sensor (night_mode_source 3), and covering the sensor (ADC ~15) switches to night and uncovering it (~2870) back to day. Flashed over the Dahua U-Boot's TFTP upgrade (every write read back), the NOR build of this profile boots with its own layout: the overlay on rootfs_data, the customizer's settings in fw_env and majestic.yaml, and a test file surviving reboots. From a fresh boot, Majestic (master+e6ba340) streams H.265 2688x1512 at 30 fps and reads the light sensor. An OpenIPC-to-OpenIPC sysupgrade from the profile's archive (--archive, -z) wrote and verified the kernel at 0xf0000 and the rootfs at 0x2f0000 and rebooted into them with the settings, sysbackup=0 and the counter kept. An earlier lite build of the profile also went stock -> OpenIPC -> stock -> OpenIPC. It is the first Ambarella device here, so ci-matrix.py gets it in SMOKE_TARGETS: --self-test requires one target per SoC vendor. sysbackup=0: the Dahua U-Boot counts boots in a byte at 0x1a80000 and, on reading 5, boots its backup system from the stock backupker/backupfs instead of OpenIPC. Stock clears the count after every good boot; OpenIPC does not, so from the factory value (2) it would fall back within a few reboots. sysbackup=0 turns the counting and the backup boot off; U-Boot's TFTP upgrade path does not read it. Tested on the flashed image: with the flash set leaving sysbackup=1 and the count at 0, U-Boot counted the first boot (err_count 00 -> 01), the customizer set sysbackup=0, and over the next three boots U-Boot printed no err_count and the count stayed at 01.
9b07731 to
57c043e
Compare
|
Thanks for the careful review. I've force-pushed an updated commit. 1. OpenIPC-to-OpenIPC upgrade. I ran it on the camera from the profile's own archive, the same The first run's SoC check passed ( After it:
2. 3. 4. Nits. Fixed: the double blank line in the fragment, and the stray On Qodo's "lite unless flash size requires otherwise": OpenIPC replaced |
Adds the Amcrest IP4M-1026E as
s3l_ultimate_amcrest-ip4m1026e, the first Ambarella device in builder. It's a Dahua IPC-HFW1430SN inside (hwid familyIPC-HX1X3X-LEXUS): Ambarella S3L, OV4689 over MIPI, 32 MiB SPI-NOR, Ethernet only, IR-cut and IR LEDs, and an analog light sensor. Tested on an IP4M-1026EW-28MM (white, 2.8 mm). The black EB and the 3.6 mm lens versions run the same Amcrest firmware.What is in it
s3l_ultimate(Majestic with its fonts and web UI) withBR2_OPENIPC_FLASH_SIZE="32"and this board's kernel fragment.rootfs_dataends at 0x1a70000. The rest of the flash stays stock and read-only (dahua), because the Dahua U-Boot writes a boot-state record into the stockupdateflagpartition on every boot.customizer.sh:ov4689), since it's held in reset until its driver loads;sysbackup=0in the Dahua U-Boot environment (see below);adcInvert.gpio.conf: the reset button (34), IR-cut, IR LEDs and the light sensor, each checked on the camera.s3l_ultimate.list): the sensor and video-out modules this board doesn't use; onlyov4689_mipiis left.ci-matrix.py: the device is added toSMOKE_TARGETS, because--self-testrequires one target per SoC vendor and there was no Ambarella one. Touching that file widens this PR's CI to the full matrix.Testing
On the IP4M-1026EW-28MM, with firmware master 35c75dc3:
Image size: the NOR build fits: uImage 1604K of 2048K, rootfs 5128K of 8192K.
Night-mode settings: netbooted from the profile, the customizer writes them into
/etc/majestic.yaml:adcReadout,adcChannel: 1,adcInvert, thresholds 256/672 andlightMonitor.Video: with Majestic
master+f2fa260, Majestic starts preview from a fresh boot and streams H.265 2688×1512 at 30 fps with its 3A (ambarella: s3l: replace s3l_lite with s3l_ultimate firmware#2787).IR-cut and IR LEDs:
/night/onand/night/offmove the IR-cut filter and switch the IR LEDs.Automatic day/night: Majestic reads the light sensor (
night_mode_source 3). Covering it (ADC ~15) switches to night: IR-cut out, IR LEDs on, grayscale. Uncovering it (~2900) switches back to day. That's one switch each way, with no flapping.Flashed: the NOR build of this profile, written through the Dahua U-Boot's TFTP upgrade with every write read back:
rootfs_data;sensor,upgrade,sysbackup) and in/etc/majestic.yaml;master+e6ba340) streams H.265 2688×1512 at 30 fps and reads the light sensor (night_mode_source 3).An earlier lite build of the profile also went stock → OpenIPC → stock → OpenIPC.
Boot counter: works on the flashed image; see below.
Repo checks:
ci-matrix.py --self-test,lint-cli-paths.py,lint-workflow-shell.pyandcheck-firmware-drift.py --self-testpass locally.The Dahua boot counter
The Dahua U-Boot counts boots in one byte at flash 0x1a80000. When it reads 5, it boots Dahua's backup system from the stock
backupker/backupfsinstead of OpenIPC. The stock firmware clears the count after every good boot; OpenIPC doesn't, so from the factory value (2) the camera would fall back within a few reboots.sysbackup=0turns the counting and the backup boot off. The customizer sets it on first boot withfw_setenv. It changes only the environment sector, not U-Boot, and U-Boot's TFTP upgrade path doesn't read it.Tested on the flashed image, with the flash set leaving
sysbackup=1and the count at 0:state:ff,err_count:00, leaving 01).sysbackup=0on that boot.err_count, and the count stayed at 01.Related: OpenIPC/firmware#2781 (overlayfs), #2782 (SDK microcode), #2787 (s3l_ultimate with Majestic), OpenIPC/linux#177 and #178.