BTW, the driver provided from the RPI would also need some modifications to fit into the rock-chip BSP.
Connect Arducam HQ Camera to ROCK5B
You got the kernel driver and device overlay working? I’m fairly sure there’s a /dev/video device that bypasses the ISP.
Yes, I got the kernel driver and device tree working.
Cool pi 4b + Ubuntu don’t use the overlay, therefore I modified the device tree and got it working.
Yes, there supposes to be a node (/dev/video0 or /dev/video1) that bypasses the ISP.
But the image samples are not correct, something like the attached image.
Yeah that looks like an incorrect sample format. Could you share some details about your software setup? Also it is worthy of note that the cool PI 4B only has 2 CSI lanes since it uses the same connector. That means you can’t use the full potential of the RK3588 and camera.
Yes, I used the v4l2-ctl command to sample a 1920x1080 stream ()
sudo v4l2-ctl --verbose -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat='NV12' --stream-mmap=4 --set-selection=target=crop,flags=0,top=0,left=0,width=1920,height=1080 --stream-to=out1.yuv
And then used the ffplay to visualize it.
ffplay out1.yuv -pixel_format nv12 -video_size 1920x1080
(There is some buffer bug inside the rockchip mipi driver that I couldn’t stream 4K resolution in RAW format, but I could stream the 4K resolution after ISP.)
Cannot complain, but have to say the rockchip documents are not well organized.
Yes, it only comes with the 2 data lanes.
I planned to use the HQ camera for star rail photography of which the bottleneck is the post-processing (Raspberry PI 4B is so so slow on that).
But I came across the same problem as @Raphael discussed. (All my inquires to Rockchip were ignored, even though my startup has made a fair amount of purchases from them)
Therefore, I decided to work on the software ISP.
exactly what I thought would happen
I had a meeting with Arducam yesterday, they’re considering supporting the Rock5 and are working on providing cameras for this platform.
It may take some time, though, but the interest is there and they already started on that.
I also told them about the very bad tuned radxa 4k camera, maybe they’re able to make it a little better.
When I know more I’ll post a few infos here and I’ll ask Arducam to join this forum
Tell them we’re looking forward to it. Would buy it no questions asked.
This is the most inspiring news I had this week:)
Thanks @Raphael so much for forwarding our issue to Arducam:)
If there is anything I could help (like drivers, testing, etc), please don’t hesitate to let me know
Bring it on.
I am willing to help to test it and give some feedback, or help somehow. Arducam, if you are following this, take note, please.
Interesting, I think years ago we contacted Arducam for collaboration on the camera modules but we never got a reply from them.
@Raphael any news from the Arducam team? Are they still working on it, or the project is cancelled and we we proceed with our own hand-made adapters and kernel drivers?
It isn’t cancelled, but I also don’t know any publishable facts yet.
What I can tell is that arducam and radxa had/have a meeting today
Sounds like a really long-term project to me
I did a quick research and found that RPI hq camera indeed has voltage step-down bundled inside the camera board, where RPI’s 3.3 volts become 1.8 which sensor requires, so there is no way that adapter layout proposed before would work (I checked, even i2c is unstable on 1.8v). The MIPI pinout and voltage seem to be part of some standart, so there should not be any issues there.
I managed to create a small board which converts 1.8v signals received from OPI 5 to 3.3v expected by the arducam/rpi hq camera, In couple of weeks I’ll see if it works.
Also I found this article where it is explained how to make IMX415 sensor work with similar processor and same kernel version, so it seems there should not be a big issue to make IMX477 work too.
Of course, by “not a big issue” I mean that I’m expecting something like proof-of-concept and not hi-end quality camera without any bugs and issues
/sorry for posting another message in the row, but it appears that newbies can add only 2 links in a single message/
Btw, here are some existing adapter boards which do the same stuff that I did:
https://wiki.veye.cc/index.php/ADP-Tfirefly
https://wiki.veye.cc/index.php/ADP-MV2_Adapter_Board_Data_Sheet/zh
First one should be easily modified if mine would not work properly.
UPD 26.05
My custom 1.8 -> 3.3 volts converter board worked and now I’m able to see my imx477 on i2c and even get it’s chip id propery.
Even with probe() method of the driver working properly, I don’t see any new devices in media-ctl -p
output and also none of /dev/video* are linked to my camera. That is next challange which I think would take a lot of time, because the issue might be in dts config, which I’m not familiar with at all.
@Raphael I understand that making isp work properly might take a lot of time, but my goal for now is at least get raw image, like the green one that you referenced to.
BTW, radxa, “newbies are limited by 3 posts in single topic”, wtf?
The issue here is a little more in depth than you would think.
Let*s start with the imx415, this camera has already been tuned by rockchip and is officially supported.
Without this tuning you’ll see the green image which I posted a few comments back.
Veye is another thing, they’re using a isp directly on their camera-board, and also have drivers for some rockchip boards, so in theory it shouldn’t be a big hassle to get them working.
Here is a link of somebody who played around some time ago with the 415, in the middle you see a green picture, that’s without the isp
Will this adapter work on Rock 5B with with OV5647 Video Camera Module For Raspberry Pi 2/4/3B ?
I don’t know if anything will work. We don’t have the software to test anything. I’m currently busy in life with other things.
If you started this project, don’t leave it. I am shure solution can be found
With all due respect, I am under no obligation to do anything. Nobody paid me to do anything.