XM530 reboots after ~ 1 minute

[jokolaco]

Hello,

i know it is a crappy device, but with the original Chinese horror firmware it is even a threat. So it would be nice to have at least a running minimal configuration. Unfortunately every time i flashed the basic XM530 images the device comes up nicely but after a minute it automatically reboots! Is there a build in tamper prevention in form of some secret values in the registers ? Or any idea what could be the cause?

Btw. the first very helpful links in the https://github.com/OpenIPC/camerasrnd/[README.md are pointing to the wrong locations and are dead. Unfortunately i cannot change it.

Best regards

[jokolaco]

Some logdata & pictures of the hardware:

XM530_Boot_OpenIPC.txt XM530_Boot_StockFirmare.txt

[dimerr]

This is some heavily modded firmware. First try flashing it to SPI, following the manual. Running from RAM assumes some deep knowledge of internals and i think it just wont work on xm530 due to extreme lack of free RAM

[jokolaco]

Thanks for the hint! Make sense, but the SPI instructions are missing from the automatically generated instructions and are hidden deep in the old wiki help. Unfortunately (as always) after an hour setting up and playing around with u-boot I accidentally erased some part of the u-boot bootloader and bricked the devices. Since i am not in the mood to de-solder the chip and potential hard brick the device in the case of destroyed solder pads on the PCB i searched for a better non-invasive de-bricking method. I found a Boot ROM uploader option if i short a pin and set the uart baudrate to 57600: ROM START! Now the chip accepts something via the serial console. But i don´t know the right format. I tried different encodings (base64, srecord, asc) for the orginal u-boot.bin file in the hope the chip will run the provided ASCII encoded binary. - Any idea what could be the right format or what kind of data the BootRom waits for? An Image file or just the orginal Uboot.bin ? As least the ROM code checks the input and comments on wrong non ASCII input stream: CMD CKECK ERROR! - Do you have per accident a dump of the chip internal BootROM ?

[dimerr]

Theres a windows app for that. pctools.tar.gz

[jokolaco]

Unfortunately the provided 560 Bytes archive contains only a 181 Bytes large mostly unreadable readme.txt. Could you please upload a valid archive? Would be nice to get the right file encoding... Thank you!

[dimerr]

pctools.tar.gz

[marianomd]

Hi! I'm facing something similar on xm530. Not at 1 minute, but when running ipctool or trying to access a video stream. The original bootargs where set the mem=40M. The recommended bootarg of openipc for this platoform is 35M.

UPDATE: After bumping it to 40MB now I can run ipctool without reboots.

What are the rest of the 64MB used for?

root@openipc-xm530:~# ipctool
The ipctool installed as remote GitHub plugin
---
chip:
  vendor: Xiongmai
  model: XM530
board:
  vendor: Xiongmai
ethernet:
  mac: "30:ff:f6:8a:a0:54"
rom:
  - type: nor
    block: 64K
    partitions:
      - name: boot
        size: 0x40000
        sha1: c3cc8dc8
        contains:
          - name: xmcrypto
            offset: 0x2fc00
          - name: uboot-env
            offset: 0x30000
      - name: env
        size: 0x10000
        sha1: d8812e1d
      - name: kernel
        size: 0x200000
        sha1: 4c5214ec
      - name: rootfs
        size: 0x500000
        path: /,squashfs
        sha1: 75397723
      - name: rootfs_data
        size: 0xb0000
        path: /overlay,jffs2,rw
    size: 8M
ram:
  total: 64M
  media: 24M
firmware:
  kernel: "3.10.103+ (SMP Mon Apr 24 18:18:51 UTC 2023)"
  toolchain: gcc version 8.4.0 (Buildroot -gff5aa3b6-dirty)
  main-app: /usr/bin/majestic
sensors:
- vendor: SmartSens
  model: SC2235E
  control:
    bus: 0
    type: i2c
    addr: 0x60

[marianomd]

I rised the mem to 44MB and there are no more reboots. Seems I could lower it to 42MB as there are 2M free.

top:

Mem: 38696K used, 2320K free, 264K shrd, 1376K buff, 4424K cached

free:

root@openipc-xm530:~# free
              total        used        free      shared  buff/cache   available
Mem:          41016       33224        1388           0        6404           0
-/+ buffers/cache:        33224        7792
Swap:             0           0           0

UPDATE: It rebooted again when running ipctool :weary:

[widgetii]

What are the rest of the 64MB used for?

ram: total: 64M media: 24M

This is like iGPU used DRAM on laptops, RPi, etc allocating it for video buffers

[marianomd]

Thanks for the clarification Dmitry, kudos for the titanic project.

At 44MB seems stable now. I've found that what creates reboots are UART disconnections. I will create a new issue to avoid polluting this one.

[marianomd]

I found a Boot ROM uploader option if i short a pin and set the uart baudrate to 57600: ROM START!

Hi @jokolaco ! I have also ruined my bootloader. Could you explain what pin are you shorting to enter this mode?

[marianomd]

I finally had to unsolder the flash, it didn't work doing it in place. I improved an existing tool to flash with ESP32

[jokolaco]

Sorry for the delay. For me to desolder the SPI chip was also the only solution. The chinese tool provided from dimerr not worked for me. I tried different windows versions and uart adapters but the program always freeze. A simple linux command line solution would be nicer but since we don´t know the exact encoding not a feasable option. I reflashed the SPI chip with the latest flashrom version and a SPI capable arm board. I also resocket the chip. Now i can play with uboot without worries. The bootloader is fine but it would be nice to have an open solution, so everything could be flashed with the right parameters in one run. I i found the time i will try it but i think i need the dts or devicetree for u-boot compiling. Any idea where i can find the devicetree ?