guidol

Great job that you tried to do this.  As you can see there are still a lot of obvious problems and mainline is not yet useful on this board. Not even for simple cases since its lack of network support. Wens made progress on this, so you can try even more complex job by adding few of those patches to userpatches/kernel/sunxi-next and recompile the kernel. Monitor debug/patching, adjust patches if necessary ... Patch is downloaded from Github by adding .patch to the commit URL, for example:
https://github.com/wens/linux/commit/48f1bef6c0b43defca07edd4d6e1962f272fe9d6.patch Have fun!

chmod -x /etc/cron.d/armbian-updates should fix this.

In the end, what worked for me:
 
0: my system: "ARMBIAN 5.35 user-built Debian GNU/Linux 8 (jessie) 4.13.16-sunxi" (called next)
1: I am not going to try using the touch layer.
2: wire things as described (with LED directly on 3.3V)
3: aptitude install linux-headers-next-sunxi
4: copy the content of "Configuration for the first spi bus" from initial post, except last line about EOF, into /root/myili9431.dts
5: armbian-add-overlay myili9431.dts
6: edit /boot/armbianEnv.txt and edit this line (some parts may be useless or overkill) overlays=usbhost2 usbhost3 spi-spidev spidev myili9431 (this appeared to be useless)
7: reboot
8: modprobe fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1
... and immediately the LCD turned from all white, into classic console (black background with prompt at the top)
 
Here is my dmesg:
 
[ 166.951033] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 166.962129] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 166.967576] fbtft_device: GPIOS used by 'fb_ili9341': [ 166.967602] fbtft_device: 'dc' = GPIO3 [ 166.967627] fbtft_device: 'reset' = GPIO0 [ 166.967649] fbtft_device: 'led' = GPIO6 [ 166.967703] spi spi1.0: fb_ili9341 spi1.0 16000kHz 8 bits mode=0x00 [ 166.983929] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. [ 167.341354] Console: switching to colour frame buffer device 30x40 [ 167.344793] graphics fb0: fb_ili9341 frame buffer, 240x320, 150 KiB video memory, 16 KiB buffer memory, fps=20, spi1.0 at 16 MHz https://kaspars.net/blog/linux/spi-display-orange-pi-zero mentions rotate=90 ... could be usefull for someone
 
9: xinit worked immediately

It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
 
In case that somebody is interested, I recently bought couple those displays from here
 
Few basic informations:
 
1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
5. My electrical setup (keep in mind it's 3.3V)
 
OPIZ - LCD (ili9431)
PA13 - CS
PA14 - SCK
PA16 - SDO
PA15 - SDI
PA03 - DC
PA00 - RESET
PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
 
And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
 
OPIZ - LCD (tsc2046)
PA10 - T_CS
PA18 - T_IRQ
PA19 - T_CLK
PA11 - T_DIN
PA12 - T_DO
 
Configuration for the first spi bus:
 
Configuration for touchscreen driver:
 
Compile and add those DTS with "armbian-add-overlay" command.
Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
# mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
Loading modules at startup:
# cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
 
I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal

 
 

Hi there,
I've been contacted by KoVu Inc. regarding their RK3328 "SwiftBoard", which should be a great candidate for NAS applications. Any thoughts?
 
https://www.board-db.org/news/2018/01/08/kovu-swiftboard-data-nas-single-board-computer-sata-hdmi-2-0-emmc-gbe-android-armbian-openmediavault/
 
P.S.: I should receive a sample of this board in the next weeks, if you're interested in further updates.
 
Cheers!

Yesterday I came across the following - for me - fine project (Demo-Page):
ESPTERM Release 2.3.0 Cricket
https://espterm.github.io/term.html
 
GitHub-Page:
https://github.com/espterm/espterm-firmware
 
Downloads:
https://github.com/espterm/espterm-firmware/releases
 
Its a VT100-Webpage-Terminal on a ESP8266-Microcontroller which opens a Accesspoint.
You could connect via this VT100-Webpage-Terminal to the TTL-Port of the ESP8266.
 
TTL-Connection is done (like allways in TTL-Connections) with RX,TX and GND
 
I connected my Orange Pi R1 via TTL and 115200 Baud and could "work" at a (max.) Terminal-Size of 80x25
(80x25 is max. in the downloadable binary - if you do compile by yourself mor is possible.... 132x50 would be fine )
 
So if you have a misconfigured Network-Connection (missed the /24 in the IP of the server in nmtui) and you dont want to use a USB-serial-Dongle because every Dongle wats its own driver  - here a second solution

That was the trick! Added a pull up resistor to AP-RESET# it was enought. The boards are booting now. Starting boot at least  
I'll have to modify few things I guess

You could try to use the info from the following thread:
- edit  /boot/armbianEnv.txt
- change "console=both" to console=display
- save
- reboot
 

cool mechanism.
 
After patching the code, mainline pine64+ seems to be working for me including ethernet!
 
Is it ok to submit that patch as a pull request to armbian?
 
Thanks!
-bob-

Yes. The network is broken due to changes in the upstream kernel driver code. I managed to port this fix to H3 & H5 from 4.15.y while AFAIK A64 is still broken. Perhaps @montjoie know more about this?

did work for me in the NanoPi Neo Core2 thread Thanks igor!

Ok, I updated the boot manager so it is now more portable and added some convenience features as well.
Be aware that it is not beginner friendly, you need at least some knowledge about writing and editing u-boot scripts, Uart cable is not needed but can be useful during testing and setting up.
I rewrote the script in python using curses so It's now more elegent (in my opinion anyway) I tried to get it as close as I can to look like grub2 interface:

Now let's explain How it works:
First, the sdcard must contain at least two fat32 partitions:

-First partition(fat32) (label=RECOVERY) content:
This partition contains the main boot manager files:
1-aml_autoscript is the script that is used to update the u-boot environment to allow for our method to work
2-dtb.img a dtb file, make sure to replace it with the appropriate one for your device I compiled it from coreelec source https://github.com/CoreELEC/device-trees-
amlogic
3-Image is the kernel image of the boot manager
4- multiboot.script is the script that is executed to display the boot manager
5-update.zip use this in your update app in android to flash the aml_autoscript above and make the bootloader ready for our boot manager
 
 
-Second Partition(fat32) (label=BOOT) content:
This partition contains at least the config.yaml file that contains general settings for the boot manager and the boot entries to be listed.
Mote that I have a folder(multiboot) that contains the boot files for my distros(kernel,initrd,dtb and boot script) you don't have to put them in this partition you can put them anywhere (another partition on the sd card, a USB drive or even in  the internal EMMC) just make sure to have the correct path and device id for them in the config.yaml file.
Also If you want to use the remote control instead of a keyboard to select the os place the correct remote.conf of your remote in the root of this partition.
 
the structure of config.yaml is like this:
generalSettings: default: 5 rememberboot: true timeout: 10 menu: - bootscript: /multiboot/COREELEC/u-boot.script device: mmc 0:2 devicefs: fat name: COREELEC - bootscript: /multiboot/armbian-3.14.29-mate/u-boot.script device: mmc 0:2 devicefs: fat name: armbian-3.14.29-mate - bootscript: /multiboot/dvb_test/u-boot.script device: mmc 0:2 devicefs: fat name: dvb_test - bootscript: /multiboot/kernel-3.14/u-boot.script first you set the general settings:
- timeout: this is how many seconds the boot manager should wait before booting into the default boot entry
- default: this is the zero based index of the default distro that the boot manager will boot to after timeout, note that index 0 is reserved for the internal EMMC boot so your menu starts at index 1.
- rememberboot: if this is set to true then the manager will remember the entry that you selected and save it's index in the default entry above so the next time you boot this will be your default entry.
 
after that you add your menu entries:
- name: is the name of the distribution displayed in the boot menu
- bootscript: this is the path of the bootscript of the distribution (note that this boot script should be capable of booting the distro on it's on, so it must have the correct path of the boot files and pass the correct root parameter to the kernel, see the example u-boot.script files that are included in each distibution)
- device is the device that contains the bootscipt using u-boot format so the first mmc and second partition would be mmc 0:2 , the second mmc and third partiton would be mmc 1:3 .
- devicefs is the filesystem type of the above device, this is usually fat because most of these tv boxes support loading files of only fat32 partitions (except some boards like khadas vim and odroid whose bootloader support ext4 partitions)
 
now let's see an example of a disto bootscript:
 
this the same bootscript that was shipped with balbes150 image I only edited the device to mmc 0:2 because this is where I have my kernel and other boot files, also I prepended the correct path before each file name.
In the uEnv.ini file of this distro I edited the root parameter to use a partition labeled "Debian-3-xfce" and created that partiton using gparted
 
 
I prepared a boot image that contains the boot manager and two distibutions, Coreelec and Debian server.
download the image here and burn it to a new sdcard then use the update application in android and update using update.zip, after that you'll see the boot menu after the reboot
https://drive.google.com/open?id=1dhpcqNrqbW493SK8J_Er9b-ZipJkTfd3
 
 
Below is the old method
 
Hi,
This is my quick and dirty solution to multiboot any amlogic device(actually it can be used on any device that uses u-boot with slight modification):

 

***Warning: the following method was only tested on one device which is KII PRO, I made this method for my own use ,it is a long and a bit complicated to setup for non-experienced users if you want to try it you are trying it at your own risk, I take no responsibility for any damage that may occur to your device.
 
 
 
Preparing the sd card for multiboot:
1- Download the zip file from the attachments multiboot.zip
2-wipe everything in your sdcard (i used a 16 gb card) and create 2 partitions:
-The first one is a fat32 partition, this can be small partition (for me i made it 1gb) it will contain the boot files for the main multiboot system and for any other distributions,i labeled this partition "BOOT".
-The second partition is ext4 partition which will contain the rootfs of your distributions in raw image format, this need to be a big partition i suggest you assign all remaining available space to this partition, also you need to label it "ROOTFS" (this is mandatory).
you can use whatever tools you want(gparted,fdisk...etc)
 

 
3-mount the partitions and extract the zip file to the root of your boot partition(the fat32 partition) and create an empty folder called ‘multiboot’ inside the root of the first and second partitions, so the first partition content should  look like this
▶ tree . ├── aml_autoscript ├── aml_autoscript.zip ├── multiboot ├── config.txt ├── dtb.img ├── s905_autoscript ├── s905_autoscript.cmd ├── umbInitrd └── zImage and the second partition should look like this
▶ tree /run/media/mohammad/ROOTFS/ └── multiboot the ‘multiboot’ folder in the first partition should contains folders with the name of the distro and inside them are the bootfiles of that distro(kernel,dtb,initramfs and s905_autoscript file) the ‘multiboot’ folder in the second partition should contain the same folders as in the first partition and inside the folder there should be an ext4 image of the rootfs of the distro
4- The dtb file i used is for kii pro tv box and you should replace that with the dtb of your device, you can get that from any of balbes150 distributions(3.14.29 kernel).
 
Now you'r ready to boot, all you need is some distros
Preparing the distros:
You can make a partition for each distro on your sd card and use it to store the rootfs but i chose a more portable solution by making a raw partition image for each distro and pass it to the initramfs to be mounted as a loop device.
I will be using one of balbes150 distros as an example (Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_mate_20170907.img.xz)
1-First extract the file 
▶xz -k -v -d Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_mate_20170907.img.xz 2- Now mount the resulting file partitions to some directories, I use kpartx to do it for me automatically
▶sudo kpartx -av Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_mate_20170907.img add map loop0p1 (254:0): 0 262144 linear 7:0 2048 add map loop0p2 (254:1): 0 8812544 linear 7:0 264192 now mount the loop devices (i use udiskctl)
 
▶ udisksctl mount -b /dev/mapper/loop0p1 Mounted /dev/dm-0 at /run/media/mohammad/BOOT1. ▶ udisksctl mount -b /dev/mapper/loop0p2 Mounted /dev/dm-1 at /run/media/mohammad/ROOTFS1.  
df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 2.0G 215M 1.8G 11% /run/media/mohammad/BOOT #this is my sd card #1 partition /dev/sdb2 13G 6.8G 4.8G 59% /run/media/mohammad/ROOTFS #this is my sd card #2 partition /dev/mapper/loop0p1 128M 53M 76M 42% /run/media/mohammad/BOOT1 #this is the mounted distro image #1 partition /dev/mapper/loop0p2 4.1G 2.9G 1.1G 75% /run/media/mohammad/ROOTFS1 #this is the mounted distro image #2 partition
 
3- create a folder with the name of the distro in the multiboot folder you created earlier (in the first and second partitions of your sd card) then copy all the boot files of your distro to the folder in the first partition
▶ mkdir /run/media/mohammad/BOOT/multiboot/armbian-3.14.29-mate #this is the first(fat32)partition ▶ mkdir /run/media/mohammad/ROOTFS/multiboot/armbian-3.14.29-mate #this is the second (ext4) partition ▶ cp /run/media/mohammad/BOOT1/* /run/media/mohammad/BOOT/multiboot/armbian-3.14.29-mate/ 4- now you need to create an ext4 partition image to contain the rootfs of your distro for me I made a 4GB image
fallocate -l 4G system.img mkfs.ext4 system.img  
5-mount the image
 
▶ sudo losetup $(losetup -f) system.img ▶ udiskctl mount -b /dev/loop1 Mounted /dev/loop1 at /run/media/mohammad/71545ae9-33c7-4d99-963e-a5a915464078. 6-copy all the files from the rootfs of your distro image to the newly created image
 
▶ cp /run/media/mohammad/ROOTFS1/* /run/media/mohammad/71545ae9-33c7-4d99-963e-a5a915464078/ UPDATE: edit the "/etc/fstab" inside the system.img file
nano /run/media/mohammad/71545ae9-33c7-4d99-963e-a5a915464078/etc/fstab and comment out the lines that start with "LABEL=ROOTFS" and "LABEL=BOOT" by adding a hash at start of each line
then add these lines to the file :
/dev/mmcblk1p1 /mnt vfat defaults 0 2 /mnt/multiboot/armbian-3.14.29-mate/ /boot none bind this will fix the 0hdmi.service problem
 
 
7- unmount everything
 
▶ umount /dev/loop1 ▶ umount /dev/mapper/loop0p1 ▶ umount /dev/mapper/loop0p2  
8-copy the system.img file to your distro folder in the second partition of your sd card
▶ cp system.img /run/media/mohammad/ROOTFS/multiboot/armbian-3.14.29-mate 9- move to your distro folder in the first partition of your sdcard:
 
▶ cd /run/media/mohammad/BOOT/multiboot/armbian-3.14.29-mate  
10- now you need to edit the s905_autoscript.cmd file ( I use nano editor, you can use any text editor you like), you need to make two types of edits in this file
  - add loop=${mbpath}/system.img to the kernel arguments
  - add ${mbpath}/ before each of uInitrd, zImage and dtb.img
so this
 
 
becomes this
 
 
Note that I removed the lines of booting from usb to decrease the boot time because I know that I’m booting from the sd card, you can leave them if you want.
 
11- compile the script
▶ mkimage -A arm64 -O linux -T script -C none -d s905_autoscript.cmd s905_autoscript 12-copy the dtb file of your device
▶ cp dtb/gxbb_p200_2G.dtb dtb.img  
Modifying u-boot and booting:
insert the sd card in the tvbox and then go to the update and backup app and select zip file to update from and choose aml_autoscript.zip that is on the root of the sd card, the device should reboot and you should now be able to use the multiboot function
 
UPDATE: after booting into the distro disable the resize2fs service using the following command
 
sudo systemctl disable resize2fs Notes(mostly for other developers):
1-I’m a very bad shell programmer, I mostly used snippet from stackoverflow to write the main script (bin/wselector) if you could improve the script or anything in my method that would be appreciated.
2-boot time is very good but there is always a possibility to improve it, somethings that I can think of are:
-buiding a smaller kernel by disabling everything in the kernel except for the framebuffer,mmc and nand driver, fat32 and ext4 filesystem,unfortunately whenever I disable something in the kernel it fails to build
-maybe building a minimum dtb file so that the kernel doesn’t spend time initializing peripherals we don’t need.
-building all binaries in umbInitrd staticaly
 

I think - you have to replace here eth0 with usb0
The following page is for the Raspberry, but could also help your OPi with the /etc/network/interfaces or the configuration within windows:
https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget/ethernet-gadget

Which image? Did you realize that Armbian currently neither supports Core nor Core2?
 
If you use an image with eMMC support (eg. those for NEO Air) it should just work, if you use any image without eMMC support (eg. those for NanoPi NEO) it can't work.

Thanks  it worked!

Thanks, guidol.  I managed to get it working.
 

fixed.

Thanks also to you  after defreeze and apt update & upgrade
ARMBIAN 5.37.171221 nightly Debian GNU/Linux 9 (stretch) 4.14.8-sunxi64
Linux opi-zeroplus 4.14.8-sunxi64 #68 SMP Thu Dec 21 12:52:19 CET 2017 aarch64 GNU/Linux
 
eth0 and wlan0 is available:
root@opi-zeroplus:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.6.98 netmask 255.255.255.0 broadcast 192.168.6.255 wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 12:01:23:9c:8f:43 txqueuelen 1000 (Ethernet)  

https://github.com/armbian/build/commit/8be38fc4a0c619d0204a78f3fecaab3c7cf8d233
It works now but forget to check wlan0
 
Thanks!
 
Beta repository updated with this fix.

We are already a few users of this board. We believe that it already has enough potential for support. I myself have managed to install armbian W.I.P, community on the 512mb of NAND of this card and works well.
Thanks

Already it is possible to see and write in NAND memory from linux, I have left a small guide (in Spanish,  use google translate) to be able to experiment with its use:
Http://surfero.blogspot.com.es/2017/08/orange-pi-iot-2g-trabajar-con-la.html
At the moment it has not been able to make linux boot from nand but mount it. Everything has been made possible thanks to the work of the gitub aib user (https://github.com/aib)
 
Dmesg:
[    0.692321] NAND device: Manufacturer ID: 0x98, Chip ID: 0xac (Toshiba TC58NYG2S0H 4G 1.8V 8-bit), 512MiB, page size: 4096, OOB size: 256
 
fdisk -l:
 
Disk /dev/mtdblock1: 8 MiB, 8388608 bytes, 16384 sectors
.........
..........
Disk /dev/mtdblock4: 280 MiB, 293601280 bytes, 573440 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

 
 
 
 

..and I would also thank @bozden for contacting OrangePi.com.tr in native turkish language ;-)

The problem with the Molex male power connector was solved with a soldering iron :-)) - the male power connector at the end of a sata power cable was replaced by a female one - a not so difficult task, since the pins can be removed from the female connector.
 
If there is some interest in these enclosures, I will try to find a company to produce and sell them (with an obligation to donate 1 USD/ 1 EUR to Armbian per housing sold). 

I didnt know that the Orange Pi One can boot from USB
But at the Boot-log I did read "scanning bus 0 for devices - 4 USB device(s) found
Could you try to boot from MicroSD-Card when only connect a Keyboard/Mouse (NOT a USB-Hub or any other storage device)?
(Did you "eject" the MicroSD-Cards via File-Explorer or did you only disconnect the card?)
 
If you are using Windows you could try to write the image with USB-IT (does work fine for me - like etcher 1.2.1):
http://www.alexpage.de/usb-image-tool/download/
 
Did you format your MicroSD-Card using SD-Formater v5  (page url says v4 but its V5) before writing the image?:
https://www.sdcard.org/downloads/formatter_4/eula_windows/index.html
Click accept at the bottom of the page for downloadinf the v5

Yesterday I came across the following - for me - fine project (Demo-Page):
ESPTERM Release 2.3.0 Cricket
https://espterm.github.io/term.html
 
GitHub-Page:
https://github.com/espterm/espterm-firmware
 
Downloads:
https://github.com/espterm/espterm-firmware/releases
 
Its a VT100-Webpage-Terminal on a ESP8266-Microcontroller which opens a Accesspoint.
You could connect via this VT100-Webpage-Terminal to the TTL-Port of the ESP8266.
 
TTL-Connection is done (like allways in TTL-Connections) with RX,TX and GND
 
I connected my Orange Pi R1 via TTL and 115200 Baud and could "work" at a (max.) Terminal-Size of 80x25
(80x25 is max. in the downloadable binary - if you do compile by yourself mor is possible.... 132x50 would be fine )
 
So if you have a misconfigured Network-Connection (missed the /24 in the IP of the server in nmtui) and you dont want to use a USB-serial-Dongle because every Dongle wats its own driver  - here a second solution