martinayotte

Make sure that PA20 is LOW, it is the WIFI-POWER-EN.

If you use newest build images, we now provide some overlays in the /boot/dtb/overlay folder, and your can activate them in /boot/armbianEnv.txt with :
overlays=uart1-enable uart2-enable i2c0 spi0-spidev

If you use newest build images, we now provide some overlays in the /boot/dtb/overlay folder, and your can activate them in /boot/armbianEnv.txt with :
overlays=uart1-enable uart2-enable i2c0 spi0-spidev

I don't understand you !!!
Who has "positive attitude" or "negative attitude" here, outside of YOU ...
The hardware design choice of Xunlong about eMMC on OPi0 is NOT an Armbian design choice !!! Armbian has NO relationship with Xunlong except to get some sample board to help community !
 
 
(I'm usually a quiet gentle guy, but here, please @igor, I'm getting out, if he fight, please BAN if forever)
What the FUCK ! As Volunteer, I'm should simply say to you :  GET OUT OF OUR FORUM !!! YOU'RE A SICK GUY !!!
 
EDIT : as I said eailer, STOP complain and become YOURSELF a CONTRIBUTOR !

Right ! ... or STA but on a different network to avoid routing isues ...

I don't understand you !!!
Who has "positive attitude" or "negative attitude" here, outside of YOU ...
The hardware design choice of Xunlong about eMMC on OPi0 is NOT an Armbian design choice !!! Armbian has NO relationship with Xunlong except to get some sample board to help community !
 
 
(I'm usually a quiet gentle guy, but here, please @igor, I'm getting out, if he fight, please BAN if forever)
What the FUCK ! As Volunteer, I'm should simply say to you :  GET OUT OF OUR FORUM !!! YOU'RE A SICK GUY !!!
 
EDIT : as I said eailer, STOP complain and become YOURSELF a CONTRIBUTOR !

I don't understand you !!!
Who has "positive attitude" or "negative attitude" here, outside of YOU ...
The hardware design choice of Xunlong about eMMC on OPi0 is NOT an Armbian design choice !!! Armbian has NO relationship with Xunlong except to get some sample board to help community !
 
 
(I'm usually a quiet gentle guy, but here, please @igor, I'm getting out, if he fight, please BAN if forever)
What the FUCK ! As Volunteer, I'm should simply say to you :  GET OUT OF OUR FORUM !!! YOU'RE A SICK GUY !!!
 
EDIT : as I said eailer, STOP complain and become YOURSELF a CONTRIBUTOR !

Here is my W1 Overlay that I use on OPi+2E, you can tweak it to change the pin number you wish to use.
/dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/"; __overlay__ { w1: onewire@0 { compatible = "w1-gpio"; pinctrl-names = "default"; pinctrl-0 = <&w1_pins>; gpios = <&pio 3 14 0>; // PD14 status = "okay"; }; }; }; fragment@1 { target = <&pio>; __overlay__ { w1_pins: w1_pins { allwinner,pins = "PD14"; allwinner,function = "gpio_in"; // in (initially) allwinner,pull = <0>; // off }; }; }; __overrides__ { gpiopin = <&w1>,"gpios:4", <&w1_pins>,"allwinner,pins:0"; }; };

Effectively, there is no PA5 in the mapping.h, simply because PA5 is on Serial Debug UART0_RX.

Yes, you have to tweak mapping.h and rebuild the library. If you still having issue, do an "rm -rf build" and then redo an "python setup.py install"

Right, you don't need my DT overlay shown in the spoiler if you are not using spidev in userspace.
In fact, you just need to replace in the main DT the status "disabled" by "okay".
For accessing the SPI itself in kernel-space, I'm not fluent with that, but you can take a look at other drivers present in the mainline.

In Mainline, the devices are defined my Device-Tree loaded by the kernel.
There is plenty of docs/tutorial that you can find on Google about DT.
Some for different platforms, but it doesn't matter if it to read and learn about DT.
 
For PiZero specific case, the SPIs are already defined in DT, but not visible in userspace until you add an SPIDEV overlay like the following one.
The /dev/spidev0.0 will appear and could be used by python library orangepi_PC_gpio_pyH3.
The /dev/spidev1.0 won't appear unless you disable led_status and uart3 since they are sharing the same pins.
 
 
 

Right ! That is the lib to use for python, but internals C function can also be copied/pasted to any C program.

Ok, guys ! I found my hardware issue : I've been caught myself with an SDCard that becames crappy !
 
For the xradio issue, I don't know if it was also related, but I've created image with Zador stuff, although I had to tweak a bit the DT, and it is now working fine.
 
@Zador, the tweak needed is related to the fact that PL7 was already defined in PiOne, but due was slipped into pio instead of r_pio (same issue found few weeks ago for PiPC https://github.com/igorpecovnik/lib/commit/31c3133cf65af66197b0e78f92eae835615a90b1 )
I will commit this fix in few minutes along some removal in PiZero since we can reuse the PL7 from PiOne, simply by using same names.
 
EDIT : here is the first fix : https://github.com/igorpecovnik/lib/commit/5fff38add9873b50bc71d540573e4294bc97c10d, and here the redundancy cleanup : https://github.com/igorpecovnik/lib/commit/fdaadb42d7587371a7cb7f1184ade5915cd77924#diff-ef59beeea2dd85451fb9bf2905fb7ebf and https://github.com/igorpecovnik/lib/commit/369d3928e7154ac12c34f0e2bc4ce0e24636cb4e#diff-ef59beeea2dd85451fb9bf2905fb7ebf

Ok, guys ! I found my hardware issue : I've been caught myself with an SDCard that becames crappy !
 
For the xradio issue, I don't know if it was also related, but I've created image with Zador stuff, although I had to tweak a bit the DT, and it is now working fine.
 
@Zador, the tweak needed is related to the fact that PL7 was already defined in PiOne, but due was slipped into pio instead of r_pio (same issue found few weeks ago for PiPC https://github.com/igorpecovnik/lib/commit/31c3133cf65af66197b0e78f92eae835615a90b1 )
I will commit this fix in few minutes along some removal in PiZero since we can reuse the PL7 from PiOne, simply by using same names.
 
EDIT : here is the first fix : https://github.com/igorpecovnik/lib/commit/5fff38add9873b50bc71d540573e4294bc97c10d, and here the redundancy cleanup : https://github.com/igorpecovnik/lib/commit/fdaadb42d7587371a7cb7f1184ade5915cd77924#diff-ef59beeea2dd85451fb9bf2905fb7ebf and https://github.com/igorpecovnik/lib/commit/369d3928e7154ac12c34f0e2bc4ce0e24636cb4e#diff-ef59beeea2dd85451fb9bf2905fb7ebf

I've sent the following email to Pantelis Antoniou :
 
 
This is because I feel that new development needs to occur to fill some current gaps :
 
- new clocks not registered dynamically properly.
- new alias not registered dynamically properly.
 
My current use-case is adding new UARTs using sc16is7xx, I got it working, but only by defining new clocks in the main DTB, it wasn't working if defined into the DT Overlay.

Fixed done and committed as explain in https://forum.armbian.com/index.php/topic/3029-mainline-ethernet-driver-h3/

Oh ! Thanks, @TKaiser !
This potentially gave me a clue here : it seems that PD6/EMAC-PWR-EN is used in Plus2E, but not on PCPlus, therefore no power apply if we don't add it to DT.
 
EDIT : Fix done and committed ...
 
EDIT2 : For those who are interested, http://www.megafileupload.com/cg8v/orangepiplus2e-20161209.tgz

Fixed done and committed as explain in https://forum.armbian.com/index.php/topic/3029-mainline-ethernet-driver-h3/

@TKaiser, 5 cents is pretty low estimate, I would rather say 20 cents, even 30 cents if we wish 128Mbits
 
BTW, today, I've worked on get U-Boot-SPL-SPI running on my Zero-M2+ ...
I've finally got it working few minutes ago, it was able to boot from USB dongle without SDCard via this U-Boot-SPL-SPI.
Next steps is to get it able to boot from network ...
 
For H5, I presume there still a lot of work to get it work, André told me that it still WIP.

Yes, RPi.GPIO is coming from RaspberryPi community, I'm using the RPi.GPIO-PineA64 derivative since it is already as most pins there, I've submit a PR yesterday to add SPI/I2C borrowed from Olimex pyA20 to this pineA64 derivative, original Pi version still don't support those yet.
 
On H3, I prefer using the orangepi_PC_gpio_pyH3 since it is a derivative directly from Olimex pyA20 : https://github.com/duxingkei33/orangepi_PC_gpio_pyH3

Here is how to shrink an existing image.
In "gparted", do "edit/resize" of the partition, but leave a certain percentage of free space, then "Apply".
Replace the "endsect" by the actual number shown by fdisk.
sudo modprobe loop sudo losetup -f sudo losetup /dev/loop0 myimage.img sudo partprobe /dev/loop0 sudo gparted /dev/loop0 sudo losetup -d /dev/loop0 fdisk -l myimage.img truncate --size=$[(endsect+1)*512] myimage.img

MIPSbian ...

The python library from https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 is supporting I2C as well as SPI, along with plain GPIOs.

About this bad path for u-boot-sunxi-with-spl.bin, I think the following patch should do the work.
 
But I would like someone testing it under the default branch before I do any commit :
diff --git a/scripts/nand-sata-install/usr/lib/nand-sata-install/nand-sata-install.sh b/scripts/nand-sata-install/usr/lib/nand-sata-install/nand-sata-install.sh index bab4960..f49e1e9 100644 --- a/scripts/nand-sata-install/usr/lib/nand-sata-install/nand-sata-install.sh +++ b/scripts/nand-sata-install/usr/lib/nand-sata-install/nand-sata-install.sh @@ -124,9 +124,10 @@ EOF # determine u-boot and write it name_of_ubootpackage=$(aptitude versions '~i linux-u-boot*'| head -1 | awk '{print $2}' | sed 's/linux-u-boot-//g' | cut -f1 -d"-") + name_of_ubootbranch=$(aptitude versions '~i linux-u-boot*'| head -1 | awk '{print $2}' | sed 's/linux-u-boot-.*-//g' | cut -f1 -d":") version_of_ubootpkg=$(aptitude versions '~i linux-u-boot*'| tail -1 | awk '{print $2}') architecture=$(dpkg --print-architecture) - uboot="/usr/lib/linux-u-boot-"$name_of_ubootpackage"_"$version_of_ubootpkg"_"$architecture""/u-boot-sunxi-with-spl.bin + uboot="/usr/lib/linux-u-boot-"$name_of_ubootbranch"-"$name_of_ubootpackage"_"$version_of_ubootpkg"_"$architecture""/u-boot-sunxi-with-spl.bin dd if=$uboot of=$emmccheck bs=1024 seek=8 >/dev/null 2>&1 || (echo "Error"; exit 0) elif [[ -f /boot/boot.cmd ]]; then