logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Exploring A9 Minicam Variation: XF16 PB380EA6341 MCU, T25S80 SPI Flash, XR872, Skylark SDK

divadiow 33444 298
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • Helpful post
    #1 21219273
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    Another A9 minicam variation. Will just use this post to dump some bits rather than add to https://www.elektroda.com/rtvforum/topic4033757.html#21035231 which has been about the Beken BK7252 and Taixin TXW817 based A9s.

    The MCU in this labelled as XF16 PB380EA6341 which has a mention in that long HA thread about the A9s here https://community.home-assistant.io/t/popular...mini-wi-fi-camera-the-ha-challenge/230108/247
    Close-up of a microchip on a PCB.

    this one has an 8mbit flash chip though, labelled T25S80
    Close-up of a circuit board with a clearly visible T25S80 chip.

    which might be this from ChipSourceTek http://www.chipsourcetek.com/DataSheet/T25S80.pdf

    Flashrom, NeoProgrammer and ASProgrammer couldn't identify the SPI ID C74014. It did detect as "1313", probably the cable wasn't seated quite right, which detected as n 8mbit ST M25P80. Right or wrong, Neo dumped the firmware. Flashrom did too. both attached.

    Screenshot of NeoProgrammer software showing the memory read of M25P80 flash.

    pics of PCB

    Apparent PCB of A9 mini camera with a connected battery and USB port. Close-up view of the A9 camera's printed circuit board (PCB) with visible electronic components and a battery. PCB of A9 mini camera with visible lens and battery. PCB of A9 mini camera with various electronic components. Disassembled A9 mini camera with visible PCB and battery. Close-up of the A9 camera PCB with visible components and connected battery.

    It didn't take long to find the UART TX pad, which is this:

    Close-up of a PCB with an XF16 microprocessor.

    Perhaps most interesting so far is the content of the log:
    Code: Text
    Log in, to see the code


    as pointed out by daniel-dona here https://community.home-assistant.io/t/popular...mini-wi-fi-camera-the-ha-challenge/230108/287 (maybe @danieldona ?) it looks to be some custom XRadiotech XR872 - https://github.com/XradioTech/xradio-skylark-sdk
    Attachments:
    • Flashrom_C74014.bin.bin (1 MB) You must be logged in to download this attachment.
    • Neo_C74014.bin (1 MB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #2 21219993
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    strings in bin

    lots of OTA
    Attachments:
    • Flashrom_C74014.bin.txt (184.47 KB) You must be logged in to download this attachment.
  • Helpful post
    #5 21278017
    andrewjhull
    Level 1  
    Posts: 1
    Help: 1
    Rate: 1
    Quote:
    # strings Flashrom_C74014.bin.bin |grep project
    ../../../../project/demo/ilnk_demo_et_1mflash/main.c
    ../../../../project/common/runtop/sd_manager/rt_sd_dev.c
    ../../../../project/common/runtop/rt_adpt/rt_adpt_adc.c
    ../../../../project/common/runtop/rt_adpt/rt_devm_gpio.c
    ../../../../project/common/runtop/librtcommon/srcs/rt_thread_freertos.c
    ../../../../project/common/runtop/librtcommon/srcs/rt_thread_locker_freertos.c
    ../../../../project/common/runtop/ble_uart/ble_uart.c
    ../../../../project/common/runtop/rt_wifi/rt_wifi.c
    ../../../../project/common/runtop/led/led_control.c
    ../../../../project/common/runtop/led/led_proc.c
    ../../../../project/common/runtop/rt_search/rt_search.c
    ../../../../project/demo/ilnk_demo_et_1mflash/ilnk_ipc/src/record_ilnk.c
    ../../../../project/common/runtop/rt_res/rt_res.c
    ../../../../project/common/runtop/routine/routine_image.c
    ../../../../project/common/runtop/camera_test/camera_test.c
    ../../../../project/common/runtop/rtb_media/rtb_av_md.c
    ../../../../project/common/runtop/rtb_media/rtb_av_api.c
    ../../../../project/common/runtop/rtb_media/imgproc.c
    ../../../../project/common/runtop/rt_time/rt_time.c
    ../../../../project/common/runtop/rtpm/rtpm_core.c
    ../../../../project/common/runtop/rt_ota/rt_ota.c
    ../../../../project/common/runtop/rtj_p2p/srcs/rtj_p2p.c
    ../../../../project/common/runtop/rtj_p2p/srcs/rt_ap.c
    ../../../../project/common/runtop/rtj_p2p/srcs/rt_playback.c
    ../../../../project/demo/ilnk_demo_et_1mflash/ilnk_ipc/src/IpcCbNet.c
    ../../../../project/demo/ilnk_demo_et_1mflash/ilnk_ipc/src/IpcCbEvent.c
    ../../../../project/demo/ilnk_demo_et_1mflash/ilnk_ipc/src/IpcDevSys.c
    ../../../../project/demo/ilnk_demo_et_1mflash/ilnk_ipc/src/IpcCbSd.c
    ../../../../project/demo/ilnk_demo_et_1mflash/ilnk_ipc/src/InkP2pModule.c
    ../../../../project/demo/ilnk_demo_et_1mflash/ilnk_ipc/src/IpcCbPassThrough.c
    ../../../../project/demo/ilnk_demo_et_1mflash/ilnk_ipc/src/IpcDevCallback.c
    ../../../../project/demo/ilnk_demo_et_1mflash/ilnk_ipc/src/IpcCbAv.c
    ../../../../project/demo/ilnk_demo_et_1mflash/ilnk_ipc/src/IpcCbSys.c

    As you can see, there are strings in the Flash Dump that suggest the XF16 camera is running a version of RTOS
    https://github.com/RT-Thread/rtthread-manual-doc/blob/master/introduction/introduction.md
    [/quote]

    Added after 7 [minutes]:

    Close-up photograph of the interior of an electronic device showing the XF16 chipset.

    I have a couple of PTZ cameras that run the same protocol as the A9 Cams and have an XF16 variant processor.
    Can I ask how you dumped the firmware on yours? I presume you clipped on to the flash chip. Did you need to hold the camera in reset while you dumped it?
  • ADVERTISEMENT
  • #6 21278253
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    andrewjhull wrote:
    I presume you clipped on to the flash chip. Did you need to hold the camera in reset while you dumped it?

    Hello! Yes, I clipped onto the flash chip. I did not need put anything into reset mode first.
  • Helpful post
    #7 21346099
    gusgorman402
    Level 4  
    Posts: 3
    Help: 2
    Rate: 3
    I have the PTZ version also. The serial port is JST GH connector. Thanks for the flash dump. Strings revealed the serial password is runtop1029
  • #8 21346105
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    oh nice. good work. I didn't do anything more with my one.

    Code snippet with console error messages and a password field.

    feel free to post all your findings!
  • Helpful post
    #9 21349910
    alistairjordan
    Level 2  
    Posts: 2
    Help: 1
    Rate: 1
    Just opened one of these up and started looking..
    I get a similar bin extract from the SPI chip.

    Going through the strings this is an XR872 base design. The 2.0 SDK can be found on "gitee" here: https://portrait.gitee.com/Dozingfiretruck/xr872_sdk/

    The strings actually give quite a way about the base design also. I would note that the ipc application doesn't appear to be in the demos folder so there is no instant drop in solution to build.

    Other things I've noticed is the csi interface (camera) is using the driver/chip/hal_csi_jpeg.c driver.
    This gives me a good guess that all the included drivers in the repo will actually be compatible with the device (to be fair, everything does appear built into the SoC.)

    In regards to the other configuration required by configure.sh, it looks to be a 40MHz oscillator from the markings, although I may have made a mistake with this one.
  • #10 21351573
    gusgorman402
    Level 4  
    Posts: 3
    Help: 2
    Rate: 3
    How are you getting Flashrom to work? I'm trying to use Bus Pirate with a SOIC8 clip, but it won't recognize the chip. It keeps backfeeding power into the board too, causing the lights to turn on briefly. I think my PTZ camera has a different chip too Close-up of a circuit board with visible integrated circuits.
  • #12 21351757
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    cloned here for safe keeping https://github.com/divadiow/xr872_sdk

    Added after 19 [minutes]:

    gusgorman402 wrote:
    How are you getting Flashrom to work?

    me? no more steps than what was in the first post I'm afraid.

    As it's only an 8 pin SOIC my next step would have been to desolder and then clamp up to read flash.
  • ADVERTISEMENT
  • #13 21352083
    alistairjordan
    Level 2  
    Posts: 2
    Help: 1
    Rate: 1
    So making a couple of notes on the above replies:
    * The BusPirate is a pile of doo doo, and WILL drive you nuts (Trust me I have one, long abandoned in a drawer). For your own sanity I would use a CH341A programmer (and included SOP8 clip) for reading the flash, and also you can pop it in serial mode to get access to the console.
    For the things this won't cover well, I tend to directly solder onto a RPI Pico (They are dirt cheap) and write the relevant code.
    Links: https://www.aliexpress.com/item/1005006520623353.html
    https://www.aliexpress.com/item/1005003371056277.html
    * Unless I'm wrong, https://portrait.gitee.com/Dozingfiretruck/xr872_sdk/blob/master/project/example/jpeg/main.c will only cover taking a picture and saving to SD.

    So I've come across this string in the dump:

    WAR WLAN Stealer
    (I guess WAR is warning)

    Does anyone know what this could be about?
    It sounds rather ominous.

    I will try flashing an example for the XR872 onto a board in the next few days, it should at least give a PoC that assumptions are all correct and this thread is going in the right direction.
  • Helpful post
    #14 21353025
    gusgorman402
    Level 4  
    Posts: 3
    Help: 2
    Rate: 3
    >>21352083 I did not find the Stealer string in the dump posted on here. However I do find "WAR %d wlan steal active" if I run strings on XradioSDK libxretf.a and librxwireless.a files.
    These cameras usually transmit data in cleartext, so you could sniff the traffic if you think it's exfiltrating personal data. Sometimes the cameras use encryption, but the original A9 HA thread has posts on how to decrypt

    Added after 42 [minutes]:

    My PTZ camera, just like the A9, uses the iLnkP2P protocol, which has been pretty well documented.
    If you watch the Defcon video, he explains how to extract the video stream from the packets:. https://hacked.camera/
    The original A9 Home Assistant postings explain & link to methods to communicate UDP packets to the camera: https://github.com/DavidVentura/cam-reverse
    I think the Defcon talk shows an example of a CGI request too. You can see which CGI scripts are on the cam by searching for ".cgi" files in the Strings output. The manual for these CGI are here: https://github.com/DavidVentura/cam-reverse/blob/master/data/cgi_ip_cam.pdf
    I attached a screenshot of the serial console menu from my PTZ. The command line help isn't very helpful, so I've had to read the source code for these commands to learn their syntax. Most of the commands' source is in the xradioSDK projects/common/cmd directory

    I think if you wanted to get total control over this cam, you would have to write a script to communicate UDP packets in iLnkP2P protocol, and interact with the CGI scripts. If you get access to serial console, there are commands to edit the memory. You could change the IP address of the Chinese P2P relay servers, or change the device UID so it doesn't authenticate with the servers.
    Temu is flooded with these cams, that's where I got mine for $10. I thought it would make a good device for a hardware hacking class. I was hoping it was running embedded linux. Some of the linux versions have the iLnkP2P libraries in the filesystem, and you can RE the library to get the device ID algorithm, as explained in the Defcon talk
    Screenshot showing a serial console menu with a list of commands and threads.
  • #15 21509791
    1864mponepound
    Level 4  
    Posts: 7
    gusgorman402 wrote:
    How are you getting Flashrom to work? I'm trying to use Bus Pirate with a SOIC8 clip, but it won't recognize the chip. It keeps backfeeding power into the board too, causing the lights to turn on briefly. I think my PTZ camera has a different chip too Close-up of a circuit board with visible integrated circuits.


    hey gusgorman402
    how were you able to overcome this problem you describe?

    I have the same problem.

    My PTZ camera has the same memory chip.
  • #16 21514728
    1864mponepound
    Level 4  
    Posts: 7
    divadiow wrote:
    Flashrom, NeoProgrammer and ASProgrammer couldn't identify the SPI ID C74014. It did detect as "1313", probably the cable wasn't seated quite right, which detected as an 8mbit ST M25P80. Right or wrong, Neo dumped the firmware. Flashrom did too. both attached.


    hi
    what tool did you use to read the flash

    I have a ch341 but for some reason it is failing - did you desolder or use a probe?
  • ADVERTISEMENT
  • Helpful post
    #19 21522142
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14388
    Help: 650
    Rate: 12308
    I got one:
    Close-up of a circuit board with a micro USB port, memory card slot, and XF16 chip.
    Close-up of a circuit board with a camera lens, an electronic microphone, and tweezers holding a micro USB port.
    USB programmer with a clip for chip programming connected to a small PCB.
    Trying to read flash in circuit gives me strange IDs:
    Code: text Expand Select all Copy to clipboard
    
Current programmer: CH341 Black
SPI ID: 8E8029
Current programmer: CH341 Black
SPI ID: 1313

    but later:
    Code: text Expand Select all Copy to clipboard
    
Current programmer: CH341 Black
SPI ID: C74014
Current programmer: CH341 Black
SPI ID: C74014
Current programmer: CH341 Black
SPI ID: C74014
Current programmer: CH341 Black
SPI ID: C74014
Current programmer: CH341 Black
SPI ID: C74014

    AWIH header like in other XR devices
    Hex editor view with binary data and ASCII representation.
    Attachments:
    • read_as_1313.bin (1 MB) You must be logged in to download this attachment.
    Helpful post? Buy me a coffee.
  • #20 21522154
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    I have wondered if an XR872 SDK demo compiled and flashed directly to flash would boot. Might try someday.

    https://github.com/divadiow/xr872_sdk/tree/main/project/demo

    The only official reference to XF16 I've seen in relation to Allwinner is an entry in a drop-down or two in their developer portal

    User dashboard on Allwinner website with open SoC platform selection dropdown.
  • Helpful post
    #21 21522159
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14388
    Help: 650
    Rate: 12308
    divadiow wrote:
    cloned here for safe keeping https://github.com/divadiow/xr872_sdk

    So has anyone tried to build a hello world image of that? Maybe then we could find the flash offset in that 1MB chip where we could flash this hello world...

    Added after 1 [hours] 37 [minutes]:

    Compiling under WSL experience so far:
    1. I got SDK from here:
    https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q2-update
    2. At first, it acted like path is wrong
    Code: text Expand Select all Copy to clipboard
    
tester@DESKTOP-6SD9MUK:/mnt/w/GIT/xr872_sdk/project/demo/hello_demo/gcc$ make lib
make  -C ../../../../src install
make[1]: Entering directory '/mnt/w/GIT/xr872_sdk/src'
make _install TARGET=install
make[2]: Entering directory '/mnt/w/GIT/xr872_sdk/src'
make  -C driver/chip install
make[3]: Entering directory '/mnt/w/GIT/xr872_sdk/src/driver/chip'
~/gcc-arm/bin/arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -c -gdwarf-2 -fno-common -fmessage-length=0 -fno-exceptions -ffunction-sections -fdata-sections -fomit-frame-pointer -Wall -Werror -Wpointer-arith -Wno-error=unused-function -MMD -MP -Os -DNDEBUG -D__CONFIG_CHIP_XR872 -D__CONFIG_CHIP_ARCH_VER=2 -D__CONFIG_ARCH_APP_CORE -D__CONFIG_CPU_CM4F -D__CONFIG_HOSC_TYPE=40 -D__CONFIG_LIBC_REDEFINE_GCC_INT32_TYPE -D__CONFIG_LIBC_PRINTF_FLOAT -D__CONFIG_LIBC_SCANF_FLOAT -D__CONFIG_LIBC_WRAP_STDIO -D__CONFIG_OS_FREERTOS -D__CONFIG_OS_FREERTOS_VER=80203 -D__CONFIG_LWIP_V1 -D__CONFIG_LWIP_VER_1_4_1 -D__CONFIG_LWIP_V1 -D__CONFIG_MBEDTLS_VER=0x02100000 -D__CONFIG_MBUF_IMPL_MODE=0 -D__CONFIG_WLAN -D__CONFIG_WLAN_STA -D__CONFIG_WLAN_AP -D__CONFIG_WLAN_MONITOR -D__CONFIG_WIFI_CERTIFIED -D__CONFIG_DEFAULT_FLASH_FLASHC -D__CONFIG_XIP -D__CONFIG_SECTION_ATTRIBUTE_XIP -D__CONFIG_SECTION_ATTRIBUTE_NONXIP -D__CONFIG_SECTION_ATTRIBUTE_SRAM -D__CONFIG_ROM -D__CONFIG_ROM_FREERTOS -D__CONFIG_ROM_XZ -D__CONFIG_PM -D__CONFIG_OTA -D__CONFIG_OTA_POLICY=0x00 -D__CONFIG_CACHE_POLICY=0x02 -D__CONFIG_DMAHEAP_PSRAM_SIZE=0 -D__CONFIG_MSP_STACK_SIZE=1024 -D__CONFIG_MALLOC_MODE=0x00 -D__CONFIG_MBUF_HEAP_MODE=0 -D__CONFIG_MBEDTLS_HEAP_MODE=0 -D__CONFIG_HTTPC_HEAP_MODE=0 -D__CONFIG_NGHTTP2_HEAP_MODE=0 -D__CONFIG_MQTT_HEAP_MODE=0 -D__CONFIG_NOPOLL_HEAP_MODE=0 -D__CONFIG_WPA_HEAP_MODE=0 -D__CONFIG_UMAC_HEAP_MODE=0 -D__CONFIG_LMAC_HEAP_MODE=0 -D__CONFIG_CEDARX_HEAP_MODE=0 -D__CONFIG_AUDIO_HEAP_MODE=0 -D__CONFIG_CODEC_HEAP_MODE=0 -D__CONFIG_ZBAR_HEAP_MODE=0 -std=gnu99 -I../../../include -I../../../include/libc -I../../../include/driver/cmsis -I../../../include/kernel/FreeRTOS/FreeRTOSv8.2.3 -I../../../include/kernel/FreeRTOS/FreeRTOSv8.2.3/portable/GCC/ARM_CM4F -I../../../include/net -I../../../include/net/lwip-1.4.1 -I../../../include/net/mbedtls-2.16.0 -I../../../include/net/nghttp2//lib/includes -I../../../include/net/lwip-1.4.1/ipv4 -o codec/ac101.o codec/ac101.c
/bin/sh: 1: /home/tester/gcc-arm/bin/arm-none-eabi-gcc: not found
make[3]: *** [../../../gcc.mk:212: codec/ac101.o] Error 127
make[3]: Leaving directory '/mnt/w/GIT/xr872_sdk/src/driver/chip'
make[2]: *** [Makefile:105: driver/chip] Error 2
make[2]: Leaving directory '/mnt/w/GIT/xr872_sdk/src'
make[1]: *** [Makefile:96: install] Error 2
make[1]: Leaving directory '/mnt/w/GIT/xr872_sdk/src'
make: *** [../../../../project/project.mk:353: lib] Error 2

    3. but path is ok. File exists, but it can't be executed, it's something else, I checked it with readelf:
    Code: text Expand Select all Copy to clipboard
    
tester@DESKTOP-6SD9MUK:/mnt/w/GIT/xr872_sdk/project/demo/wlan_demo/gcc$ readelf -l ~/gcc-arm/gcc-arm-none-eabi-4_9-2015q2-20150609-linux/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gcc | grep interpreter
      [Requesting program interpreter: /lib/ld-linux.so.2]

    4. Then I checked for ld-linux.so:
    Code: text Expand Select all Copy to clipboard
    
tester@DESKTOP-6SD9MUK:/mnt/w/GIT/xr872_sdk/project/demo/wlan_demo/gcc$ ls /lib/ld-linux.so.3
ls: cannot access '/lib/ld-linux.so.3': No such file or directory

    5. ld-linux.so is missing, so I did update:
    Code: text Expand Select all Copy to clipboard
    
sudo apt update
sudo apt install libc6-i386 lib32z1 lib32stdc++6

    6. now it seems to compile fine?
    Terminal window showing gcc compiler output for an SDK project on ARM platform, with many lines of make output.

    More info soon

    Added after 4 [minutes]:


    Screenshot of a console with XR872 firmware build commands and system image configuration.

    Added after 3 [minutes]:

    attached firmware
    Attachments:
    • wlan_demo_image.zip (848.78 KB) You must be logged in to download this attachment.
    Helpful post? Buy me a coffee.
  • #22 21522253
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    good going. I haven't been able to try anything since posting. I have one eye on this thread and the other on work.
  • #23 21522255
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14388
    Help: 650
    Rate: 12308
    Do you have time to try my binaries?

    Comparison (build vs read):
    Comparison of two binary files in a hex editor, with differences highlighted.

    Added after 39 [seconds]:

    String refs similar:
    Screenshot of a hex comparison tool displaying differences between two binary files.

    Added after 4 [minutes]:

    XR872 in original flash of A9 camera:
    Screenshot of a hex editor showing the contents of a binary file in hexadecimal and text (ASCII) form.

    Added after 31 [minutes]:

    Original bootlog:
    Code: text Expand Select all Copy to clipboard
    
[bl ERR] main():629, build:20:38:52
[FD I]: mode: 0x4, freq: 48000000Hz, drv: 0

Password:PMA: mode select:e

wlan information ===================================================
firmware:
    version : R-XR_C10.08.52.64_01.80 Jul  6 2019 20:05:10-P01.46-R
    buffer  : 12
driver:
    version : XR_V02.05
====================================================================

PMA: wlan mode:a

platform information ===============================================
XRADIO Skylark SDK 1.2.0 Oct 17 2024 10:39:50

sram heap space [0x21fc70, 0x25fc00), total size 262032 Bytes
cpu  clock 240000000 Hz
HF   clock  40000000 Hz

sdk option:
    XIP           : enable
    INT LF OSC    : enable

mac address:
    efuse         : 18:9e:2d:81:89:ce
    in use        : 38:0a:8d:47:2b:71
====================================================================

StartupState:5
[os E] OS_MutexDelete():54, handle 0
io=20 mode=0 pull=1
HAL_Wakeup_SetIO en:40 mode:0 pull:1000
Enter Sleep Mode 1
[os E] OS_MutexLock():65, handle 0
[os E] OS_MutexUnlock():80, handle 0
[os E] OS_MutexLock():65, handle 0
[os E] OS_MutexUnlock():80, handle 0
rec enter sleep mode
<-500119_192428 rtb_av_api.c:2063>media not init
ntp enter sleep mode 0
Enter Sleep Mode 2
HAL_Wakeup_ClrTimer
[bl ERR] main():629, build:20:38:52
[FD I]: mode: 0x4, freq: 48000000Hz, drv: 0

Password:PMA: mode select:e

wlan information ===================================================
firmware:
    version : R-XR_C10.08.52.64_01.80 Jul  6 2019 20:05:10-P01.46-R
    buffer  : 12
driver:
    version : XR_V02.05
====================================================================

PMA: wlan mode:a

platform information ===============================================
XRADIO Skylark SDK 1.2.0 Oct 17 2024 10:39:50

sram heap space [0x21fc70, 0x25fc00), total size 262032 Bytes
cpu  clock 240000000 Hz
HF   clock  40000000 Hz

sdk option:
    XIP           : enable
    INT LF OSC    : enable

mac address:
    efuse         : 18:9e:2d:81:89:ce
    in use        : 38:0a:8d:47:2b:71
====================================================================

StartupState:5
[os E] OS_MutexDelete():54, handle 0
io=20 mode=0 pull=1
HAL_Wakeup_SetIO en:40 mode:0 pull:1000
Enter Sleep Mode 1
[os E] OS_MutexLock():65, handle 0
[os E] OS_MutexUnlock():80, handle 0
[os E] OS_MutexLock():65, handle 0
[os E] OS_MutexUnlock():80, handle 0
rec enter sleep mode
<-500119_192428 rtb_av_api.c:2063>media not init
ntp enter sleep mode 0
Enter Sleep Mode 2
HAL_Wakeup_ClrTimer

    You can use USB breakout to get TX without soldering
    Helpful post? Buy me a coffee.
  • #24 21522282
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    just hooking up to flash now
  • #25 21522287
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14388
    Help: 650
    Rate: 12308
    Why verify fails at random offets, omg?
    Screenshot showing a memory verification error in the CH341 Black programmer.

    Added after 1 [seconds]:

    Why verify fails at random offets, omg?
    Screenshot showing a memory verification error in the CH341 Black programmer.

    Added after 20 [seconds]:

    Verify flash fails for randomly.

    Added after 11 [minutes]:

    UART access via USB;
    Prototype electronic circuit with wires and USB and PS/2 connectors on a white background.
    Desoldering flash:

    Close-up of a SOP16/8-DIP8 REV4 electronic adapter held in a hand.
    Trying flasher outside circuit:
    Code: text Expand Select all Copy to clipboard
    
Current programmer: CH341 Black
SPI ID: C74014

    Outside circuit, Verify is OK:
    Code: text Expand Select all Copy to clipboard
    
Current programmer: CH341 Black
15:31:59
Verify memory...
Success
Execution time: 00:00:09.503

    read_outsi...ircuit.bin (1 MB)You must be logged in to download this attachment.
    Helpful post? Buy me a coffee.
  • #26 21522299
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    SREG read before programming. detected as 1313 first time and now C74014, as it did originally.

    A program window for reading and writing status registers (SREG) of Winbond memory, with all SREG3 checkboxes selected.
    Screenshot from NeoProgrammer showing flash chip CH341 Black detection with various SPI IDs.

    flashed with Neo but nothing from TX. trying flashrom and other things
  • #27 21522301
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14388
    Help: 650
    Rate: 12308
    I seemingly can flash outside circuit:
    Code: text Expand Select all Copy to clipboard
    
Current programmer: CH341 Black
15:39:48
Programming memory... Main Memory
Success
Execution time: 00:00:18.015

    but then verify always fail:
    Code: text Expand Select all Copy to clipboard
    
15:40:38
Verify memory...
Verification error on address: 0x00000008, Device: 0xA2, Buffer: 0xE2
Execution time: 00:00:00.086

    Probably it does not flash in reality.
    Helpful post? Buy me a coffee.
  • #28 21522326
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    yes, this is annoying. read-back is rubbish and erase is mostly ineffective in Neo and As. I've been toggling protections bits but still no joy. Just moving onto other flash chips I might have lying around.
  • #29 21522328
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14388
    Help: 650
    Rate: 12308
    Just make sure that you erase first:

    Screenshot of NeoProgrammer software with an open memory write options menu.
    but it does not help for me:
    Code: text Expand Select all Copy to clipboard
    
Current programmer: CH341 Black
16:23:42
Erasing memory...
Success
Execution time: 00:00:03.954
Current programmer: CH341 Black
16:23:46
Erasure control...
Success
Execution time: 00:00:22.254
Current programmer: CH341 Black
16:24:08
Programming memory(verifying)... Main Memory
Verification error on address: 0x00000384, Device: 0xFF, Buffer: 0x29
Execution time: 00:00:00.268
    Helpful post? Buy me a coffee.
  • #30 21522368
    divadiow
    Level 38  
    Posts: 4833
    Help: 420
    Rate: 851
    frustrating. not getting anywhere with any erase/sreg bits /programs tried.

    Added after 28 [minutes]:

    in As what do your SREG bits read out as?

    AsProgrammer window with GD25Q80 chip selected, hex editor visible, and SREG settings popup for GigaDevice memory.

    and does the selection change if you click read again and again?
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion focuses on a variation of the A9 mini Wi-Fi camera featuring the XF16 PB380EA6341 MCU, an 8Mbit SPI flash chip labeled T25S80 (likely from ChipSourceTek), and the XR872 SoC running the Skylark SDK. Attempts to read and dump the flash firmware using tools like Flashrom, NeoProgrammer, and ASProgrammer faced challenges due to unrecognized SPI IDs and unreliable read/write operations, especially when the flash chip was in-circuit. Desoldering the flash chip improved read/write reliability. The firmware strings indicate the use of an RTOS and the iLnkP2P protocol for communication. The XR872 SDK (version 2.0 and later 1.2.x) was explored for building and flashing demo applications, including a "hello world" example, which successfully booted on the hardware after flashing via UART using PhoenixMC. Flashing custom firmware requires careful handling of flash erase and protection bits, with some users experiencing verification errors and random write failures. The flash layout includes an AWIH header and OTA partitions, with OTA updates compressed by XZ, raising concerns about fitting OTA images into the 1MB flash. Hardware details such as the presence of a pull-up resistor on the flash hold pin and UART pin configurations (PB02/PB03) were examined. The community also discussed the compatibility of different flash chip sizes (1MB vs 2MB) and the impact on firmware booting and flashing. Some users successfully transplanted firmware to larger flash chips (2MB) to run custom firmware like OpenXR872 (OBK). The discussion includes references to related projects for video stream capture without flashing (cam-reverse) and the challenges of flashing and booting custom firmware on these devices. Overall, the thread provides detailed technical insights into hardware probing, firmware extraction, SDK usage, flashing procedures, and troubleshooting for the XF16-based A9 mini camera variant with XR872 SoC.
Generated by the language model.
Today's popular

FAQ

TL;DR: With 1MB stock flash, many XF16 A9 cameras can be dumped and restored over UART, and one contributor confirmed "OpenXR872 ... boots on 1mb flash" only after fixing the image layout. This FAQ helps XR872/XF16 camera owners back up firmware, understand AWIH partitions, fix PhoenixMC/UART issues, and avoid bad SPI-flash writes. [#21530564]

Why it matters: XF16 A9 cameras look identical externally, but small changes in flash size, OTA layout, console settings, and sensor wiring decide whether firmware boots, flashes, or bricks.

Method What works best Main strengths Main failure mode
PhoenixMC over UART Read/write on XF16/XR872 without opening some A9 units No desoldering; can restore stock dumps Custom builds may lose UART flashing after power cycle if console support is wrong
CH341A + SOIC8 clip Quick first dump attempts Cheap; widely available In-circuit reads often return bad IDs like 1313 or 8E8029
CH341A with desoldered flash Most reliable SPI backup/restore Stable verification; works with replacement chips Some flash chips still fail erase/write unless decoupling is added
Bus Pirate Usually poor choice here Can talk SPI/UART Backfeeds power and often fails chip detection

Key insight: The hardest XF16 problems were not caused by the XR872 core. They came from image layout, OTA header placement, console enablement, and fragile SPI flash behavior on specific 1MB chips.

Quick Facts

  • XF16 boot logs repeatedly report 240000000 Hz CPU, 40000000 Hz HF clock, and XRADIO Skylark SDK builds such as 1.2.0 Jun 20 2024 10:58:31 or 1.2.2 test builds, which makes the platform easy to fingerprint from UART alone. [#21219273]
  • The stock A9 XF16 camera flash is commonly 8 Mbit / 1 MB with IDs such as C74014 or 5E3214, while test replacements that booted OpenXR872 included 2 MB and even 64 Mbit chips. [#21522966]
  • UART flashing can work through the camera’s USB path on some XF16 A9 boards because RX/TX are routed through the USB connector traces; contributors built simple USB-TTL adapters from NodeMCU or CH340 hardware to exploit that. [#21528571]
  • The stock firmware exposes a local AP at 192.168.238.1/24, while OpenXR872 test builds used 192.168.51.1/24 or 192.168.4.1/24, so IP range alone can reveal whether you are in factory or custom firmware. [#21219273]
  • Confirmed XF16 camera-connector tracing mapped SDA/SCL to PA18/PA17, PCLK to PA08, MCLK to PA09, HSYNC to PA10, VSYNC to PA11, and DVP data lines across PA00–PA07. [#21732686]

How can I dump and restore firmware on an XF16 A9 minicam with a T25S80 or C74014 SPI flash chip using a CH341A, clip, or PhoenixMC over UART?

You can dump and restore XF16 firmware either over SPI or over UART. 1. For SPI, clip or desolder the 8-pin flash, then read it with a CH341A in NeoProgrammer, ASProgrammer, or EasyFlasher. 2. For UART, connect through the XF16 USB-routed RX/TX path and use PhoenixMC to read or flash without opening some cameras. 3. Always verify the dump and keep at least one known-good stock backup before testing OpenXR872. One contributor confirmed they clipped directly onto the flash and did not need reset mode first. [#21278253]

Why do some XF16 A9 cameras report strange SPI flash IDs like 1313, 8E8029, C74014, or 5E3214 when reading the flash in-circuit?

Those odd IDs usually mean the in-circuit SPI read is unstable, not that the chip is truly changing identity. The thread showed 1313, 8E8029, and then stable C74014 on the same 1MB camera, while a desoldered read later became consistent and verified correctly. Shared power rails, leakage from the rest of the board, bad clip contact, and marginal CH341A supply decoupling all caused false IDs. A clean off-board read or UART dump was much more trustworthy than an in-circuit first pass. [#21522287]

What is the AWIH header in XR872/XF16 firmware dumps, and how can it help identify image sections like boot, app, app_xip, and wlan_fw?

"AWIH is a firmware image header that marks XR/XF system images, stores image metadata, and helps separate boot, app, XIP, and WLAN sections." In this thread, contributors matched AWIH-tagged section IDs such as 0xa5ff5a00, 0xa5fe5a01, 0xa5fd5a02, 0xa5fa5a05, and 0xa5f95a06 to boot_40M.bin, app.bin, app_xip.bin, wlan_bl.bin, and wlan_fw.bin. Searching a dump for those little-endian markers was enough to start slicing it for Ghidra or manual comparison. [#21589985]

What is iLnkP2P on these A9 and PTZ cameras, and how is it related to the YSX/YSXLite apps and cam-reverse tools?

"iLnkP2P is a peer-to-peer camera transport protocol that carries control and media traffic, identifies devices with UIDs, and lets mobile apps reach cameras through local AP mode or relay servers." These XF16 and PTZ cameras logged IpcP2pStart, device rtuid, and p2pID, then worked with YSX or YSXLite. The same protocol is what cam-reverse and related reversing notes target, including video extraction and CGI-style control. Multiple posts linked the protocol directly to the apps and to the reverse-engineering workflow. [#21353025]

Why did OpenXR872 boot on a 2MB flash chip but initially fail on the stock 1MB flash chip in the XF16 A9 camera?

It failed because the early image layout still assumed space beyond the stock 1MB boundary. The same OpenXR872 image booted when the original dump was transplanted to a 2MB flash chip, but not on the original 1MB flash. That exposed a layout problem rather than a CPU or sensor problem. The boot logs showed image max size is invalid and missing XIP section errors on the 1MB setup, while the 2MB chip could tolerate the oversized placement. [#21525075]

How was the 1MB XF16 boot issue solved by changing the OpenXR872 image configuration and OTA header placement?

The fix was to shrink the effective image layout for 1MB flash and move the OTA header out of the failing location. First, contributors rebuilt with max_size around 880K. Later they proved that a no-OTA image booted on 1MB stock flash, then refined the layout so the OTA header sat at 1020K with 4K size instead of the breaking 1024K arrangement. After that, 1MB XF16 boards booted OpenXR872 normally. As one post put it, “ota was the problem.” [#21530564]

Why does UART flashing through PhoenixMC stop working on some OpenXR872 builds after a power cycle, and how was PRJCONF_CONSOLE_EN involved in fixing it?

UART flashing stopped because the custom build no longer exposed the console command path that PhoenixMC uses after reboot. The breakthrough was enabling #define PRJCONF_CONSOLE_EN 1, which restored the upgrade command path and made Open comm OK ! survive fresh power cycles on 1MB XF16 boards. Before that fix, some builds could still be reflashed only until RAM state was lost, which made the problem look random. After the console option was re-enabled, PhoenixMC download-mode entry became reliable again. [#21536774]

CH341A vs Bus Pirate vs PhoenixMC over UART — which works best for reading and flashing XF16/XR872 camera firmware, and what problems should I expect with each?

PhoenixMC over UART is the best day-to-day method on XF16 once stock firmware or a console-enabled OpenXR872 build is present. CH341A is best for first-rescue backups, off-board writes, and recovery when UART entry is gone. Bus Pirate was the worst performer here: users reported non-detection, backfeeding power, and brief LED power-up when clipped in. CH341A also had pitfalls, especially with sensitive 1MB chips, but it still worked reliably after desoldering or after adding extra capacitance. [#21352083]

How do I enter XR872/XF16 download mode over UART without grounding PB02 or PB03, and what commands does PhoenixMC actually send?

You do it by speaking the stock console protocol, not by forcing strap pins low. PhoenixMC sends the text command upgrade, then repeated U sync bytes; a receptive firmware answers with OK and a BROM response. Later reversing tied that behavior to the XR command handler where cmd_upgrade_exec() reboots with PRCM_CPUA_BOOT_FROM_SYS_UPDATE. That is why stock firmware and console-enabled OpenXR872 can enter download mode over UART without grounding PB02 or PB03 at all. [#21534886]

What does the XRADIO Skylark SDK boot log tell me about an XF16 camera, including CPU clock, flash mode, sensor detection, and network behavior?

The boot log gives you the board fingerprint in one place. It exposes flash mode like [FD I]: mode: 0x4, CPU at 240000000 Hz, HF clock at 40000000 Hz, SDK build date, MAC addresses, sensor probe results such as detect sp0828, and AP behavior such as 192.168.238.1 on stock firmware. It also shows whether the camera starts in AP mode, tries STA mode, fails SD mount, or enters iLnkP2P. For XF16 debugging, the UART log is the fastest way to identify variant, sensor, and failure stage. [#21219273]

How can I build XR872 SDK demos under WSL, and which toolchain and 32-bit libraries are needed to compile hello_demo or jpeg examples successfully?

Builds under WSL worked after installing the older ARM GCC toolchain plus missing 32-bit runtime libraries. The thread used gcc-arm-embedded 4.9-2015-q2-update, then fixed execution errors by installing libc6-i386, lib32z1, and lib32stdc++6. Without those, WSL reported missing loader errors even when the path was correct. Once the 32-bit compatibility packages were installed, make lib and example builds such as hello_demo started compiling normally. [#21522159]

Why do some SPI flash chips like TJ25Q08M, T25S80, or 25QH32CHIG fail erase/write verification in NeoProgrammer or EasyFlasher unless extra capacitance or special handling is used?

These chips appear unusually sensitive to supply stability during SPI writes. The thread documented random verify errors, partial writes, and false erases on desoldered chips until extra capacitance was added directly on the CH341A setup; after that, the same chip verified cleanly. One test with a 25QH32CHIG failed repeatedly, then passed once a capacitor was added across the supply. Some users also had to experiment with protection-register handling, but the strongest repeated fix was better decoupling on the programmer side. [#21709832]

How can I trace the 18-pin FFC camera connector on an XF16 A9 board to map SDA, SCL, DVP data pins, MCLK, HSYNC, VSYNC, and PCLK to XR872 GPIOs?

The cleanest method is continuity tracing plus a pin-toggle test firmware. On the confirmed XF16 A9 mapping, pin 2 is SDA on PA18, pin 3 is SCL on PA17, pin 13 is MCLK on PA09, pin 12 is HSYNC on PA10, pin 11 is VSYNC on PA11, pin 15 is PCLK on PA08, and DVP data runs from PA00–PA07. Contributors validated the map with an 18-pin FFC walker that pulsed each GPIO while a multimeter watched the connector. [#21732686]

Which camera sensors seem to be supported or referenced in XF16/XR872 firmware strings, and how can I start adapting drivers for parts like SP0828, GC0328C, GC0329, or HI0704?

The firmware strings reference many sensors, including ov9660, ov7740, sp2518, gc0310, gc0328, gc0329, hi0704, hi0708, and sp0828. Start by reusing initialization tables and SCCB/I2C setup from the closest supported driver, then confirm the actual sensor with ribbon markings or UART detection logs. For XF16 A9 specifically, sp0828 was repeatedly detected in stock logs, while separate posts confirmed useful initialization arrays existed for hi704-class parts. That makes driver adaptation a sensor-data problem more than a core XR872 problem. [#21547719]

How can I split or parse a stock XF16 firmware dump into PhoenixMC-style partitions for reverse engineering in Ghidra, and where does mkimage fit into that process?

Use the AWIH section markers and the XR image config as your map, then reverse from there. Search the dump for little-endian IDs like 005affa5, 015afea5, 025afda5, 055afaa5, and 065af9a5 to locate boot, app, app_xip, wlan_bl, and wlan_fw boundaries. The SDK’s mkimage.exe is the packer that assembles those partitions into one AWIH image, so it is the right binary to study if you want PhoenixMC-style slicing for Ghidra. The thread specifically identified mkimage.exe as the image-creation step. [#21587062]
Generated by the language model.
ADVERTISEMENT