SoC not recognised: Ambarella S3L (Amcrest IP4M-1026E / Dahua IPC-HFW1430SN)

@0x36

ipctool master+e816803 (built 2026-11-04, release ipctool ARM static) on an Amcrest IP4M-1026E
(Dahua OEM, HWID IPC-HFW1430SN-Lexus) running its stock firmware, as root:

ipctool: SoC not recognised, no hardware report possible.
  no UART0 entry in /proc/iomem
  no vendor matches /proc/cpuinfo: Ambarella

Hardware:

SoC: Ambarella S3L, chip marking S3L-K-B0-RH; single Cortex-A9 r4p1 (NEON/VFPv3)
DRAM 256 MiB (Linux gets mem=118M; IAV/DSP carve-out from 0x07800000)
Sensor OmniVision OV4689 (MIPI, I2C0 @0x36)
32 MiB SPI NOR (Winbond W25Q256JV), Ambarella amba_spinor controller
Ethernet: Ambarella MAC, RMII PHY ID 0x001cc816 (RTL8201F)
Stock: Linux 3.10.73, glibc 2.21 armhf, BusyBox 1.18.4, Dahua U-Boot 2010.06

Possible detection hints:

/proc/cpuinfo Hardware is Ambarella S3L (Flattened Device Tree)
/proc/device-tree/compatible contains ambarella,s3l
/proc/iomem lists only System RAM / kernel code / data, so the UART0 check has nothing to match.
The Ambarella UART0 is on APB at 0xe8005000 (APB base 0xe8000000), see the Ambarella: APB = boot line.
The Ambarella: IAVMEM = ... lines are specific to Ambarella kernels.

Note for anyone else running ipctool on Dahua Ambarella firmware: this kernel refuses execve() of
files on writable filesystems (/tmp, jffs2). The shell reports /tmp/ipctool: Success with exit code 2.
I had to start the static binary through a small userland loader run by /lib/ld-linux-armhf.so.3.

(The init=/etc/rootsh.sh in the command line below is my own dev change; stock is init=/linuxrc.)

cat /proc/cpuinfo; cat /proc/iomem; dmesg | head -40:

processor	: 0
model name	: ARMv7 Processor rev 1 (v7l)
BogoMIPS	: 812.64
Features	: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x4
CPU part	: 0xc09
CPU revision	: 1

Hardware	: Ambarella S3L (Flattened Device Tree)
Revision	: 0000
Serial		: 0000000000000000
00200000-077fffff : System RAM
  00208000-005afce7 : Kernel code
  005ce000-0061c66f : Kernel data
Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpu
Linux version 3.10.73 (jenkins@centos234) (gcc version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-2) ) #2 PREEMPT Tue Nov 7 17:30:32 CST 2017
CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Ambarella S3L (Flattened Device Tree), model: Ambarella S3L Olive Board
os ----- 200000 ,  7600000
logmem start:777e000, size:80000.
network type:1.
debug: ignoring loglevel setting.
init gLogRamRes: start=0x777e000;size=0x80000
Memory policy: ECC disabled, Data cache writeback
Ambarella:      AHB = 0xe0000000[0xe0000000],0x01000000 0
Ambarella:      APB = 0xe8000000[0xe8000000],0x01000000 0
Ambarella:      PPM = 0x00000000[0xdfe00000],0x00200000 9
Ambarella:      AXI = 0xf0000000[0xf0000000],0x00030000 0
Ambarella:    DRAMC = 0xdffe0000[0xef000000],0x00020000 0
Ambarella:   DBGBUS = 0xec000000[0xec000000],0x00200000 0
Ambarella:  DBGFMEM = 0xee000000[0xee000000],0x01000000 0
Ambarella:   IAVMEM = 0x07800000[          ],0x18800000
Ambarella:    FBMEM = 0x00000000[          ],0x00000000
On node 0 totalpages: 30208
free_area_init_node: node 0, pgdat 803f808c, node_mem_map 80421000
  Normal zone: 236 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 30208 pages, LIFO batch:7
CPU: All CPU(s) started in SVC mode.
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 29972
Kernel command line: console=ttyS0,115200 mem=118M root=/dev/mtdblock5 rootfstype=squashfs init=/etc/rootsh.sh ignore_loglevel
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 118MB = 118MB total
Memory: 114940k/114940k available, 5892k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0x87800000 - 0xff000000   (1912 MB)

Thanks for the detailed report. The hints were right: these kernels list no UART in /proc/iomem, and ipctool had no Ambarella entry. The PR that adds detection is linked above. It is untested on real hardware, so could you try it on your camera?

Please run these with the stock application running. The sensor probably needs the vendor video stack to be up, so your rootsh init may not show it:

ipctool
hexdump -C /proc/device-tree/iavmem/reg
hexdump -C /proc/device-tree/memory/reg
ls /dev/i2c-* /dev/iav /proc/ambarella
cat /proc/ambarella/clock

I also have one question about memory. You list 256 MiB of DRAM, but your boot log has IAVMEM = 0x07800000,0x18800000, which ends at 512 MiB. Where does the 256 MiB come from? The marking on the DRAM chip would settle it. Amboot builds that value from a compile-time constant, so the log alone doesn't prove either figure. Until this is clear, ipctool will report only the memory the kernel sees.

The report will say S3L rather than the exact part, because only the DSP firmware knows that. Thanks for the note about execve() too; it's now in the project notes.

ambarella: detect the SoC from the machine string (#267)

Thanks for the quick fix. I tested the latest release ipctool (sha256 63c9be5) on the stock firmware, with sonia running (uptime about 80 s). It was started through the userland loader because of the execve() restriction.

ipctool (exit 0):

---
chip:
  vendor: Ambarella
  model: S3L
ethernet:
  mac: "9c:8e:cd:28:3c:ae"
rom:
- type: nor
  block: 64K
  partitions:
    - name: MinBoot
      size: 0x40000
      sha1: e31ae6db
    - name: U-Boot
      size: 0x40000
      sha1: fb32c8f6
    - name: hwid
      size: 0x20000
      sha1: 5def2b63
    - name: partition
      size: 0x10000
      sha1: 66ca4257
    - name: Kernel
      size: 0x180000
      sha1: e4c773ea
    - name: romfs
      size: 0x150000
      path: /,squashfs
      sha1: 44b21bd1
    - name: web
      size: 0x680000
      path: /mnt/web,squashfs
      sha1: 94f3305c
    - name: user
      size: 0x1030000
      path: /usr,squashfs
    - name: updateflag
      size: 0x30000
      sha1: 9e8305bc
    - name: config
      size: 0x70000
      path: /mnt/mtd,jffs2,rw
    - name: product
      size: 0x10000
      sha1: 8ab0e3f7
    - name: custom
      size: 0x20000
    - name: backupker
      size: 0xe0000
      sha1: e985dde0
    - name: backupfs
      size: 0x50000
      sha1: c7e50963
    - name: data
      size: 0x100000
      sha1: 56e4b847
    - name: user1
      size: 0x290000
      sha1: e2c470bb
  size: 31M
ram:
  total: 128M
firmware:
  kernel: "3.10.73 (PREEMPT Tue Nov 7 17:30:32 CST 2017)"
  toolchain: gcc version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-2)
  main-app: /usr/bin/sonia

Detection works. No sensor section appears; see the I2C note below.

hexdump -C /proc/device-tree/iavmem/reg and .../memory/reg: not possible on this firmware. The Dahua 3.10.73 kernel exports no device tree: there is no /proc/device-tree (CONFIG_PROC_DEVICETREE is off) and /sys/firmware is empty. Its busybox also has no hexdump/od. The flash DTB (at 0x8000 in the kernel partition) has memory { reg = <0x200000 0x7e00000>; } and no iavmem node. The IAVMEM range comes from the bootloader's boot parameters, and Linux is then capped by mem=118M on the command line.

ls /dev/i2c-* /dev/iav /proc/ambarella:

ls: /dev/i2c-*: No such file or directory
/dev/iav

/proc/ambarella:
clock
dma
usbphy0
ambarella_hwtimer
ambarella_hwtimer_outfreq
vout0
vout0_event
vout1
vout1_event
iav
vin0_idsp

There are no i2c-dev nodes: Dahua's own prc.ko/sensor.ko drive the sensor I2C. For reference, the sensor is an OmniVision OV4689 on SoC I2C0 at 7-bit address 0x36, chip ID 0x4688 at register 0x300a, confirmed under an OpenIPC kernel that has i2c-dev.

cat /proc/ambarella/clock:

Clock Information:
        pll_out_core:   720000000 Hz
        pll_out_sd:     1200000000 Hz
        gclk_cortex:    816000000 Hz
        gclk_axi:       272000000 Hz
        gclk_ddr:       840000000 Hz
        gclk_core:      360000000 Hz
        gclk_ahb:       180000000 Hz
        gclk_apb:       90000000 Hz
        gclk_idsp:      348000000 Hz
        gclk_so:        23993520 Hz
        gclk_vo2:       0 Hz
        gclk_vo:        0 Hz
        gclk_uart:      24000000 Hz
        gclk_audio:     12288000 Hz
        gclk_sdxc:      120000000 Hz
        gclk_sd:        120000000 Hz
        gclk_ir:        3000000 Hz
        gclk_adc:       12000000 Hz
        gclk_ssi:       51428571 Hz
        gclk_ssi2:      360000000 Hz
        gclk_ssi3:      360000000 Hz
        gclk_pwm:       18000000 Hz

Memory: the board really has 512 MiB of DRAM. My "256 MiB" in the report was wrong. The DRAM is a single Samsung K4B4G1646E-BYMA (datasheet): 4 Gbit DDR3L-1866 organised 256M × 16, so one chip on the 16-bit bus = 512 MiB. The stock IAVMEM = 0x07800000,0x18800000 (ending at 0x20000000) is therefore correct:

0x00200000–0x07800000: Linux, capped by mem=118M on the command line
0x07800000–0x20000000: IAV/DSP carve-out, 392 MiB

Checked on the running board: physical memory above 256 MiB holds its own data and does not alias the low 256 MiB (e.g. 0x10208000 ≠ 0x00208000), and stock's DSP command queue sits near the top of the 512 MiB at 0x1fad8000. The ram: total: 128M in the ipctool output below is only the kernel-visible part, as you described.

Thanks, that settles it. Detection is confirmed on your camera, and the DRAM marking plus the aliasing check answers the memory question. I had treated the IAVMEM value as unproven because of the 256 MiB figure, but it was right.

Memory: #268 makes ipctool report the top of the DSP carve-out, so your camera should show total: 512M and media: 392M. Your stock kernel has no /proc/device-tree, so it reads the IAVMEM line from the kernel log. That line is printed once at boot, so a camera that has been up for a long time may fall back to 128M.

Sensor: I'll leave this as a known limit on stock firmware. There are no /dev/i2c-* nodes, and using the I2C controller directly would race Dahua's sensor.ko while sonia is running.

Two more checks, when you have time:

Run the ambarella: report total RAM from the DSP carve-out #268 build on stock and post the ram: section.
Run it on your OpenIPC kernel with i2c-dev. That is the first test of ipctool's own sensor probe, and it should report OV4689. Please include the sensors: and ram: sections. On that kernel the memory figure should come from /proc/device-tree/iavmem/reg, if the node exists there.

A build from the PR's branch is the easiest way to test before it merges. The latest release will have it once it's in.

ambarella: report total RAM from the DSP carve-out (#268)

ram: keep a total that is already a power of two

Tested #268 on both firmwares. Detection and media are right, but total came out doubled, which #269 fixes.

Merged #268 (latest, 7c51a7e):

Stock firmware (IAVMEM read from the boot log): total: 1024M, media: 392M
OpenIPC kernel (/proc/device-tree/iavmem/reg = 07 80 00 00 18 80 00 00): total: 1024M, media: 392M

ambarella_totalmem() returns the right 524288 KiB. The doubling is in rounded_num(), which turns an exact power of two into the next one (512 → 1024); a kernel MemTotal never hit that.

With #269, stock firmware (sonia running):

ram:
  total: 512M
  media: 392M

No sensors: section on stock, as expected (no /dev/i2c-*).

With #269, OpenIPC kernel (3.10.104, s3l.generic.config + CONFIG_LBDAF=y, i2c-dev, H.264 stream running; VCAP kept ticking during the run, 71 -> 163):

ram:
  total: 512M
  media: 392M
sensors:
- vendor: OmniVision
  model: OV4689
  control:
    bus: 0
    type: i2c
    addr: 0x6c

OV4689 on I2C0 at 0x6c (7-bit 0x36), chip ID 0x4688. This was the first run of ipctool's own probe, and it found the right part. media here comes from /proc/device-tree/iavmem/reg.

Both #269 builds are arm32 with the CI toolchain (toolchain.hisilicon-hi3516cv100, musl) and packed with UPX 4.2.3, as in release.yml.

Thanks for testing on both firmwares. The doubled total was my miss: I said #268 should report 512M without checking the rounding in ram.c, and your #269 fixes it. I've reviewed and approved that PR, and its CI is running.

The OV4689 result is the one we were missing. It's the first run of ipctool's own sensor probe on Ambarella hardware, and it found the right part at the right address with the stream running.

On this camera that now confirms the following:

Detection: Ambarella / S3L on both firmwares.
Memory: with ram: keep a total that is already a power of two #269, total: 512M and media: 392M, from the boot log on stock and from /proc/device-tree/iavmem/reg on your OpenIPC kernel.
Sensor: OV4689 on the OpenIPC kernel. Stock has no sensors: section because it has no /dev/i2c-*, as expected.

This issue can close once #269 is merged.

Closing this now that #269 is merged. On the Amcrest IP4M-1026E, the reporter confirmed Ambarella / S3L detection on stock and OpenIPC firmware, total: 512M and media: 392M on both, and OV4689 on the OpenIPC kernel. Stock firmware reports no sensor because it has no /dev/i2c-*. The exact part (33M, 55M and so on) is not reported, because only the DSP firmware knows it. Thanks for all the testing.

ram: keep a total that is already a power of two (#269)

ambarella: S3L machine, so ipctool and load_ambarella run without the…

Navigation Menu

Repository navigation

SoC not recognised: Ambarella S3L (Amcrest IP4M-1026E / Dahua IPC-HFW1430SN) #266

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

SoC not recognised: Ambarella S3L (Amcrest IP4M-1026E / Dahua IPC-HFW1430SN) #266

Description

Activity

openipc-ai commented on Nov 6, 2026

DeathCamel58 commented on Nov 6, 2026

openipc-ai commented on Nov 6, 2026

DeathCamel58 commented on Nov 6, 2026

openipc-ai commented on Nov 6, 2026

openipc-ai commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions