I have a FriendlyElec 1080P HDR camera(MACM400). It only works on some FriendlyElec Release with 4.4 kernel.

So how could this camera work on Armbian with Mainline kernel?

1 hour ago, LuvLetter said:

So how could this camera work on Armbian with Mainline kernel?

By developing/porting a driver?

On 10/19/2019 at 12:26 PM, Igor said:

By developing/porting a driver?

 

the driver is here... it's just a question of time to implement it properly.. And the driver itself tends do be a bit buggy see:

https://lkml.org/lkml/2019/7/30/1201

 

I just don't see a reason to implement this into our kernel yet. Due to:

• It's likely to still have bugs (as by the submitter explained)
• without hardware accelerated encoding/decoding I don't see much of a gain to use the camera on mainline, the current state of those drivers and their userspace applications are unknown to me (I'm not much of a desktop user guy, camera support for the tinkerboard was added cause it pissed me off annoyed that I don't find the rootcase why this driver hanged the kernel each time).
• I don't have the hardware to test it (e.g. a nanopi, they use a 4lane csi compared to RPi/rockpi 2 lane, I'm quite sure I would fail on such an implementation without hardware to test)
• None of the two available camera modules for the nanopi (ov13850, nor ov4689) are mainlined, there's a vo13858 driver there but I've no idea how much those two differ.
• Even when the initial support was done for rkisp1 for rk3288, the community contribution to enhance the quality (e.g. imx219 aka rpi cam v2.1picture is green cause something with color stuff doesn't work properly - config files have to be loaded from userspace to ensure it gets corrected) seems to be of minor interest. I don't see a big chance that this changes with a driver which is probably in a worse condition compared to the bsp driver (in case of functionality not code quality - the mainline driver goes through the review process).

the initial stuff to support the camera on mainline is here, but it's up to someone to apply and test it. Currently I don't think this someone will be myself. But I will help in case questions come up.

On 10/22/2019 at 3:09 AM, chwe said:

a nanopi, they use a 4lane csi compared to RPi/rockpi 2 lane

 

NanoPi M4 uses 2 lanes out of 4. Don't know about Neo4 but this is how driver configures ov4689 on M4. Some say it's because of dual camera support. Neo4 has only 1 CSI so it may use 4 lanes. But if you want one driver for all 3 NanoPi boards you have to use 2 lanes.

 

I'm currently trying to get 60 FPS over 2 lanes on 4.4 kernel. May be I will help you with mainline driver later.

well if the module itself has wired out the 4 lanes, it's likely only a DT issue to define those 4 lines

https://github.com/rockchip-linux/kernel/blob/27f039b43ada8d0301867505ce9a91d8b5c604bc/arch/arm/boot/dts/rk3288-firefly-reload-linux.dts#L319

vs.

https://github.com/rockchip-linux/kernel/blob/27f039b43ada8d0301867505ce9a91d8b5c604bc/arch/arm/boot/dts/rk3288-miniarm.dts#L459

 

likely that on mainline driver the data lines are also configurable via DT. But you need also then a camera module with 4 data lanes and I've no idea how the schematics of those camera modules look like. For sure getting this "properly" working on mainline isn't an easy task. Even on 4.4 kernel the cameras don't work perfectly cause nobody cares. See:

https://github.com/armbian/build/pull/1482

 

during development of the isp1 driver (branch deleted by rockchip but you can grab most of the information here: https://github.com/rockchip-linux/kernel/issues/33) people also used it successfully on rk3399. I assume with a bit of tinkering (e.g. apply the patches to fix the boot issue https://github.com/chwe17/build/blob/21c372631e4dd0a4d011c989c50d3c06667b5d3c/patch/kernel/rockchip-default/320_fix_kernelcrash_with_isp1.patch support for dt overlays in rk3399 4.4 kernel, I think we didn't add overlay support for 4.4, obviously the needed camera drivers and a proper overlay for your cameras). All this would be relatively straight forward if someone takes the time to do it. It's just the question if someone takes this task up and actually tries to get it working.. I only have 2 lane CSI cameras (e.g. RPi cams which may work on the RockPi, for everything else I miss useful CSI cameras...)

 

I saw someone's post on FriendlyArm forum that RK3399 can handle only 6 CSI lanes at a time. Do you know something about it? Is it true?

 

This is how cameras are configured in FriendlyArm kernel: https://github.com/friendlyarm/kernel-rockchip/blob/nanopi4-linux-v4.4.y/arch/arm64/boot/dts/rockchip/rk3399-nanopi4-rkisp1.dtsi#L47

I want to go from 10-bit down to 8-bit and from 30 fps to 60 fps. But I don't know which distro and kernel to choose to experiment with. FriendlyDesktop or Armbian. Does Armbian has issues with cameras on 4.4 kernel?

 

P.S. why rk3399 kernel is 4.4.192 but source package is 4.4.179?

2 hours ago, -WOLF- said:

P.S. why rk3399 kernel is 4.4.192 but source package is 4.4.179?

cause we patch:

https://github.com/armbian/build/tree/master/patch/kernel/rk3399-default

 

2 hours ago, -WOLF- said:

Does Armbian has issues with cameras on 4.4 kernel?

no idea, no camera module nor this board at hand (I've a m4v2 but still no camera).

 

for CSI I would rather expect issues than assuming everything is fine.. Just from my own experience..

 

the module itself supports 4 lane mipi see: http://wiki.friendlyarm.com/wiki/index.php/Matrix_-_MCAM400

now it's a question of driver and DT if you get them working

3 hours ago, -WOLF- said:

P.S. why rk3399 kernel is 4.4.192 but source package is 4.4.179?

Will be fixed when possible.