/dev/video[01]?

#22

I don’t see anything wrong with the dts.

Unfortunately, I can’t help much, my whole setup is based on 5.10 due to using libmali, i can’t just switch kernel as you can with Armbian.

What i know is these guys are actively working on the rockchip media and perhaps they have up-to-date documentation (or they can talk to rockchip directly) and can give you some inside information.
@nyanmisaka @amazingfate

I think you are right.
If you want to debug the kernel: (https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr1/drivers/media/platform/rockchip/cif/capture.c#L6405)

I will follow the conversation…

#23

Thanks. Yes amazingfate usually answers on discord armbian-rockchip channel. I’ll try to contact him there too.

Update: since this CIF and ISP driver/sdk software is Rockchips work their staff should be most suited for solving it. I sent an email to someone there.

#24

@avaf @Oskar_Enoksson did you find a solution to the problem? I’m facing the same on a different SBC, however, my overlay for cameras works on 5.1.160 kernel but fails on both 6.1.y kernel from friendlyelec and also 6.1.57 armbian kernel…

#25

I have reserved my ready-to-fire image with kernel 6.1 to Rock 5C but no sign of the board being delivered any time soon. I am waiting for a few SD card to arrive soon and then i will try on Rock 5B. I think OrangePi has kernel 6.6 , have you tried that kernel version?

#26

I still have the same problem. The camera overlay works for me though, it is just the video processing drivers that don’t work (with armbian 6.1 vendor kernel that is, the 5.10 vendor kernel works).

I opened issues here and here but no solution yet.

Note that you must have “vendor” kernel and the only existing versions are 5.10 and 6.1 for all I know. The mainline 6.1 or 6.6 or any other kernel can’t use the MIPI/CSI camera as far as I know because the functionality is not yet implemented there. Collabora has it on their TODO list but I hear that they are not as focused on rockchip development lately.

#27

Please, disregard this info.

#28

thx for the info, at least I’m not alone :slight_smile:

#29

FYI
I don’t know if you have found a solution to the issue with kernel 6.1 but it is working on rock-5c.

rock@rock-5c:~$ ./capture -d /dev/video11 -f NV12 -K 400 -c 500 -s 1920x1080
HDMI-A-1 -> connected
rga_api version 1.10.0_[9]
frameSize: 6220800, srcWidth: 1920, srcHeight: 1080
rock@rock-5c:~$ ls *.png
screenshot_1920x1080.png
rock@rock-5c:~$ ./capture -d /dev/video11 -f NV12 -c 2000 -s 1920x1080
HDMI-A-1 -> connected
rga_api version 1.10.0_[9]
rock@rock-5c:~$ uname -ra
Linux rock-5c 6.1.43-10-rk2312 #eb3b42978 SMP Fri Jun  7 02:38:46 UTC 2024 aarch64 GNU/Linux
rock@rock-5c:~$ v4l2-ctl -d /dev/video11 --get-fmt-video
Format Video Capture Multiplanar:
	Width/Height      : 1920/1080
	Pixel Format      : 'NV12' (Y/UV 4:2:0)
	Field             : None
	Number of planes  : 1
	Flags             : 
	Colorspace        : Default
	Transfer Function : Default
	YCbCr/HSV Encoding: Default
	Quantization      : Full Range
	Plane 0           :
	   Bytes per Line : 1920
	   Size Image     : 3110400
rock@rock-5c:~$
#30

it’s been a while, however I just retried this on 6.1.99 armbian kernel today and found the issue to still be there… @Oskar_Enoksson did you ultimately find a fix?

#31

@avaf just to be on the same side - this test captures from HDMI-IN, right? In @Oskar_Enoksson and my case we want to capture from a MIPI CAM…

#32

I also tried it again a month ago, on latest kernel 6.1, same issue. I’m also trying to capture from a MIPI camera on the Rock5A, and trying to take advantage of the hardware rescaling ISP block in the CPU.

I think @avaf captures video on the device which is directly connected to the camera, i.e. without passing it through the ISP. I’m able to do that too, with the cameras native resolution and output format.

A few things do work, but it’s very shaky. Fiddling with v4l often hangs the system requiring reboot.

#33

Yes. I mean it works on HDMI-IN as well.

The Kernel 6.1.x is running on Rock 5C, not Rock 5A. I think there are some minor differences regarding the MIPI connection on 5A. My advice is to use vendor kernel 6.1.43, find the correct DTS and then move on to newer kernel.

FYI
Kernel 6.1.x on Rock 5B is using CAMERAOUT_M3 / mipim0_camera3
Kernel 6.1.x on Rock 5C is using CAMERAOUT_M2 / mipim0_camera2

I think Rock 5A is more like Rock 5B than 5C.

#34

@Oskar_Enoksson yes I verified that capturing the native raw data works fine for me as well, but the connection to the ISP is simply not there, so the /dev/v4l-subdev4 is not there…

@avaf I’m on the NanoPC-T6 actually, but it is exactly the same problem that Oskar has described… my setup is just either one single 4-lane OV4689 on csi0, or two 4-lane OV4689 on csi0 and csi1 - DeviceTree works on 5.10.160 fine, does not on 6.1.99

#35

@avaf not sure I understand you right, but I am running Armbians “6.1.99-vendor-rk35xx” kernel on my Rock-5A (I understand you have Rock-5C and that there are differences, but Armbian has some sort of “unsupported inofficial support” for Rock-5A with a working devicetree). If you talk about mainline kernel I think RKISP support is one of the things that is unfortunately still not implemented there.

But does anyone know: is the idea that the desired connections between the video blocks of this CPU can be changed/configured in the devicetree? If so maybe that is the missing key to success?

#36

I meant Radxa official OS. (6.1.43)
Interestingly, people with Rock 5A are silent about kernel 6.1 and the camera.

If i recall correctly, i had this issue when i tried rockchip 6.1.57 with the wrong camera engine.

FYI:
According to Rock 5A overlay, it uses CAMARAOUT_M2 and camera2_clk, same as Rock 5C (CSI2), did you try with this configuration?