Coder Social home page Coder Social logo

ipctool's Introduction

OpenIPC Logo

IP camera hardware checking tool

Build Build CI status GitHub repo size GitHub issues GitHub pull requests License

This basic concept belongs to Maxim Chertov (thank you for your original utility) and Nikita Orlov (for cute YAML format for describing hardware). A warm welcome also to Igor Zalatov (for suggestions for new features and describing ways to do them).


Download

Use the link to download latest build (even directly to your camera). The build uses musl C library to work on vast majority of hardware.

Alternative launch methods

  • Public NFS server (in case your camera firmware includes NFS client support, proven to work on XM cameras):

    $ mount -o nolock 95.217.179.189:/srv/ro /utils/
    $ /utils/ipctool

    As an alternative, you may run your own NFS server, putting ipctool on it.

  • Using UART and rx busybox applet on camera side. This option was described in @themactep blog post.

  • Using telnet/console and uget utility: basically convert small uget binary into echo/printf chunks and deploy to /tmp partition. Read more in documentation

  • TFTP, since some cameras have tftp clients and/or servers by default. Assuming you have the ipctool-mips32 binary ready under /directory/to/serve:

    On a desktop computer:

    $ pip install ptftpd
    $ ptftpd -p 6969 en0 /directory/to/serve
    

    On the camera:

     # tftp -r /directory/to/serve/ipctool-mips32 -g 192.168.1.107 6969
    
       46% |**************                 | 61952   0:00:01 ETA
    
  • Using telnet/console only: uses a python script to transfer ipctool via telnet/echo to the camera.

    On a desktop computer:

    $ tools/telnet_upload.py 192.168.1.10
    

    On the shell:

    # transfer
    

Usage

# ipctool -h
Usage: ipctool [OPTIONS] [COMMANDS]
Where:
  -c, --chip-name           read chip name
  -s, --sensor-name         read sensor model and control line
  -t, --temp                read chip temperature (where supported)

  backup <filename>         save backup into a file
  upload                    upload full backup to the OpenIPC cloud
  restore [mac|filename]    restore from backup (cloud-based or local file)
     [-s, --skip-env]       skip environment
     [-f, --force]          enforce
  upgrade <bundle>          upgrade to OpenIPC firmware
                            (experimental! use only on cameras with UART)
     [-f, --force]          enforce
  printenv                  drop-in replacement for fw_printenv
  setenv <key> <value>      drop-in replacement for fw_setenv
  dmesg                     drop-in replacement for dmesg
  i2cget <device address> <register>
  spiget <register>
                            read data from I2C/SPI device
  i2cset <device address> <register> <new value>
  spiset <register> <new value>
                            write a value to I2C/SPI device
  i2cdump [--script] [-b, --bus] <device address> <from register> <to register>
  spidump [--script] <from register> <to register>
                            dump data from I2C/SPI device
  i2cdetect [-b, --bus]     attempt to detect devices on I2C bus
  reginfo [--script]        dump current status of pinmux registers
  gpio (scan|mux)           GPIO utilities
  trace [--skip=usleep] <full/path/to/executable> [program arguments]
                            dump original firmware calls and data structures
  -h, --help                this help

When run without parameters utility produces YAML with all hardware-specific information about given IP-camera or DVR:

---
board:
  vendor: Xiongmai
  model: 50H20L
  cloudId: 3beae2b40d84f889
chip:
  vendor: HiSilicon
  model: 3516CV300
ethernet:
  mac: "00:12:89:12:88:e1"
  u-mdio-phyaddr: 1
  phy-id: 0x001cc816
  d-mdio-phyaddr: 0
rom:
  - type: nor
    block: 64K
    chip:
      name: "w25q128"
      id: 0xef4018
    partitions:
      - name: boot
        size: 0x30000
        sha1: 7a7a83e9
        contains:
          - name: xmcrypto
            offset: 0x1fc00
          - name: uboot-env
            offset: 0x20000
      - name: romfs
        size: 0x2e0000
        path: /,squashfs
        sha1: 62529dab
      - name: user
        size: 0x300000
        path: /usr,squashfs
        sha1: cbb7e9ca
      - name: web
        size: 0x160000
        path: /mnt/custom/data/Fonts,squashfs
        sha1: 48140b3b
      - name: custom
        size: 0x40000
        path: /mnt/custom,cramfs
        sha1: fb72a5f5
      - name: mtd
        size: 0x50000
        path: /mnt/mtd,jffs2,rw
    size: 8M
    addr-mode: 3-byte
ram:
  total: 128M
  media: 72M
firmware:
  u-boot: "2010.06-svn1098 (Jun 11 2018 - 13:17:42)"
  kernel: "3.18.20 (Thu Jul 5 14:44:19 CST 2018)"
  toolchain: gcc version 4.9.4 20150629 (prerelease) (Hisilicon_v500_20170922) 
  libc: uClibc 0.9.33.2
  sdk: "Hi3516CV300_MPP_V1.0.0.0 B010 Release (Jun 22 2018, 19:22:22)"
  main-app: /usr/bin/Sofia
sensors:
- vendor: Sony
  model: IMX291
  control:
    bus: 0
    type: i2c
    addr: 0x34
  params:
    bitness: 12
    databus: LVDS 4 ch
    fps: 30
  data:
    type: LVDS
    lane-id:
    - 0
    - 1
    - 2
    - 3
    lvds-wdr-en: 0
    lvds-wdr-mode: 0
    lvds-wdr-num: 0
    raw-data-type: RAW_DATA_12BIT
    sync-mode: LVDS_SYNC_MODE_SAV
    data-endian: LVDS_ENDIAN_BIG
    sync-code-endian: LVDS_ENDIAN_BIG
    sync-code:
    - 
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
    - 
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
    - 
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
    - 
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
      - 0xab0, 0xb60, 0x800, 0x9d0
  clock: 37.125MHz

In your own scripts

  • Determine chip name:

    # ipctool --chip-name
    hi3516cv300
  • Determine sensor model and control line:

    # ipctool --sensor-name
    imx291_i2c
  • Get temperature from chip's internal sensor (not all devices supported):

    # ipctool --temp
    50.69

As backup/restore tool

  • Save full backup with YAML metadata into specific file:

    # mount -o nolock mynfsserver:/srv /var/utils
    # ipctool backup /var/utils/mybackup-00:12:17:83:d6:39
    # sync

As reverse engineering tool

  • Drop-in replacement of dmesg command:

    # ipctool dmesg
  • Drop-in replacement of fw_printenv and fw_setenv commands:

    # ipctool printenv | grep bootargs
    # ipctool setenv bootargs "mem=\${osmem} mtdparts=hi_sfc:256k(boot),64k(env),2048k(kernel),5120k(rootfs),-(rootfs_data)"
  • Drop-in replacement of i2cget, i2cset and i2cdump commands from i2c-tools package:

    # ipctool i2cget 0x34 0x3000
    # ipctool i2cset 0x34 0x3000 1
    # ipctool i2cdump 0x34 0x3000 0x31ff
    # ipctool i2cdump --script 0x34 0x3000 0x31ff
  • The same approach is to manipulate SPI sensor registers:

    # ipctool spiget 0x200
    # ipctool spiset 0x200 1
    # ipctool spidump 0x200 0x300
    # ipctool spidump --script 0x200 0x300
  • Dump the state of pinmux registers in human- and machine-readable format or shell script ready to be applied on another system:

    # ipctool reginfo
    # ipctool --script reginfo
  • Advanced replacement of strace:

    # ipctool trace /usr/bin/Sofia

To help the researcher

On Ingenic devices, the original Sensor I2C address needs to be right shifted by 1bit, example:

IMX335: (0x34 >> 1) = 0x1A
SC2230: (0x60 >> 1) = 0x30
GC2053: (0x6E >> 1) = 0x37

Supported SoCs

Tested on:

Manufacturer Models
HiSilicon Hi3516CV100/200/300, Hi3516EV100/200/300, Hi3516DV300, Hi3518EV100
SigmaStar SSC335
Xiongmai XM510, XM530, XM550
Rockchip RV1109
Goke GK7205v200/210/300

Please test on your device to help us extend the list.

Supported boards

Tested on:

Manufacturer Models
Xiongmai Various models
Hankvision V6202IR-IMX327
Ruision RS-H649F-A0, RS-H651JAI-AO, RS-H656S-AO
TP-Link NC210

Supported sensors

Tested on:

Manufacturer Models
Silicon Optronics, Inc. JX-F22, JX-F23, JX-F37, JX-H62, JX-H65, JX-K05
Sony IMX224, IMX290, IMX291, IMX307, IMX322, IMX323, IMX327, IMX335, IMX415, IMX664
ON Semiconductor AR0130, AR0237
SmartSens SC2135, SC223A, SC2232, SC2235, SC2235P, SC2239, SC2315e (SC307E, SC4239Р), SC335E (SC5300)
OmniVision OV9712
GalaxyCore GC2053

Please test on your device to help us extend the list.


Support

OpenIPC offers two levels of support.

  • Free support through the community (via chat).
  • 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.

Participating and Contribution

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.

Thank you.

Open Collective donate button

ipctool's People

Contributors

brainstorm avatar ch999dev avatar chertov avatar cronyx avatar dimerr avatar dimerrr avatar gckzl avatar nekromant avatar nitr0man avatar p0i5k avatar pfalcon avatar pianist avatar roboschmied avatar themactep avatar valpackett avatar viktorxda avatar widgetii avatar wonbinbk avatar ystinia avatar zigfisher avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ipctool's Issues

IMX347 detected as IMX335

board MC-K45 ( SSC30KQ / IMX347 )

// from IMX335 datasheet, p.40

I think something like this would be better

int sensor_id = READ(0x57); // 0x3057
switch(sensor_id) {
  case 0x06: // IMX347
  break;
  case 0x07: // IMX335
  break;
}

i2cdump does not show last register byte

last byte of requested sequence is missing

ipctool i2cdump 0x60 0x3107 0x3109 shows only 2 of 3 register bytes CB 3E . The last byte of the register is always skipped:

root@openipc-gk7205v210:/tmp# ./ipctool i2cdump 0x60 0x3107 0x3109
       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
CB  3E

But output should be (in my case) CB 3E 01.
Even though we can get the output we want by incrementing the to-register by 1, the last register will never be readable by i2cdump.

In other words: source

ipctool is kinda stupid and does not include the last region in the sequence

code problem

for (size_t i = from_reg_addr; i < to_reg_addr; ++i) {

solution

for (size_t i = from_reg_addr; i <= to_reg_addr; ++i) {

ipctool-mips32 trace not working as expected

/tmp # ./ipctool-mips32 trace /tmp/encoder
found unknown command: trace

ipctool, version: master+76c7253, built on 2022-08-11

OpenIPC is asking for your help!
Please help the Team of OpenIPC project to cover the cost of development
and long-term maintenance of what we believe will be a stable, flexible
Open IP Network Camera Framework for users worldwide.

Your contribution could help us to advance the development and keep you
updated on improvements and new features more regularly.

Please visit https://openipc.org/sponsor/ to learn more. Thank you.

Usage:  ipctool [OPTIONS] [COMMANDS]
Where:
  -c, --chip-id             read chip id
  -s, --sensor-id           read sensor model and control line
  -t, --temp                read chip temperature (where supported)

  backup <filename>         save backup into a file
  restore [mac|filename]    restore from backup (cloud-based or local file)
     [-s, --skip-env]       skip environment
     [-f, --force]          enforce
  upgrade <bundle>          upgrade to OpenIPC firmware (experimental feature, use only on cameras with UART)
     [-f, --force]          enforce
  printenv                  drop-in replacement for fw_printenv
  setenv <key> <value>      drop-in replacement for fw_setenv
  dmesg                     drop-in replacement for dmesg
  i2cget <device address> <register>
  spiget <register>
                            read data from I2C/SPI device
  i2cset <device address> <register> <new value>
  spiset <register> <new value>
                            write a value to I2C/SPI device
  i2cdump [--script] <device address> <from register> <to register>
  spidump [--script] <from register> <to register>
                            dump data from I2C/SPI device
  i2cdetect                 attempt to detect devices on I2C bus
  reginfo [--script]        dump current status of pinmux registers
  gpio (scan|mux)           GPIO utilities
  trace [--skip=usleep] <full/path/to/executable> [program arguments]
                            dump original firmware calls and data structures
  -h, --help                this help
/tmp # 
/tmp # ls -alh /tmp/encoder
-rwxr-xr-x    1 root     root        2.5M Jan  1 00:00 /tmp/encoder

gc1024 is not detected

ipctool -s returns a message Error: unexpected value for SuperPix == 0x78.

Manual detection

I've followed suggestions of OpenIPC's telegram chat members and ran:

# ./ipctool i2cdetect
       0  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f
     : xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |
                      ....
   70: xx xx xx xx xx xx xx xx  78 79 xx xx xx xx xx xx  |
                      ....
  f0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx

The sensor id can be found at f0 - 10 24. (Unnecessary lines are removed, file with the original output - i2cdump_0x78.txt)

# ./ipctool i2cdump 0x78 0 0x3ff
       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
    : 00 1F FF 03 98 01 6F 00  A6 00 00 00 08 02 E6 05  |  ......o.........
  10: 08 00 18 11 01 00 C0 17  0A 06 11 4F 11 10 F8 38  |  ...........O...8
...
  e0: 00 AB B6 80 9D EC F1 C7  DA 00 00 00 00 00 1D 40  |  ...............@
  f0: 10 24 0F 00 03 00 00 B9  03 0E 00 78 C4 11 00 00  |  .$.........x....
 100: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |  ...............
...
 1f0: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  |  ................
 200: 03 03 03 03 03 03 03 03  03 03 03 03 03 03 03 03  |  ................
 ...
 2d0: 03 03 03 03 03 03 03 03  03 03 03 03 03 03 03 03  |  ................
...
 3f0: 98 98 98 98 98 98 98 98  98 98 98 98 98 98 98     |  ...............

The problem

According to the detection function source code, 3f0 or 3f1 should be FF to read the value from f0 address.

ipctool/src/sensors.c

Lines 664 to 675 in 11f8946

static int detect_galaxycore_sensor(sensor_ctx_t *ctx, int fd,
unsigned char i2c_addr) {
if (i2c_change_addr(fd, i2c_addr) < 0)
return false;
int prod_msb = i2c_read_register(fd, i2c_addr, 0x3f0, 2, 1);
int prod_lsb = i2c_read_register(fd, i2c_addr, 0x3f1, 2, 1);
if (prod_msb == -1 || prod_lsb == -1) {
prod_msb = i2c_read_register(fd, i2c_addr, 0xf0, 1, 1);
prod_lsb = i2c_read_register(fd, i2c_addr, 0xf1, 1, 1);
}

But it's not the case, because 3f0 and 3f1 are filled with a garbage. You can see the output of multiple executions below:

# ./ipctool i2cdump 0x78 0x3f0 0x3ff
       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
 3f0: CE CE CE CE CE CE CE CE  CE CE CE CE CE CE CE
# ./ipctool i2cdump 0x78 0x3f0 0x3ff
       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
 3f0: 50 50 50 50 50 50 50 50  50 50 50 50 50 50 50
# ./ipctool i2cdump 0x78 0x3f0 0x3ff
       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
 3f0: 59 59 59 59 59 59 59 59  59 59 59 59 59 59 59

Side-effects

Also, garbage in fa and in fb addresses prevents the early break in SuperPix detection function

ipctool/src/sensors.c

Lines 746 to 749 in 11f8946

prod_msb = i2c_read_register(fd, i2c_addr, 0xfa, 1, 1);
// early break
if (prod_msb == -1)
return false;

and execution falls into the default case

ipctool/src/sensors.c

Lines 768 to 769 in 11f8946

default:
SENSOR_ERR("SuperPix", res);

, so we get an error message Error: unexpected value for SuperPix == 0x78, but it's not a SuperPix sensor

Solutions?

I'm knew to this topic and don't have a fundamental knowledge in sensors/i2c stuff, so I can't say if it's OK to have a "garbage" in a memory and how to deal with it. But can we check the value of f0 address before 3f0?

Please add the output for more information about the Ethernet interface

This code allows us to get excellent information about the processors of the first group

for hieth in $(ls -l /sys/module/hieth/parameters | awk '{print $9}'); do echo ${hieth}=$(cat /sys/module/hieth/parameters/${hieth}); done

mdioifd=1 mdioifu=1 phyaddrd=1 phyaddru=0

Please add the information in some other order, see the example.

---
chip:
  vendor: HiSilicon
  model: 3518EV100
ethernet:
  mac: "00:00:23:34:45:66"
  mdioifu: 1
  mdioifd: 1
  phyaddru: 1
  phyaddrd: 0
......

Note: mdioifX 0=mii, 1=rmii

TNX !

P.S. It would be very good to find the same data for other processor groups, but I haven't been able to do it yet..

gpio scan issue

I have module IMA20S07 with SSC335 and IMX307.
I've flashed module with latest image 2.3.12.07-lite.
IRCUT is not working, so i ran command ipctool gpio scan, but i got empty return with exit code 1.

I tried ipctool trace /tmp/ipctool gpio scan, but ipctool creates child process and trace tool does not support tracing of child processes.

Is there any other way of debugging this? Besides setting up complete SDK and compiling new ipctool with additional outputs.

ipctool doesn't create any output

When I run ipctool on my hardware, I run it from the SD card as the root filesystem is readonly.

I've noticed it won't output a file. Only a few of the options produce any kind of output. I can get the dmesg command to output a lot of info.

Here's my Mini 4k Spy Camera I found for like... $5 at a liquidation store:

/proc/cpuinfo output

[root@anyka /mnt]$ cat /proc/cpuinfo
Processor       : ARM926EJ-S rev 5 (v5l)
BogoMIPS        : 199.06
Features        : swp half fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 5

Hardware        : Cloud39E_AK3918E+H42_V1.0.2
Revision        : 0000
Serial          : 0000000000000000
[root@anyka /mnt]$

dmesg output

PS h62_g_ctl val:25
<4>irq_handle_continous_mode 549: vb->i=3, but id -1
<4>irq_handle_continous_mode 549: vb->i=2, but id -1
<4>h62_set_fps :fps = 10
<4>FPS h62_g_ctl val:10
<4>RTL871X: rtw_set_ps_mode(wlan0) Leave 802.11 power save - WIFI-TRAFFIC_BUSY
<4>RTL871X: rtl8188e_set_FwPwrMode_cmd: Mode=0 SmartPS=2 UAPSD=0
<4>irq_handle_continous_mode 549: vb->i=3, but id -1
<4>RTL871X: rtw_set_ps_mode(wlan0) Enter 802.11 power save - WIFI-TRAFFIC_IDLE
<4>RTL871X: rtl8188e_set_FwPwrMode_cmd: Mode=1 SmartPS=2 UAPSD=0
<4>h62_set_fps :fps = 25
<4>FPS h62_g_ctl val:25
<4>~~irq_handle_continous_mode 555: vb->i=1, but id 128
<4>irq_handle_continous_mode 549: vb->i=0, but id -1
<4>irq_handle_continous_mode 549: vb->i=1, but id -1
<4>irq_handle_continous_mode 549: vb->i=3, but id -1
<4>h62_set_fps :fps = 10
<4>FPS h62_g_ctl val:10
<4>h62_set_fps :fps = 25
<4>FPS h62_g_ctl val:25
<4>irq_handle_continous_mode 549: vb->i=1, but id -1
<4>irq_handle_continous_mode 549: vb->i=0, but id -1
<4>h62_set_fps :fps = 10
<4>FPS h62_g_ctl val:10
<4>h62_set_fps :fps = 25
<4>FPS h62_g_ctl val:25
<4>~~irq_handle_continous_mode 555: vb->i=1, but id 128
<4>RTL871X: rtw_set_ps_mode(wlan0) Leave 802.11 power save - WIFI-TRAFFIC_BUSY
<4>RTL871X: rtl8188e_set_FwPwrMode_cmd: Mode=0 SmartPS=2 UAPSD=0

I can glean from this that the camera is the ankya variety. That also shows in the login info when I telnet into it.

I can see a config file for the firmware, but I don't know what to do with that.

Anyone know why it won't output the info?

Сообщение об инициализации

При выполнении инициализации сенсора приложение может "подвисать" на 15-20 секунд. Что-бы пользовательне нервничал, неплохо было-бы выводить какое-то сообщение, мол, подождите N секунд.

Detect OpenWrt or Buildroot environments to prevent firmware backup

Sample output for OpenWRT:

root@OpenWrt:/mnt/sd/mpp/ko# cat /etc/os-release 
NAME="OpenWrt"
VERSION="SNAPSHOT"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt SNAPSHOT"
VERSION_ID="snapshot"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
BUILD_ID="r13272+2-367a30389d"
OPENWRT_BOARD="hi35xx/18ev200"
OPENWRT_ARCH="arm_arm926ej-s"
OPENWRT_TAINTS="no-all busybox"
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt SNAPSHOT r13272+2-367a30389d"

tftp as alternative method and new T10 camera

My MIPS-based camera has a tftp binary and no NFS support on mount, therefore:

On a desktop machine

$ pip install ptftpd
$ ptftpd -p 6969 en0 /Users/rvalls/Downloads

On the embedded device (camera)

# tftp -r /Users/rvalls/Downloads/ipctool-mips32 -g 192.168.1.107 6969

/Users/rvalls/Downlo  46% |**************                 | 61952   0:00:01 ETA
/Users/rvalls/Downlo  97% |****************************** |   126k  0:00:00 ETA
/Users/rvalls/Downlo 100% |*******************************|   129k  0:00:00 ETA
/Users/rvalls/Downlo 100% |*******************************|   129k  0:00:00 ETA

Then the resulting YAML file for this camera with this bootlog looks like this:

/tmp # ./ipctool-mips32 
---
chip:
  vendor: Ingenic
  model: T10
ethernet:
  mac: "40:ffaa:56:32:13:ff"
rom:
  - type: nor
    block: 32K
    partitions:
      - name: boot
        size: 0x40000
        sha1: 3ed97345
      - name: kernel
        size: 0x190000
        sha1: 5e503445
      - name: root
        size: 0x300000
        sha1: c67bd327
      - name: appfs
        size: 0x330000
        path: /system,jffs2,rw
    size: 8M
ram:
  total: 64M
  media: 0M
firmware:
  kernel: "3.10.14 (PREEMPT Tue Oct 30 18:55:41 PDT 2018)"
  toolchain: gcc version 4.7.2 (Ingenic r2.3.3 2016.12) 
  libc: uClibc 0.9.33.2

It didn't really collect any information about the sensor, UBoot version, etc... like the example on the README.md though :/

Thanks @ZigFisher for your assistance over Gitter!

Incorrect sensor detection on two test cameras

172.17.32.51# ./ipc_chip_info 
Chip: HiSilicon 3516cv300
Sensor: Sony IMX323

172.17.32.52# ./ipc_chip_info 
Chip: HiSilicon 3516cv300
Sensor: Sony IMX323

cat /proc/umap/sys on both shows ar0237 type but Sofia detects as SC2235:

[DEBUG]: mirror=0
[DEBUG]: Flip=0
[DEBUG]: ~~~~~~~~~~SC2235_init  JJ ~~~~~~~~~
[DEBUG]: Denoise level:  Day[3]      Night[3]
[DEBUG]: Denoise level:  Day[3]      Night[3]
[DEBUG]: IR: 65

Отображение разделов MTD

Прошу добавить в вывод утилиты отображение разделов MTD, получаемых по команде (один из вариантов) cat /proc/mtd

Problem with GK7205V210 chip detection

root@openipc-gk7205v210:~# ipctool
The ipctool installed as remote GitHub plugin
---
chip:
  vendor: Goke
  model: 7205V210
  id: 25e9e400808f41e3
Platform is not supported
root@openipc-gk7205v210:~# 
root@openipc-gk7205v210:~# ipcinfo -csvtFS
gk7205v210
sc2239
goke
55.53
nor
/usr/bin/majestic
root@openipc-gk7205v210:~#

It is possible that the solution can be found here

#define IS_16EV200 IS_CHIP("3516EV200") || IS_CHIP("7205V200")
#define IS_16EV300 IS_CHIP("3516EV300") || IS_CHIP("7205V300")
#define IS_18EV300 IS_CHIP("3518EV300") || IS_CHIP("7202V300")
#define IS_16DV200 IS_CHIP("3516DV200") || IS_CHIP("7605V100")

Collecting information about SigmaStar devices

Recently I found this output of information.
Perhaps it will be useful when researching the original firmware.

root@uniview-dev:~# cat /sys/devices/soc0/machine

INFINITY6B0 SSC009A-S01A QFN88

Inproper chip detection for Hi3516cv100 board

Reported by @Bertrand_dHerouville in OpenIPC.org (EN) telegram channel.

root@OpenIPC_HI35xx:/tmp# ./ipc_chip_info
Chip: HiSilicon 3518?v100
Open /dev/i2c-0 error!
CMD_SET_DEV error!
CMD_SET_DEV error!
CMD_SET_DEV error!
CMD_SET_DEV error!

It seems it's a different chip:

image

By the way it also reported in kernel logs as:

[    0.000000] Machine: hi3518
[    0.000000] Ignoring unrecognised tag 0x54410010

i2cdetect output corrupted on last line

The last line of the output from command ipctool i2cdump is arranged the wrong way.

Example 1

root@openipc-gk7205v210:/tmp# ./ipctool i2cdump 0x61 0x00 0xfe
       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
    : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  10: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  20: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  30: 00 00 00 01 00 00 60 00  00 18 00 00 00 00 00 00  |  ......`......... 
  40: 00 00 00 00 0A 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  50: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  60: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  70: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  80: 2B 07 01 9F A1 37 24 41  C4 A0 39 40 6B A0 37 B2  |  [email protected]. 
  90: 09 00 00 00 00 00 00 00  4E 44 45 32 38 34 04 00  |  ........NDE284.. 
  a0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  c0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  d0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  e0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  f0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00        |  .............. 
00

Example 2

root@openipc-gk7205v210:/tmp# ./ipctool i2cdump 0x61 0x00 0xff
       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
    : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  10: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  20: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  30: 00 00 00 01 00 00 60 00  00 18 00 00 00 00 00 00  |  ......`......... 
  40: 00 00 00 00 0A 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  50: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  60: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  70: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  80: 2B 07 01 9F A1 37 24 41  C4 A0 39 40 6B A0 37 B2  |  [email protected]. 
  90: 09 00 00 00 00 00 00 00  4E 44 45 32 38 34 04 00  |  ........NDE284.. 
  a0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  c0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  d0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  e0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |  ................ 
  f0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00     |  ............... 
00  |  ................

'Segmentation fault' using telnet_upload.py

I have a TOP-201 (Hi3518E) camera that i want to convert to OpenIPC if possible.

I tried running ipctool, had to use the telnet_upload.py method as it doesn't have tftpd or something available.

The Python script ran for a few minutes and seem to be done. But it exited with this error:

# chmod 755 /tmp/ipctool
# /tmp/ipctool
Segmentation fault

I tried a few times, but couldn't get it working.

Upgrade / Restore fails on Videopark devices

Hi, I've tested upgrade / restore functunality of the tool and it fails on my devices
I have some devices to test and can flash ofw back, how should I debug the flash process?

Also, should i upload a dump somewhere? I did not see the hunter streamer binary anywhere

/tmp # ./ipctool
---
chip:
  vendor: HiSilicon
  model: 3516CV300
ethernet:
  mac: "e0:61:b2:4e:a6:ff"
  u-mdio-phyaddr: 1
  phy-id: 0x001cc816
  d-mdio-phyaddr: 0
rom:
  - type: nor
    block: 64K
    partitions:
      - name: boot
        size: 0x40000
        sha1: 48195e9b
        contains:
          - name: uboot-env
            offset: 0x20000
      - name: defcfg
        size: 0x10000
        sha1: 67d9fc96
      - name: kernel
        size: 0x1f0000
        sha1: 7625fbaa
      - name: root
        size: 0x960000
        path: /,squashfs
        sha1: cb44f590
      - name: custom
        size: 0x400000
        sha1: f427120a
      - name: config
        size: 0x60000
        sha1: 928813b9
    size: 16M
    addr-mode: 3-byte
ram:
  total: 256M
  media: 144M
firmware:
  kernel: "3.18.20 (Wed Apr 4 14:46:18 CST 2018)"
  toolchain: gcc version 4.9.4 20150629 (prerelease) (Hisilicon_v500_20150831)
  libc: uClibc 0.9.33.2
  sdk: "Hi3516CV300_MPP_V1.0.1.0 B070 Release (Feb 13 2017, 20:42:49)"
  main-app: hunter
sensors:
- vendor: Sony
  model: IMX323
  control:
    bus: 0
    type: i2c
    addr: 0x34
  data:
    type: DC
  clock: 37.125MHz

~ # cat /proc/partitions
major minor  #blocks  name

  31        0        256 mtdblock0
  31        1         64 mtdblock1
  31        2       1984 mtdblock2
  31        3       9600 mtdblock3
  31        4       4096 mtdblock4
  31        5        384 mtdblock5
~ # cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / squashfs ro,relatime 0 0
devtmpfs /dev devtmpfs rw,relatime,size=53760k,nr_inodes=13440,mode=755 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /tmp tmpfs rw,relatime 0 0
tmpfs /var tmpfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
/dev/mtdblock4 /mnt/special squashfs ro,relatime 0 0
/dev/mtdblock5 /mnt/mtd jffs2 rw,sync,relatime 0 0

~ # dmesg | grep hisi_spi_nor.0
hisi-sfc hisi_spi_nor.0: all blocks is unlocked.
hisi-sfc hisi_spi_nor.0: gd25q128 (16384 Kbytes)

/tmp # ./ipctool upgrade upgrade.cv300
There was no Sofia process detected
Use --force switch to skip the check
aborting...
/tmp # ./ipctool upgrade upgrade.cv300 --force
There was no Sofia process detected
Unmounting /mnt/special
Unmounting /mnt/mtd
Using 'upgrade.cv300' as upgrade bundle
        boot    0xb68d4010, size: 262144 bytes
        env     0x63010, size: 65536 bytes
        kernel  0xb66f3010, size: 1966080 bytes
        rootfs  0xb6272010, size: 4718592 bytes
Analyzing boot
Analyzing env
Analyzing kernel
Analyzing rootfs
Upgrading boot
Flashing [wwww]
Upgrading env
Flashing [w]
Upgrading kernel
Flashing [wwwwwwwwwwwwwwwwwwwwwwwwwwwwww]
Upgrading rootfs
Could not open mtd device: 46.....................................................]

Something went wrong, aborting...
Early exit, check the logs

/tmp # ./ipctool restore bak
Restoring the backup

Loading backup from file bak...
Are you sure to proceed? (y/n)? y
Checking boot...
[0] 0x00000000  0x00040000      48195e9b        48195e9b
Checking defcfg...
[1] 0x00040000  0x00010000      67d9fc96        67d9fc96
Checking kernel...
[2] 0x00050000  0x001f0000      7625fbaa        7625fbaa
Checking root...
[3] 0x00240000  0x00960000      cb44f590        cb44f590
Checking custom...
[4] 0x00ba0000  0x00400000      f427120a        f427120a
Not checked (no SHA1)
[5] 0x00fa0000  0x00060000           n/a
Backups were checked
Analyzing boot
Analyzing defcfg
Analyzing kernel
Analyzing root
Analyzing custom
Analyzing config
Restoring boot
Flashing [wwww]
Restoring defcfg
Flashing [w]
Restoring kernel
Fail to erase +0x40000...................]

Something went wrong, aborting...

Incorrect CV300+IMX290 on SPI detection

---
chip:
  vendor: HiSilicon
  model: 3516CV300
ethernet:
  mac: "00:13:02:01:f9:c3"
rom:
  - type: nor
    size: 16M
    block: 64K
    partitions:
      - name: boot
        size: 0x80000
      - name: kernel
        size: 0x300000
      - name: rootfs
        size: 0xc80000
hibvt-i2c 12110000.i2c: wait idle timeout, RIS: 0x10, SR: 0xe0100
hibvt-i2c 12110000.i2c: wait idle timeout, RIS: 0x10, SR: 0xe0200
hibvt-i2c 12110000.i2c: wait idle timeout, RIS: 0x10, SR: 0xe0200
hibvt-i2c 12110000.i2c: wait idle timeout, RIS: 0x10, SR: 0xe0100
hibvt-i2c 12110000.i2c: wait idle timeout, RIS: 0x10, SR: 0xe0200

Hardware was bought on link https://aliexpress.ru/item/32974244338.html

run ipctool on Goke GK7205V300

Hi all,
First, thanks for the wonderful work done on ipctool.
I have a vanilla Goke GK7205V300 SoC with http admin access and would like to install ipctool.
From the ipctool installation instructions, it seems I need to have some kind of terminal connection to the SoC.
I did a nmap, and port 23 is open, so I should be able to telnet and install ipctool, but when asked for login/password, I don't know what to put.

Is there any other way to install ipctool, or do you know how we can telnet to this SoC?
I do have admin access through http.

Thanks in advance for your help.
Best,
Jérôme.

FYI nmap results:

nmap -v -sV -sT -p- -oA nmap_full 192.168.8.130
Starting Nmap 7.80 ( https://nmap.org/ ) at 2022-11-04 12:47 CET
NSE: Loaded 45 scripts for scanning.
Initiating ARP Ping Scan at 12:47
Scanning 192.168.8.130 [1 port]
Completed ARP Ping Scan at 12:47, 0.06s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 12:47
Completed Parallel DNS resolution of 1 host. at 12:47, 0.00s elapsed
Initiating Connect Scan at 12:47
Scanning e0:3c:5b:95:ac:06 (192.168.8.130) [65535 ports]
Discovered open port 23/tcp on 192.168.8.130
Discovered open port 80/tcp on 192.168.8.130
Discovered open port 8080/tcp on 192.168.8.130
Discovered open port 554/tcp on 192.168.8.130
Discovered open port 3210/tcp on 192.168.8.130
Discovered open port 8554/tcp on 192.168.8.130
Discovered open port 13452/tcp on 192.168.8.130
Discovered open port 1935/tcp on 192.168.8.130
Completed Connect Scan at 12:47, 9.53s elapsed (65535 total ports)
Initiating Service scan at 12:47
Scanning 8 services on e0:3c:5b:95:ac:06 (192.168.8.130)

ipctool collects complete firmware dumps without the user's knowledge or approval

When run without arguments, ipctool prints a summary about the device information, as is documented in the README.

However, it also starts a background process that uploads the entire device storage to an S3 bucket, without asking for confirmation from the user, nor even letting them know that this is happening. This behaviour is not documented anywhere, and it is completely unexpected given the description of the tool.

This "feature" may have been implemented with the best intentions, but the collected data contains personal information, such as /etc/passwd files, wifi passwords, SSL/SSH/VPN keys, etc. As such, it is in violation of the GDPR. As a general principle, if you want the user's help in collecting device information, you should ask for that help, not do it behind the user's back. Users of unsuported devices will be more than happy to assist you, and you'll also avoid getting firmware dumps for devices you already support.

I'm happy to provide a patch removing this unwanted behavior, but first I'm curious to hear your thoughts on this.

GPIO scan use instructions?

Trying to configure GPIOs on "BLK18E-0012-38X38_S 50H10PE-S" board. It flashed without any issues (other than Ethernet needed some IOs enabled I guess, but that information was found.

I can do registry GPIO dump and there is no IR cut. Web interface has night mode disabled and no pins assigned.
So GPIO scan appeared to be the right tool. I can scan and see the report, but there is no explanation how it works and what to expect. There is a message: "waiting to toggle some IOs". I did toggle inputs to the IR Cut driver chip, expecting they are inputs on 3518 when unconfigured and I should see the change, but nothing happens.

I'm also concerned tat if IO is already output - it can be blown by external stimulus. Most IOs on HiSi chips are only 4 or 8mA.

Would be nice to have a bit more explanation about GPIO scan:

  • Does GPIO scan put all pins in HiZ? Maybe only unassigned/undeclared in registry?
    -how long pin have to be stimulated to be registered as changed? is it instantaneous or slow and require full scan cycle? How long is it?
    -as I have not seeing report of changed pins - some screen grabs would help. Unless it is so obvious.
  • web interface IO number format? Scan reports dual numbers separated by underscore. Is web interface takes the same format or it is remapped as linear numbers?
  • A little walk through use and operation of GPIO scan tool would be nice.
  • Best practice to scan and identify pins for IRcut, IRlight and SDC input?
  • How is "ipc tool/gpio scan"related to "gpio" app that I assume is independent app in default firmware. That one offered to scan toggle all pins or a (linear) range, so I assume it is not reading but driving, which is also can potentially blow some IOs.

I think whole community will benefit from these clarifications.

Cheers y'all!

Longse additional info

# cat /var/cfg/Ver.ini
[VERSION]
sofvar=RV1109_IMX335NAND_BVH0L0A0T0Q0_W_21.1.36.6

it could be sofvar=3516CV500_IMX307_B1T1A1M0C0P1_W_9.1.53.1 as well

Run ipctool from SD card

Hi, any chance of some instructions on how to run ipctool from an sdcard, serial connection or from micro USB? Im having trouble setting up a tftp connection.

Please add the CPU temperature measurement code to your beautiful utility

HI3516CV200 / HI3518EV200 / HI3518EV201
devmem 0x20270110 32 0x60FA0000 ; devmem 0x20270114 8  | awk '{print "CPU temperature: " ((($1)*180)/256)-40}'

HI3516CV300 / HI3518EV100
devmem 0x1203009C 32 0x60FA0000 ; devmem 0x120300A4 16 | awk '{print "CPU temperature: " (((($1)-125.0)/806)*165)-40}'

HI3516EV200 / HI3516EV300
devmem 0x120280B4 32 0xC3200000 ; devmem 0x120280BC 16 | awk '{print "CPU temperature: " (((($1)-117)/798)*165)-40}'

HI3536C/HI3536D
himm 0x0120E0110 0x60320000 > /dev/null; himm 0x120E0118 | awk '{print $4}' | dd skip=1 bs=7 2>/dev/null | awk '{print "0x"$1}' | awk '{print "CPU temperature: " (($1*180)/256)-40}'

P.S. I didn't find a formula for old processors.

[Same Chip ID] 3 sensors are not distinguished

Problem

There are 3 sensors in the openipc repos that have the same chip ID cb3e and are all seen as sc223a by ipctool.

#define SC223A_CHIP_ID_H	(0xcb)
#define SC223A_CHIP_ID_L	(0x3e)
#define SC233A_CHIP_ID_H	(0xcb)
#define SC233A_CHIP_ID_L	(0x3e)
#define SC2239P_CHIP_ID_H	(0xcb)
#define SC2239P_CHIP_ID_L	(0x3e)

ipctool handling chip id cb3e

    case 0xcb3e:
        // XM
        strcpy(ctx->sensor_id, "SC223A");
        return true;

History

Here we found out that there may be different "versions" of the sc223a.

Thanks to @johndi3 who mentioned sc233a and thanks to @themactep who helped discovering the ChipID.

Solution

As done here we should regard more registers to differentiate between the 3 sensors.

ToDo

If you have one of the 3 sensors, please post the result of this command:

ipctool i2cdump 0x60 0x3100 0x310F

That will show your device ID + some more registers.

The output of my "version" of the sc223a (sold as sc5239s) is:

root@openipc-gk7205v210:~# ipctool i2cdump 0x60 0x3100 0x310F
       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
3100: 00 12 00 08 01 12 05 CB  3E 01 00 00 00 00 00

The important part here is CB 3E 01.
The register 0x3109 (here value 01) can differ between the 3 sensors.

We need to find the different values of register 0x3109 for each of the 3 sensors.
Thank you.

i2cdetect skips last address (0xff)

Problem

ipctool i2cdetect is always skipping the last address in its output. So i2c address 0xff is not readable with it.

root@openipc-gk7205v210:/tmp# ./ipctool i2cdetect
       0  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f
    : xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  10: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  20: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  30: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  40: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  50: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  60: 60 61 xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  70: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  80: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  90: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  a0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  b0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  c0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  d0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  e0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  f0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx 

The problem is similar to #113 (but in an other function).

for (i2c_addr = 0x0; i2c_addr < 0xff; ++i2c_addr) {

Solution

The solution is not as simple as #114 because the data type unsigned char used for i2caddr is always a value between 0-255 (0x00 - 0xFF). And 0xff + 1 = 0x00.
So changing the < to <=will result in an infinite loop because the condition i2c_addr <= 0xff is always true when using unsigned char.

So we have to check the condition at the end of the loop to get the desired output.

} while (i2c_addr != 0xff);

Final output:

root@openipc-gk7205v210:/tmp# ./ipctool i2cdetect
       0  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f
    : xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  10: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  20: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  30: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  40: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  50: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  60: 60 61 xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  70: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  80: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  90: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  a0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  b0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  c0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  d0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  e0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  f0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |

[ipctool spidetect] always calls i2cdetect

edited: short summary of the problem see next comment.

When I run the command ipctool spidetect I get the same results as running ipctool i2cdetect:

root@openipc-gk7205v210:/tmp# ipctool i2cdetect
       0  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f
    : xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  10: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  20: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  30: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  40: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  50: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  60: 60 61 xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  70: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  80: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  90: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  a0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  b0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  c0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  d0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  e0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  f0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx 
root@openipc-gk7205v210:/tmp# ./ipctool spidetect
       0  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f
    : xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  10: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  20: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  30: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  40: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  50: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  60: 60 61 xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  70: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  80: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  90: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  a0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  b0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  c0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  d0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  e0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx  |  
  f0: xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx 

code problem

    } else if (!strcmp(argv[0] + 3, "detect")) {
            return i2cdetect(argc - optind, argv + optind, script_mode);
    }
  • The i2c_mode is not regarded as done here:
    } else if (!strcmp(argv[0] + 3, "dump")) {
        if (i2c_mode)
            return i2cdump(argc - optind, argv + optind, script_mode);
        else
            return spidump(argc - optind, argv + optind, script_mode);
  • And there is no spidetect function in i2cspi.c.

Solution 1 (if spidetect should be implemented)

  • regard i2c_mode:
    } else if (!strcmp(argv[0] + 3, "detect")) {
+       if (i2c_mode)
            return i2cdetect(argc - optind, argv + optind, script_mode);
+       else
+           return spidetect(argc - optind, argv + optind, script_mode);

and:

ToDo 1

  • create a spidetect function.

Solution 2 (if spidetect is not needed)

  • regard i2c_mode
    } else if (!strcmp(argv[0] + 3, "detect")) {
+       if (i2c_mode)
            return i2cdetect(argc - optind, argv + optind, script_mode);

in i2cspi.c

Wrong chip detection for IPG-80HE20PS-S

Xm_Wdt:g_cpu_type:1[0:16CV300,1:16EV100].
SC2235P SensorID 0x2232
Xm_Wdt:CPU_TYPE_HI3516EV100

**********************************************************************
|                      SYSTEM INFO                                       
|                 ID:           0x0001
|       product type:           HI3516EV100_50H20L_S38
|           DSP chip:           DSP_HI3516EV100
|     LIBDVR version:       Complied at Aug 13 2018 18:23:40 SVN:3086
**********************************************************************

ipctool segfaults on xm510

Hi

I am playing around with a camera I have laying around, I think we identify this as an xm510. I got telnet access with the Snawoot/hisilicon-dvr-telnet tool.

I tried to download the ipctool binary on https://github.com/OpenIPC/ipctool/releases/download/latest/ipctool which appears to have been updated two days ago.

$ sha256sum ipctool 
8d0f7c48c1f6a616d39bff8dc41c1e2ac86b1b6276995eca0211eecd29cd97eb  ipctool
$ file ipctool 
ipctool: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, no section header

My device reports:

~ # cat /proc/cpuinfo
cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 199.06
Features        : swp half fastmult edsp 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc05
CPU revision    : 1

Hardware        : xm510
Revision        : 0000
Serial          : 0000000000000000
cat /proc/kmsg
<5>Linux version 3.0.101 (jinze@xd-server-0001) (gcc version 4.9.2 (Buildroot 2014.08) ) #11 Tue Jun 20 08:36:44 CST 2017
<4>CPU: ARMv7 Processor [410fc051] revision 1 (ARMv7), cr=10c53c7d
...

So I guess that it segfaults because it is not built for the correct abi? Does a version for ARMv7 exist somewhere precomipled?

Last part of the transfer for completeness:

~ # echo -ne '\x27\xf8\xd3\xf8\x58\xa0\x77\x03\x5f\x60\x27\x3b\x98\x6f\x4f\x72\x
98\x5f\xc8\x68\x03\x64\x25\xba\xf5\x05\x58\x60\x6c\x43\x1e\x00\x25\x67\x36\x6a\x
0b\x0b\x27\xf2\x28\x8e\xe5\x24\x7e\xc9\x94\x23\x5d\x6f\x83\x4f\x30\x60\x0f\xbf\x
27\x28\x00\x25\xbd\x1b\xf6\x03\x78\x4b\x76\x70\x17\x1d\x4c\xd2\x27\x2c\x43\x00\x
60\x9b\x6c\x27\x19\x78\xa4\x88\x01\x00\x00\x00\x00\x00\x04\x80\xff\x00\x00\x00\x
00\x55\x50\x58\x21\x00\x00\x00\x00\x00\x00\x00\x55\x50\x58\x21\x0e\x17\x03\x08\x
76\xcb\x14\x52\x90\xbf\xd9\xc3\x80\x81\x04\x00\x64\x06\x02\x00\x80\x81\x04\x00\x
50\x00\x00\xab\xa0\x00\x00\x00' >> /tmp/ipctool
~ # chmod 755 /tmp/ipctool
~ # /tmp/ipctool
Segmentation fault
~ # 

I wonder why the file size appaers to be different:

/tmp # ls -la ipctool 
-rwxr-xr-x    1 root     root        271080 Apr  3 23:07 ipctool

vs my own machine

ipctool]$ ls -lb ipctool 
-rwxr-xr-x 1 foo  foo 132744 Apr  3 23:02 ipctool

Could not start ipctool on original firmware

Hi and thanks for your work.

I have Hi3518ev100 (ESCAM QF001) camera.
I could not run ipctool on original firmware. I could install OpenIPC and ipctool works there, but I think sensor detected incorrectly.

chip:
  vendor: HiSilicon
  model: 3518EV100
board:
  vendor: OpenIPC
  version: 2.3.06.14
ethernet:
  mac: "00:12:16:b4:3c:3e"
  u-mdio-phyaddr: 1
  phy-id: 0x02430c54
  d-mdio-phyaddr: 0
  phy-mode: mii
rom:
  - type: nor
    block: 64K
    partitions:
      - name: boot
        size: 0x40000
        sha1: 42f2bad9
      - name: env
        size: 0x10000
        sha1: b82436a1
        contains:
          - name: uboot-env
            offset: 0x0
      - name: kernel
        size: 0x200000
        sha1: 8259e82a
      - name: rootfs
        size: 0x500000
        path: /,squashfs
        sha1: e9ba9523
      - name: rootfs_data
        size: 0xb0000
        path: /overlay,jffs2,rw
    size: 8M
    addr-mode: 3-byte
ram:
  total: 64M
  media: 32M
firmware:
  u-boot: "2010.06 (Nov 14 2022 - 19:25:39)"
  kernel: "3.0.8 (Wed Jun 14 10:11:57 UTC 2023)"
  toolchain: buildroot-gcc-12.2.0
  sdk: "Hi3518_MPP_V1.0.B.0  (Nov 19 2015, 16:37:04)"
sensors:
- vendor: Silicon Optronics
  model: JXH42
  control:
    bus: 0
    type: i2c
    addr: 0x60
  vicap-state: down

So in original FW I got:

hisilicon # tftp 0x82000000 ipctool
Hisilicon ETH net controler
miiphy_register: non unique device name '0:1'
miiphy_register: non unique device name '0:2'
MAC:   00-12-16-B4-3C-3E
UP_PORT : phy status change : LINK=UP : DUPLEX=FULL : SPEED=100M
TFTP from server 192.168.1.86; our IP address is 192.168.1.38
Download Filename 'ipctool'.
Download to address: 0x82000000
Downloading: #################################################
done
Bytes transferred = 128244 (1f4f4 hex)
hisilicon # go
## Starting application at 0x82000000 ...
undefined instruction
pc : [<82000008>]          lr : [<80807804>]
sp : 807cf1f0  ip : 0000001c     fp : 807cf629
r10: 807cfa29  r9 : 000003f3     r8 : 807cffe0
r7 : 00000002  r6 : 82000000     r5 : 807cfe20  r4 : 00000002
r3 : 82000000  r2 : 807cfe20     r1 : 807cfe20  r0 : 00000001
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

Am I doing something wrong?

Bad output on 3518?v100

172.17.32.53# ./ipc_chip_info 
Chip: HiSilicon 3518?v100
Open /dev/i2c-0 error!
CMD_SET_DEV error!
CMD_SET_DEV error!
CMD_SET_DEV error!
# ls -l /dev|grep i2c
crw-rw----    1 root     root       10,  47 Jan  1  1970 hi_i2c

Error: unexpected value for SmartSens == 0x1145

Executing ipc_chip_info produces an error
"Error: unexpected value for SmartSens == 0x1145"
for the --sensor_id part.
It is run in a camera doorbell device

# cat /proc/cpuinfo 
Processor       : ARM926EJ-S rev 5 (v5l)
BogoMIPS        : 269.10
Features        : swp half fastmult edsp java 
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 5

Hardware        : hi3518ev200

Full ipc_chip_info output:

# ./ipc_chip_info 
---
chip:
  vendor: HiSilicon
  model: 3518EV200
ethernet:
  mac: "*****"
rom:
  - type: nor
    size: 8M
    block: 64K
    partitions:
      - name: boot
        size: 0x60000
      - name: kernel
        size: 0x200000
      - name: rootfs
        size: 0x280000
      - name: rom
        size: 0x50000
      - name: app
        size: 0x2d0000
Error: unexpected value for SmartSens == 0x1145

Does it mean, that this type of sensor is not supported by OpenIPC?

Implement possible sensor detection algorithm on XM510

Strace output while system starts:

/var/utils # ./strace -f -e trace=ioctl dvrHelper /lib/modules /usr/bin/Sofia 127.0.0.1 9578 1 2>&1 |grep ioctl\(9
[pid  1039] ioctl(9, CMD_I2C_WRITE, {dev_addr=0x30, reg_addr=0x12, addr_byte_num=0x1, data=0x80, data_byte_num=0x1}) = 0
[pid  1039] ioctl(9, CMD_I2C_WRITE, {dev_addr=0x30, reg_addr=0x12, addr_byte_num=0x1, data=0x80, data_byte_num=0x1}) = 0
[pid  1039] ioctl(9, CMD_I2C_READ, {dev_addr=0x30, reg_addr=0xa, addr_byte_num=0x1, data=0x3d264, data_byte_num=0x1}) = 0
[pid  1039] ioctl(9, CMD_I2C_READ, {dev_addr=0x30, reg_addr=0xb, addr_byte_num=0x1, data=0xffffffff, data_byte_num=0x1}) = 0
[pid  1039] ioctl(9, CMD_I2C_READ, {dev_addr=0x30, reg_addr=0x3008, addr_byte_num=0x2, data=0xffffffff, data_byte_num=0x1}) = 0
[pid  1039] ioctl(9, CMD_I2C_READ, {dev_addr=0x30, reg_addr=0x3005, addr_byte_num=0x2, data=0xffffffff, data_byte_num=0x1}) = 0
[pid  1039] ioctl(9, CMD_I2C_WRITE, {dev_addr=0x36, reg_addr=0x103, addr_byte_num=0x2, data=0x1, data_byte_num=0x1}) = 0
[pid  1039] ioctl(9, CMD_I2C_READ, {dev_addr=0x36, reg_addr=0x300a, addr_byte_num=0x2, data=0x3d264, data_byte_num=0x1}) = 0
[pid  1039] ioctl(9, CMD_I2C_READ, {dev_addr=0x36, reg_addr=0x300b, addr_byte_num=0x2, data=0xffffffff, data_byte_num=0x1}) = 0
[pid  1039] ioctl(9, CMD_I2C_WRITE, {dev_addr=0x10, reg_addr=0x301a, addr_byte_num=0x2, data=0x1, data_byte_num=0x2}) = 0
[pid  1039] ioctl(9, CMD_I2C_READ, {dev_addr=0x10, reg_addr=0x3000, addr_byte_num=0x2, data=0x3d264, data_byte_num=0x2}) = 0

Alternative method to upload binary

Since NFS (perm error), bin2sh and other methods did not work I came up with another (automated) method to upload ipctool.
busybox with uudecode needed on target

Proof-of-concept:

#!/usr/bin/env python

#encode file with uuencode -m ipctool ipctool > ipctoolu
#run script with  python sender.py --host IP ipctoolu

import argparse
import telnetlib
from tqdm import tqdm


argparser = argparse.ArgumentParser()
argparser.add_argument('--host', required=True)
argparser.add_argument('--port', type=int, default=23)
argparser.add_argument('--user', type=str, default="root")
argparser.add_argument('--password', type=str, default="ivideo")
argparser.add_argument('src')
args = argparser.parse_args()

# Connect to the cam
t = telnetlib.Telnet(args.host, args.port)
#t.set_debuglevel(4)

# handle login prompt
t.read_until(b'(none) login: ', timeout=1)
t.write(args.user + b'\n')

t.read_until(b'Password: ', timeout=1)
t.write(args.password + b'\n')

#bad test if we are logged in
print("If this takes 10+ secs something is wrong...")
expected_sh = b'~ # '
t.read_until(expected_sh, timeout=10)
t.write(b'echo "test" > /tmp/testf\n')
t.read_until(expected_sh, timeout=10)
print("Did it? I am too lazy to implement a check xD")

#load file
payload = open(args.src, 'r')
Payload_Lines = payload.readlines()

expected_sh_2 = b"/tmp # "

print("If this takes 10 secs something is wrong...")
t.write(b'cd /tmp;F=payload;true>$F;chmod +x $F\n')
r = t.read_until(expected_sh_2, timeout=10)

print("Pushing file, go and grab a coffee :)")
for line in tqdm(Payload_Lines):
    t.write(b'echo "' + line.strip() + '" >> $F' + b'\n')
    r = t.read_until(expected_sh_2, timeout=10)

print("Captain speaking: File arrived at destination, we are now going to convert it back. hehe")
#decode on target
t.write(b'busybox uudecode payload\n')
r = t.read_until(expected_sh_2, timeout=5)
#make executable on target
t.write(b'chmod +x ipctool\n')
r = t.read_until(expected_sh_2, timeout=5)

print("Done :)")

xm530: No sensor detected

Hello!

Using openipc 2.1 firmware for xm530. ipctool does not detect any sensor.
Majestic only works in hls h265 mode, mp4, jpg, rtsp does not work...
Only some i2c_write timeout is shown in the kernel log.

root@openipc-xm530:~# ipctool --sensor_id
root@openipc-xm530:~# dmesg -c
i2c_write timeout 0x2
i2c_write timeout 0x2
i2c_write timeout 0x2
i2c_write timeout 0x2
i2c_write timeout 0x2

This is the setting file from the original firmware:

root@openipc-xm530:~# cat /mnt/mtd/Config/SensorType.bat
snsType:55

Can I provide some more info from /proc/* ?

Please fix report if command line added. TNX !

bbc@caramel:/# ssh root@host0 '/usr/bin/ipc_chip_info'
Chip: HiSilicon 3516cv300
Sensor: SmartSens SC2235P

bbc@caramel:/# ssh root@host0 '/usr/bin/ipc_chip_info --sensor_id'
Segmentation fault

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.