Jump to content

Tinkerboard with ISP1 driver doesn't boot (camera support)

chwe

By chwe
in Tinkerboard

 Share

Recommended Posts

chwe

chwe

Posted
Posted (edited)

Since Armbian moved to the official Rockchip kernel, camera support should work with their new ISP1 driver. I built an image with the needed drivers but unfortunately it doesn't boot anymore... :( 

A boot log with the compiled drivers can be seen here (kernel config is attached to this post):

  Reveal hidden contents

What I tried so far:

-disable all patches which have something todo with MIPI system and adjust defconfig

-try to compile kernel with isp1 as module (doesn't compile)

-the 'asus way' of getting the camera to work seems also not possible (thanks to @TonyMac32 for providing those links). Please consider that they don't use the same kernelsource.

The 'asus way':

https://github.com/TinkerBoard/debian_kernel/commit/159704c50bc8b6ea5cdc312a2425aa85ddb4c19e

https://github.com/TinkerBoard/debian_kernel/commit/5ba2b36a2f6a419088f2482fbf955228ce36ebb6

https://github.com/TinkerBoard/debian_kernel/commit/24ef89c0d19b4bc8251c24207f25b0e3cb96c497

https://github.com/TinkerBoard/debian_kernel/commit/c2b6426fed813cf668f8ac272dba0f7714115647

(it's possible that I did a mistake here, cause there are so many changes that I might miss something... :P )

 

To my knowledge there's no linux available for the tinker which uses the new ISP1 driver for camera support. Any help/idea/hint for getting up the camera support is appreciated. 

linux-rockchip-default.configFetching info...

Edited by chwe
spoiler
1
TonyMac32

TonyMac32

Posted
Posted

I've picked up both the 5 MP and 8 MP camera module, we'll see if I can help.  If not I have a pile of Pi's lying about gathering dust...

1
chwe

chwe

Posted
  • Author
Posted

hmmm.. getting confused by this issue. It seems to be (somehow) device tree related. When I play around with asus miniarm device tree (which solved the camera support differently) the board boots with the activated drivers.

TonyMac32

TonyMac32

Posted
Posted

Hmmm, what is the armbianmonitor -u look like when it boots?  :-P.  I should have my cameras in a matter of hours, so I can join in in the confusions.  :-)

chwe

chwe

Posted
  • Author
Posted

too late.. the image is away (running out of SD-Cards so I've to erase them from time to time).. dmesg showed that it fails to touch it and multiple errors with the isp10 driver (that's the one Asus uses for camera support, according to the RK config it's  ok to have both activated)... 

  On 3/6/2018 at 7:48 PM, TonyMac32 said:

so I can join in in the confusions.  :-)

Expand  

have fun. :P 

 

 

TonyMac32

TonyMac32

Posted
Posted

I've hit the same wall you have, I'm getting a kernel oops as the first thing that happens, tied to the ISP1 driver.  Nothing is particularly different about the device tree between tinker and firefly, and as you pointed out, someone claimed to have gotten it working on firefly...  Tomorrow I will investigate any changes that were made to the other camera drivers that may not have been made to the rpi cameras...

 

[edit]  of note, it happens on both cameras, same fault, so it is either a common error to the 2 drivers, or it is the isp1 driver itself.  This is of particular interest as the same configuration is required for the rk3399.

chwe

chwe

Posted
  • Author
Posted

In case someone wants to dive in to this topic:

Here is where it seemed to work:

https://github.com/rockchip-linux/kernel/issues/33#issuecomment-346275025

Keep in mind, this was done with a different board and due the time the ISP was in a early access branch. They removed this branch after merging it to the 4.4 kernel. But a 'snapshot' of it can be found in his github repo cause he forked it:

https://github.com/teseo-sw/kernel/tree/isp-early-access

There are a lot of changes made in the device tree and the kernel is ~3500 changes behind the release kernel now, so playing with this kernel instead of release kernel is only a 'research option'.. :D 

 

edit:

to make it easier for you, here you should find the needed drivers in case you play with the buildsystem:

device drivers -->  <*> Multimedia support  --->  [*]   Media Controller API     

[*]   V4L2 sub-device userspace API 

[*]   V4L platform devices  ---> <*>   Rockchip Image Signal Processing v1 Unit driver  

 [ ]   Autoselect ancillary drivers (tuners, sensors, i2c, frontend... needs to be unset

 Encoders, decoders, sensors and other helper chips  ---> imx219 ov5647 and TC35874X (I think the thoshiba tc35874x is not necessary cause this chip is not populated on the tinkerboard but I guess that the firefly uses this configuration when you look into its dts, nevertheless I let it activated as rockchip suggests it) can be found here...

TonyMac32

TonyMac32

Posted
Posted

I will try building it without any extra patches to see if it works that way.  If not I will reach out to Rockchip concerning the issue.

1
chwe

chwe

Posted
  • Author
Posted

I'm building an image with their buildscript right now.  In case this doesn't work I'll open an issue on their github repo (and as a side note that they should rename their rootfs name on gdrive: rootfs-debian-20171225(fix a stupid mistake, affect performance since 20170901).tar.gz :lol: it's nasty to work with such names from console... ).

 

Another side note: 

RK suggests to use gcc <6:

  Quote

If you insist on developing on your own environment, please make sure the version of gcc-arm-linux-gnueabihf and gcc-aarch64-linux-gnu is less than 6.

Expand  

 

Whereas we use gcc7, I tested it with: 

case $BRANCH in
	default)
	KERNELSOURCE='https://github.com/rockchip-linux/kernel.git'
	KERNELBRANCH='branch:release-4.4'
	KERNELDIR='linux-rockchip'

	KERNEL_USE_GCC='< 6.0'

it built without issues but the kernel failed also to boot... Can this have an effect? I'm not that motivated to test all possible configurations with gcc<6...  :ph34r:

 

Update:

At least it boots... :P  but dmesg shows: 

linaro@linaro-alip:/usr/local/bin$ dmesg | grep ov56
[    3.664487] OF: graph: no port node found in /i2c@ff660000/ov5647@36
[    3.677146] ov5647 2-0036: DT parsing error: -22
[    3.687968] ov5647: probe of 2-0036 failed with error -22

and therefore as expected their camera test fails too: 

linaro@linaro-alip:/usr/local/bin$ sudo ./test_camera.sh
Start MIPI CSI Camera Preview!
./test_camera.sh: 9: ./test_camera.sh: cannot create /sys/module/video_rkisp1/parameters/rkisp1_debug: Permission denied
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstRkXImageSink:rkximagesink0: GStreamer error: state change failed and some element failed to post a proper error message with the reason for the failure.
Additional debug info:
gstbasesink.c(5184): gst_base_sink_change_state (): /GstPipeline:pipeline0/GstRkXImageSink:rkximagesink0:
Failed to start
Setting pipeline to NULL ...
Freeing pipeline ...

I'll open an issue...  Seems that the camera is powered during boot (red LED on camera board shines up for a short time before it turns off). 

 

Update II:

issue is open and I hope we get some respond:

https://github.com/rockchip-linux/kernel/issues/72

 

1
JMCC

JMCC

Posted
Posted

Just ordered an ov5647 camera to join the party. Will take a few days to ship from China, though

2
chwe

chwe

Posted
  • Author
Posted

It's a lame pary..  :lol: It' normally ends with the first message you get from USB-UART (I guess you have one, otherwise buy one :P). In case you start with the Linaro built with  their buildscript (at least this ones boot with the ISP), the DTB  can be found on partition 4 or so (if you only change parts of the DTS cross-compiling a kernel takes a few seconds and you get a kernelimage + a new DTB), you have to mount it first when you want to replace without recompilation and I think they still have the reboot issue, so cutting the power was the only way I got it booting... The GitHub issue might be a good starting point (e.g. port description).  

JMCC

JMCC

Posted
Posted (edited)

Dumb question:  Has anybody tried to use the old driver (CONFIG_VIDEO_RK_CIF_ISP10) as a workaround, until the new one works? @TonyMac32 said in some other thread that it requires more tweaking to work, so I'm guessing it won't work "out-of-the-box" just enabling the kernel config.

 

[EDIT: I just saw this post, saying that @chwe already tried it]

Edited by JMCC
chwe

chwe

Posted
  • Author
Posted
  On 5/17/2018 at 7:03 PM, JMCC said:

[EDIT: I just saw this post, saying that @chwe already tried it]

Expand  

I think I messed in one or two attempts with it before I gave up... :P It failed everytime on build if I've this right in mind.. :P 

This might help you:

 

  On 3/8/2018 at 4:43 PM, chwe said:

edit:

to make it easier for you, here you should find the needed drivers in case you play with the buildsystem:

device drivers -->  <*> Multimedia support  --->  [*]   Media Controller API     

[*]   V4L2 sub-device userspace API 

[*]   V4L platform devices  ---> <*>   Rockchip Image Signal Processing v1 Unit driver  

 [ ]   Autoselect ancillary drivers (tuners, sensors, i2c, frontend... needs to be unset

 Encoders, decoders, sensors and other helper chips  ---> imx219 ov5647 and TC35874X (I think the thoshiba tc35874x is not necessary cause this chip is not populated on the tinkerboard but I guess that the firefly uses this configuration when you look into its dts, nevertheless I let it activated as rockchip suggests it) can be found here...

Expand  

 

  On 3/8/2018 at 8:53 PM, chwe said:

Update II:

issue is open and I hope we get some respond:

https://github.com/rockchip-linux/kernel/issues/72

Expand  

 

have fun. :P :beer: I lost a bit track on it.. due to dealing with other crap.. :P in case you want to compare:

the output of make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- rockchip_linux_defconfig is attached bellow.. 

rockchip_orig.config

1
JMCC

JMCC

Posted
Posted
  On 5/18/2018 at 10:53 PM, chwe said:

Means, you have now time for the RPi cam on the tinker? 

Expand  

Yeah, let's give it a try. It's in my to-do list, together with making a script for the XU4.

 

Just to save me some time, which .dts should I tinker with, the one in the u-boot or in the kernel tree?

TonyMac32

TonyMac32

Posted
Posted
  On 5/20/2018 at 8:18 PM, JMCC said:

Yeah, let's give it a try. It's in my to-do list, together with making a script for the XU4.

 

Just to save me some time, which .dts should I tinker with, the one in the u-boot or in the kernel tree?

Expand  

 

The kernel tree.  at the end this will beast be done with overlays, as the 2 different possible cameras conflict with each other for resources, but if we get one working then we can handle that later.

chwe

chwe

Posted
  • Author
Posted

@JMCC

if you have the imx219 (rpi cam2), dts should be 'fine' in case you've the ovXX(v 1.3) you have to switch the endnodes (cut from imx and post in ov)... But I think, it's related to some other modules we compile/load compared to defaultconig... but mess around with kernelkonfig can be nasty.. :P

 

--> moved to thread where it belongs

JMCC

JMCC

Posted
Posted

Some updates on the issue:

  1. the OV5647 camera works out of the box in a Rockchip-Linaro image compiled 2018-03-19 (an image made with the current status of the repo won't just boot). I decompiled rk3288-miniarm.dtb, and edited the resulting .dts file as described in this post. That should not be necessary for the imx219 camera, enabled by default.
  2. If you want to do the test yourself, you can use these two gstreamer commands for displaying and capturing, respectively: 
    $ gst-launch-1.0 rkcamsrc device=/dev/video0 io-mode=4 isp-mode=0A ! videoconvert ! video/x-raw,format=NV12,width=640,height=480 ! rkximagesink
$ gst-launch-1.0 rkcamsrc device=/dev/video0 io-mode=4 isp-mode=0A num-buffers=512 ! video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1  ! queue ! mpph264enc ! queue ! h264parse ! mpegtsmux ! filesink location=videotest.ts

    Notice that this driver supports the full 1080p@30 resolution of the camera, unlike the older one included in ASUS image, that only supports up to 640x480

  3. Compiling a current Armbian kernel with the camera enabled will cause a kernel panic on boot.

  4. Changing the rk3288-miniarm.dtb from that current Armbian image to the one from the rockchip-linaro referenced above, makes the board boot, but with no HDMI display, and the camera nodes (/dev/video*) don't show up either. UART works OK, you can login, and you have network.

Of course, the problems referenced in 4. may not have anything to do with the dtb, but with the fact that Armbian's rockchip kernel is now messed up. I'll try to do the same experiment with an older snapshot. @TonyMac32 @Igor any suggestion on what snapshot to use (and the best way to prevent Armbian script from auto-updating)?

TonyMac32

TonyMac32

Posted
Posted
  On 6/4/2018 at 11:44 AM, JMCC said:

Notice that this driver supports the full 1080p@30 resolution of the camera, unlike the older one included in ASUS image, that only supports up to 640x480

Expand  

Excellent.

 

  On 6/4/2018 at 11:44 AM, JMCC said:

Changing the rk3288-miniarm.dtb from that current Armbian image to the one from the rockchip-linaro referenced above, makes the board boot, but with no HDMI display, and the camera nodes (/dev/video*) don't show up either. UART works OK, you can login, and you have network.

Expand  

 

Kernel config issues.  I'm on the right track with the Mali I think, filtering through feedback and I now get a desktop coming up making mali-for-android a module.  Apparently when Rockchip says "allow compile as module" they mean "force compile as module"

 

With the mali as module:  

  Reveal hidden contents

 

Myy

Myy

Posted
Posted

For OpenGL ES issues, Apitrace might help you get a trace that can be analyzed by other people : https://github.com/apitrace/apitrace

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept