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...

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...

@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...

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...

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...

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...

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...

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?

I've ran in to this as well after updating about a week ago (on manjaro, whatsie is at 4.14.2-1 now). Additionally I can't send new messages anymore either, which worked...

any future poor souls that might land here trying to get this running might have a look here: https://github.com/biemster/openipc-1.0/commit/b32e9e2