rreignier

Members
  • Content Count

    18
  • Joined

  • Last visited

About rreignier

  • Rank
    Member

Recent Profile Visitors

631 profile views
  1. Wow! That's very nice! Thanks a lot for the help. I did not have the time to try it yet. But for sure, a dts overlay should be pushed to armbian!
  2. Yes, I have been trying on an Orange Pi One. I also have Orange Pi PC Plus and Orange Pi Lite2 (H6) on which I could also try. But since I have received the ov5640 board, I did not try the driver, only the i2cdetect.
  3. Interesting, indeed. But avafinger does not appear to be a contributor of the mainline driver : here. I think he has worked the old one, for kernel 3.4. Interestingly, the PineTab device tree uses an ov5640 here. On a A64 that uses the same sun6i_csi driver that the H3. So I am sure there is still hope. What device tree are you using? Are you using the device tree overlay I have posted above?
  4. Thnak you @jgauthier very interesting report. I did not take the time yet to test a 3.4 kernel to make sure my module is actually working or not.
  5. Before talking to /dev/video0, I would like to see some activity on the i2c side, so just with i2cdetect. But it did not work for me. If you have another camera module, maybe you could try.
  6. Actually. I cannot see the device on the i2c bus, so I don't think that the driver is to blame here. Or maybe i2c driver, but I don't think so. Which kernel are you using to make use of the OV5640 so I could check that my camera works?
  7. @olivluca Sorry, but I don't feel like writing a full kernel driver After some discussions with the vendor and some delivery delays because of the COVID-19, I have now received the OV5640 camera sensor board! But with the overlay previously posted, there is not anything better I have then crafted this simple overlay to enable the `i2c2` with pull-up: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { i2c2_pins: i2c2-pins { pins = "PE12", "PE13"; function = "i2c2"; bias-pull-up; }; }; }; fragment@1 { target = <&i2c2>; __overlay__ { pinctrl-0 = <&i2c2_pins>; status = "okay"; }; }; }; I applied it with: $ sudo armbian-add-overlay i2c2-with-pullup.dts $ sudo reboot Once rebooted, I have checked the i2c device number. I am looking for address `1c2b400` according to the dtsi: $ ls -l /sys/class/i2c-adapter/ total 0 lrwxrwxrwx 1 root root 0 Jan 1 1970 i2c-0 -> ../../devices/platform/soc/1ee0000.hdmi/i2c-0 lrwxrwxrwx 1 root root 0 Jan 1 1970 i2c-1 -> ../../devices/platform/soc/1c2b400.i2c/i2c-1 So let's check the detected devices on bus `1`: $ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Nothing! While with the GC2035 connected, I have: $ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6f 70: -- -- -- -- -- -- -- -- Does someone who owns an H3 based Orange Pi and the OV5640 camera module could try the above commands to see if the module is detected? Thank you.
  8. Actually, I have just discovered that the camera module I have received is a GC2035 and not a OV5640 as ordered. So I won't be able to continue my investigations.
  9. By replacing `CLK_CSI_MCLK`, `GPIO_ACTIVE_LOW` and `GPIO_ACTIVE_HIGH` constants by respectively `107`, `1` and `0` the device-tree overlay can be compiled. But during the boot, I got: [ 10.837084] i2c i2c-1: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 10.843681] ov5640 1-003c: ov5640_read_reg: error: reg=300a [ 10.849315] ov5640 1-003c: ov5640_check_chip_id: failed to read chip identifier So I have disabled my overlay and load the sun8i-h3-i2c2 overlay instead. With the command: i2cdetect -y 1 I got a lot of these errors in the serial console: [ 40.470126] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 42.518174] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 44.566261] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 46.614294] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 From this post I assumed that I could have a pull-up issue so I have created this overlay to enable the internal pull-up on the i2c-2 pins: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { i2c2_pins: i2c2-pins { pins = "PE12", "PE13"; function = "i2c2"; bias-pull-up; }; }; }; fragment@1 { target = <&i2c2>; __overlay__ { pinctrl-0 = <&i2c2_pins>; status = "okay"; }; }; }; But now, I do not see the camera at the address 0x3c and if I let the i2cdetect continue, I get the "I2C bus locked" errors. With the GC235 camera module, I detect something at the address 0x4c. So, even if my OV5640 camera module is brand new, I am not sure if it is working. Does anyone have an idea on how to test if my module is still functional?
  10. Ok, I see. Thank you @martinayotte From sun8i-h3-ccu.h I see: #define CLK_CSI_MCLK 107 So what syntax should I use to set it to 107? clocks = <&ccu 107>; or clocks = <107>; or clocks = "107"; Thank you
  11. Hi! Now that the camera interface has been merged in mainline Kernel, I would like to try to use the OrangePi OV5640 camera module on my OrangePi One. So with the latest Armbian Bionic (20.02.1, kernel 5.4.20), I have been trying to get a device tree overlay. But for now, it fails to compile with: $ sudo armbian-add-overlay sun8i-h3-csi.dts Compiling the overlay Error: sun8i-h3-csi.dts:27.23-24 syntax error FATAL ERROR: Unable to parse input tree Error compiling the overlay My current overlay looks like this: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; }; }; fragment@1 { target = <&i2c2>; __overlay__ { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu CLK_CSI_MCLK>; clock-names = "xclk"; AVDD-supply = <&reg_aldo1>; DOVDD-supply = <&reg_dldo3>; DVDD-supply = <&reg_eldo3>; reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */ powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */ port { ov5640_ep: endpoint { remote-endpoint = <&csi_ep>; bus-width = <8>; data-shift = <2>; /* lines 9:2 are used */ hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; }; fragment@2 { target = <&csi>; __overlay__ { status = "okay"; port { csi_ep: endpoint { remote-endpoint = <&ov5640_ep>; bus-width = <8>; hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; }; So the line 27, which seem to trigger the error is: `clocks = <&ccu CLK_CSI_MCLK>;` Also, according to the documentation, the regulator fields are required but this board does not have much regulators (like AXP209), so I have no idea what to write here. But this is my first time writing a device-tree overlay so I am not sure what is wrong with this line. Could someone guide me to get my overlay right? And, does anyone already got the CSI interface working with OV5460 sensor on a H3 based board? Thank you.
  12. I have noticed the same behavior with my Orange Pi One with Armbian 5.20 upgrading to 5.24. I have tried 4 times and let it work for one full day without success. But I was suspecting my SD card or power supply when I did not see anyone on the forum with the same issue. And I am not able to test other SD cards and power supplies at the moment so I will try again later.
  13. Hi, The mini FAQ is a good idea, it is nice to have all the infos gathered in one place. There should be a link in the Download page of the different H3 boards. Tonight, I have planned to test i2c and SPI but I don't have many experience on that field on Linux because until now I have mostly used libraries on the RPi so everything was working out of the box. I have spent some time to understand the GPIO system. I was trying to use the classical /sys/class/gpio/gpioX structure like explained in the linux-sunxi wiki but most of the GPIOs were "busy" (only the 4, 5, 11, 12 were free and 11 and 12 drive TWI0_SDA and TWI0_SCK, respectively PA11 and PA12). Then I have figured that the GPIOs are already exported in /sys/class/gpio_sw. I found it strange that it was different than the wiki. But with this issue, I did not have enough time to test the SPI and i2c yet. I won't be able to test them before next week I have tested the UART1 and trying to use UART1_RTS signal to trigger a RS-485 transceiver but I have measured a 3 ms turnaround (the delay to put back the transceiver in receiver mode after the transmission) and it is too long for my application. There is no RS-485 driver for Allwinner (yet). But the UART1_RX and UART1_TX work well for classical communication. I have also tried some USB Wifi dongles. The one based RT5370 works well, but the other one, an Atheros AR9271 (which is one of the only Wifi chipset with a full open source driver since Linux 2.6) did not work because the firmware htc_9271.fw was missing: [ 5.503980] usb 2-1: ath9k_htc: Firmware htc_9271.fw requested [ 5.517296] usb 2-1: ath9k_htc: Failed to get firmware htc_9271.fw While talking about drivers, it would be nice to have the Linux USB Gadgets modules (g_serial, g_ether, g_mass_storage, g_multi) available for the OTG port. I found them very useful to connect to the board and get a serial port and network connection when the Wifi or Ethernet is not set.
  14. Hi, I am not an expert in that domain, but I am also interested in RS-485 communication on Allwinner based SBC. For your information OMAP is a series of CPU for Texas Instrument, so the OMAP UART driver is only used on these CPUs. The BeagleBone Black is made of an OMAP processor for example. What I found is that RS-485 drivers only exists for few devices likes the AT91 series from Atmel, OMAP serias from Texas Instruments, i.MX28 series from Freescale (now NXP)... One solution is to use the RTS signal of the UART to drive the RS-485 direction. But I have measured a 3 ms delay for the turnaround on a H3 based Orange Pi One, that delay is too big for my application. So I am finally using a USB-RS485 adapter from Devantech which manage the RS-485 direction automatically. I did not measured the turnaround yet but it worked well for my tests and they advertise a 3uS delay turnaround. But note that this module cost two times the price of my Orange Pi One http://www.robot-electronics.co.uk/htm/usb_rs485_tech.htm