gounthar

Solved the problem (edited)
Disabled usb gadget service of orangepi zero
`sudo  /sbin/rmmod g_serial`  (edited)
then 
 `sudo bash create-gadget.sh` 
link to solution: https://vjordan.info/log/fpga/nanopi-neo-usb-otg-with-armbian-mainline-4x-kernel.html
 
after `rmmod g_serial` , it can be verified on the host pc by `lsmod`.
 
On the orangepi:
 `ls /dev/hid*`  lists the hid device ports (hidraw1, hadraw2 ... ) and gadget port (hidg0)
 
 

(disclaimer) No itention to make a Frankendebian (https://wiki.debian.org/DontBreakDebian) but ubuntu package "zram-config" works perfectly.
I tested it for two weeks in a: Orange PI Zero 512MB Armbian Stretch 5.40 4.14.18, Orange PI PC2 Armbian Stretch 5.40 4.14.18, AMD Sempron microserver Debian Stretch 9.4 4.9.0-6-amd64.
 
A short tutorial:
 
1. Download zram-config package (it's a universal package, it does not matter the architecture in use)
wget http://de.archive.ubuntu.com/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb
 
2. Install it
sudo dpkg -i zram-config_0.5_all.deb
 
3. Remove the installer
rm zram-config_0.5_all.deb
 
4. Check vm.swappiness
cat /proc/sys/vm/swappiness
(must be 60, default)
 
5. If not (i.e. "cat /proc/sys/vm/swappiness" return "1" ) change it to "60"
sudo nano /etc/sysctl.conf
and add "vm.swappiness=60" at the end of file
... and reboot
 
6. check zRAM service
sudo zramctl

NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo         437,8M  5,2M  1,4M  1,9M       2 [SWAP]
/dev/zram1 lzo         437,8M  5,2M  1,4M  1,9M       2 [SWAP]
 
7. (optional) change lzo compression to lz4
sudo nano /usr/bin/init-zram-swapping
 
# initialize the devices
for i in $(seq ${NRDEVICES}); do
  DEVNUMBER=$((i - 1))
  echo $mem > /sys/block/zram${DEVNUMBER}/disksize
  mkswap /dev/zram${DEVNUMBER}
  swapon -p 5 /dev/zram${DEVNUMBER}
done
 
to...
 
# initialize the devices
for i in $(seq ${NRDEVICES}); do
  DEVNUMBER=$((i - 1))
  echo lz4 > /sys/block/zram${DEVNUMBER}/comp_algorithm
  echo $mem > /sys/block/zram${DEVNUMBER}/disksize
  mkswap /dev/zram${DEVNUMBER}
  swapon -p 5 /dev/zram${DEVNUMBER}
done
 
8. restart the service
sudo systemctl restart zram-config.service
 
9. check new compression algorithm
sudo zramctl

NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4         437,8M  5,2M  1,4M  1,9M       2 [SWAP]
/dev/zram1 lz4         437,8M  5,2M  1,4M  1,9M       2 [SWAP]
 
10. check the zRAM priority over file swap
cat /proc/swaps
 
zRAM devices must be at priority "5", swap file at "-1" or "-2"
 
11. finish
:-)
 
 
 

This is something hopefully suitable to become a 'Board Bring up' thread.
 
The NanoPC T4 was the smallest RK3399 board around featuring full set of interfaces (Rock960 was smaller but there you can't use GbE without a proprietary expander) but in the meantime he got two smaller siblings: NanoPi M4 and the cute NEO4.
 
Pros:
Another RK3399 board so software support is already pretty mature Rich set of interfaces (2 x USB2 without shared bandwidth, 2 x USB3, triple display output and so on) No powering hassles due to 12V (2A) PSU requirement 16GB superfast eMMC 5.1  Usable and performant Wi-Fi (dual band and dual antenna so MIMO can be used, for numbers see here) All 4 PCIe lanes exposed (M.2 M key connector on the bottom, suitable for NVMe SSDs, or to attach a 4 port SATA controller or a PCIe riser card)  
Cons:
A bit pricey (but if you compare with RockPro64 for example and order all Add-Ons you end up with a similar price) High idle consumption (4W PSU included in idle), maybe this is just bad settings we can improve over time heatsink too small for continous loads  
I started relying on @hjc's work since he's currently using different kernels than we use on RockPro64 or ODROID-N1 (though all the 4.4 kernels are more or less just RK's 4.4 LTS branch with some modifications, with mainline I didn't had a look what's different in Heiko's tree and 'true' mainline).
 
Tinymembench numbers with RK 4.4 vs. mainline kernel (the latter both showing lower latency and higher bandwidth).
 
Internal 16 GB eMMC performance:
eMMC / ext4 / iozone random random kB reclen write rewrite read reread read write 102400 4 23400 28554 26356 26143 27061 29546 102400 16 48364 48810 85421 85847 84017 47607 102400 512 48789 49075 273380 275699 258495 47858 102400 1024 48939 49053 290198 291462 270699 48099 102400 16384 48673 49050 295690 295705 294706 48966 1024000 16384 49243 49238 298010 298443 299018 49255 That's what's to be expected with 16 GB and exactly same numbers as I generated on ODROID-N1 with 16 GB size. When checking SD card performance it maxed out at 23.5 MB/s which is an indication that no higher speed modes are enabled (and according to schematics not possible since not able to switch to 1.8V here -- I didn't try to adjust DT like with ODROID-N1 where SDR104 mode is possible which led to some nice speed improvements when using a fast card -- see here and there)
 
Quick USB3 performance test via the USB-3A port:
Rockchip 4.4.132 random random kB reclen write rewrite read reread read write 102400 4 24818 29815 33896 34016 24308 28656 102400 16 79104 90640 107607 108892 80643 89896 102400 512 286583 288045 285021 293431 285016 298604 102400 1024 315033 322207 320545 330923 320888 327650 102400 16384 358314 353818 371869 384292 383404 354743 1024000 16384 378748 381709 383865 384704 384113 381574 mmind 4.17.0-rc6-firefly random random kB reclen write rewrite read reread read write 102400 4 37532 42871 22224 21533 21483 39841 102400 16 86016 104508 87895 87253 84424 102194 102400 512 274257 294262 287394 296589 287757 304003 102400 1024 294051 312527 317703 323938 323353 325371 102400 16384 296354 340272 336480 352221 339591 340985 1024000 16384 367949 189404 328094 330342 328136 139675 This was with an ASM1153 enclosure which shows slightly lower numbers than my usual JMS567 (all currently busy with other stuff). Performance with RK 4.4 kernel as expected, with mainline lower for whatever reasons. I also tried to test with my VIA VL716 enclosure directly attached to the USB-C port but ran into similar issues as with RockPro64 but since my enclosure and the cable also show problems when using at a MacBook Pro I suspect I should blame the hardware here and not USB-C PHY problems with RK3399.
 
This is NanoPC T4 with vendor's heatsink, lying flat on a surface that allows for some airflow below, running cpuburn-a53 on all 6 cores after half an hour:
13:57:31: 1008/1416MHz 8.44 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:40: 1008/1416MHz 8.52 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:48: 1008/1416MHz 8.51 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:57: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 90.6°C 0/5 13:58:05: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 91.1°C 0/5 So with heavy workloads you most probably need a fan to prevent throttling. 
 
Development related questions: IMO we should try to rely on single sources for all the various RK3399 boards that are now available or will be soon. And I would prefer ayufan's since he's somewhat in contact with RK guys and there's a lot of great information/feeback provided by TL Lim. What do others think?
 
Also an issue is IRQ affinity since on boards where PCIe is in use those interrupts should clearly end up on one of the big cores while on other boards USB3 and network IRQs are better candidates. I already talked about this with @Xalius ages ago and most probably the best idea is to switch from static IRQ affinity set at boot by armbian-hardware-optimization to a daemon that analyzes IRQ situation every minute and adopts then dynamically the best strategy.
 
Wrt information for endusers. All RK3399 boards basically behave the same since the relevant stuff is inside the SoC. There's only different DRAM (matters with regard to consumption and performance), different interfaces exposed and different power circuitry (and obviously different settings like e.g. cpufreq behaviour but I think we should consolidate those for all RK3399 boards). So you already find a lot of information in my ODROID-N1 'review', my SBC storage performance overview and most probably also a lot around RockPro64. No idea where to inform about RK3399 GPU/VPU stuff since not interested in these areas at all (hope others add references or direct information).

This bug will hopefully be fixed with today update ... which I am still fixing for other problems. It would be best to try with not updated image yet or some older image updated to nightly.

Thank you for your help! 
 
Edit: Please pay attention to log rotation service. If that works properly. Starting with today update, current is broken.

Hi,
 
Thank you for your interest, you won't be disappointed. You have probably read that the developer want to do some changes - and some of this changes are now ready to get tested in the BETA's of armbian.
 
Do not test with your 'production' SDcard unless you have done a backup ;-)
 
Once done that, please go to 'armbian-config' System  switch to BETA (Nightly), do an update/upgrade, reboot, check if your system still performs as before.
If it does work like before - please let us know and post your 'armbianmonitor -u' link If it doesn't work, please try a reboot, check if the problem is reproduceable and if so  explain the steps to reproduce it and post your 'armbianmonitor -u' link  
If you like to know what has changed or is changing:
Kernel upgrade for Allwinner boards. NEXT is 4.17.y and it's getting daily updates. (LIB_TAG="sunxi-4.18" in our build system)
https://forum.armbian.com/topic/7398-bsp-scripts-rfc/
https://forum.armbian.com/topic/5565-zram-vs-swap/
https://forum.armbian.com/topic/6444-varlog-file-fills-up-to-100-using-pihole/
 
This is not all, see details on GitHub look at the shell code - which makes this happen - more eyes less errors
 
And if you want to try a fresh install, look for the nightly created 17. June https://dl.armbian.com/
 
Thank you in advance for your support
 

not for the NanoPi A64 with armbian - but somebody is working on a kernel 4.4.111 at
http://www.friendlyarm.com/Forum/viewtopic.php?f=53&t=1543

By the way if we start to be numerous to buy the board, it may finally become incentive for someone to design a 3D printed enclosure. I'd prefer a metal one with a thermal pad serving as a heat sink at the same time, but I'd be happy with anything better than cardboard+duct tape...

Any "correct" USB power supply delivering more than 1.5A under 5V will work, though you'll have to make you own cable or to solder the wires. But with good quality USB cables, it will also work via the micro-USB port, because the current drawn by this board is not *that* high. I even power mine from a USB3 connector of my laptop which delivers about 1.6A (it's over spec and that's great for this use case). You really need to test. Some reported 1.2A under 5V. It's only 33% higher than the regular USB3 limit (900mA) and may actually work fine with most PCs or chargers due to large enough margins in the design.

As an experiment i tried running Arch Linux on my NanoPi a64 with 4.15.0-rc5. It's a pine64 image . To my total surprise it works. But it's no Armbian though...

For me it did. On all of my boards (Opi+2e, Opi+2, OpiPC, OpiZero) I was trying:
 
stable "next" nightly "next" Unfortunately it failed (sometimes I was able to get some exceptions in logs, example of one of them is here:
 
 
So I went back to "default" (stable). And on all boards - no issues.

I use this one.

Most likely above  It is already hard to provide support for existing hardware or do any serious development.
 

Majority of current engagement is sponsored by our private resources which means we probably can't expand this project further since it can become more fragile and could collapse. We actually need to step down a bit and from my personal perspective, I need to get few weeks off to recharge. 

Well, all these multi-port chargers never deliver up to the amount they claim. You can safely expect 50 to 66% though, which is not bad overall. I removed the current limit detection in mine to stabilize the output for the MiQi farm. That said, I never managed to pull more than 1.6A in peak from my Fire3 at 1.6 GHz under 1.25V, so you have some headroom I guess. You need to consider that when the board is hot, its DC-DC regulators' efficiency starts to drop and to turn the current into more heat. Thus it's more important to measure the current when the board is already hot if you want to be pessimistic (or realistic). That was the case for me at when I measured 1.6A. Quite frankly, you're worrying too much : if when loading all the boards it still works, that's fine. If you want to buy more boards, then buy them and plug them to your charger until you find the limit. The charger will either cut one port or completely shut down. Then you'll know how many more chargers you need to buy depending on the number of boards :-)

I now have quite a few of these boards running and I am powering them through Anker mulitport usb charging hubs and all seems well.
 
This might be more of a general Armbian question but if I wanted to verify that my boards aren't experiencing any undervolting, is there a log file that I can look at?
 
I am just being cautious now - everything seems to be running in tip-top shape with no issues.

You are right ... and out of luck for now:
https://github.com/armbian/build/issues/1003#issuecomment-394987272
 
you could try a recent nightly build:
https://dl.armbian.com/orangepizero/
 
One BananaPi running a recent kernel (Armbian 5.45 / kernel 4.17.0 rc7) has been up and running for 12 days now ...

Take a look at this example:

https://github.com/igorpecovnik/iot

First of all thank you all for this wonderful project!
 
And thank you for tracking down this issue. I had deployed two banana pi pros and hat always this issues (freeze without logs). I tried all usual troubleshooting (power, sd card, ...) but nothing resolved the issue. The only fix for me was to downgrade (i'm using the mainline debian server version)  as a few post earlier suggested (THANK YOU). Both pis are now running stable for more than 14 days  on old kernel bananapi 4.11.5-sunxi #3 SMP armv7l GNU/Linux. I'm really happy because this made me mad, as they are both remote devices that became unresponsive after a 1-4 days. 
Somehow it strange because I'm running also a third pi with the latest (not nightly)  Linux bananapi 4.14.18-sunxi #24 SMP armv7l GNU/Linux version, this one with attached SATA disk and it is working fine for month. I'm doing a daily reboot (which didn't helped with the other two pis) and the system is under heavy load. The two pis (that do not work stable with the new kernel) do not use the sata connector, one of them uses a usb disk and the other pi is running without any external devices attached.
Maybe this may help on tracking the issue.
 
 
Here are the commands that I've run to downgrade the kernel on for the banana pi pro
 
apt install linux-image-next-sunxi=5.31 linux-dtb-next-sunxi=5.31
apt install linux-u-boot-bananapipro-next=5.31
 
run armbian-config and configure that new kernel updates are ignored for the time being as this issue is resolved
 
 

Have a look at this:
https://forum.armbian.com/topic/6386-lime2-mainline-kernel-with-debian-9-stretch-becomes-unresponsive-forced-reboot-required/?page=2&tab=comments#comment-55225
 

Just so you don't waste your time, this kernel version does not support composite video output anyway.

Well I added a tiny, cheap fan running off the 3.3v pin in conjunction with the included heatsink and thermal pad. At 100% CPU load I am getting a very stable 58-59 degrees C according to armbianmonitor. This is with an ambient room temp of about 23 degrees C.
 
It's like night and day compared to the heatsink alone. I guess these boards really like to have a fan. So if anybody out there wants to run their board hard - get a fan asap!

Proposal to introduce a new BOARDFAMILY based on MT7623n SoCs. The only (widely) available board currently is the BananaPi R2 build by Sinovoip. I 'tried' to clean and split their BSP into different repos to make it usable for armbians Buildscript. The 'initial' work is done and built images boot up (with some additional work).
 

(found one on http://www.banana-pi.org/r2.html - hidden in the 'gallery photos' which looks like the revision I have)
 
 
Some specs (and just to be clear here, this is not a in-depth description about performance of those interfaces, there are more experienced people for benchmarking interfaces etc. don't hang me when there's a mistake in the description ):
MT7623n (ARM Cortex-A7 quad core) GbE over MTK7530 (1x "wan" 4x "lan") 2x USB 3.0 and 1 USB 2.0 otg port 2x SATA over asm1061 (up to) 2 mPCIE interfaces (one populated as mPCIe, the other is muxed with USB3 - you've to disable USB if you want to use it - never tested) Hardware NAT & cryptoDEV (also none of them is tested in my builds made with armbians Buildscript) wifi/bluetooth combo-chip (b/g/n / 4.1) HDMI Powering over 12V barrel jack  
Pros:
relatively cheap (~90$ Aliexpress) Metal case and 4G modem available (I dont' own both - so must be considered as 'not working' at the moment) 2x2 MIMO WiFi should be possible over mPCIE (as before I didn't test it) MT7623 gets relatively good upstream support by Mediatek in mainline There is a 4.14.y Kernel (currently at 4.14.42 - so it seems to be quite up-to-date) maintained by 'Frank-W' which gets frequently updates and patches from upstream are back-ported (more experienced kernelhacker have to decide if he does it in a sane way or not, that's over my skills)  See https://forum.armbian.com/topic/7296-bananapi-r2-csc/?do=findComment&comment=55245  the board has some nice features either as a NAS or a routerboard (I know about the concerns of mixing router with NAS capabilities and I didn't benchmark one of this features - better let people benchmark it which know what they're doing ). It seems that Sinovoip starts to clean up their GitBook mess by switching to a wiki. There are still things wrong inside (e.g. the board-picture shows a battery connector but it was removed in the newer revisions of the board, still a lot of stuff linked to sources not provided by them self e.g. description of 'how network is implemented), but at least it's not that messy than their former 'gitbook' documentation. Frank-W provides a independent wiki where he documents his efforts and what works with his builds.  U-Boot patches for this SoC are under review for upstream   
Cons:
u-boot is based on a v2014.04 rc1 together with some Mediatek additional stuff with further modification by Sinovoip (and in the end by me which doesn't make things much better). Some cleanup is done (not pushed to github since it's early WIP and I only push it when it works 'somehow' reliable, it fools me quite often cause I'm definitively not a 'experienced' u-boot hacker - cause it's a bit outdated a lot of things changed to upstream and I've to google a lot of stuff to get things working). There are 3 binary blobs needed to boot into U-boot (see picture) and I still don't understand fully what they're doing (as said I'm not a u-boot hacker ) http://fw-web.de/dokuwiki/lib/exe/detail.php?id=en%3Abpi-r2%3Astorage&media=bpi-r2:boot-structure.png  the 'Preloader' differs between eMMC and SD-card, so this needs for sure some 'additional work' for something like nand-sata-install. The 'Headers' are in fact two files (one seems to have he size it should, the other one is to big and get's partly overwritten by the 'preloader', so no idea how sane this is) and it seems that they set some variables to env in u-boot (I simply overwrite them to ensure that they don't do insane things and the board is booted with a bootscript sitting in /boot/boot.scr (currently wip - doesn't work every-time) During compilation of u-boot there are some warnings (I didn't care cause in the end the board boots into u-boot so this warnings are of minor interest to me - it would be possible to build u-boot based on v2014.04 upstream with huge patching, as it is done for a yocto-build by Wolfgang Tolkien here, but his is currently adjusted to yocto and will need some rework to make it usable for Armbian - nevertheless, without the help of Wolfgang, this thread would never came up he gave me a lot of hints here and there to deal with u-boot) There is no kernel defconfig for the R2 nor mt7623n SoC upstream (as far as I understand frank-w made a defconfig based on a 4.9 kernel, based on the evb board - so give him the credits for doing a lot of the hard work ), nevertheless an 'mt7623n-next/dev.config' needs some adjustments.  I think, I pickt more or less all of the SoC relevant drivers after 'a few attempts'...  Currently load a kernel with 'Flattened Device Tree blob' (CONFIG_OF_LIBFDT) does not work (Wolfgang reported similar problems for his yocto builds with the R2, but it should/does work with his evb board) and only 'appended device tree blob to zImage' (I didn't care about the drawbacks yet) works yet. Probably this needs some adjustments in builddebb (at the moment this is done by hand with 'cat zImage *.dtb > zImage-dtb ). U-boot 'should' be capable of booting a with a separate dtb file but it doesn't...   The EVB can also be booted with FIT images but this seems also not work on the BPi, maybe it's related to the binaries, maybe I got fooled by u-boot once again (it happened a lot). I simply don't know. From a support point of view: This board has a bunch of features which people will mix together (from router/NAS/'home cloud' up to HDMI capabilities) for a relative affordable price, so 'less experienced' people will buy it, will mess with it and will ask here a bunch of questions when we decide to build images or have it as .csc in armbians repo. Cause it will introduce a new boardfamily (probably *.csc only at the moment) this board doesn't get any kernel updates until the maintainers decide to add it to armbians apt server and if we do, it's more than csc and people will expect 'some support'. I only did the 'initial work' so, a lot of kernel module adjustments, u-boot cleanup and enhancements are needed to build useful 'Armbian images' and to be clear: I'm not willing nor able to do all this work alone. In case no serious developer is willing to join this 'clean up' party, we should not add this board to .csc cause it will end similar to the OPi-2g-IoT where people ask from time to time for support whereas nobody works actively to enhance the Images.  No LTS-Kernel due to 4.14 has a lot of back-ports inside which might mess up things in case a other member of the same SoC will join the boardfamily. 4.19 will be the first LTS which we might use for this board Edit: just in case somebody asks, as far as I know HDMI is not working yet on 4.14 and only usable with the 4.4 BSP kernel, I played some days with it, tried to fix things, I failed, I got headache from the BSP-Kernel and decided to drop it fully. From my side, there will be no efforts in the BSP Kernel to get it working. If someone wants to deal with it, there's a 'kernel only' repo on my github fully 'unmaintained' not patched and currently not available as buildoption. I think people who are able to fix issues for this kernel are able to add it as buildoption but I decided to not deal with it.  
So to summarize, what's done, what works and what's not working (everything not mentioned here must be considered as not working!):
Next Kernel (4.14.y) builds without issues, the devicetree blob is attached after its manually (mount image --> cat zImage *dtb > zImage-dtb) Will not longer be supported by my builds. U-Boot was slightly adjusted so that it is capable of booting zImages, is able to handle ext4 FS & getting it's bootscript from /boot/boot.scr. This needs still some rework for accessing eMMC due to not working 100% reliable with freshly built Images (the first boot is done by manual u-boot commands, probably due to something gone wrong with the bootscript, after recompilation of boot.cmd onboard, the board boots up automatically without manual u-boot hacking) SATA devices are recognized, ETH was only tested once and didn't work (I guess, some adjustments in NM are needed or I missed something, cause the board is mostly connected only via UART during testing I didn't spend much attention to it (this might be a goal as soon as the board boots up reliable even on the first run). Onboard wifi will for sure not work, cause I don't pack the driver binaries to it (I don't care about wifi yet, and there are IMO more important things to fix before I even set onboard wifi to my 'issues list'). Will most likely never be supported due to 'mainline only' and I will not implement an android wifi driver into the mainline kernel. dmesg (for next) spies some errors related to USB (xhci-mtk 1a1c0000.usb: fail to get vbus), this was solved upstream, from what I see frank-w applied the patch too for his 4.14-main branch but it seems to not work properly yet on my builds. Maybe I missed some 'USB quirks' for a kernelcommand, maybe I missed a module or something else - I didn't read all the posts related to it and I don't follow all the stuff on BPis forum to get informations. Keep in mind, I'm not super experienced and this is early WIP (I fully understand why the maintainers don't want to waste much time with new SoCs, it's a bunch of work and if it's not well documented things are even worse). Dev (Linus master branch) will not be properly packed due to changes in builddebb (a slightly adjusted mt7623n-dev.config based on frank-w 4.16 defconfig is there but completely untested, it build's without fails but I never booted a dev image - wouldn't be surprised that it will not boot). 4.17.0-rc7 based on multi_v7_defconfig slightly adjusted to bring up the device but still a lot of 'clean up' needed.  
Disclaimer: 
If you're smart enough, you'll find part of this initial work on GitHub (if not, it's probably better that you don't play with it, cause it's only initial, and Images built with this configuration must be expected as early experimental, for testing purposes only). Some of the adjustments living only on my buildmachine as patches and aren't pushed upstream yet (call it lazy, call it I want avoid that unexperienced people clone the repo build images and complain that they don't work as expected, I don't care)...  Every support question related to 'why is *random feature* not working' will be happily ignored. I'll share my experience only with people who want to contribute to enhance things at the moment not to use it for 'home' ore 'productive' use-cases (it's a way to early for that). 
 
It's not armbian, it's just a Image created with armbians buildscript at the moment:  
 
 
This thread should give the maintainers and interested people a clue what's needed to get this board up with armbian. Some Initial work is done (we don't need any FAT partition anymore, we can start the board with bootscripts) and some current limitations (appended device tree blob, binary blobs for boot, u-boot needs cleanup etc.). I think with the initial work I did, a new 'board bring up' (as the socialists in germany would say `Ergebnisoffen`  open-ended) make sense. In case it ends like the last BPi R2 board bring up thread, where people were more focused on personal insults, and people start to throw dirt to each other, I'll remove all the work I did on GitHub and close this thread! You've been warned! Some initial work is done but more is needed before I'll even consider to send a PR to Armbians repo. I would be really disappointed when somebody fork my initial work and puts then 'Armbian for BPi R2' on some services like google-drive or mega (if you want to enhance the support for it, just send PRs to the repo, it helps nobody if you make some 'experimental' builds based on the initial work and give them to inexperienced users to test, the images are simply not ready yet).
 
So happy discussion (with valid arguments)... 

Nope, that's just a random number and there's absolutely no need to obfuscate random numbers. Same with the HW address of Ethernet (derived from the SoC's SID but linux-sunxi devs discovered that they have to change the algorithm recently so MAC adresses will change sometimes in the future anyway).
 
Thanks for the nice picture but I prefer avoiding in vendor forums but the original version of this information and to use one single source for all sunxi devices: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero#Expansion_Port

The MAC address of your wifi port on your Orange Pi Zero probably starts with C8:27:A7:F9:xx:xx 
I obsfucated the last 4 digits of mine.
 
The Ethernet Port MAC starts with : de:ae:b8:d7:xx:xx
 
I needed this when I was trying to find the device on my network to SSH in.
 
root/1234
 
It showed up on my network as a reasonably "fast" device with 0ms lag.  I'm running a Cat 6 network with a gigabit switch.
 
A nice pinout that Linux34 from Orange Pi posted.

 
 
 

Why should we?
 
To you? Maybe. To others? Maybe not. Especially for people who may need to do development and not just use images already made by others.
 
And why should we work on improving that?
 
But why don't you try this also?
 
 
Since we received more support requests than actual board bring up threads I'm locking the "Board Bring Up" subforum. If somebody posts a proper bring up worthy thread any moderator or developer should be able to move the thread there.

It's stupid to combine routing/firewalling with NAS and multimedia stuff on the same device. On a router/firewall you do NOT want to increase attack surface by unnecessarily running any unneeded services (especially no graphics stuff). Also you usually do NOT want to expose your NAS to the whole world (security best practices).
 
Have you ever seen a RealTek SDK? Yeah, me neither. The W2 is a 'closed source' thingie (running Android and a chrooted OpenWRT/Linux inside) and the R2 might maybe supported sometimes in the future if mainline kernel support evolves and someone wants to spend his spare time on a questionable device (again: you do NOT want to combine routing/firewalling with NAS and multimedia stuff on the same device)