IMX415 Sensor on a Novatek NT98566

[DrSamjames]

I bought this Camera from Aliexpress:

https://www.aliexpress.com/item/1005005944052795.html

It comes with a IVG-N8S mainboard running a Novateck NT98566 SoC connected to a Sony IMX415 sensor and a FM25Q128A 16MB NOR. I’m interested in it for a security camera and the house, power board, lights, microphone and speaker make it a fairly nice unit for this. The Camera I bought comes with software branded at Xmeye, which has been truly terrible to work with! At the time of writing OpenIPC does have limited support for the Novateck NT9856, marked as work in progress. I was given a precompiled .bin to flash to the camera but my reading of the current state of the build-root firmware you can currently build for this SoC would only run a SC401AI, SC500AI or a SC501AI sensor. So I’m trying to get the IMX415 sensor working. I’ll document everything I’ve found out that might help anyone wanting to help me, including the steps that would help anyone wanting to follow in my footsteps. I’ve tried to use heading so people can skip stuff that isn’t useful for them.

Orignal software:
Although it says you have to download software to run the camrea it is possible to get a RTSP feed off it. My camrea got a ip address off my DHCP server, other say it presents on 192.168.1.10. This command worked for me:

ffmpeg -i rtsp://admin:@192.168.1.10:554/ -vcodec copy test.mp4

although I replace 192.168.1.10 with the IP it had been given on my local LAN

UART, U-BOOT and flashing new firmware:
The Xmeye firmware really does try everything it can to stop you messing with it! I didn’t even bother to try and get the camera working with its stock firmware as you had to download and install software to find it.
The UBoot doesn’t let you interrupt the boot process and the linux kernel doesn’t present a terminal on the UART once it’s loaded. Also if you try a glitch attack (shorting the NOR chip after UBoot loads but before the Kernel loads) you will still find it is password protected. So you’ll have to go straight to using a CH341A programmer and SOP8 chip adapter to flash directly to the NOR chip. My board had Write protection on each block of the NOR chip not just via the Write protection pin (3). The datasheet for the FM25Q128A is freely available and my trusty AI friend wrote me a script to unlock it, I will happily post what I have if anyone wants it. Once unlocked I was about to dump the old firmware off and flash the OpenIPC image given to me that boots up and works, albeit without an image from the sensor.

The UART is the 3 unused pad at the bottom of the board on the side with a single 6 pin connector. It is the normal 115200 baud rate and 8 bit mode.
Current State of IMX415 support and simple stuff I found:
There is a NVT_SEN_IMX415.ko driver and a sen_imx415.cfg config file in the firmware github, but they are not copied to the image by the current buildroot process. Also the current load_novetek script ignores any other sensor other than sc401a, sc500ai, sc501ai. I was able to find in the dump of the original firmware a couple of ISP config files such as isp_imx415_0.cfg. My first hope had been to simply copy the files from github onto my camera and alter the load_novatek script with the line:

insmod nvt_sen_imx415.ko sen_cfg_path=/etc/sensors/sen_imx415.cfg

This didn’t work.

One simple reason would be that the sen_imx415.cfg from the original firmware of the camera differs from the OpenIPC github file by specifying the reset pin as 0x41 not 0x40:

[MAP]
path_1 = 1                          #Path 1 Enable
path_2 = 0                          #Path 2 Disable
path_3 = 0                          #Path 3 Disable
path_4 = 0                          #Path 4 Disable
path_5 = 0                          #Path 5 Disable
path_6 = 0                          #Path 6 Disable
path_7 = 0                          #Path 7 Disable
path_8 = 0                          #Path 8 Disable

[PRESET]
id_0_expt_time = 10000              #10000us
id_0_gain_ratio = 1000              #1x gain

[DIRECTION]
id_0_mirror = 1                     #mirror
id_0_flip = 1                       #flip

[POWER]
id_0_mclk = 0                       #CTL_SEN_CLK_SEL_SIEMCLK
id_0_pwdn_pin = 0xFFFFFFFF          #no pwdn pin, C_GPIO:+0x0; P_GPIO:+0x20; S_GPIO:+0x40; L_GPIO:0x60   
id_0_rst_pin = 0x41                 #S_GPIO_1, C_GPIO:+0x0; P_GPIO:+0x20; S_GPIO:+0x40; L_GPIO:0x60
id_0_rst_time = 1                   #1ms
id_0_stable_time = 1                #1ms

[I2C]
id_0_i2c_id = 0                     #SEN_I2C_ID_1
id_0_i2c_addr = 0x1a                #0x1a>> 1

Current thinking and lines of investigation:
At the moment i2cdetect doesn’t find anything on the I2C bus. There are 3 of them and all come back empty. Similarly ipctool -s comes back empty.
I am guessing it’s a pin mux problem. I was able to find the command:

echo sensor 0x220 > /proc/nvt_info/nvt_pinmux/pinmux_set

in the original firmware. I assume the pinmux_set working in the OpenIPC firmware?

[DrSamjames]

Update on progress:

A very big thanks has to go to Dima Tsygankov who sent me all of the information in this post and help me put it into action.

I had originally given up on the stock firmware as even under a glitch attack the Uboot was password protected and no linux terminal presented on the URAT or via LAN.
However Dima supplied a password which was correct and this reminded me that it always useful to search the OpenIPC github. The password was:

#Ux6@9V&4_Rz

And it can be found in a number of posts.

https://github.com/search?q=repo%3AOpenIPC%2Ffirmware+%23Ux6%409V%264_Rz&type=issues

Once we had the uboot promote it should be a simple matter of setting some environmental variables:

setenv xmuart 1   (maybe 0)
setenv telnetctrl 1
saveenv

however the most important one of these failed:

nvt@na51089: setenv xmuart 1 
Invalid Args.

This behaviour is documented here (again thanks Dima for the link) it’s well written and short so I’m not going to rewrite it:

https://kuku.eu.org/?projects/xm530/part1

(the more Xmeye do this the more I want to make sure I get OpenIPC running on the hardware!)

Following kuku.eu.org I found this:

nvt@na51089: bdinfo
arch_number = 0x00000000
boot_params = 0x00000000
DRAM bank   = 0x00000000
-> start    = 0x00000000
-> size     = 0x08000000
eth0name    = eth_na51089
ethaddr     = 00:00:23:34:45:66
current eth = eth_na51089
ip_addr     = 192.168.1.99
baudrate    = 115200 bps
TLB addr    = 0x03fb0000
relocaddr   = 0x03edf000
reloc off   = 0x005df000
irq_sp      = 0x03bc9f90
sp start    = 0x03bc9f80
Board Type  = 0
Early malloc usage: 70 / 400
fdt_blob    = 0x03bc9fa0

Suggesting that I needed to first dump out from relocaddr = 0x03edf000, the first attempt was:

md.b 0x03edf000 20000

This dumps 128 KiB of bytes of raw hex to the screen and you are looking for a string about “xmuart” in it. I dumped this to a file, in my case I called it xmuart.cap I was using minicom, and used commands like:

strings xmuart.cap | grep -i uart

to search it. The first dump I tried didn’t come up with anything, so I took a larger dump:

md.b 0x03edf000 0xd0000

and this got me what we needed:

03f109d0: 02 78 6d 75 61 72 74 00 78 6d 61 75 74 6f 00 6e .xmuart.xmauto.n 
03f27090: 30 30 30 0a 00 20 2d 69 20 75 61 72 74 0a 00 61 000.. -i uart..a 
03f280f0: 75 61 72 74 20 76 61 72 69 61 62 6c 65 2e 00 00 uart variable... 
03f29090: 67 73 20 78 6d 75 61 72 74 2e 63 61 70 20 7c 20 gs xmuart.cap | 
03f290a0: 67 72 65 70 20 2d 69 20 75 61 72 74 00 73 20 74 grep -i uart.s t 
03f29d20: 72 69 61 62 6c 65 20 27 78 6d 75 61 72 74 27 20 riable 'xmuart' 
03f29d40: 65 20 74 68 65 20 55 41 52 54 20 75 6e 64 65 72 e the UART under 
03f2b4d0: 20 6f 6f 74 61 72 67 73 2e 78 6d 75 61 72 74 2e ootargs.xmuart.

worth noting I found this long before the end of my massive read out, so you might not need to read out as much as I did to find it.

The command to disrupt the setenv and read the data back to check were therefore:

mw.b 0x3f109d1 41
md.b 0x3f109d0 100

After which:

setenv xmuart 0
Saveenv

I think you can just do a hard restart at this point, but I undid the change:

mw.b 0x3f109d1 78
md.b 0x3f109d0 100

And booted as normal:

run bootcmd

I am now getting the terminal on the URAT, but I had to stop further investigation for the moment as I ran out of time to do more. I’ll post more updates if I get logged in