Repository navigation
Ambarella S3L: how to ship the DSP microcode #2767
Description
s3l_lite can load and start the DSP, but the image has no microcode, so it gives no video. This issue tracks how the microcode gets onto the image. It follows the discussion in #2763 and #2766.
Where things stand
load_ucodeis built from source inambarella-osdrv-s3l(ambarella-osdrv-s3l: build an open-source load_ucode #2766).load_ambarellaruns it whenorccode.binis in/lib/firmware(ambarella: s3l: build for the Cortex-A9, load the drivers at boot #2764), and otherwise logs that video will not start.- The three files needed are
orccode.bin,orcme.binanddefault_binary.bin. toolchain.ambarella-s3l.tgzis published, andmake BOARD=s3l_litebuilds an image that fits the 8 MB layout.s3l_litebuilds musl hard-float (ambarella: s3l: build hard-float, so the SDK's image library links #2780).
Decided (see this comment; it replaces the earlier proposal to use stock firmware)
- Source: a vendor SDK release. Binaries extracted from factory firmware don't pass the tree's binary gate, and a build-time download of them would only sidestep it.
- Delivery: files in
ambarella-osdrv-s3l, like other osdrv blobs, in a separate PR. - Version:
s3l_2.5.0_20181109,genericset (2018-10-28, svn 284712). - Hardware run: done on the IP4M-1026E: real power-on, DSP modes 0 and 1, stream 0. Run with a netboot and initramfs, not from flash. Not tested: 29.97 fps VIN.
- ISP configuration: same rule. A configuration captured from stock firmware won't ship.
Also still needed for video, separately from this issue: the board's device tree (full iavmem, sensor reset on GPIO 107), the 3A/VIN setup, a streamer (Divinus HAL), and a fix for cold-boot streaming. Details are in #2763.
Activity
DeathCamel58 commentedon Nov 6, 2026
I'd love some input on this from maintainers because I'm not quite sure the best way to handle this.
Also for accuracy, there are a number of different microcode versions I've seen for the S3L's DSP (
orccode.bin):6e1e1fcb…1af9d296…cc0eb38c…6ea4f5c0…df6ce435…2c471c79…714bd83f…openipc-ai commentedon Nov 7, 2026
@DeathCamel58 thanks, the table is very useful. It shows how many versions are in the field, which is why a version can't be assumed to work with these modules.
Source: a vendor SDK release, not stock firmware. This replaces the proposal in the issue description, which I wrote and which was wrong. The tree doesn't accept binaries extracted from factory firmware (§2.4 of
best_practices.md, and the "No binaries without a buildable source" gate). A build-time download of the same files would only sidestep that rule, so 267837 from the IP4M-1026E can't be what ships. You can of course keep using it for your own testing.Delivery: files in
ambarella-osdrv-s3l, like the vendor blobs other osdrv packages ship, such ashevcenc.fwbinxiongmai-osdrv-xm530. No build-time download.Versions. These are the S3L SDK releases we have. Each has a
genericand anencode_onlyset. None of them is in your table:genericorccode md5s3l_linux_sdk_2016102036a49592…s3l_2.5.0_201802085d968841…s3l_2.5.0_20181109d41b4a59…Testing. None of these has run with the package's modules. 267837 is still the only version proven with them, so whichever SDK version we pick has to stream on hardware before it merges. QEMU can't show this, because it doesn't model the DSP.
I'd start with
s3l_2.5.0_20181109, the newest, using thegenericset, and fall back to 280077 ifiav.koanddsp.kodon't work with it. The microcode PR will come from our side, since the files come from the SDK.Could you run the candidate on your IP4M-1026E once that PR is up? The useful evidence is the same as in #2766:
load_ucode's version line and the DSP entering its mode from power-on, plus stream 0 if your bring-up stack can get that far. If the fractional-rate problem you found at 29.97 fps behaves differently on this version, that would be useful to know too.ISP configuration: same rule. A configuration captured from stock firmware won't ship either, so it needs to come from an SDK release or your own tuning.
ambarella-osdrv-s3l: ship the DSP microcode from SDK 2.5.0_20181109
DeathCamel58 commentedon Nov 7, 2026
Thanks, that settles it for me: SDK microcode, shipped in
ambarella-osdrv-s3l, and proven on hardware before it merges.I've run #2782's 284712 set on the IP4M-1026E. The details are on that PR. In short, 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 (2688×1512 H.264 at 20 fps). So the 280077 fallback shouldn't be needed. The one difference from 267837 is that statistics set up right after preview starts don't arrive until the setup is sent again, which I'll handle in the streamer.Understood on the ISP configuration too. What I use for testing comes from this unit's stock firmware and stays local, so the shipped one will need to come from an SDK release or our own tuning.
openipc-ai commentedon Nov 7, 2026
@DeathCamel58 thanks, that's the run this needed, and more than I'd asked for: a real power-on, both DSP modes, the version read back, and a decoded stream. Your results on #2782 meet the merge condition for
s3l_2.5.0_20181109, so 284712 is the version and the 280077 fallback is dropped. I've updated the description here and the PR.I've read that evidence but not reproduced it, since I have no OV4689 board. A few things it leaves open:
ffprobeshows20/1. Is that your streamer's setting, or does 267837 run faster on the same image? If this version limits the rate, that's worth knowing before it ships.encode_onlyset, as you said. The PR ships only thegenericset, soencode_onlydoesn't matter here.Statistics: agreed, that belongs in the streamer, and it's not a blocker for the PR. Thanks for writing it up.
Logging the version in
load_ambarella: good idea. I'd do it as a small separate PR, so #2782 stays exactly what you tested.ISP configuration: thanks, that's the right way to handle it.
DeathCamel58 commentedon Nov 7, 2026
20 fps was my streamer's setting (
fps: 20in its config), not a limit of the microcode. I set it to 30 and compared both versions on the same image, netbooted, with only the microcode swapped:calc_dsp_fpsdsp_fps 30000dsp_fps 30000vcap/vencinterrupts per secondavg_frame_rate30/130/1So no difference at 30 fps.
Boot path: agreed. I'll run it from flash once the board's profile is up, which needs #2781 for the overlay.
Statistics: I found the cause, and it may matter for Majestic on S3L (#2785) too.
AAA_STATISTICS_SETUPcan only be sent once preview has started.openipc-ai commentedon Nov 7, 2026
@DeathCamel58 thanks, that closes the frame-rate question, and the statistics finding is really useful.
20 fps: closed. 284712 and 267837 match at 30 fps, so nothing is needed there.
Boot path: that works. Note that #2781 is still waiting on the pasted evidence and uImage size from my review, and it needs a rebase to get an S3L build, now that CI builds
s3l_lite(#2783).Statistics: this may well affect Majestic on
s3l_lite, and the test we have doesn't rule it out. The S3Lm + AR0237 run in #2785 started Majestic after the vendor's stack had already run a preview, so its preview was never the first one after a microcode load. By your analysis, that's the only case that fails. So Majestic's first session after a cold boot on ans3l_liteimage is untested, and that's now what the images ship: #2782 and #2785 are both merged.I haven't reproduced this or checked the static comparison myself, so for now I'm treating it as your measurement plus a likely risk.
If you have time, this test would settle it, since the IP4M-1026E is the board that can run it. On a current
s3l_litewith Majestic, from a real power-on:Majestic has no OV4689 tuning proven on this board as far as I know, so if 3A won't start at all, please paste that log too. That would be a different problem from this one, and it would need sorting out first.
Your Divinus workaround is a useful data point: one return to idle and a new preview, about 2.5 s once per boot.