Search the Community

Hi guys, do you know some article about how to run DHT11 or DHT22 sensors on Banana Pi? I have one sensor bmp180 on I2C bus and reading temperature and barometric pressure was quite easy but this is different bus and move code from Raspberry needs more effort. Basically I need proper binary able to read from gpio pins and I want to record/show values from this sensor on Rpi Monitor. If somebody have previous experiences with that and want to share them I will be very appreciated.

No idea. According to their Wiki I2S is available at the 40 pin GPIO header. But according to their wiki the Guitar is able to output 4096*2048@30HZ through HDMI and drive LCD displays also with 4096*2048 pixel (both wrong. The S500's maximum resolution is 1920x1080 on both HDMI and LCD). You can't trust the informations there as usual. It's just copy&paste from somewhere else and noone of the responsible people gives a sh*t about correct specifications/informations.

Shit, this was visible in the editor... For the history: both lines starting with "ap6xxx_" were ment to be bold and the rest italic. I would also assume, that all lines in a disabled section are not processed. Therefore I kept wifi_used and bt_used enabled. As the modules are not loaded, nothing should change the pin state also. It would be the easiest way for me to remember at next setup: just disable the modules and keep everything in script.fex as it is. In case someone would like to do the modification to the gpio pins directly, the complete section in script.fex would look like this: [gpio_para] gpio_used = 1 gpio_num = 5 gpio_pin_1 = port:PH20<1><default><default><1> gpio_pin_2 = port:PH10<0><default><default><0> gpio_pin_9 = port:PH09<1><default><default><0> gpio_pin_68 = port:PH18<1><default><default><0> gpio_pin_69 = port:PH24<0><default><default><0> Please notice, that there is a <1> after the pin name to set them as output.

Italic and bold are not working in code blocks I didn't mention these lines because csi, smc, lcd, mmc and whatever else are disabled by default. If wifi_used and bt_used are disabled, I'm not sure if pin settings in this block will have any effect, so it's better to set them in gpio or gpio_init explicitly.

Sorry, but the Guitar is dead. Way too expensive, high performance only possible when combined with an annoying fan and weird design decisions. Since every standard Micro-USB3-OTG cable does NOT work together with the Guitar they need to bundle such a cable with their baseboard otherwise the advertised feature "USB 3" isn't available. It's moronic to inform customers that they have to customize their cables to use the only interesting feature for a board in this price range: USB3. Without useable USB3 both storage and network performance are way too slow. Even if you're not interested in storage/network performance the Guitar is a bad choice: You have to configure the board to either run slow or you get in trouble due to thermal issues. Due to the brain-dead board layout you can not use GPIO-Add-Ons (Raspberry Pi HATs) and a fan at the same time. So it will be either slow or with limited functionality. Add the software problems (no mainline kernel support, just a horribly outdated kernel 3.10.37 lacking essential features) and you have to come to the conclusion that the Guitar isn't worth the price (the reseller's prices here in Germany are rather high: Baseboard and Coreboard add up to over 90,-€ including shipping and ordering directly from lenovator.com with shipping costs of $33 doesn't make a difference). For less than that I get an ODROID-XU4 (8 CPU cores and not just 4, 2 GByte RAM instead of 1, 2 useable USB3 ports instead of 0, GBit Ethernet instead of Fast Ethernet, experimental mainline kernel support instead of an outdated 3.10.37 kernel being 2450 fixes behind 3.10.92) and for the same price I get two comparable ODROID-C1+ which shares some limitations (kernel 3.10 and no USB3) but is way more attractive due to high performance without thermal issues and GBit Ethernet.

Mainline kernel comes with new gpio driver with standart linux gpio interface, it doesn't need any DT configuration. You need to "export" pin number for it to appear in sysfs tree (I'm assuming you want sysfs access) Read section "Accessing the GPIO pins through sysfs with mainline kernel" here: https://linux-sunxi.org/GPIO

Dear Sir I realy appreciate your help. But how about the GPIOs part ? I still use that pins (1-6) for other purpose. I also Took a look dtsi .. and found there is no 'normal' gpio definition in dts and dtsi. Sincerely -bino-

I think that in sun7i-a20-cubieboard2.dts you need to change leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&led_pins_cubieboard2>; blue { label = "cubieboard2:blue:usr"; gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>; }; green { label = "cubieboard2:green:usr"; gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; }; }; to leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&led_pins_cubieboard2>; blue { label = "cubieboard2:blue:usr"; gpios = <&pio 4 11 GPIO_ACTIVE_HIGH>; }; green { label = "cubieboard2:green:usr"; gpios = <&pio 4 10 GPIO_ACTIVE_HIGH>; }; }; and led_pins_cubieboard2: led_pins@0 { allwinner,pins = "PH20", "PH21"; allwinner,function = "gpio_out"; allwinner,drive = <SUN4I_PINCTRL_10_MA>; allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; }; to led_pins_cubieboard2: led_pins@0 { allwinner,pins = "PE10", "PE11"; allwinner,function = "gpio_out"; allwinner,drive = <SUN4I_PINCTRL_10_MA>; allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; }; You'll need to recompile kernel (or at least device tree part) with build script to get new sun7i-a20-cubieboard2.dtb file. Alternatively you can try to decompile, change and recompile dtb file with dtc from device-tree-compiler package, but I'm not sure if it will work.

I use one free gpio in [gpio_para] and now working THX

I add w1_para on gpio 5, But it seems to me that it is already used in CSI1? modprobe: ERROR: could not insert 'w1_gpio': no such device Which gpio can I use?

Hiya, I'm attempting to use Wifi on the Banana Pi M1Plus board, supposed to be a Banana Pro clone from SinoVoip, but I cannot get the wifi module working with the latest Armbian 4.5, Jessie kernel 3.4.109. I have already linked script.bin to the /boot/bin/bananapro.bin file I try loading the ap6210 module and it gives errors. root@bananapi:~# modprobe ap6210 <3>[ap6210] parse wifi_used failed in script.fex. <3>[ap6210] bluetooth is disable in script.fex. <3>[ap6210] [dhd_module_init] get wl_host_wake gpio failed modprobe: ERROR: could not insert 'ap6210': Operation not permitted Thankyou for any help Lemonzest

Hi all, after building several images for BananaPi and R1 with Igors lib and getting some insight to the great stuff he has done I have extended my "configuration.sh" with the following: BPI-M2)#enabled #description A31 quad core 1Gb SoC Wifi #build 0 #-------------------------------------------------------------------------------------------------------------------------------- # Bananapi M2 #-------------------------------------------------------------------------------------------------------------------------------- REVISION="1.0" BOOTLOADER="https://github.com/BPI-SINOVOIP/BPI-Mainline-uboot" BOOTCONFIG="Bananapi_M2_defconfig" BOOTSOURCE="u-boot-bpi-m2" BOOTDEFAULT="master" UBOOTTAG="" MODULES="hci_uart gpio_sunxi rfcomm hidp sunxi-ir bonding spi_sun7i 8021q a20_tp" MODULES_NEXT="brcmfmac" LINUXFAMILY="banana" ;; No other changes were made. I successfully build images for trusty and jessie with mainline kernel (4.2.2). Armbian is booting without issues as far as I can see. I have tested ethernet and HDMI, both working, WLAN can be enabled and is up (only verified with "ifconfig", not connected to AP yet). "htop" shows all 4 cores. https://github.com/BPI-SINOVOIP/BPI-WiringPi can be build without issues and "gpio readall" shows all 40 pins. Further tests are ongoing as time permits. Comments are welcome.

Today I tested the mechanical compatibility of 4 GPIO-Add-Ons. They all fit nicely and the distance between Add-On-board and core board is far enough to avoid shortcuts. But due to the different board layout some problems do exist. It would be a good idea if LeMaker exchanges the position of the battery connector and the mounting hole nearby so that 3 mounting holes could be used instead of 2. This would not only help with the first Add-On I tested but with many available Add-Ons and HATs that use the RPi's mounting hole positions. 16x2 LCD + IO Shield: The two top mounting holes match the positions of the wholes on Guitar's baseboard. But the bottom mounting holes are useless as well as the spacer on the bottom PCB side doesn't work so you have to DIY a mounting solution or build an enclosure where everything's securely mounted. 3.2inch TFT+Touchscreen Shield (also available from Waveshare): Same applies to this touchscreen LCD. The spacer is not of any use therefore you can't use this display with the Guitar without an specially designed enclosure I2C to 1-Wire® bridge: Same problem. You cannot use the mounting hole to attach the Add-On-board to the base or core board so you have to either take care of mechanical force or invent a solution to securely fix both base board and Add-On I2C GPIO extend board: Same problem since there is not even a mounting hole. You simply have to take care. But the space between I2C Extender and core board is wide enough

First steps with LeMaker's guitar: These days a few SBC appear that are based on Actions Semi's S500 SoC (quad core Cortex A9r4 processor with 512KB L2 Cache and a PowerVR SGX544 GPU). Two competitors share the Raspberry's form factor (they both use Actions Semi's reference design): Lemon Pi: Roseapple Pi: The Allo SPARKY is also compatible to RPi HATs LeMaker's Guitar differs in size and shape(s) since the Guitar is the combination of one core board as SO-DIMM containing SoC, DRAM and the power management unit (PMU) and a few base boards featuring different hardware: (yes, currently you won't see a product picture since the LeMaker guys seem to like broken links -- they also start every few weeks to destroy every working link between their support forum and their wiki but since noone cares... I don't care too) All boards share the same common 40 pin GPIO header known from RPi A+/B+/2 and hardware characteristics due to using the same SoC/PMU: 2 USB 2.0 ports, 1 x USB 3.0, 1 or 2 GByte DRAM, up to 64 GByte Micro-SD-card, (optional) eMMC, HDMI output, MIPI DSI/CSI connectors for LCDs and cameras and a 'native' 10/100 MBit/sek Ethernet implementation. And they also share the same software limitations: Actions Semi provides only a weird 'SDK' containing a bunch of scripts and outdated heavily patched 3.10.37 kernel sources and there is zero efforts to get Actions Semi's SoCs supported by mainline kernel (which is really bad -- Amlogic/Hardkernel show with their kernel 3.10.y branch how it should work instead: you clone the official kernel tree, get a huge patchset from the SoC's manufacturer and can then merge all official patches in your customized kernel tree). Actions Semi now seems to be there where Allwinner was back in 2012 regarding 'openness' How differs the Guitar from the other boards: The coreboard/baseboard concept should theoretically help developing baseboards that suit ones needs. But since LeMaker hardware isn't Open-source hardware (OSH) I doubt we will anytime soon see baseboards from other manufacturers than LeMaker They use a different power scheme. The base board can be fed with 5-12V @ 2A which will then be used to power USB peripherals (somehow proprietary and not acting as charging downstream ports (CDP) in conformance with the USB Battery Charging Specification) and also the voltage will be converted down to 4.28V to feed the PMU which then creates the different voltages the board's core components need. According to LeMaker they're able to supply additional 3.1A@5V on the USB ports. For details see below USB 3: According to LeMaker they couldn't use the usual blue Type A port to easily connect peripherals like disks, Ethernet adapters or USB3 hubs but had chose the Micro-B port instead since this port can automagically determine whether to operate in host or device mode (obviously they believe people do flash way more often the onboard eMMC than trying to connect USB peripherals). For reasons yet unknown to me the Micro-B port LeMaker used is incompatible with certain (most?) USB3 cables. To sum it up: USB3 isn't useable unless you're lucky enough to find an adapter cable to interconnect the Guitar with normal USB peripherals. Update: These cables do not exist and you have to customize a cable to get USB3 support with LeMaker's Guitar. Unbelievable! Since I'm neither interested in Android (should work flawlessly since Actions Semi's SoCs originate from this environment) nor in Linux as a desktop nor in GPIO stuff (should just work but unfortunately LeMaker chose wider spaces between the mounting holes which has consequences for HATs -- see below) I focused on the basics (getting any information about S500 and the board's hard- and software) and the area I'm interested in: low-power servers that act partially as a NAS. Therefore you won't find any words on GPU/VPU performance/acceleration or classical SBC/IoT stuff like interacting with sensors and stuff like that. I did some tests regarding integer performance with the default 1.1 GHz and also with 1.3 GHz using an own kernel build (you have to adjust operating points in the kernel's cpufreq sources to define clock speeds and Vcore voltage accordingly). With 1.3 GHz the S500 is the fastest quad core SoC I tested so far. But unless you use a fan I wouldn't recommend running at this speed since both SoC and PMU get freaking hot and when thermal throttling jumps in after a few minutes the performance drops drastically. Without a fan you can operate the device only short periods of time with 1.3 GHz and then it either starts to overheat or to throttle down (for yet unknown reasons throttling sometimes failed in my tests and I managed to trigger emergency shutdowns at 125°C throttling is now fixed). Therefore I used the 1.1 GHz setting for the tests. The other 4 boards I compared with were also clocked at reasonable speeds: Raspberry Pi 2, BroadCom BCM2836 quad core SoC, 1.0 GHz Hardkernel ODROID-C1+, Amlogic S805 quad core SoC, 1.7 GHz Wandboard Quad, Freescale i.MX6 quad core SoC, 1.0 GHz not yet released SBC with Allwinner's A20 quad core successor, 1.1 GHz (tests done with Banana Pi @ 960 MHz and interpolated to 1.1 GHz and 4 CPU cores) The board performs nicely in this area (same applies to sequential transfer speeds to/from SD card or eMMC) but for my use cases I/O and network performance are way more important. Due to LeMaker's choice to introduce mechanical incompabilities that prevent using USB 3.0 for this purpose I will stop at the moment. The USB 2.0 performance is bad (caused by the outdated 3.10.37 kernel we have to use with the S500 that doesn't feature UAS or btrfs support and does not contain USB/ext4 fixes and maybe also caused by Actions Semi's USB implementation) and WiFi or 10/100 Mbits/sec aren't worth to measure since other SoCs feature native GBit Ethernet. Therefore I will stop testing the Guitar unless LeMaker designs a baseboard that makes USB3 useable (featuring the normal Type A port and ideally containing an USB hub and both an UAS capable USB-to-SATA bridge like JMicron's JMS567 and an Ethernet adapter like the ASIX AX88179) and wait for Allwinner's next quad core baby that features both native SATA and GBit Ethernet It's too early to draw conclusions and my use case is obviously too specific for the Guitar. Unfortunately it was rather hard work to get/collect all the informations below and still many questions are open. Time will tell whether they'll be answered by LeMaker and Actions Semi and whether the software side evolves. With the current outdated 3.10.37 kernel the S500 is cut off from important stuff like mature kernel code for modern filesystems and tons of fixes inside the kernel (bug and/or security fixes) Original Thread starting one week ago: Today I received my Guitar (well done since it shipped at the end of last week in Shenzen and has been delivered an hour ago in Munich!). I connected it via HDMI to a display, via Ethernet to a network with DHCP server and via a simple 5V/2A PSU to wall power. The Guitar comes with 1 GByte DDR3 RAM and a quad core SoC. (Partially misleading/wrong) informations here: http://wiki.lemaker.org/LeMaker_Guitar Boot time below 30 seconds. Consumption peak at 3.5W while booting and 2.7W when idling with X server running. Both the SoC (thermal_zone1) as well as the ATC2603 PMU expose internal thermal sensors: /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0/ic_temperature: 49822 mCel /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-power.0/power_supply/battery/temp: 0 /sys/devices/virtual/thermal/thermal_zone1/temp: 60000 The PMU can be queried (and maybe its behaviour also modified) using I2C: root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065# ls -al total 0 drwxr-xr-x 29 root root 0 Jan 1 2011 . drwxr-xr-x 4 root root 0 Jan 1 2011 .. drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-adckeypad.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-audio.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-cap-gauge.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc1.1 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc2.2 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc3.3 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ext-pwm-dcdc1.1 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ext-pwm-dcdc2.2 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-gpio.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-hwmon.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-irkeypad.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo1.1 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo11.11 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo2.2 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo3.3 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo5.5 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo6.6 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo7.7 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo8.8 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-onoff.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-pm.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-power.0 drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-pwm.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-rtc.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-sgpio.0 drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-switch1.1 -r--r--r-- 1 root root 4096 Oct 5 14:26 auxadc_dbg lrwxrwxrwx 1 root root 0 Jan 1 2011 driver -> ../../../../bus/i2c/drivers/atc260x_i2c -r--r--r-- 1 root root 4096 Oct 5 14:26 modalias -r--r--r-- 1 root root 4096 Jan 1 2011 name drwxr-xr-x 2 root root 0 Oct 5 14:11 power -r--r--r-- 1 root root 4096 Oct 5 14:26 pstore_dbg -rw-r--r-- 1 root root 4096 Oct 5 14:26 reg_dbg lrwxrwxrwx 1 root root 0 Jan 1 2011 subsystem -> ../../../../bus/i2c -rw-r--r-- 1 root root 4096 Jan 1 2011 uevent root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-dcdc1.1/regulator/regulator.1# ls -al total 0 drwxr-xr-x 3 root root 0 Jan 1 2011 . drwxr-xr-x 3 root root 0 Jan 1 2011 .. -r--r--r-- 1 root root 4096 Oct 5 14:27 bypass lrwxrwxrwx 1 root root 0 Oct 5 14:27 cpu0-cpuvdd -> ../../../../../../system/cpu/cpu0 lrwxrwxrwx 1 root root 0 Oct 5 14:27 device -> ../../../atc2603c-dcdc1.1 -r--r--r-- 1 root root 4096 Oct 5 14:27 max_microvolts -r--r--r-- 1 root root 4096 Oct 5 14:27 microvolts -r--r--r-- 1 root root 4096 Oct 5 14:27 min_microvolts -r--r--r-- 1 root root 4096 Oct 5 14:27 name -r--r--r-- 1 root root 4096 Oct 5 14:27 num_users drwxr-xr-x 2 root root 0 Oct 5 14:11 power -r--r--r-- 1 root root 4096 Oct 5 14:27 state -r--r--r-- 1 root root 4096 Oct 5 14:27 status lrwxrwxrwx 1 root root 0 Oct 5 14:27 subsystem -> ../../../../../../../class/regulator -r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_disk_state -r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_mem_state -r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_standby_state -r--r--r-- 1 root root 4096 Oct 5 14:27 type -rw-r--r-- 1 root root 4096 Jan 1 2011 uevent Kernel config: http://pastebin.com/9bUSA7Rr For whatever reasons the device is not able to run at 1.3Ghz as advertised (UPDATE: I managed to clock it with 1.3 GHz by modifying kernel sources and building the kernel on my own -- see a few posts below): root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_frequencies 408000 720000 900000 1104000 root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_governors conservative ondemand userspace powersave interactive performance root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq 408000 root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo performance >scaling_governor root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo 1104000 >scaling_max_freq root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq 1104000 Clocked with 1.1Ghz it reaches 2338 7-zip benchmark points -- compare with https://s1.hoffart.de/7zip-bench/ "sysbench --test=cpu --cpu-max-prime=5000 run --num-threads=4" finishes in 19.5 seconds. Regarding integer/memory performance in these two short tests the Guitar is roughly 2.3 times faster at this clock speed compared to an A20 based device with the same clock speed: http://linux-sunxi.org/Category:A20_Boards Disclaimer: It's not clear whether memory performance improves if one disables GPU stuff (like it's the case with slow Allwinner SoCs where high display resolution/colordepth/bandwidth decreases overall memory throughput) so this is just a rough estimate and not a benchmark at all. While running the sysbench test on all CPU cores the consumption increases by 3W and the reported temperature rise up to 76°C SoC and 57°C PMU (when idle in my setup with the Guitar operated vertically with enough airflow around: 60°C SoC and 50°C PMU, when set to ondemand governor and idling at just 408 MHz the temperatures decrease to 56°C SoC and 47°C PMU). Warning: These are just values read out using sysfs and not any real measurements. I collected some other informations at the link below (apply to Guitar Core Board v1.3 and Guitar Base Board Rev. B and "Lemuntu" V1509 (http://www.lemaker.org/article-64-1.html -- obviously LeMaker doesn't care about correct informations, the kernel version there is completely wrong) http://pastebin.com/ZpMNkbU1 Complete boot log via debug UART: http://pastebin.com/X2ppDEwS Device tree used: http://pastebin.com/QNb3i9F6 Contents of /boot/uEnv.txt: uenvcmd=setenv ramdisk_addr_r -; setenv os_type linux; bootargs=earlyprintk clk_ignore_unused selinux=0 scandelay root=/dev/mmcblk0p2 rw console=tty0 rootfstype=ext4 console=ttyS3 loglevel=4 rootwait If sometimes in the future an "SDK" will be released I believe it would be a nice board to add to Armbian? Any comments on that? UPDATE: In the meantime some docs/tools have been released and maybe a community evolves around Actions Semi's SoCs: S500 manual v1.4: http://mirror.lemaker.org/Datasheet_For_S500_V1.4.pdf ATC2603C manual v2.1: http://mirror.lemaker.org/Datasheet_For_ATC2603C_V2.1.pdf image-create-tools (to combine bootloader+kernel with rootfs): https://github.com/LeMaker/image-create-tools-actions bootloader+kernel (both not as source!) LeMaker uses: https://github.com/LeMaker/hwpack-s500 XApp-le community: http://wiki.linux-xapple.org/w/index.php/Main_Page

thank you for your answer Igor . I have tested on my SD Card the image you offer on your website (jessie + kernel 4.2) This works fine on my board A10 lime. My plan is to use the nand and configure the kernel to use the Mali harware and GPIO..I already do it with Wheezy and kernel 3.4.103 I think the error message that I get is related to the installation of my distrib but I do not see how to update the DTC , I do not know what it is I continued to search.... Grégory

I need to use i2c, uart, sound, gpio and nand. As I understood not all of this would work in vanilla kernel? I thought about newer kernel because my wifi adapter driver is in kernel since 3.10.

Of course my question came just before I had some progress. I see /dev/mmcblk1 now! I just used some wrong diskimage (I think, I'll have to check). It is not very stable now, maybe due wrong content or timing. Another thing I have to find out. But you may ignore my questions for now. Sorry for the noise. An the next step will be difficult. I want to boot from the eMMC. No idea whether this is really possible but that's what I really want to do. There is a possibility that I'll ask questions about this. I'll try to be more thorough then. I forgot to mention: Using the fex file I misuse a GPIO pin to simulate an SD DETECT line. That's how I can at least boot Linux and it gives me some possibility to check what's happening. Guus

If it can help when I do modprobe w1_sunxi terminal return modprobe: ERROR: could not insert 'w1_sunxi': Invalid argument and in serial output I have : <3>invalid gpio pin in fex configuration : -1 the fex file edited at the begining

Hello , thanks for your help It's ok for fex2bin and bin2fex for me I have modified In doubt I have converted to fex and modified the two bin: /media/mmc/boot/bin/lime2.bin ( in the sdcard ) and /boot/bin/lime2.bin ( in the sata disk ) ( my system boot from sd and , system on SATA) bin2fex /media/mmc/boot/bin/lime2.bin >> output.fex bin2fex /boot/bin/lime2.bin >> output2.fex added [w1_para] w1_used = 1 gpio = 12 in some tuto i've found gpio lines like this gpio_pin_12 = port:PC18<1><default><default><1> it is important or i can leave gpio_pin_12 = port:PC18<0><default><default><default> ? after i do fex2bin output2.fex >> /boot/bin/lime2.bin and fex2bin output.fex >> /media/mmc/boot/bin/lime2.bin reboot the system but got errors with : modprobe w1_sunxi modprobe w1_gpio root@lime2:~# modprobe w1_sunxi modprobe: ERROR: could not insert 'w1_sunxi': Invalid argument root@lime2:~# modprobe w1_gpio modprobe: ERROR: could not insert 'w1_gpio': No such device root@lime2:~# modprobe w1_therm root@lime2:~# I run the image Armbian_4.2_Lime2_Ubuntu_trusty_3.4.108_desktop.zip from here

Hello , I have a olinuxino a20 lime2 and I'm new with armbian I try to get 1wire working I have see i've to configure it in fex file but i cant find the process can you help me ? Thanks Edit : I have find /media/mmc/boot/bin/lime2.bin ( I have root fs on sata disk) it's this file I have to convert to fex and edit ? I have a problem when I do # modprobe w1-gpio modprobe: ERROR: could not insert 'w1_gpio': No such device # modprobe w1_sunxi modprobe: ERROR: could not insert 'w1_sunxi': Invalid argument # modprobe w1-therm is ok

The whole idea is crap. The person supplying additional power used the wrong Micro-USB connector (USB OTG and not power-in). You always have to keep in mind that this is not a Raspberry Pi (where you can insert power easily through GPIO pins since its power scheme is totally different) but an A20/AXP209 device. And the PMU (AXP209) decides on its own where to take power from if there is more than one source available. In case you use kernel 3.4 I would suggest installing RPi-Monitor with the sunxi fixes since this immediately shows you thermal values for SoC and PMU and the power used from the three different available sources (power-in, USB-OTG and LiPo -- for the latter not exactly when you connect a PSU to the LiPo connector since the voltage can't be read out and my sunxi fixes then assume 5V). I delivered one R1 recently to a customer. Runs vertical, no heat sinks (one on the SoC but a crappy one that doesn't help at all) but some sort of convection and a small fan that jumps in if the PSU's temperature exceeds 55°C. Uptime while being totally stable for 30+ days. Temperature was a problem a few weeks ago when ambient temperature exceeded 30°C (since inside the enclosure it were 7°-8° above and then the PMU's temperature exceeded 55° -- might be ok if it gets higher but I decided to let then a fan cool down both SoC and PMU since the fan is just a few cm above both)

are the 1-wire modules built into legacy kernel ( 3.4.xx ) with debian jesse on an Olimex A20 LIME2 ( also the -SOM-4GB ) ? To use 1-Wire for DS18b20 temperature sensors on GPIO5 (from my fex file : gpio_pin_5 = port:PG04<0><default><default><default>) I added [w1_para] w1_used = 1 gpio = 5 to the aw_som_a20.fex file but I don't see any 1-wire modules or drivers loaded. I then used fex2bin ( in windows) to get the .bin file, copied it over and replaced the symlink from script.bin that was pointing to lime2.bin to point to my SSM_som.bin ( I changed the name of the edited one to my board name : SSM_som) Would I need to recompile the kernel to add these modules or can I add them to the current installation ? where are the bin2fex and fex2bin files stored on these images ( i used FTP to get them off, edit, put them back on ) -dd SSM_som_fex.txt

Huh, I don't know if I can help you here either. This functionality is shared among all Allwinner boards so it won't be in this file, but somewhere here: #include "sun7i-a20.dtsi" #include "sunxi-common-regulators.dtsi" #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/pinctrl/sun4i-a10.h> ... then you could possible override it in Olimex dts.

Hey, I am currently trying to get sending IR commands from my CubieTruck working. I am using Igors Armbian_4.2_Cubietruck_Debian_jessie_3.4.108 image. But it seems like the modules are not initialised in a way that they also can send since irsend returns errors that this device does not support sending. I tried it with the hardware.conf from the image aswell as with the hardware.conf and init.d file from https://github.com/matzrh/sunxi-lirc/wiki. Apparently, I have to do "echo $GPIO-Number > /sys/class/lirc_gpio/tx_gpio_pin" which I did with the right pin so in theory, the driver should be set up the way it is supposed to be. Yet still irsend throws errors. Can anybody give me a hint on how to set up the IR sending over GPIO properly? p.s.: Unrelated to this, but maybe generally interesting: Apparently, when GPIO-Pin 2 exists, it automatically binds to wl_host_wake - which obviously is generally annoying if you want to work with that gpio.

Hello, I used to work with script.bin to configure LED and Battery management on my Olimex A20 Lime2. It was pretty easy. Since I switched to kernel 4.1 I had to deal with device tree which is terrible to understand. I would like to do a simple thing : change my Led conf. @petrmaje I fallowed your indication but I can't find a way to adapt it on my board. Below is what I have : led_pins@0 { allwinner,pins = "PH2"; allwinner,function = "gpio_out"; allwinner,drive = <0x1>; allwinner,pull = <0x0>; linux,phandle = <0x35>; phandle = <0x35>; }; and leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <0x35>; green { label = "a20-olinuxino-lime2:green:usr"; gpios = <0x1a 0x7 0x2 0x0>; default-state = "on"; }; }; The gpio declaration is not clear at all gpios = <0x1a 0x7 0x2 0x0>; I don't know how to modify it to GPIO 3 PIN 33 (PH20) Sometime on the web, I find this gpios = <&gpio3 20 0>; But same, it does not work. Any clue ?