Releases contain automatically generated firmware files for transition from stock to OpenIPC
WARNING! Coupler is a work-in-progress. If the firmware update fails, then it will be necessary to to carry out a tftp recovery process. You are strongly advised to carefully review the recovery process documentation and check for any relevant open issues, before proceeding.
It's highly recommended to upgrade to latest available stock firmware before transition.
You can use coupler if a coupler binary is available which matches the "System version" for your device.
For example a device running vendor firmware with the version "V5.00.R02.000059A8.10010.040400.0020000" has device ID "000059A8".
There are several ways to discover the vendor firmware version:
- The IPCam's built-in web interface e.g. "Device Config" → "Info" → "Version".
- The vendor's management software e.g. XiongMai's DeviceManager.
- IPCam_DMS management software (Windows binaries, but also run under Wine on Linux).
- ipctool.
Select the firmware from the download list which exactly matches your device's ID.
Many firmwares in the list below are compatible with multiple different image sensor (CCD) types, and must be configured to expect a particular sensor type before images or video can be captured. You should ensure that you know the image sensor (CCD) make/model which your camera uses. This can be found using the methods listed above for determining the device ID, but is also often shown on the item description or model number (e.g. when the item is sold, or on the product packaging).
- 00001510
- 00001520
- 00001531
- 00001532
- 00002510
- 00002520 (No sensor driver)
- 00002531
- 00002532 (If IMX291. No sensor driver)
- 00006510
- 00006531
WARNING! Provides linux rootfs ! Manual Rollback only !
Use vendor-specific software (e.g. XiongMai DeviceManager), IPCam_DMS, or the camera's built-in web server (n.b. not all vendor firmwares support browser based updates) to install the OpenIPC coupler firmware binary.
After flashing and rebooting, the camera will request an IP from a DHCP server. It will listen for web based management (e.g. http://w.x.y.z/ where the w.x.y.z is replaced with the IP address is the one that your local DHCP server has assigned), and also on ssh. After the first boot with the new firmware you need to clean the overlay partition. Run this command in your terminal window: firstboot . The coupler firmware build may not be the latest, so you may want to upgrade the firmware further at this point.
If no image is available via the web interface, then the sensor may need to be manually configured. This can be checked via ssh with fw_printenv -n sensor, which may respond unknown. On HiSilicon SoCs, a list of known sensor types can be found in the /usr/bin/load_hisilicon script. Once you have a matching sensor type, it can be set with e.g. fw_setenv sensor imx291_i2c.
Check the main project docs and wiki for more info.
To rollback firmware to stock, you will have to connect UART console and do TFTP recovery
Our ExIPCam software can do that in semi-automatic mode.
- Setup a TFTP server
- Make sure that the network to which the camera is connected has internet access.
- Download appropriate recovery.img file for you IPC board from Releases page/Original firmware (https://github.com/OpenIPC/coupler/releases/tag/original), place it to TFTP root folder and rename to update.img
ipctool printenv (review serverip and ipaddr)In the output of this command, we are looking for the value "serverip" (e.g. serverip=192.168.1.254), set the received IP address on the computer with TFTP and launch the TFTP server.
ipctoolThis is to download the latest version of ipctool from the repository/tmp/ipctool setenv bootcmd "run up && re; setenv setargs setenv bootargs \${bootargs}; run setargs; sf probe 0; sf read 0x42000000 0x50000 0x200000; bootm 0x42000000"reboot
ipctoolThis is to download the latest version of ipctool from the repository/tmp/ipctool setenv bootargs "mem=32M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfstype=cramfs mtdparts=xm_sfc:256K(boot),1536K(kernel),1280K(romfs),4544K(user),256K(custom),320K(mtd)"/tmp/ipctool setenv bootcmd "run up;sf probe 0;sf read 80007fc0 40000 180000;bootm 80007fc0"reboot
Obtain stock firmware file and open it in an editor. First 8 bytes are NAME and next 8 bytes are SENSOR
For example: 16AV300 IMX415b
Get appropriate file for your model and flash it via web.
OpenIPC offers two levels of support.
- Free support through the community (via chat and mailing lists).
- Paid commercial support (from the team of developers).
Please consider subscribing for paid commercial support if you intend to use our product for business. As a paid customer, you will get technical support and maintenance services directly from our skilled team. Your bug reports and feature requests will get prioritized attention and expedited solutions. It's a win-win strategy for both parties, that would contribute to the stability your business, and help core developers to work on the project full-time.
If you have any specific questions concerning our project, feel free to contact us.
If you like what we do, and willing to intensify the development, please consider participating.
You can improve existing code and send us patches. You can add new features missing from our code.
You can help us to write a better documentation, proofread and correct our websites.
You can just donate some money to cover the cost of development and long-term maintaining of what we believe is going to be the most stable, flexible, and open IP Network Camera Framework for users like yourself.
You can make a financial contribution to the project at Open Collective.
Zenointel (Hangzhou Zenointel) OEM cameras (e.g. SD-2N-4G / NC-IPTC2200_DL_4G-4,
Goke GK7205V510, 128 MiB SPI-NAND) run a Dahua-derived hunter userland and
speak Dahua DHIP (TCP 5000), not XiongMai DVRIP. The build here mirrors the
XiongMai approach — it repackages OpenIPC's kernel + rootfs into the vendor's
own Dahua "zzip" upgrade container and does not touch u-boot, so the stock
bootloader (and TFTP recovery) always survives.
VALIDATED on hardware — one upstream blocker for CI. The full flow was proven end-to-end on a GK7205V510 SD-2N-4G: the locally-built OpenIPC gk7205v500-family NAND (ultimate) artifact (gk7205v510 is SoC family gk7205v500), wrapped by this builder and pushed over DHIP with
python-dhip, booted OpenIPC keeping the stock u-boot. The stock XMediabootkboots the OpenIPC kernel+rootfs from the vendorkernel/rootpartitions, andhunteraccepts the partial (kernel+rootfs-only) package. The one remaining blocker is CI: the gk7205v500-family NAND-ultimate artifact is not published upstream yet (CI currently ships gk7205v500_lite NOR), so the fetch step here fails until it is. Build it locally in the meantime (make BOARD=gk7205v500_ultimate). Back up the full NAND and keep a UART console ready before attempting anything.
There is no XiongMai-style Device ID. The upgrade package is gated on Cpu
(SoC, GK7205V510), Vendor (the unit's OEM, e.g. Rostelecom) and a
Devices allow-list of [model, hardware-version] pairs. Match all three to
your unit. Read them over DHIP with python-dhip
(magicBox.getSystemInfo / getSoftwareVersion), or from the web UI's version page.
The package is a Dahua zzip (a ZIP with the first PK mangled to ZL); inspect
it with the zenointel project's tools/zzip.py verify. Push it over DHIP with
python-dhip (DahuaClient.upgrade_firmware(pkg, confirm=True) on port 5000),
mirroring how XiongMai uses python-dvr. Full recipe:
~/projects/cameras/zenointel/docs/openipc-transition.md.
Fully recoverable — u-boot is never touched. Interrupt the stock u-boot over UART
(console password zenotech) and TFTP the stock partitions back, or restore the
full NAND backup taken before flashing.
Thank you.
