[openipc-ai]

Problem

s3l_lite has no DSP microcode. The drivers load, load_ambarella logs No DSP microcode on this image, video will not start, and the DSP never starts. This is the delivery PR for #2767.

It adds the generic set from Ambarella's S3L SDK release 2.5.0_20181109, version 2018/10/28 284712.282649, to ambarella-osdrv-s3l, installed to /lib/firmware:

File	Bytes	md5
orccode.bin	1799300	d41b4a594930c4c957bb2fd7133428a0
orcme.bin	211244	99bf6852883c8e8bfc86a15049565e5e
default_binary.bin	400640	aca067f0c8043e7c8ecc1e6dbc79bd40

This does not give video by itself. #2767 lists what else is needed.

Hardware tested on

Ambarella S3L, Amcrest IP4M-1026E, OV4689, run by @DeathCamel58, not by me: full output. From a real power-on, it reports ucode version 2018/10/28 284712.282649, enters DSP modes 0 and 1 with the package's modules, and streams stream 0. That run used master d86e9fc1 with these three files, netbooted with an initramfs, the DTB from OpenIPC/linux#178 and a streamer that isn't upstream yet.

Not tested: booting from flash, 29.97 fps VIN.

Evidence

The hardware output is in the comment linked above. The rest is from QEMU, on qemu-bench's s3l machine, with this branch's kernel, the real dsp.ko, and the rootfs unpacked into an initramfs. QEMU doesn't model the DSP, so this proves the files reach their slots and nothing about whether the DSP runs them.

Before (files removed from this image):

ambarella: No DSP microcode on this image, video will not start
=== load_ucode again
load_ucode: /lib/firmware/orccode.bin: No such file or directory

After:

=== modules
ov4689_mipi iav hw_timer imgproc vout dsp
=== load_ucode again
orccode.bin: 1799300 bytes at +0x000000
orcme.bin: 211244 bytes at +0x300000
default_binary.bin: 400640 bytes at +0x3a0000
ucode version 2018/10/28 284712.282649
rc=0
=== kernel errors
0

Image size, full make BOARD=s3l_lite:

- uImage: [1582KB/2048KB]
- rootfs.squashfs: [4156KB/5120KB]
- uImage: [1582KB/4096KB]
- rootfs.ubi: [8960KB/16384KB]

S3L is in UNBUILT_FAMILIES, so CI won't build this. Touching the package gives the 14-board smoke set, none of which is S3L.

Scope

• No kernel patches under general/package/all-patches/linux/ (those go to OpenIPC/linux)
• No files specific to a single retail camera model (those go to OpenIPC/builder)
• No probing or bring-up tooling (that goes to OpenIPC/ipctool)
• Nothing under general/overlay/ or in a shared load_<vendor> script hardcodes a value specific to my board
• Package sources come from an OpenIPC repository, and any version bump keeps at least the specificity of the pin it replaces (a new package should pin a full 40-character SHA)
• No LD_PRELOAD, and no binaries that cannot be rebuilt from source
• New code is selected by a defconfig, so CI actually builds it

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Package S3L DSP microcode from the Ambarella SDK

✨ Enhancement 📝 Documentation 🕐 20-40 Minutes

AI Description

• Install generic S3L SDK microcode into /lib/firmware so load_ambarella can find it.
• Identify the SDK release and proprietary licensing in package metadata.
• Hardware compatibility remains unverified; QEMU confirms loading, not DSP operation.

Diagram

graph TD
  SDK["S3L SDK firmware"] --> PKG["Package recipe"] --> FS[("/lib/firmware")] --> SCRIPT["load_ambarella"] --> LOADER["load_ucode"] --> DSP["DSP driver"]
  FS --> LOADER

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use an older SDK microcode set

• ➕ Could reduce compatibility risk if hardware testing shows the newer set fails with the packaged modules.
• ➖ Would replace the intended SDK release; the proposed 2018 fallback also needs hardware validation.

Recommendation: Packaging the generic SDK set is consistent with the repository's stated sourcing constraint. Keep this version only if hardware testing confirms DSP mode entry with the packaged modules; QEMU loading alone does not establish compatibility.

Files changed (3) +11 / -6

Enhancement (1) +7 / -2

ambarella-osdrv-s3l.mkInstall SDK microcode into the target firmware directory +7/-2

Install SDK microcode into the target firmware directory

• The recipe installs firmware binaries into '/lib/firmware' and records their SDK origin. It also distinguishes the MIT-licensed loader from the proprietary modules and microcode.

general/package/legacy/ambarella-osdrv-s3l/ambarella-osdrv-s3l.mk

Documentation (2) +4 / -4

Config.inDescribe microcode in the package help +1/-1

Describe microcode in the package help

• The package help now lists DSP microcode alongside the kernel modules and libraries.

general/package/legacy/ambarella-osdrv-s3l/Config.in

load_ambarellaCorrect bring-up comments to reflect packaged microcode +3/-3

Correct bring-up comments to reflect packaged microcode

• The script comments now state that microcode comes from the package and that images with the firmware pruned can still boot. Runtime behavior is unchanged.

general/package/legacy/ambarella-osdrv-s3l/files/script/load_ambarella

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can hide the parts of a finding you never read, like the evidence or the agent prompt

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[DeathCamel58]

Ran it on the IP4M-1026E. 284712 boots from a real power-on, enters both DSP modes, and streams stream 0 with these modules. I found one difference from 267837, in the 3A statistics. It's below, and I'm treating it as a streamer issue, not a blocker for this PR.

How it was run. Netbooted through the Dahua U-Boot's TFTP recovery, so the flash wasn't touched. The image is master d86e9fc1 (s3l_lite's package, load_ambarella and load_ucode unchanged) with this PR's three files installed to /lib/firmware (md5s match your table) and nothing else from the unit's stock firmware. Your load_ambarella change is comments only, so the boot path is the same. It's my bench profile: initramfs, the board DTB from OpenIPC/linux#178, and my Divinus S3L backend as the streamer (not upstream yet). The power-on was a real unplug and replug, not a reboot.

From power-on:

$ md5sum /lib/firmware/*.bin
aca067f0c8043e7c8ecc1e6dbc79bd40  /lib/firmware/default_binary.bin
d41b4a594930c4c957bb2fd7133428a0  /lib/firmware/orccode.bin
99bf6852883c8e8bfc86a15049565e5e  /lib/firmware/orcme.bin
$ dmesg | grep -E "probe status|OV4689|Entering DSP|Entered mode|ENC sub mode|chip ID"
[    2.050791] iav_drv_probe_status(308): IAV probe status [255], dsp mode [255].
[    2.151625] VIN: OV4689 init(4-lane mipi), [vinc:vsrc]0:0
[    2.378657] dsp_set_op_mode(408): Entering DSP mode [0]...
[    2.379464] dsp_set_op_mode(416): [Done] Entered mode [0].
[    2.510064] check_dsp_mem_bandwidth(1049): S3L chip ID [4], DSP memory bandwidth [574 MB/s], limit [1842 MB/s].
[    2.527201] dsp_set_op_mode(408): Entering DSP mode [1]...
[    2.533493] dsp_set_op_mode(416): [Done] Entered mode [1].
[    2.533507] dsp_set_enc_sub_mode(358): Entering DSP ENC sub mode from [7] to [1]

load_ambarella sends load_ucode's output to /dev/null, so the boot doesn't log the version line. I read it back afterwards with a read-only UCODE_GET_VERSION on /dev/ucode, using the same struct as load_ucode.c:

$ ./ucode-ver
ucode version 2018/10/28 284712.282649

It might be worth letting load_ambarella log that line, since it's the first thing anyone will want to see.

Stream 0, H.264 over RTSP from the same cold boot:

$ ffprobe -v error -rtsp_transport tcp -select_streams v -show_entries stream=codec_name,width,height,avg_frame_rate -of csv=p=0 rtsp://192.168.1.10/
h264,2688,1512,20/1
$ grep -E " vcap$| venc$" /proc/interrupts
 46:       1512       VIC  vcap
 47:       1503       VIC  venc

A 6-second decode is clean, and the picture is properly exposed and in colour. I got the same results on two warm netboots.

The one difference: 3A statistics right after preview starts. With 284712, the AAA_STATISTICS_SETUP my streamer sends about 150 ms after mode 1 gets no statistics back. img_get_statistics times out every 5 s with statistics_ready = 0 (15 times in the first 75 s after power-on, and on both warm boots too). Video is unaffected. On the same image with 267837 the count is 0. Sending the setup again later, here by restarting the streamer with the DSP still in mode 1, clears it: no timeouts afterwards. So the microcode seems to need the statistics setup after VCAP has settled. I'll handle that in the streamer (send the setup again when statistics time out), and it doesn't affect what this PR ships. I'm mentioning it in case Majestic or anything else configures statistics at the same point.

Not tested: 29.97 fps VIN, and the encode_only set.

On #2767's merge condition, this is the hardware run for 284712. The fallback to 280077 shouldn't be needed.