g40

I think this is all out of date. I am running a 4.16 on FriendlyArm H3 and H5 boards which all have CSI enabled and working OV5640 hardware. These are the FA CAM500B models. A set of patches was posted to the V4L list some months back with a CSI driver and subsequent device tree mods. The CSI/OV drivers are enabled (and built-in) in the latest FA distros. Should be trivial to port to the Armbian set ups. FWIW my experience with the OPi camera was _terrible_. Apart from being limited to 2MP max, they never 'worked' at better than VGA and image quality was appalling. HTH.

Greetings. The FriendlyArm docs imply that the parallel camera connection is the usual 24way FPC. Can anyone confirm this is the case? Is the imaging side of things supported in mainline (or near to it)? TVM

Greetings. For anyone interested FriendlyArm have a Github repo which contains a working AW CSI driver. and has device tree files for NanoPi M1+ and Neo Air. See https://github.com/friendlyarm/linux.git. The branch is sunxi-4.16.y This is a work in progress but the setup is vastly simplified compared to the VFE subsystem in the 3.4/3.10 kernels. The OV5640 driver does produce video but I'm getting some odd images at the moment. Possibly colorspace related. As a bonus USB OTG is also working ... fa@FriendlyELEC:~/src$ v4l2-compliance Driver Info: Driver name : sun6i-video Card type : sun6i-csi Bus i[59399.088082] sun6i-csi 1cb0000.camera: ================= START STATUS ================= nfo : platform:camera Driver version: 4.16.0 Capabiliti[59399.102740] sun6i-csi 1cb0000.camera: ================== END STATUS ================== es : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Test input 0: Control ioctls: test VIDIOC_QUERYCTRL/MENU: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 14 Private Controls: 0 Format ioctls: fail: v4l2-test-formats.cpp(259): duplicate format 32314d48 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) fail: v4l2-test-formats.cpp(314): !colorspace fail: v4l2-test-formats.cpp(417): testColorspace(pix.pixelformat, pix.colorspace) test VIDIOC_G_FMT: FAIL test VIDIOC_TRY_FMT: OK (Not Supported) test VIDIOC_S_FMT: OK (Not Supported) test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK fail: v4l2-test-buffers.cpp(500): q.has_expbuf(node) test VIDIOC_EXPBUF: FAIL Total: 38, Succeeded: 35, Failed: 3, Warnings: 0

Hi Thorsten, No. It was simpler and more productive to use the NanoPi Neo Air and M1 boards. The FA CAM500B module works pretty well with the patch included in the legacy Armbian build. BR Jerry

to reduce the noise level? For example I created a topic this afternoon that is irrelevant at best, misleading at worst and solves no problems for anyone. It would be best if it never got into the Google cache. But, failing that, can

Hello Thomas. This is not a systemic Armbian problem, just a local issue.

Hello Igor and thanks. I will check that out.

Using Armbian 5.33. What am I missing? I know the hardware is good as I've had this working before. The modules listed in /etc/modules include hci_uart which is missing. When and how is this built? It does not appear in the 3.4.113 kernel menuconfig options TAIA Jerry $ uname -a Linux nanopiair 3.4.113-sun8i #22 SMP PREEMPT Mon Sep 25 13:11:21 BST 2017 armv7l GNU/Linux # this did work! $sudo nmcli r wifi on $sudo nmcli dev wifi # lists available WAP's $sudo nmcli dev wifi connect <WAP name> password <your password here>

@perfstr Good to know you had this working. By any chance do you still have the .config? My Windows host gets as far as installing the driver then fails trying to get a device descriptor. Device side (H3 powered NanoPi Air) reports below TAIA ``` @nanopiair:/test/gadget_usb$ sudo gadget_usb -v /dev/gadget/sunxi_usb_udc ep0 configured serial="mjqebex15vip4cq2dptcpzak8f508n36z1ulgiqmwe5lgfborb0a5sj4x4xb40a" ** Mon Sep 18 14:01:55 2017 CONNECT high speed SETUP 80.06 v03ee i0000 18 ... protocol stall 80.06 SETUP 80.06 v0303 i0409 255 SETUP 80.06 v0300 i0000 255 SETUP 80.06 v0300 i0000 257 read 2 ep0 events DISCONNECT SUSPEND CONNECT high speed read 2 ep0 events DISCONNECT SUSPEND ```

@zador.blood.stained hello and thanks. I did not realise those notes applied to legacy kernel only. OTG works using Arabian dev for some H3 boards but not others. No obvious rhyme or reason.

Don't quite know what to expect here. The download page implies that there should be a gadget serial connection but there is nothing. I don't even see the USB DRC getting registered. Is this a known issue and is there a solution? TAIA. # nanopineo:~$ uname -a Linux nanopineo 4.11.3-sun8i #3 SMP Wed Jun 7 13:28:34 CEST 2017 armv7l armv7l armv7l GNU/Linux # nanopineo:~$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M # nanopineo:~$ lsmod Module Size Used by evdev 20480 1 brcmfmac 172032 0 brcmutil 16384 1 brcmfmac cfg80211 204800 1 brcmfmac rfkill 24576 4 cfg80211 sun8i_codec_analog 24576 0 snd_soc_core 122880 1 sun8i_codec_analog snd_pcm_dmaengine 16384 1 snd_soc_core snd_pcm 77824 2 snd_pcm_dmaengine,snd_soc_core sun8i_ths 16384 0 gpio_keys 16384 0 uio_pdrv_genirq 16384 0 cpufreq_dt 16384 0 uio 16384 1 uio_pdrv_genirq thermal_sys 57344 2 cpufreq_dt,sun8i_ths g_serial 16384 0 libcomposite 40960 1 g_serial

Hello Enno and thanks. Yes - Indeed mine is the last comment, posted at some point yesterday For the M1 board the FA distro does not specify the usb0_id_det-gpios = <0xe 0x6 0xc 0x0>; section in the DTS.

Greetings, I've got 2 M1 boards in front of me. The FA is running their latest distribution: http://www.mediafire.com/file/kc44mm1mdahslho/nanopi-m1_debian-jessie_4.11.2_20170905.img.zip By default the device tree for the FA has the USB controller (usb@01c19000) marked as disabled and is missing the dr_mode = "OTG" attribute. Enable the controller and Add the dr_node property and the board comes up as a mass storage device in both Windows and Linux. The board running Armbian has exactly the same device tree entries, dmesg shows the USB controller is loaded and visible with lsusb -t. When a gadget module is loaded all appears to work on the M1 but it never appears as a valid USB device on the host. Windows eventually complains that the port reset failed. I figured this might be a problem with the OTG ID pin not being set up properly but both boards report the same PIO pin status. Does anyone have working gadget mode on an M1? Or might they suggest how I can diagnose this issue? Just for laughs Armbian 4.11.5 running on an OPI One *does* have working gadget mode. Given identical hardware and USB wiring I figure this makes it unlikely (but not impossible) to be a kernel issue. TAIA P.S. If anyone wants to do a bit of consulting to fix this problem, please PM me. nanopim1:~$ uname -a Linux nanopim1 4.11.5-sun8i #7 SMP Mon Sep 11 17:50:49 BST 2017 armv7l GNU/Linux ~# uname -a Linux FriendlyELEC 4.11.2 #1 SMP Mon Jul 10 11:06:36 CST 2017 armv7l GNU/Linux nanopim1:~$ sudo sunxi-pio -m PG12 PG12<7><0><1> @FriendlyELEC:~# sunxi-pio -m PG12 PG12<7><0><1>

Ditto. See here:

Some additional points. For the OPI one you have to enable one of the PIO pins otherwise the camera remains off. Ensure that the cable is conductor side down on the camera adapter and facing the bottom of the OPI board. This means with boards and cable lying flat the camera is looking down at the desktop, Despite this the modules I have will not run correctly at anything above VGA resolution IMVHO the FriendlyArm boards with the 5MP OV5640 sensor are far easier to wrangle and do work at advertised resolutions/speeds. # run before you modprobe gc2035! sudo sunxi-pio -m "PG11<1><0><1><1>"