• Content count

  • Joined

  • Last visited

  1. @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 ```
  2. @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.
  3. 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
  4. 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.
  5. 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>
  6. 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>"
  7. Hello Thorsten No to reverse engineering. And the camera (connected to an OPI One) seems unwilling to work at anything better than VGA resolutions. By comparison the FriendlyArm OV5640 based module is a paragon of stability and quality, a much better bet IMHO. BR
  8. testers wanted Testers wanted: sunxi Device Tree overlays

    @martinayotte Thank you.
  9. testers wanted Testers wanted: sunxi Device Tree overlays

    @selfbg Slightly off-topic: I've not seen that FDT command before. How is it installed/built? fdt set /soc@01c00000/${tmp_spi_path} status "okay" TAIA.
  10. [Apologies. There seem to be a number of posting close to this subject. Trying to get a definitive view] So, with the 3.4.113 kernel the gc2035 driver fails when trying to identify the sensor. The problem lies in the sensor_init function where a read of the I2C/CCI bus fails. Before I break out the breakout board can anyone verify these basics please? I've tried the various suggestions for setting one of the GPIO pins prior to loading the modules but to no avail. Cable, blue insulation on top side of the expansion board FPC, blue insulation facing up towards SD card on the OPI one. FEX as below. [csi0] vip_used = 1 vip_mode = 0 vip_dev_qty = 1 vip_define_sensor_list = 0 vip_csi_pck = port:PE00<2><default><default><default> vip_csi_mck = port:PE01<2><default><default><default> vip_csi_hsync = port:PE02<2><default><default><default> vip_csi_vsync = port:PE03<2><default><default><default> vip_csi_d0 = port:PE04<2><default><default><default> vip_csi_d1 = port:PE05<2><default><default><default> vip_csi_d2 = port:PE06<2><default><default><default> vip_csi_d3 = port:PE07<2><default><default><default> vip_csi_d4 = port:PE08<2><default><default><default> vip_csi_d5 = port:PE09<2><default><default><default> vip_csi_d6 = port:PE10<2><default><default><default> vip_csi_d7 = port:PE11<2><default><default><default> vip_csi_sck = port:PE12<2><default><default><default> vip_csi_sda = port:PE13<2><default><default><default> vip_dev0_mname = "gc2035" vip_dev0_pos = "front" vip_dev0_lane = 1 vip_dev0_twi_id = 2 vip_dev0_twi_addr = 120 vip_dev0_isp_used = 0 vip_dev0_fmt = 0 vip_dev0_stby_mode = 0 vip_dev0_vflip = 1 vip_dev0_hflip = 1 vip_dev0_iovdd = "" vip_dev0_iovdd_vol = 2800000 vip_dev0_avdd = "" vip_dev0_avdd_vol = 2800000 vip_dev0_dvdd = "" vip_dev0_dvdd_vol = 1800000 vip_dev0_afvdd = "" vip_dev0_afvdd_vol = 2800000 vip_dev0_power_en = port:PA17<1><default><default><1> vip_dev0_reset = port:PE14<1><default><default><1> vip_dev0_pwdn = port:PE15<1><default><default><0> vip_dev0_flash_en = vip_dev0_flash_mode = vip_dev0_af_pwdn = vip_dev0_act_used = 0 vip_dev0_act_name = "ad5820_act" vip_dev0_act_slave = 24 vip_dev1_mname = "" vip_dev1_pos = "rear" vip_dev1_lane = 1 vip_dev1_twi_id = 0 vip_dev1_twi_addr = vip_dev1_isp_used = 0 vip_dev1_fmt = 1 vip_dev1_stby_mode = 0 vip_dev1_vflip = 0 vip_dev1_hflip = 0 vip_dev1_iovdd = "" vip_dev1_iovdd_vol = 2800000 vip_dev1_avdd = "" vip_dev1_avdd_vol = 2800000 vip_dev1_dvdd = "" vip_dev1_dvdd_vol = 1500000 vip_dev1_afvdd = "" vip_dev1_afvdd_vol = 2800000 vip_dev1_power_en = vip_dev1_reset = vip_dev1_pwdn = vip_dev1_flash_en = vip_dev1_flash_mode = vip_dev1_af_pwdn =
  11. Any help much appreciated. Having something of a battle getting the GC2035 working with an OPI One. TAIA.
  12. Ha, ok good to know, thank you. Does undocumented mean likely to be removed?
  13. In case anyone else needs help with this. These steps create an oven-baked .img complete with all custom goodies on board from the get-go. 1. rysnc custom code and any other local dependencies into userpatches/overlay 2. Ensure any library dependencies (libv4l-dev in this case) are met by adding 'PACKAGE_LIST="$PACKAGE_LIST libv4l-dev"' to userpatches/lib.config 3. Step 1 ensures that the target image will have content in /tmp/overlay. In userpatches/customize-image.sh one needs to move said content from the read-only directory to somewhere suitable (/test in my case) 4. Finally have customize-image.sh run the relevant build system and optionally install as usual. In order to automate the process end to end I modified compilation.sh so it called an arbitrary set of scripts in the newly created userpatches/custom install_external_applications() { #-------------------------------------------------------------------------------------------------------------------------------- # Install external applications example #-------------------------------------------------------------------------------------------------------------------------------- display_alert "Installing extra applications and drivers" "" "info" for plugin in $SRC/packages/extras/*.sh; do source $plugin done # set up any custom packages for cross-compilation for plugin in $SRC/userpatches/custom/*.sh; do display_alert "Processing custom $plugin" "" "wrn" source $plugin done } An example being #!/bin/sh # example of how to build custom stuff in Armbian environment # # This sets up the source code we need to build grab so it will # be automatically copied to /tmp/overlay. # it would be great if we could add to $PACKAGE_LIST here # as we need the V4L2 development stuff to build grab rsync -rt ~/src/grab ~/armbian/userpatches/overlay rsync -rt ~/src/g40 ~/armbian/userpatches/overlay Finally, some trivial modifications to customize_image.sh # your code here # create test folder mkdir /test # copy from RO temp cp -r /tmp/overlay/grab /test cp -r /tmp/overlay/g40 /test # clean and build on target make -C /test/grab clean make -C /test/grab The target will end up with a binary in /test/grab in this case. The final build step would probably benefit from the more abstracted, modular, mechanism used to rsync. If anyone has ideas for improvement etc, or wants a PR please let me know. HTH Jerry
  14. So, after some digging around I discovered the following: 1. Any files placed in userpatches/overlay automatically get copied by the build process into /tmp/overlay 2. Shortly before the image is finalized, customize-image.sh is run. This is run at the root of the file system '/' as shown by calling `pwd` and `ls -als` from the script itself (see snippet below) 3. So the answer to the copy question is pretty simple. Simply add a line calling `cp /tmp/overlay/myfile` to the destination folder of your choice. Place this where it suits and optionally test the parameters passed to the script for build type/board name etc. Hope this helps someone else. Will add to my upcoming documentation PR. [ o.k. ] Calling image customization script [ customize-image.sh ] Inside Main() pwd / ls -als 0 drwxr-xr-x 21 root root 420 Aug 24 12:52 . 0 drwxr-xr-x 21 root root 420 Aug 24 12:52 .. 0 drwxr-xr-x 2 root root 3120 Aug 23 13:38 bin 0 drwxr-xr-x 4 root root 340 Aug 24 12:54 boot 0 drwxr-xr-x 19 root root 4240 Aug 22 19:27 dev 0 drwxr-xr-x 91 root root 3520 Aug 24 12:55 etc 0 drwxr-xr-x 2 root root 40 Jul 17 04:02 home 0 drwxr-xr-x 19 root root 640 Aug 24 12:54 lib 0 drwxr-xr-x 2 root root 40 Aug 23 13:33 media 0 drwxr-xr-x 2 root root 40 Aug 23 13:33 mnt 0 drwxr-xr-x 2 root root 40 Aug 23 13:33 opt 0 dr-xr-xr-x 299 root root 0 Aug 13 17:18 proc 0 drwx------ 2 root root 100 Aug 24 12:52 root 0 drwxr-xr-x 2 root root 60 Aug 24 12:52 run 0 drwxr-xr-x 2 root root 3600 Aug 23 13:38 sbin 0 drwxrwxr-x 2 root root 40 Aug 24 12:52 selinux 0 drwxr-xr-x 2 root root 40 Aug 23 13:33 srv 0 dr-xr-xr-x 13 root root 0 Aug 24 12:36 sys 0 drwxrwxrwt 3 root root 80 Aug 24 12:55 tmp 0 drwxr-xr-x 10 root root 200 Aug 23 13:33 usr 0 drwxr-xr-x 11 root root 260 Aug 23 13:33 var