Jump to content

g40

Members
  • Posts

    66
  • Joined

  • Last visited

Everything posted by g40

  1. @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.
  2. 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
  3. 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.
  4. 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>
  5. 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>"
  6. 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
  7. @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.
  8. [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 =
  9. Any help much appreciated. Having something of a battle getting the GC2035 working with an OPI One. TAIA.
  10. Ha, ok good to know, thank you. Does undocumented mean likely to be removed?
  11. 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
  12. 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
  13. Documentation is a little thin here. Does anyone have a working example of how to get a file (or files) properly copied into the destination image? Specifically I'm trying to get a binary copied into /sbin on the target. TAIA
  14. Ah, many thanks @zador.blood.stained. I can see my documentation PR is going to get larger.
  15. Idly wondering if the .debs directory could be owned by the user rather than root ...
  16. A bit late but may help others. The output/debs directory contains a number of debian package files (.deb). The 2 relevant to the kernel are linux-image-xxxxx and linux-headers-xxxxxx. If you rysnc those onto your board, you can then install with sudo dpkg -i path/to/linux-xxxx.deb
  17. If somebody gives me a hint I'd be happy to send in a PR to extend the documentation! TAIA.
  18. Bit late but if it helps ... One method is to use a lib.config file in armbian/userpatches to reference a custom GIT repo and branch. This is where you'd be pushing your module changes and .config. Here's an example I am using to build a mainline for a NanoPi M1. # override GIT repo when we build default echo "Branch is $BRANCH" if [[ $BRANCH == "default" ]]; then KERNELSOURCE='https://github.com/g40/armbian-linux' KERNELBRANCH='branch:sunxi-vfe' # specify where our sources are found KERNELDIR='sunxi-vfe' fi
  19. If I have understood correctly, usb-redirector is an example of adding a custom application to an Armbian build? Is there a slightly simpler 'hello world' example? I typically use Buildroot to assemble an OS and RFS - is there anything similar to the BR package system in Armbian if I have misunderstood the above? TAIA.
  20. Ideal, I will experiment. Thank you, much appreciated.
  21. Greetings, Apologies for jumping in here but I'm trying to chase down the same for the FriendlyAram NanoPi M1. My device tree foo is, well, bar, so please indulge me here. Looking at the schematics for the 2 boards they seem to share the same pinnng for USB OTG (I think) http://linux-sunxi.org/images/8/88/Orange_pi-lite-v1_1.pdf and http://wiki.friendlyarm.com/wiki/images/d/d8/NanoPi-M1-1603-Schematic.pdf Looking at sunxi-common-regulators.dtsi, the 'reg_usb0_vbus' section has 'status' marked as disabled. Is this the one that should be set to 'ok'? I'd add a link to the relevant but Github is truncating the listing of files. TAIA
  22. Thanks again. I did manage to work that one out myself
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines