op1tjaap

Another idea, which might help fighting confusing regarding base choice - Ubuntu / Debian. Currently Armbian would be Ubuntu Xenial and when Stretch is up and ready, Armbian become Debian Stretch. Which base was used for building is noted only in small print. Build script selection between those two is hidden under EXPERT=yes ? 

OK to round it up........ ( trying to wave with a white flag and wearing a blue helmet.....)
 
What I would do with a Zero is. Forget about the driver/wifi/wlan0. What do you expect for $6.99?
 
Run to the nearest Action Supermarket ( or US equivalent) and buy a cheap usb WIFI dongle. I bought one for 3 euro's. Works fine.
This one:
http://domoticx.com/usb-stick-wifi-ralink-technology-rt5370-adapter/
 
[ 4.208943] usb 3-1: new high-speed USB device number 2 using ehci-platform [ 4.418224] usb 3-1: New USB device found, idVendor=148f, idProduct=5370 [ 4.418234] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4.418240] usb 3-1: Product: 802.11 n WLAN [ 4.418245] usb 3-1: Manufacturer: Ralink [ 4.418250] usb 3-1: SerialNumber: 1.0 [ 8.589015] usb 3-1: reset high-speed USB device number 2 using ehci-platform [ 8.832680] usbcore: registered new interface driver rt2800usb Do a little udev magic magic and make a new rule
 
vi /etc/udev/rules.d/75-persistent-net.rules contains:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:13:ef:c5:2d:40", NAME="wlan0 And use nmtui to activate.. Of you go.... and forget about the driver.......
 
 
[  198.551193] wlan0: associated [  198.551371] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready  
 

 

Highly doubt it because of totally different situations - different target audience, different software state to begin with (linux support for generic x86/x64 vs ARM), people buying hardware first (due to its low price) and trying to fit it to their use cases later
 
We are already splitting kernel branches (default/next/dev) and image types (stable/nightly), and this doesn't work in general since people don't get the difference between them.

Added yet another link - directly to "Getting started". @pfeerick I hope words are not too harsh ?

(btw, you don't need to post in BOLD)
 
It is stricly impossible that you got an Chinese Android from Armbian build, and if you had flash the eMMC, this Android should never came up !
So, you simply did NOT succeed to flash eMMC !
 
(... and you didn't answered if you plugged a USB Serial and capture boot log to prove your facts ...)
 
(@op1tjaap is right, you seems to hijack this thread : do you known what dwmac-sun8i driver is ?)

Patience. My response time is currently close to one month and going faster, working more than possible, means risking burn out / mental breakdown, which leads to no response at all for longer period of time. This bug affect all humans and workarounds make things only worse.

If you are using our build scrpit - you already can do that - just use the packaging adjustements we made. And those you did, they look o.k. to me. Well, the kernel branch you are using, might not be bootable? Try first with some stable branch, "known to work kernel". 4.12 and sun8i doesn't look close to fully stable branch.

I'm not sure if anyone is interested in a very small distro without gcc, but I spent some time the last week using buildroot and armbian's source files to create a 3.4.112-rt image for the nanopi neo. It is going to be part of a realtime audio project (think synth or guitar pedal) that I'm working on and it demands a quick boot, among other things. 
 
There is also a mainline version, but it doesn't have all the fixings you folks like, so I don't know if you'd want to use that. 
 
You can find the build scripts and config files on my github. I'll be posting the legacy image in a zip file tonight, once I verify everything is reproducible. 
 
I would like to thank the Armbian developers for all their time and energy doing what they do. Their code and guides have helped me understand how one would even attempt something like this, and I'm very grateful. If you ever use my image, please donate to the Armbian community. 
 
The screenshot is proof that the system works, and how much ram it uses while forwarding a puredata session over X-forwarding. 
 
I'm open to any questions. Thanks. 

And it will look like this (please note the most important difference to crappy boards: barrel plug instead of Micro USB):

 
eMMC is socketed and seems to be the same Pine Inc is using for all their designs now: http://linux-sunxi.org/File:16GB_NCEMBSF9-16G_eMMC.jpg

dwmac-sun8i v6 driver was just merged to net-next and it will be included from 4.13 onwards. So just a 2-3 months away.

Interestingly, it looks like the AppleTalk routing issue is actually an issue in the kernel AppleTalk layer; at some point, it stopped finding the correct socket for broadcast packets received and just went with the first socket with a matching port (ignoring the receive interface's address ranges).  Working on fixing that now... no idea how long that's been in the kernel, though I suspect it's been quite a while.
 
Even if it doesn't involve a new patch, I'll probably still suggest a 2.2.6 release because the latest post-2.2.5 patches are critical to anyone using real AppleTalk.
 
One of these days, I want to make a userland daemon that just runs on BPF for platforms which no longer support AppleTalk natively, especially if it can be made to share metadata with netatalk 3.x.  Alas, I'm short on round tuits...

Not that surprising. IIRC some critical AppleTalk fixes never made it into the Linux kernel. But this has been long ago (IIRC even prior to Netatalk 2.0 release and that was IIRC in 2004). On production machines we tried to avoid Linux back at that time if AppleTalk was involved (only needed for printing any more) so we ended up with Solaris as host, SuSE when trying to use AppleTalk (since their kernel contained loads of AppleTalk related stuff) or an OS X machine accessible through IPP speaking PAP with old printers (printer proxy).

If not done already simply ask on netatalk-devel list. If you prepare the stuff in a finished state I don't believe Ralph has any objections against releasing a 2.2.6 with fixes applied.

No, I don't think he does; I'm mostly planning on submitting it as an SF pull request, which should be easiest to integrate. Given the other patches (which address serious issues with running an AppleTalk server, which is the only reason one would use 2.x anymore) are from 2014, I have to imagine a 2.2.6 release would be useful just as an intended-final release of 2.x.
 
Now that I think about it, I may have conversed with you on the netatalk-devel lists before; I never put the names together. :-)

I don't know of any extant, no. It woudn't be the hardest thing in the world, though doing the DPLL for the serial decoding isn't the most pleasant thing in the world. The PSoC is probably easier to get started on and has easier tools, but the CPLD/FPGA is the "right" way.
 
It's also worth noting that most small micros are way more than powerful enough to do AppleTalk routing at a scale that could handle reasonably large networks. You might find the ESP32 with something tied on to do the LocalTalk decoding to be an ideal platform; it's well more powerful than most AppleTalk routers that existed out in the world short of the high end Cisco multiprotocol routers and such (and even then, it's only smaller RAM, still a faster CPU). But you'd have to write the AppleTalk stack from scratch, most likely. It's something I have way back on my queue whenever I plow through the pile of projects currently on my plate.

I'm also active on mac68k.info (more interested in the low-level stuff the cover, and can't keep up with the forum traffic on 68kmla).  I'm actually working on fixing some of the routing stuff in netatalk 2.2.5+ (several important patches in git from 2014 that never made it into a release, wonder if they'll ever do a 2.2.6); the routing is broken and it's screwing up my home network, which also encompasses a VAX and an Alpha running VMS (with Pathworks for Mac).
 
FWIW, while I like the idea of small ARM boards as AppleTalk routers/MacIP gateways, I wish there was a better way to get LocalTalk signals through. The rather high-speed serial decoding must be super ugly to do on the Linux GPIO layer, but a small CPLD/FPGA or a PSoC or similar might do the trick connected over SPI. Relying on something like an Asante bridge seems just about as problematic. :-)

Few more things to add:
- SPI and eMMC flash optional, not in all/both versions
- those 4 pins are jumpers to switch between power connector and OTG+battery

Ok, let's try to spot the technical details:
 
A64 with 1 GB DRAM A64's single USB2.0 host port connected to a GL852G hub providing 4 type A receptacles USB OTG available as Micro USB port  Gigabit Ethernet using RTL8211E PHY AP6212 providing both Wi-Fi and BT 3 pin debug header IR receiver 24 pin CSI camera connector (most probably compatible to Xunlong's GC2035 2MP camera) 24 pin LCD connector (Edit: due to pinmuxing with RGMII for Ethernet it's MIPI DSI -- 1920x1200@60fps max) 2 buttons, microphone, 40 pin GPIO header, another 4 pin header eMMC possible to be populated but not included in $25 standard offer 2MB SPI NOR flash (according to Aliepxress listing) 4 pin header for 'power selection', board can be powered through 4.0/1.7mm barrel jack, Micro USB (don't do this!) or battery (solder pads on the bottom PCB side) Audio out and Mic in available on 3.5mm TRRS barrel  
The naming scheme points to Win10 IoT and hardware details seem to make it possible to use settings that are compatible to BPi M64.
 

Here are kernel+headers for sun8i-dev with fix applied: sun8i-ethernet-multicast-fix.tgz

Since there is official support for Docker on ARM for quite a while now, this thread is "resolved" to me.
 
@Igor I suggest to update the docs here: https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-run-docker. I opened a PR:  https://github.com/igorpecovnik/lib.docs/pull/5
 

understood. I just ordered the official 2.5A usb PSU for RPI3 from Microsoft Store. Will report back once I receive it.

You are asking for troubles and wasting time by using this kind of PSU. Here you have to do something ... 

What about a little bit of patience? https://github.com/montjoie/linux/commit/43934e114a3a3358a570480c8974e4e52769cd11#commitcomment-21951122

Strange, I can not remember that we ever released Netatalk 2.2.4 or above back then
 
Anyway: glad that it works and I hope you informed @montjoiethat his fix did it? If you can provide a diff I could try to throw the patch to our current sun8i dev sources so you would get both working NBP and all the other improvements (like cpufreq scaling AKA 'performance'  )

Yesterday my 14" Pinebook arrived so I thought I'll collect some already available information. A lot of work still has to be done to get a decent laptop experience with this hardware so this is neither a review nor a stupid Un-Review but just a preview instead.
 
To get the idea about dimensions I added a 13" and a 15" laptop to the picture. Pinebook is wedge-shaped and thickness matches both the 2011 15" MacBook Pro and the 13" from 2015:
 

 
Display size closely matches the 13" MacBook Pro (but of course pixel density / resolution don't match as well as quality: TN vs. IPS and coating -- it should be obvious if you've the 'you get what you pay for' principle in mind but I'm sure we'll see reviews somewhere else where people are comparing Pinebook with Chrome/MacBooks and think they would get the same display quality for a fraction of costs)
 
Last hardware detail: heat dissipation. I've been curious how well the Pinebook's thermal design is and it looks pretty good. This is the moronic sysbench pseudo benchmark calculating prime numbers endlessly and the Pinebook sitting on a pillow to prevent airflow below the case bottom. Throttling settings are rather conservative with 65°C defined as first trip point and only after a couple of minutes the internal A64 SoC temperature reached this value and slight throttling occured (1.15 GHz down to 1.1 GHz, that's a 'difference' you won't be able to notice). So it seems the combination of a thermal pad with a large metal plate inside the case is rather sufficient:
 

 
What you see here is a graph drawn by RPi-Monitor, one of my favourite tools to get a clue what's going on with ARM devices (since it's not a heavy monitoring tool that changes the way the OS behaves but it's pretty lightweight sp you can run it in the background and let it monitor/record stuff like cpufreq scaling, consumption and so on).
 
Pinebook currently ships with a rather clean Ubuntu Xenial on the eMMC with Mate desktop environment based on latest BSP u-boot and kernel. To get RPi-Monitor installed on this Ubuntu @pfeerickprovides a script (please follow progress over there). When I played around with Wi-Fi I noticed that Wi-Fi powermanagement seems to be enabled (makes working via SSH close to impossible) and that MAC address changes on every reboot. To disable Wi-Fi powermanagement I simply used the Armbian way:
root@pinebook:~# cat /etc/NetworkManager/dispatcher.d/99disable-power-management #!/bin/sh case "$2" in up) /sbin/iwconfig $1 power off || true ;; down) /sbin/iwconfig $1 power on || true ;; esac Unless Wi-Fi driver gets a fix to use a MAC address based on the SoC's individual so called SID one way to assign a fixed MAC address for the Wi-Fi is to add a wifi.cloned-mac-address property to all NetworkManager profiles after establishing a Wi-Fi connection first:
nmcli con show | grep wlan | while read ; do set ${REPLY}; nmcli con modify "$1" wifi.cloned-mac-address $(cat /sys/class/net/$4/address); done (I'm pretty sure some masochistic people prefer fiddling around in /etc/network/interfaces instead so if you're not using your laptop as a laptop being carried around and seeing a lot of Wi-Fis you can also use the usual tweaks for the interfaces file. Please also note that using a random MAC address can be considered a privacy feature on laptops since it makes tracking of you in public environments harder).
 
While watching the Pinebook's charging/discharging behaviour I noticed that consumption drawn from wall while charging oscillates between 9W and 15W while being used and display active so it's really great that Pine Inc fixed Pine64's design flaw N° 1: Pinebook is NOT equipped with shitty Micro USB for DC-IN leading to all sorts of trouble but just like SoPine baseboard now uses a 3.5mm/1.35mm barrel jack combined with a 5V/3A PSU (for other hardware details please refer to linux-sunxi wiki page).
 
Battery status (health, capacity, voltage and so on) is already available through sysfs but some values are wrong or need calibration. This needs to be fixed with further upgrades. Also interesting: charging seems to be under control of the ARISC core inside A64 SoC and works together with Pinebook's AXP803 PMIC (powermanagement IC) even when there's no OS running. This will be somewhat challenging to implement later with mainline I would believe...
 
I'll stop here for now since Pinebook is still stuff for developers and not end users. Just some resources for interested parties:
https://github.com/ayufan-pine64/boot-tools (Kamil implemented an u-boot based approach to flash directly to eMMC and there you find the necessary BLOBs to convert other BSP based Pine64 images for Pinebook since different DRAM and other settings require different SPL+u-boot) https://github.com/ayufan-pine64/linux-pine64 (based on longsleep's BSP kernel but with more fixes currently for Pinebook) $mainline resources (I lost track where to find most recent stuff but will add this later)  
Wrt Armbian running on Pinebook we could now simply exchange u-boot+SPL+DT of our Xenial Desktop image... but I hope we won't do that but wait until dust has settled while helping with development efforts in the meantime. In other words: no Armbian on Pinebook (right) now