zador.blood.stained

Disabled. 

Note to self, don't be stupid.
 
On the plus side, both of my Orange Pi One boards now have working SPI0.  Want to guess why?
 
Let's use my previous post to show how to do it right as that worked perfectly.  One might just make a note to remember to perform all of those actions *on the same board*.
 
I'm going to go enjoy my working SPI and my stupidity.
 
Thanks for all of the help, @zador.blood.stainedand @martinayotte.  Also, sorry for the grief.

This depends on your boot script version and kernel/DT packages build date. I would recommend using both as new as possible (may require using a new image or manually upgrading the boot script). Serial console can be useful to spot any issues, but SPIdev overlays should work out of the box if they are loaded properly.

The holes look more elliptical than circular (like on SoPine), and at least on SoPine standard 2.54mm connectors with ~0.7mm square pins won't fit there. But pins on popular IR receivers are usually flattened and will fit in the holes like these without any problems.
 
I would prefer to wait for the schematic release just to be sure (assuming nobody here will get a sample board)

I pushed the patch so next nightly and packages in beta repository should have the fix.
@willmore you'll have to extract the u-boot binary from the appropriate package (default for the legacy kernel or dev for the mainline kernel) and reflash the u-boot binary to the SD card. If this fixes the issue for you maybe MoeIcenowy should be pinged about this (since she is the maintainer for the OPi Zero u-boot defconfig)
 
u-boot packages: u-boots-opizero.zip
 
Edit: According to the schematic CPU on Zero should be powered with 1.3V by default, so it shouldn't be an undervoltage?
Edit 2: At least my board is powered with 1.3V by default

Here it's about board bring up. Which voltage is the SoC being fed with if no software started to control anything? Zero can switch between 1.1V and 1.3V but there's a default state when powering up and control is later turned over to software which then decides based on clockspeed which voltage to chose (remaining at 1.1V with lower clockspeeds and switching to 1.3V when exceeding 816MHz -- mainline -- or 912MHz -- legacy)
 
Edit: to elaborate on that a bit (and to stand corrected if necessary and also to add stuff to @zador.blood.stained's TODO list  ):
 
So the board's VDD_CPUX voltage is 1.3V when the board boots regardless of clockspeed set anywhere (what's happening when a 'reboot' has been issued before?). This should prevent any undervoltage issues at boot. Next step is booting u-boot, here a static cpufreq will be set (either u-boot default, IIRC 1008 MHz with sun8i, or in our case it's 480 MHz -- we chose this value since we prefer minimum consumption over boot duration) Next step is booting the kernel, with H2+/H3 legacy kernel here the userspace governor is set so the board remains at 480 MHz clockspeed while with mainline kernel schedutil governor takes over and results are not really predictable, at least now CPU cores might clock up to the highest limit allowed with sun8i dev kernel -- what's the value? 1296 MHz? -- and since DVFS is now active voltage starts to jump between 1.1V and 1.3V based on cpufreq) As soon as cpufreq-utils daemon is started it looks really weird since now we switch with legacy kernel from userspace to interactive governor while with mainline from schedutil to ondemand (everything ok, interactive is the better choice with legacy and we switched just recently to ondemand due to some strange reports regarding schedutil). From now on maximum cpufreq can be set by the user (h3consumption tool or /etc/defaults/cpufrequtils -- defaults for large H3 boards 1296MHz, for smaller H3 boards 1200 MHz and for NanoPi NEO/Air 912 MHz) DVFS settings switch voltage above 816MHz with mainline (since that's defined in official DT for Orange Pi One which we use for the Zero) and above 912MHz with legacy since after some extensive internal testing we don't give a sh*t about Allwinner's recommended defaults and let a few thousand Armbian H2+/H3 board users do some reliability testing in the field  
For me personally questions 1 and 3 are interesting. What happens at reboot and what's maximum cpufreq with sun8i dev kernel before cpufrequtils daemon is loaded?
 
And then I would propose to switch to userspace governor in sun8i dev kernel config too for obvious reasons (we discussed this back then when developing IoT settings for the smaller H3 boards and my tests revealed that boot times for the large boards aren't affected that much since their boot clockspeed in N° 2 above is 1008MHz and not 480MHz). Also I would prefer to switch voltages with mainline kernel on the primitive H3/H2+ board also above 912MHz and not 816MHz any more to get more test feedback for mainline DVFS implementation. But no need to hurry, opinions first!
 

Mostly we need SoC specific adjustments, not per board ones. And we moved most of the things to the sources templates already, so there isn't much left to do - armbianmonitor & rpi-monitor templates, firstrun adjustments and MOTD adjustments. I hope this will be resolved eventually, but my TODO list is long enough already.

I pushed the patch so next nightly and packages in beta repository should have the fix.
@willmore you'll have to extract the u-boot binary from the appropriate package (default for the legacy kernel or dev for the mainline kernel) and reflash the u-boot binary to the SD card. If this fixes the issue for you maybe MoeIcenowy should be pinged about this (since she is the maintainer for the OPi Zero u-boot defconfig)
 
u-boot packages: u-boots-opizero.zip
 
Edit: According to the schematic CPU on Zero should be powered with 1.3V by default, so it shouldn't be an undervoltage?
Edit 2: At least my board is powered with 1.3V by default

I think this
means that he most likely used a prebuilt nightly image and upgraded it from the repository.
 
Anyway missing characters in the logs don't look good. Maybe voltage regulator or CPU frequency limits were lost during u-boot patches upgrade and now the board is undervolted/overclocked. I'll check the commits later.
 
Edit: CPU frequency limit and CVBS output settings was lost, I'll add a patch to fix this.

I think this
means that he most likely used a prebuilt nightly image and upgraded it from the repository.
 
Anyway missing characters in the logs don't look good. Maybe voltage regulator or CPU frequency limits were lost during u-boot patches upgrade and now the board is undervolted/overclocked. I'll check the commits later.
 
Edit: CPU frequency limit and CVBS output settings was lost, I'll add a patch to fix this.

Yes. Main problems / considerations here are:
We have multiple platforms/SoCs, and most overlays will need modifications / adjustments for each platform Compared to RPi we don't have support for overlay parameters, so instead we use u-boot scripts which have some limitations Compared to RPi SoCs, Allwinner A20, for example, has 4 SPI controllers, 5 I2C controllers and 8 UART controllers, and for I2C/SPI devices we have to support attaching devices to each of potentially available bus/controller So instead of blindly trying to port all existing RPi overlays it will be easier to add them by user requests.

From Armbian documentation (https://docs.armbian.com/User-Guide_Allwinner_overlays/)
 
Most in-circuit and GPIO based interfaces (SPI, I2C, I2S, …) don’t have a mechanism for detecting and identifying devices connected to the bus, so Linux kernel has to be told explicitly about the device and its configuration details.
 
While Device Tree is a way of describing hardware configuration to the kernel, Device Tree overlays are a way for modifying the DT in order to provide the kernel and kernel drivers with details about external devices or to activate interfaces disabled by default.
 
What do we want?
 
We want to add Device Tree overlays for the onboard interfaces and tested external devices so that they appear in future mainline Armbian images. This means that activating this type of hardware will not require recompiling the Device Tree or will require compiling just the overlay file which will be compatible with future kernel updates.
 
What kind of help do we expect?
 
We want people to participate in making and testing overlays for the hardware that they have.
Participation requirements:
An A10, A20 or H3 board that can boot the current mainline kernel Serial console adapter for getting the u-boot logs if they are needed Extra SD card to use for booting the nightly/beta images I2C, SPI or I2S (only A10 and A20 based boards since I2S driver is not present on H3 yet) device that you can connect to the board and that requires either generic driver (like SPIdev) or a special driver (available in the mainline kernel), with an exception of custom built boards that don't have commercially available compatible alternatives and devices that don't have in-tree kernel drivers. Some generic Linux knowledge (i.e. how to obtain a dmesg log, how to check file contents) At least a basic understanding of the hardware that you have and how does it integrate into Linux. For example I have no idea how to calibrate a resistive touch screen even if I can write a DT overlay for it. Please note that some hardware limitations (i.e. number of SPI chip selects, missing SPI DMA support) may affect possibility of supporting some devices  
What overlays are already available?
 
Please check the README in the subdirectory for your SoC in the overlays repository: https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian

From Armbian documentation (https://docs.armbian.com/User-Guide_Allwinner_overlays/)
 
Most in-circuit and GPIO based interfaces (SPI, I2C, I2S, …) don’t have a mechanism for detecting and identifying devices connected to the bus, so Linux kernel has to be told explicitly about the device and its configuration details.
 
While Device Tree is a way of describing hardware configuration to the kernel, Device Tree overlays are a way for modifying the DT in order to provide the kernel and kernel drivers with details about external devices or to activate interfaces disabled by default.
 
What do we want?
 
We want to add Device Tree overlays for the onboard interfaces and tested external devices so that they appear in future mainline Armbian images. This means that activating this type of hardware will not require recompiling the Device Tree or will require compiling just the overlay file which will be compatible with future kernel updates.
 
What kind of help do we expect?
 
We want people to participate in making and testing overlays for the hardware that they have.
Participation requirements:
An A10, A20 or H3 board that can boot the current mainline kernel Serial console adapter for getting the u-boot logs if they are needed Extra SD card to use for booting the nightly/beta images I2C, SPI or I2S (only A10 and A20 based boards since I2S driver is not present on H3 yet) device that you can connect to the board and that requires either generic driver (like SPIdev) or a special driver (available in the mainline kernel), with an exception of custom built boards that don't have commercially available compatible alternatives and devices that don't have in-tree kernel drivers. Some generic Linux knowledge (i.e. how to obtain a dmesg log, how to check file contents) At least a basic understanding of the hardware that you have and how does it integrate into Linux. For example I have no idea how to calibrate a resistive touch screen even if I can write a DT overlay for it. Please note that some hardware limitations (i.e. number of SPI chip selects, missing SPI DMA support) may affect possibility of supporting some devices  
What overlays are already available?
 
Please check the README in the subdirectory for your SoC in the overlays repository: https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian

For the mainline u-boot you have to recompile it with
CONFIG_MMC0_CD_PIN="" added to the config file (or set via menuconfig)
 
For the legacy kernel you have to change "sdc_detmode" in the fex file for your board (kernel code and some FEX files should have comments about possible values for this option)
 
For the mainline kernel you have to remove "cd-gpios" property and add "non-removable" or "broken-cd" properties to the mmc0 node - check Documentation/devicetree/bindings/mmc/mmc.txt in the kernel source for the details.

FDTI/CH341/PL2303 have been added for next mainline nightly build
 

It depends on OS distribution. Debian Jessie based images have only PHP5 available in the default repositories, and Ubuntu Xenial images do have PHP7.

You missed this thread in this subforum and notice on the "Known issues" tab. eMMC currently requires a special installation procedure - u-boot has to be loaded from SD and then transferred to eMMC either by issuing commands from serial console or by editing boot script.

Latest kernels include experimental fbttf modules. I connect cheapest oled screen(128x64px) via SPI to orange pi pc.
Connections:
data - spi0 mosi (PC0 pin 19) clk - spi0 clk (PC2 pin 23) cs - spi0 cs (PC3 pin 24) d/c - PC7 (pin 18) vcc - 3.3v (pin 1) gnd - gnd (pin 6) dts overlay:
/* * adafruit13m-overlay.dts * * based on overlay for RPi https://github.com/kenrestivo/linux/blob/3d61a22b05cbf7ac2f6b620dcd45c2fb49fb9442/arch/arm/boot/dts/overlays/adafruit13m-overlay.dts */ /dts-v1/ /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/aliases"; __overlay__ { spi0 = "/soc/spi@01c68000"; }; }; fragment@1 { target = <&pio>; __overlay__ { adafruit13m_pins: adafruit13m_pins { allwinner,pins = "PC7"; allwinner,function = "gpio_out"; }; }; }; fragment@2 { target = <&spi0>; __overlay__ { /* needed to avoid dtc warning */ #address-cells = <1>; #size-cells = <0>; status = "okay"; adafruit13m: adafruit13m@0{ compatible = "solomon,ssd1306"; reg = <0>; pinctrl-names = "default"; pinctrl-0 = <&adafruit13m_pins>; spi-max-frequency = <6000000>; buswidth = <8>; fps = <20>; dc-gpios = <&pio 2 7 0>; #debug = <3>; rotate = <0>; }; }; }; __overrides__ { #speed = <&adafruit13m>,"spi-max-frequency:0"; #rotate = <&adafruit13m>,"rotate:0"; fps = <&adafruit13m>,"fps:0"; #debug = <&adafruit13m>,"debug:0"; }; }; build:
/usr/src/linux-headers-4.10.0-sun8i/scripts/dtc/dtc -@ -I dts -O dtb -o /boot/dtb-4.10.0-sun8i/overlay/adafruit13m-overlay.dtbo adafruit13m-overlay.dts
added to /boot/armbianEnv.txt:
overlays=adafruit13m-overlay #overlay loading extraargs=fbcon=map:1 #remove fbcon attachement 
after reboot new framebuffer device found (/dev/fb0 on my headless configuration)

Works flawlessly: http://sprunge.us/AOPF

Small typo here.

LTS (long term support) release, so you'll get security fixes for packages for a longer period of time: https://wiki.ubuntu.com/LTS Package base is newer in general compared to current Debian stable (Jessie). Once Debian Stretch is released this won't be true Ubuntu repositories have more packages than Debian

Well, I don't like the theme too, but it's too early to say it for sure (for me) because it may be just because it is new. And it may be possible to install a different skin that is closer to the old one.
 
Functional differences are a different kind of issue. Unread content is confusing and harder to read, but it can be customized a little bit and I see a "Set as default" tick/button. No switch for BBcode view in the editor is another downgrade, but hopefully it won't be needed or can be enabled in admin preferences.

These packages are for default OpenWRT kernel and don't affect the kernel in unofficial Zero builds. Also firmware may be missing for the realtek wireless adapters.

Fixed.

Sorry, we can't support in-place upgrade from any other releases (and even dist-upgrades from much older Armbian releases is not recommended). Just install a clean Armbian image and try to transfer your configuration to the new system.