F23 support in hi3516cv300

[biemster]

I have a hi3516ev100 with an F23 sensor and I'm running into some issues getting this combo to work (see also https://github.com/OpenIPC/majestic/issues/138). I've noticed that hi3516cv300 (where the ev100 is a member of) has a F22 sensor library but not F23, while the hi3516cv200 has support for both F22 and F23. Is there a specific reason why there are no F23 libraries in the hi3516cv300 osdrv? (I've noticed that the cv200 is using osdrv2 and the cv300 osdrv3, but I'm not sure if that's part of the reason)

[widgetii]

cv200 and cv300 are different SDK generations, so F23 driver for cv300 should be adapted specifically

[biemster]

Thanks @widgetii , any pointers on how to do this? I noticed glutinium has the sources for both f22 and f23, but for osdrv2. Are the osdrv3 f22 sources somewhere public, so I can have a crack at adapting the f23 code in a similar way?

[widgetii]

osdrv2 and osdrv3 differ but not too much, I'd study source code difference between the same sensor model for osdrv2 and osdrv3 and make the same changes for f23 external API for osdrv3

[biemster]

Indeed that was my initial plan, but then I noticed that in openipc/firmware the sensor drivers are provided as binaries and I don't have access to the hisilicon SDKs. How was for example libsns_jxf22_i2c_dc.so built with osdrv3, and where can I find the sources?

[widgetii]

jx_f22_dc.tar.zip Source code from my dir Hi3516CV300_SDK_V1.0.4.0 (but I'm not sure that it works on real system)

af7be5cda9cceeb5f18caebebbdd3f598a64cdc5 lib/libsns_jxf22_dc.so

[biemster]

Looking at the sources in osdrv2, the only difference is basically the init sequence sent over i2c. This should be really straightforward to adapt to osdrv3, if only I had the SDK. I seem to remember from a couple years ago that openipc provided backers and contributors with a download of this, is that still the case? (if not, I'm trying to download it from some pan baidu link at the moment, since the links on hasecurity.com 404 now)

[themactep]

@biemster ping me on telegram, i'll send you the sdk.

[widgetii]

Sensor init sequence is not HiSilicon SDK API specific, but sensor specific, so I think the incompatibility issue is in something else but the only way to get know is compile and try driver on real hardware

[biemster]

@widgetii indeed, that was what I was trying to say too :smiley: (not english native here) I'm hoping the sensor is throwing the errors because it is in a non-initialized state, but I'll start experimenting when I get this compiled. I compiled a new firmware with https://github.com/OpenIPC/mini instead of majestic since the code for that is available, that is supposed to work right? (I noticed development there is a bit slow lately)

[widgetii]

yep, mini should work on cv300 platform, but you also can try compiled so with Majestic as well

[biemster]

I've compiled a libsns for the f23 for osdrv3, with the i2c init sequence of f23 osdrv2. Also I fixed https://github.com/OpenIPC/majestic/issues/138, that was a memory allocation issue when loading the kernel modules. Now majestic starts properly, but the venc channel times out:

iq_monitor> [     sdk] monitor_thread@363            Query exposure info
iq_monitor> [     sdk] monitor_thread@363            Unknown error code FFFFFFFF
  majestic> [     sdk] venc_read@926                 Timeout get any data from venc channel 0
  majestic> [     sdk] venc_read@946                 NOTE: Current frame is NULL!

[widgetii]

Does ipctool detect your sensor now?

[biemster]

Yes, but that worked already for quite a while (since I managed to load the kernel modules)

firmware:
  u-boot: "2010.06 (Nov 14 2022 - 19:27:26)"
  kernel: "3.18.20 (Sat Nov 4 00:39:04 UTC 2023)"
  toolchain: buildroot-gcc-12.2.0
  sdk: "Hi3516CV300_MPP_V1.0.4.0 B050 Release (Jun  3 2018, 21:42:04)"
sensors:
- vendor: Silicon Optronics
  model: JXF23
  control:
    bus: 0
    type: i2c
    addr: 0x80
  data: {}
  clock: 24MHz
root@ipcam3:~# 

not sure what data: {} means though

[widgetii]

Can you elaborate how did you end up with this driver I've compiled a libsns for the f23 for osdrv3?

[biemster]

I compared the f22 and f23 drivers in osdrv2, and concluded that the only difference is the i2c init sequence. Then I acquired Hi3516CV300_SDK_V2.0.4.0, which contained the same code as you posted a couple comments up. After I pointed the CC and AR variables in the Makefile (Hi3516CV300_SDK_V2.0.4.0/mpp/component/isp/sensor/jx_f22/Makefile) to the binaries from the openipc firmware toolchain, I was able to compile a modified f22 driver with the i2c init sequence of the osdrv2 f23.

That produced a libsns_jxf23.so. (after changing the references to f22 to f23 in the Makefiles and C sources)

[widgetii]

Another possible issue can be binary incompatibility (we're using ulibc-based Hi3516CV300_SDK_V1.0.4.0, not Hi3516CV300_SDK_V2.0.4.0 which is same version but glibc-based)

[biemster]

I do have Hi3516CV300R001C02SPC040, which is Hi3516CV300_SDK_V1.0.4.0 but contains Hi3516CV300_SDK_V2.0.4.0.tgz liteOS, so these version numbers are confusing me a bit. Also, I compiled it myself with the openipc ulibc based toolchain so that should not be an issue I'd guess? (although I'm not an expert)

[biemster]

I also have Hi3516CV300_SDK_V1.0.1.1 which seems uclibc based, should I move my code into this sdk and then compile with the openipc toolchain? Would that make a difference?

[widgetii]

And I suggest studying this doc for debugging techniques Sensor Debugging Guide.pdf

For configuring the initialization sequence, you are advised to see the sensor driver in the SDK for rapid development. To facilitate the debugging, you need to eliminate the interference from the AE configuration and frame rate configuration.

Few years ago it helped me a lot