Jump to content

MikePooh

Members
  • Posts

    13
  • Joined

  • Last visited

Reputation Activity

  1. Like
    MikePooh got a reaction from srinath in OV5640 device tree overlay for OrangePi One H3   
    Could you please share the full step-by-step how-to enable the OV5640 camera on mainline kernel on H3 devices. Including CSI, drivers etc. Thanks in advance.
  2. Like
    MikePooh got a reaction from lanefu in Armbian Boot Logo only shown when boot from SD Card.   
    It is so nice that you post the code as image. Please let me paste it as code.
     
    if test -e ${devtype} ${devnum} ${prefix}boot.bmp; then    splashpos=m,m    splashimage=66000000    load ${devtype} ${devnum} ${splashimage} ${prefix}boot.bmp    bmp d ${splashimage} fi  
    P.S. Code works.
  3. Like
    MikePooh reacted to gsumner in OV5640 device tree overlay for OrangePi One H3   
    @MikePooh, I think there's still some schematic-reading involved at the moment, if you're willing to do that though it should be do-able. I don't know anything about other boards yet so this is the process followed. I think for "it just works" you'll need to wait a bit more. I'm assuming a lot here, e.g. active high and fixed-voltage gpio-switched regulators, so there is risk in following this.

    The first step is getting i2c working, the driver won't be able to do anything until you can communicate with the camera. I'll use the h5 in my Orange Pi Zero Plus2 as an example but I believe the process should be identical for h3 boards. Looking at the schematic (https://linux-sunxi.org/images/f/f6/ORANGE_PI-ZERO-PLUS2_V1_0.pdf), on page 9 is the csi connector. We want AFCC_EN, CSI_EN and CSI-PWR-EN to be '1' to power the camera. They might be named differently on different boards, but generally you're looking for the ones that aren't connected to pins (on page 6,  chip U1D) with a CSI_* function (e.g. PE9/CSI_D5/TS_D5). I'm looking for AFCC_EN and CSI-PWR-EN which link to page 6. So AFCC_EN comes from pin PA7/SIM_CLK/PA_EINT7 and CSI-PWR-EN from PA8/SIM_DATA/PA_EINT8. We need to remember those PXX numbers.
     
    rreignier said their camera was on the i2c1 bus, so we need to confirm that too. Following CSI-SCK and CSI-SDA from page 9 to page 6 reveals the i2c interface. CSI-SCK for me connects to "PE12/CSI_SCK/TWI2_SCK" and CSI-SDA to "PE13/CSI_SDA/TWI2_SDA". Maybe someone can confirm, but I think TWIx_SDA equals I2Cx. You can test by enabling the i2c bus overlays one after the other and running i2cdetect while measuring with a multimeter on low range (200mv) A/C voltage between ground and the SCK pin on the camera connector - the correct bus will generate a voltage for a short while. We need to remember that bus number.

    Note the reset-gpios and powerdown-gpios the same way.

    Next is the change to the device tree. In Armbian checkout the linux source  with "apt install linux-source-<kernel version>-current-sunxi" (or linux-source-<kernel version>-current-sunxi64 for h5) which will leave you with a tar in /usr/src of your kernel source. extract it (do it in a new folder or it will trash your current one) and then copy your kernel config in (cp /boot/config-* ./.config). Edit your .dts (./arch/arm/boot/dts/ for h3, ./arch/arm64/boot/dts/allwinner/ for h5) in line with my previous comment, swapping in your values for regulators, i2c bus and reset/powerdown. for a quick bodge, which pin goes in which regulator doesn't actually matter - my change just forced them all on anyway. As lex said, there's supposed to be an order, my change doesn't respect that order but it has worked so far. Then run "make dtbs" from the top level of the kernel source. That should produce a .dtb file in the same folder as the .dts.

    backup your current dtb and copy the new one to /boot/dtb/allwinner/*.dtb (that's the h5 path, not sure of the h3 path sorry, might be /boot/dtb/). I think you can alternatively specify this as fdtfile in the armbianEnv.txt. The armbianEnv.txt way will probably survive an update better.

    Finally, add a line to /etc/modules that says ov5640. Reboot and you might be good to go. If you don't have a /dev/video0 device we'll have to debug.

    Obviously if I've got something wrong feel free to chip in.

    Has anyone had success with resolutions other than 640x480? The driver seems to have some code for it, but I haven't gotten anything to work.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines