VEYE IMAGING Forum

desperex

desperex

@veye_xumm Thanks, just used a PCA9306 level shifter and it works perfectly.
I was also looking at ROC-RK3588S-PC but it's a closed linux source targeting mostly Android with weird file structure, partitioning and mounting approaches so it's a no go.

Thanks!

desperex

@veye_xumm So there's no pull-ups on camera's pcb side on I2C rails?
And hey, if you (your company) really intend to support Rockchip SBCs, it's something that I'm going through with all things asked.
BTW Just looked into Orange Pi 5's datasheet and it also uses 1.8V I2C bus for cams.

desperex

@veye_xumm That's why I measured SDA and SCL with multimeter.
Anyway it seems you're not going to help me here with I2C schematics of your cam or any other way.

desperex

@veye_xumm that's really strange but IMX219's I2C DOES work just fine with 1.8V I2C bus.
Orange Pi 4 LTS uses 1.8V I2C bus, I did the measuring and here's a pic:
Screenshot 2023-03-02 at 04.02.02.png
I don't know where you got this screenshot from, here is a link to their schematics - link

So my question was: is I2C level shifter is of any good here? and may I have your cam schematics?

desperex

@desperex said in Please advise compatible mono camera:

@veye_xumm said in Please advise compatible mono camera:

mv seriescamera access to rockchip platform is what we are promoting. It is estimated that it will be completed within a month.
As for the upgrade tool, we will also provide the corresponding binary file.

And BTW I know it's too early but maybe there's already some progress=)
I'm just interested how do you see that task, is it also something to support stats & params of Rockchip ISPs?

Is there any news?

desperex

Hello, is it possible to use the camera on device with 1.8V I2C bus?
I've just made a test on Orange Pi 4 LTS with two cameras:

Raspberry Pi Camera v2.1 (IMX219), camera is detected OK and registered as a subdevice though it's designed to work on 3.3V I2C bus.
Your RAW-MIPI-SC132M is not detected. Is it the issue with camera's I2C logic level or I need to search somewhere else for the cause? In case it's I2C voltage issue will I2C level shifter solve this?

Any may I have camera's electric schematics to discuss it on relevant forum?

desperex

@veye_xumm
Another issue that I'm having with gstreamer that I run like this:

gst-launch-1.0 v4l2src device=/dev/video1 ! "video/x-raw, width=1024, height=768" ! queue ! autovideosink -e

is sometimes gives me 'squeezed frames moving up' effect (please see video). So that may happen right after the launch of gstreamer and I have to relaunch it. I haven't had that issue with the same setup but different camera (imx219), but my ISP driver is a little bit patched to support Y8 and Y10...
Do you know is it camera related or ISP related or maybe some gstreamer bug?

desperex

@veye_xumm, is there a particular reason why veye-raw drivers are missing these controls:

V4L2_CID_ANALOGUE_GAIN_
V4L2_CID_EXPOSURE_
V4L2_CID_HBLANK_
V4L2_CID_VBLANK_

EDIT: Figured out how to implement ANALOGUE_GAIN but the rest requires your help... EXPOSURE should be somehow converted from microseconds to image lines, the rest is just not in specs.
Why PIXEL_RATE in driver is set to constant 750000000?
Shouldn't it be like that?

#define MVCAM_LINK_FREQ 750000000
#define MVCAM_NUM_DATA_LANES 2

#define MVCAM_PIXEL_RATE_8BIT = (MVCAM_LINK_FREQ * 2 * MVCAM_NUM_DATA_LANES / 8)
#define MVCAM_PIXEL_RATE_10BIT = (MVCAM_LINK_FREQ * 2 *  MVCAM_NUM_DATA_LANES / 10)

Since RAW-MIPI-SC132M camera has no AE, I'm evaluating libcamera for this purpose. And it has some requirements:
https://git.linuxtv.org/libcamera.git/tree/Documentation/sensor_driver_requirements.rst#n25

Is there any document that shows how to deal with your raw camera sensor, like creating control loop etc.?

What's your best practices of using this sensor in opencv+libcamera scenarios?

@veye_xumm said in Please advise compatible mono camera:

mv seriescamera access to rockchip platform is what we are promoting. It is estimated that it will be completed within a month.
As for the upgrade tool, we will also provide the corresponding binary file.

And BTW I know it's too early but maybe there's already some progress=)
I'm just interested how do you see that task, is it also something to support stats & params of Rockchip ISPs?

desperex

@veye_xumm said in RAW-MIPI-SC132M on VisionFive 2:

We suggest you find a dts of mipi sensor that has been running successfully on Vision Five for reference, or seek help from the board manufacturer.

Current device tree for VF2 includes working example of imx219 sensor, which is used as a base for your own driver - https://github.com/starfive-tech/linux/blob/JH7110_VisionFive2_devel/arch/riscv/boot/dts/starfive/jh7110-visionfive-v2.dtsi
I just don't see big difference.

Pins J1-11 need to be pulled high.
http://wiki.veye.cc/index.php/RAW-MIPI-SC132M_Data_Sheet#Interface_.26_Pin_list

I don't think you can put the Raspberry Pi dts directly onto Vision Five. This dts corresponds to two parts of the driver. The part of the camera driver named veyemvcam, and the other part corresponds to the mipi reception and processing driver of the main chip (for your board it is the Vision Five main chip).

Thanks, I'd probably need to study specs & docs for the sensor and SBC more deeply.

desperex

Hi, just tried to use the camera with recently received StarFive VisionFive 2 SBC, I know it's "out of your support list" for now, but I just can't make it go through power on cycle.
I use the same camera driver port from rpi5.15 which worked just fine on Rock Pi 4b. But there's something I'm probably missing in DTS part.
(Q1) Wrong power-on sequence? Wrong pinctrl? Wrong GPIO pins?
I use this code:

/ {
    cam_vana_2v8: 2p8v {
        compatible = "regulator-fixed";
        regulator-name = "camera_vana";
        regulator-min-microvolt = <2800000>;
        regulator-max-microvolt = <2800000>;
        regulator-always-on;
    };

    cam_vdig_1v8: 1p8v {
        compatible = "regulator-fixed";
        regulator-name = "camera_vdig";
        regulator-min-microvolt = <1800000>;
        regulator-max-microvolt = <1800000>;
        regulator-always-on;
    };

    cam_vddl_1v2: 1p2v {
        compatible = "regulator-fixed";
        regulator-name = "camera_vddl";
        regulator-min-microvolt = <1200000>;
        regulator-max-microvolt = <1200000>;
        regulator-always-on;
    };

    cam_clk: cam_clk {
        status = "okay";
        compatible = "fixed-clock";
        #clock-cells = <0>;
        clock-frequency = <24000000>;
    };
};

&vin_sysctl {
    status = "okay";

    ports {
        #address-cells = <1>;
        #size-cells = <0>;

        port@1 {
            reg = <1>;
            #address-cells = <1>;
            #size-cells = <0>;

            mipi_in_ucam: endpoint@0 {
                reg = <0>;
                remote-endpoint = <&ucam_out>;
                bus-type = <4>;      /* MIPI CSI-2 D-PHY */
                clock-lanes = <4>;
                data-lanes = <0 1>;
                lane-polarities = <0 0 0>;
                status = "okay";
            };
        };
    };
};

&i2c6 {
    status = "okay";
    clock-frequency = <100000>; //????
    i2c-sda-hold-time-ns = <300>;
    i2c-sda-falling-time-ns = <510>;
    i2c-scl-falling-time-ns = <510>;
    auto_calc_scl_lhcnt;
    pinctrl-names = "default";
    pinctrl-0 = <&i2c6_pins>;

    veyemvcam: veyemvcam@3b {
        compatible = "veye,mvcam";
        reg = <0x3b>;
        status = "okay";

        //clocks = <&cam_clk>;
        clocks = <&clk_ext_camera>;
        clock-names = "xclk";

        VANA-supply = <&cam_vana_2v8>;
        VDIG-supply = <&cam_vdig_1v8>;
        VDDL-supply = <&cam_vddl_1v2>;
        rotation = <0>;

        pinctrl-names = "default";
        pinctrl-0 = <&csi_pins>;
        reset-gpio = <&gpio 18 0>;

        port {
            ucam_out: endpoint {
                remote-endpoint = <&mipi_in_ucam>;
                clock-lanes = <4>;
                data-lanes = <0 1>;
                lane-polarities = <0 0 0>;
                clock-noncontinuous;
                link-frequencies =
                    /bits/ 64 <750000000>;
            };
        };
    };
};

StarFive DTS stuff can be found here - https://github.com/starfive-tech/linux/tree/JH7110_VisionFive2_devel/arch/riscv/boot/dts/starfive
And I use jh7110-visionfive-v2.dts with above overrides of jh7110-visionfive-v2.dtsi.
Media platform and camera drivers go here - https://github.com/starfive-tech/linux/tree/JH7110_VisionFive2_devel/drivers/media/platform/starfive

(Q2) Am I right that with wrong power-on sequence I won't see camera using i2cdetect? Now it shows blank (--) and there's no mvcam logs in dmesg.

It would be really great if you could shed some light on that issue.

desperex

@veye_xumm said in Please advise compatible mono camera:

Which functions of isp do you need, please?

Just AE,IS and crop, if there was a way to skip ISP, I'd do.
Other reqs would come up later, now I just can't start developing CV part.

desperex

@veye_xumm After deep analysis of rkisp driver I see two completely different implementations:

from vendor: https://github.com/JeffyCN/mirrors/commit/72e4ba0ccf477a6d90f40a2fb5e3bc9e5025093b. That one explicitly supports MEDIA_BUS_FMT_Y8_1X8 and MEDIA_BUS_FMT_Y10_1X10 as input for ISP. I tried to bring all the changes to mainline (5.15.90) but it still fails somewhere when setting pipeline
from collabora, mainline kernel, it seems to also have some mono camera support https://github.com/torvalds/linux/commit/9a0e3cd50d3967b669f0f0ea79a7054c7877d95b. But they require the camera to be set to YUV422 which can't be done with RAW-MIPI-SC132M

@veye_xumm said in Please advise compatible mono camera:

mv seriescamera access to rockchip platform is what we are promoting. It is estimated that it will be completed within a month.

EDIT: There's also a warning "mvcam 4-003b: Consider updating driver mvcam to match on endpoints", not sure if it's harmful or not
https://github.com/torvalds/linux/blob/v6.1/drivers/media/v4l2-core/v4l2-async.c#L142

Ok will work on no.1 while waiting for any updates from you
Thanks!

desperex

@veye_xumm
Just finished setting up RAW-MIPI-SC132M camera on rock pi 4b using rpi mvcam ported driver.
Now I'm trying to create a working rkisp1 pipeline, which is not straightforward for me, so I've got some questions:

The sensor supports only Y8 and Y10 formats so how do I map it to ISP which supports only YUV/RGB/bayer formats? At the moment I'm getting 'Broken pipe' error. In topology (below) I need to map formats of rkisp1_isp:pad0 and 'mvcam 4-003b:pad0
How to upgrade camera's firmware? Didn't find any sources on your github, only binaries (incompatible).

EDIT: So this setup is to use the sensor in OpenMV, if rkisp1 just can't work with mono cams, is there any other way to use this cam in my configuration?

Below is media topology for reference:

media-ctl -p -d "platform:rkisp1"
Media controller API version 5.15.90

Media device information
------------------------
driver          rkisp1
model           rkisp1
serial          
bus info        platform:rkisp1
hw revision     0xa
driver version  5.15.90

Device topology
- entity 1: rkisp1_isp (4 pads, 5 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
	pad0: Sink
		[fmt:SRGGB10_1X10/1080x1280 field:none
		 crop.bounds:(0,0)/1080x1280
		 crop:(0,0)/1024x768]
		<- "mvcam 4-003b":0 [ENABLED]
	pad1: Sink
		[fmt:unknown/0x0 field:none]
		<- "rkisp1_params":0 [ENABLED,IMMUTABLE]
	pad2: Source
		[fmt:YUYV8_2X8/1024x768 field:none
		 crop.bounds:(0,0)/1024x768
		 crop:(0,0)/1024x768]
		-> "rkisp1_resizer_mainpath":0 [ENABLED]
		-> "rkisp1_resizer_selfpath":0 []
	pad3: Source
		[fmt:unknown/0x0 field:none]
		-> "rkisp1_stats":0 [ENABLED,IMMUTABLE]

- entity 6: rkisp1_resizer_mainpath (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev1
	pad0: Sink
		[fmt:YUYV8_2X8/1024x768 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range
		 crop.bounds:(0,0)/1024x768
		 crop:(0,0)/800x600]
		<- "rkisp1_isp":2 [ENABLED]
	pad1: Source
		[fmt:YUYV8_2X8/1024x768 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range]
		-> "rkisp1_mainpath":0 [ENABLED,IMMUTABLE]

- entity 9: rkisp1_resizer_selfpath (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev2
	pad0: Sink
		[fmt:YUYV8_2X8/800x600 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range
		 crop.bounds:(0,0)/800x600
		 crop:(0,0)/800x600]
		<- "rkisp1_isp":2 []
	pad1: Source
		[fmt:YUYV8_2X8/800x600 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range]
		-> "rkisp1_selfpath":0 [ENABLED,IMMUTABLE]

- entity 12: rkisp1_mainpath (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video5
	pad0: Sink
		<- "rkisp1_resizer_mainpath":1 [ENABLED,IMMUTABLE]

- entity 16: rkisp1_selfpath (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video6
	pad0: Sink
		<- "rkisp1_resizer_selfpath":1 [ENABLED,IMMUTABLE]

- entity 20: rkisp1_stats (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video7
	pad0: Sink
		<- "rkisp1_isp":3 [ENABLED,IMMUTABLE]

- entity 24: rkisp1_params (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video8
	pad0: Source
		-> "rkisp1_isp":1 [ENABLED,IMMUTABLE]

- entity 28: mvcam 4-003b (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev3
	pad0: Source
		[fmt:Y8_1X8/1080x1280 field:none colorspace:srgb
		 crop.bounds:(0,0)/1080x1280
		 crop:(0,0)/1080x1280]
		-> "rkisp1_isp":0 [ENABLED]

desperex

@veye_xumm thanks for the input, will give it a try with SC132 on rock pi 4b+, sure there will be lot to do with dts.
Yes it's old, but still good in terms of cores/RAM/M.2 support, it only lacks extra CSI and 4 lanes/MIPI CSI-2 support.
It'd be really cool to see your roadmap with all stuff planned and I hope there will be Orange Pi 5 with SC130 adapter for my next project.

desperex

Hi there, I'm interested in SC130 and SC132 mono cameras, going to use them on Rock Pi 4B+ now and probably later on Orange Pi 5.

Concerning Rock Pi 4B+ (RK3399): I see there were some issues with similar board (http://wiki.veye.cc/index.php/VEYE_MIPI_327_for_Nano_Pi_4_ubuntu#Exsiting_bugs) and different camera, but I guess the tests were not done on mainline 5.10+ kernels (which has rkisp1 official support). Anyway I'll probably need an adapter.
Concerning Orange Pi 5: I see you support t-firefly ROC-RK3588S-PC, but Pi 5 uses different type of camera connector, so the adapter is definitely required.

So the question is are those two sensors compatible with two stated boards?

Posts made by desperex