zador.blood.stained

More precisely delete /boot/script.bin first (it is a symlink) and then recreate the file with fex2bin.

Yep, if you have something like this (from "lspci" output) then inserted SD/MMC cards will be displayed as /dev/mmcblk* and you'll have access to SD/MMC additional partitions, card info in /sys, etc.
08:03.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 08:03.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 08:03.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) The main disadvantage of this is that these controllers need drivers, compared to devices that present themselves as a standard USB mass storage class.
 
Edit: "native" may be not be a correct word in my previous post since this is an internally attached PCI device, the main difference is whether it represents itself as s SD/MMC host controller or a mass storage abstraction, which I'm pretty sure is specific to USB devices.

Or via a native SD/MMC interface on a laptop (tested with SD->microSD->HK eMMC adapter->eMMC setup)

Not to me. USB hub by itself is a very light load but it results in a measurable voltage drop on DC IN. And I have a couple of USB hubs that can reboot a microUSB powered RPi if you connect them - most likely because of a filtering capacitor on the input causing a large enough current spike.

There shouldn't be any issues regarding "working" since Mali binaries are just copied to the package as is, I just disabled building the testing tools package and updated dependencies.

### meminfo: MemTotal: 1024100 kB MemFree: 901772 kB This looks odd. AFAIK the OPi Zero only comes with 256M or 512M.
 
 

Not related to armbian, but I made some work with friendlyarm kernel 4.11.2 for support i2s driver for h3/h5 with support 16/24 bit master/slave mode i2s (link) and build Volumio image for nanopi neo (link). In future I want to get same in mainline kernel.

Not to me. USB hub by itself is a very light load but it results in a measurable voltage drop on DC IN. And I have a couple of USB hubs that can reboot a microUSB powered RPi if you connect them - most likely because of a filtering capacitor on the input causing a large enough current spike.

Not to me. USB hub by itself is a very light load but it results in a measurable voltage drop on DC IN. And I have a couple of USB hubs that can reboot a microUSB powered RPi if you connect them - most likely because of a filtering capacitor on the input causing a large enough current spike.

Because AFAIK snd-soc-dummy doesn't have DT bindings and can't be instantiated from DT, at least without patching (something like this - http://mailman.alsa-project.org/pipermail/alsa-devel/2014-August/080287.html, or like this - https://patchwork.kernel.org/patch/7679391/). 
This
doesn't match any of_device_id tables so your simple-audio-card codec is connected to nothing.

OK, so it tries to open /dev/rtc0 before it is registered. Not sure if there is an easy way to fix this on the kernel side.
You could try putting "hwclock --hctosys" to /etc/rc.local (before "exit 0") so it would try to update the system time later.

... and will never be supported. It wasn't supposed to be buildable at all but the condition was implemented in wrong place.

No, you need to add a slave device to this node. Something like this
i2c@c1108500 { compatible = "amlogic, meson-i2c"; dev_name = "i2c-A"; status = "okay"; reg = <0x0 0xc1108500 0x0 0x20>; device_id = <0x1>; pinctrl-names = "default"; pinctrl-0 = <0x10>; #address-cells = <0x1>; #size-cells = <0x0>; use_pio = <0x0>; master_i2c_speed = <0x493e0>; clocks = <0xc 0xa>; clock-names = "clk_i2c"; resets = <0xc 0x9>; rtc@51 { compatible = "nxp,pcf8563"; reg = <0x51>; }; };  

Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with:
root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.

I have to disagree with a lot of points on that FAQ since I'm monitoring some other forums and see complaints towards Armbian from a perspective of an inexperienced user.
For people that want to use CSI cameras, C or Python GPIO libraries that have questionable (at best) hardware detection by parsing /proc/cpuinfo or want to run Kodi or Android Armbian won't be an answer. For poor souls that bought an OPi 2G-IOT or its lighter variant Armbian won't be an answer either. For boards that (currently) have rather poor mainline support (OPi Win/Win+) Armbian may have more problems than vendor's images.
Please keep in mind that an average person may not care about security or performance optimizations but may want specific software features that won't work on our images out of the box.

DT changes should look like this: https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/32-h3-DT-add-mali-node.patch.disabled

I have to disagree with a lot of points on that FAQ since I'm monitoring some other forums and see complaints towards Armbian from a perspective of an inexperienced user.
For people that want to use CSI cameras, C or Python GPIO libraries that have questionable (at best) hardware detection by parsing /proc/cpuinfo or want to run Kodi or Android Armbian won't be an answer. For poor souls that bought an OPi 2G-IOT or its lighter variant Armbian won't be an answer either. For boards that (currently) have rather poor mainline support (OPi Win/Win+) Armbian may have more problems than vendor's images.
Please keep in mind that an average person may not care about security or performance optimizations but may want specific software features that won't work on our images out of the box.

Feel free to test. Assuming we don't care about breaking pre-initrd btrfs images with old boot scripts it can be switched to module everywhere.

I would prefer to split it into multiple services: a logging service, an optimizing service, a hardware monitoring service, etc.
And instead of reinventing the wheel with zram we could use a systemd-swap service, i.e. this implementation from Arch Linux: https://github.com/Nefelim4ag/systemd-swap
 
This way it would be easy to disable individual components of Armbian that may not be needed or that may interfere with other services (i.e. your "activate_zram" function checks only for zram-config package and it would interfere with systemd-swap installed by users without an easy way to disable it (since any changes to armhwinfo will be lost on upgrade))

While we have time I would propose to split armbian-config from BSP to a separate package since looks like it may need a lot more frequent updates and bugfixes that 2-3 per year, and telling users to switch everything to the beta repo is not a good solution to armbian-config problems because they will install partially broken or incomplete u-boot and kernel builds.

P.S. my friend purchased an OPi R1 and I may help him to make it mainlined ;-)

And for new boards in the future a better solution would be adding a eMMC connector compatible with Hardkernel and Pine boards.

And for new boards in the future a better solution would be adding a eMMC connector compatible with Hardkernel and Pine boards.

I disagree with this for 2 simple reasons:
this device is listed as supported there are prebuilt images for this board Remove all prebuilt images and force users to read documentation and build images themselves and you won't get these types of messages. But instead we are adding new boards, new nightlies and new testing images that are marked as "stable".
 
This will only get worse.

For the legacy kernel it should be set via kernel command line (from boot.cmd or armbianEnv.txt). Mainline kernel uses simplefb driver and framebuffer is set up in u-boot (using EDID or saved environment).
While the legacy kernel will obviously never get a DRM/KMS driver, linux-next (mainline) got the driver a couple of days ago, though Banana Pi didn't get the DT bits so it will need additional patching later.