search

Miouyouyou / RockMyy-Build

Prebuilt 4.13 kernels for RK3288 boards, including the Mali r19p0 drivers. Usable on MiQi, Tinkerboards, Firefly and other similar boards.
5 stars 4 forks source link

Failed to create I2C device #3

Open VE2UDX opened 5 years ago

VE2UDX commented 5 years ago

Hello,

I'm booting RK3288 Tinker Board with Raspberry Camera Module V2 attached (IMX219). Here is the output of dmesg | grep i2c

[ 0.751264] i2c /dev entries driver [ 0.759772] of_get_named_gpiod_flags: parsed 'dvs-gpios' property of node '/i2c@ff650000/pmic@1b[0]' - status (0) [ 0.760051] of_get_named_gpiod_flags: parsed 'dvs-gpios' property of node '/i2c@ff650000/pmic@1b[1]' - status (0) [ 0.778772] i2c i2c-2: Invalid 7-bit I2C address 0x00 [ 0.778809] i2c i2c-2: of_i2c: Failure registering /i2c@ff660000/af-controller@0 [ 0.778841] i2c i2c-2: Failed to create I2C device for /i2c@ff660000/af-controller@0 [ 0.778880] i2c i2c-2: Invalid 7-bit I2C address 0x00 [ 0.778907] i2c i2c-2: of_i2c: Failure registering /i2c@ff660000/m24c08@50 [ 0.778936] i2c i2c-2: Failed to create I2C device for /i2c@ff660000/m24c08@50

Mainline zImage, rk3288-tinker.dtb (The 4.18-rc5), lib and usr were used.

Miouyouyou commented 5 years ago

Greetings,

The error messages seems to be about I2C peripherals, defined in the DTS file, not being registered. That does not mean that I2C lines are unusable. I'll check why these peripherals are not detected.

Meanwhile, what does cat /proc/interrupts return ?

Also could you try to play with i2cdetect ? This binary is often provided by packages named i2c-tools

Miouyouyou commented 5 years ago

@TonyMac32 Which RasPi camera had issues with mainline kernels ? The first one or the second one ?

Tonymac32 commented 5 years ago

Ugh, As far as cameras go I've never gotten either of them to work. The I2C EEPROM throwing an error is new, and shouldn't be there, perhaps something changed in the bindings...

VE2UDX commented 5 years ago

Thank you for the feedback. I was wrong mentioning the attached camera module because dmesg | grep i2c yields the same output when the camera is detached.

As the camera module is expected at i2c-2 line, here is the output of i2cdetect -y 2 with the camera module (IMX219) attached:

---- 0--1--2--3--4--5--6--7--8--9--a--b--c--d--e--f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --

The presence of the camera module is supposed to be observed as appearance of 0x10 (IMX219 sensor) and 0x64 (crypto chip) addresses. But here we see only 0x64 instead.

The device /dev/video0 appears no matter if the camera module is attached or not. Here is the output of v4l2-ctl -d /dev/video0 --all: videoctl_Miouyouyou.txt

The output of cat /proc/interrupts is below: wi_cam_interrupts_Miouyouyou.txt

As a reference, here are the outputs of i2cdetect -y 2 , cat /proc/interrupts and v4l2-ctl -d /dev/video0 --all when the pure TinkerOS 2.0.7 (with ISP10) is booted: wi_cam_i2cdetect_2_Tinker207.txt wi_cam_interrupt_TinkerOS_207.txt videoctl__TinkerOS_207.txt

Under TinkerOS 2.0.7 the camera is working but a very special way - yielding dark green image, see https://tinkerboarding.co.uk/forum/archive/index.php/thread-645.html and https://www.tinkerboarding.co.uk/forum/thread-659-page-2.html for details.

Miouyouyou commented 5 years ago

On mainline kernels, /dev/video0 is provided by the RGA driver, which is only useful to perform a few operations on video frames.

Now, I see that the TinkerOS uses the rkisp10 driver, which is some Rockchip specific driver...

Since it's a Raspberry Camera, isn't there an official driver for that one. I think I saw something similar in the "staging" area some time ago.

Could you try to adapt this sequence and see how it goes ?

https://devtalk.nvidia.com/default/topic/1031666/jetson-tx2/patching-compiling-kernel-with-auvidea-j20-csi-camera-module-imx219-on-tx2-jetpack-3-2-28-2-/post/5248762/#5248762

You might have to change the -y argument.

I'm not very familiar with I²C, but I guess that you might need a special sequence to "wake up" the camera.

However, you might still need a V4L2 driver for the camera itself to use it with any software. Hmm... I'll take a look and see what I find about Raspberry Pi camera drivers on mainline kernels.

Miouyouyou commented 5 years ago

Also, if you run into color issues, maybe the color encoding is just a little off. Dumping a frame and trying to shift bits or reorder bytes might do the trick sometimes.

Tonymac32 commented 5 years ago

An attempt at the ISP driver on Armbian yielded unbelievably smooth frames, all dark green. We never debugged it. (Kernel 4.4)

Miouyouyou commented 5 years ago

The dark green stuff isn't due to Big Endian / Little Endian mixed reads ? Anyway, I'll take a look at the 4.4 kernel... Once I sort out how to port the JPEG V4L2 decoder for Rockchip systems into an OOT module.

Miouyouyou commented 5 years ago

I misread the forum post about that previous i2cset commands. These commands are only useful to setup the CSI clocks on Nvidia Jetson boards. Ugh...

Taking a quick look at the driver, it seems some clocks needs to be initialized in a very special way : https://github.com/rockchip-linux/kernel/blob/a3c79584a44219e2845301e7f10d1ef7601c1653/drivers/media/platform/rk-isp10/cif_isp10_rk3288.c

So I guess the reason you're not seeing the Camera chip is due to the clocks being inactive. Since I don't know how I²C works, I don't know if you can emulate a clock by driving a specific GPIO and setting it as a "clock" for testing purposes.

VE2UDX commented 5 years ago

@Tonymac32 Dark green images - it most likely means that 2A (AE/AWB) is not implemented. So it is working, but unbalanced. Could you please share your v4l2-ctl -d /dev/video0 --all output with this ISP driver?