chwe

update to 4.14.70 and then it should work
 
https://apt.armbian.com/pool/main/l/linux-4.14.70-rockchip/
 
 

When I copy/pase links from AliExpress or eBay, I always shortening them manually to before the first "?" and check if link still relevant ...

from a quick overview, your PlatformDetect looks... a bit messy.. from what I understand it looks like the following?

 
let's face it.. the majority of your users which use this lib on linux will be RPi users.. the boards are well known, 'cheap' and everywhere available. There are only a few beagles so it makes sense to look at them first before you start with the armbian boards (we support roughly 50 boards).. and if everything fails let the user manually decide which board he has..
 
https://github.com/adafruit/Adafruit_Python_PlatformDetect/blob/672713699e6d21854d65ec8f0d765c8fb125d03b/adafruit_platformdetect/board.py#L85-L87
looks like not that easy to add new boards.. a more general way would be something like:
if self.armbian: etc... for all those RPi thingies something like talking to the threadX would easily tell you that it is a RPi.. no board else will ever talk ThreadX commands.
 
https://github.com/adafruit/Adafruit_Python_PlatformDetect/blob/672713699e6d21854d65ec8f0d765c8fb125d03b/adafruit_platformdetect/board.py#L58-L68
no ESP32 in the future? I don't even buy esp8266 anymore.. The 32 is in a similar price-class and especially for python/micropython a way more powerful..
 
 
IMO your board detection mechanism should look more like this:

 
 
proc/cpuinfo should give you all you need to distinguish between RPi/BB and 'everything else' and from there you can start a proper way of detecting supported boards on armbian.. your code gets messy as soon as you add more boards on armbian...
 
 

Yeah you can integrate wireguard into the kernel, but you can also use DKMS framework to let it being recompiled each time a new kernel is installed.
Wireguard already comes with a small configuration file for DKMS, just follow a tutorial on how to install and setup DKMS on your machine (which is quite easy, just few steps) and register wireguard module and you're done.

assuming that nobody uses it cause you don't use it is kind of.. Clearly  a bunch of people don't use GPIOs. Sarcastically 90% of the SBCs will collect dust as soon as 'it's not funny anymore' so they don't even need an SoC..
As @Igor pointed out.. there are a bunch of SBCs for different use-cases.. Connectors are mostly cheap, so they solder as much as possible on it.. E.g. for the HC1 I would love to have at least an I2C bus and some GPIOs wired out.. (for some DS18b20 ore something like that to monitor the temperature).. If you want performance you'll have to pay for it anyway no matter if there are only a few or a bunch of connectors.. See RK3399 boards..
 
Something else you've to consider.. you need some storage for the bootloader.. Normally those SoCs can't boot directly from SATA.. you either need an SD-Card, eMMC or SPI flash.. Here as well SD-Card is just the 'most convenient' way of doing it. Not much can go wrong and in case it does.. just reflash it.

in case the adafruit people follow this one...
enable i2c etc. can also be done with armbian-config, you don't even have to know how the overlays are named.. @martinayotte  spends quite some time to keep it working with it. even then.. please educate your users to read the related README.sunXi - it's not fun to explain again and again why ds18b20 on one-wire "doesn't work", whereas the proper question should be: how-to configure W1 on different pins. pip on debian is prone to mess up stuff (well in fact the user messes stuff up ), IMO a proper way is to use virtualenv (https://virtualenv.pypa.io/en/latest/) once you got fooled enough by lib dependencies which mess up your python installation on debian and you got it properly working on virtualenv you don't want to go back sudo i2cdetect -y 0 only for debug purposes - happened once to me that it messed with the pmic --> freeze (if I've it right in mind i2cdetect actually warns you that you shouldn't use it when devices are on the bus which are currently running.. check schematics if the wired out i2c aren't used for pmics as well it might lead in funny stuff happening ) if they still sell a bunch of their stuff for 5V and 3.3V (didn't follow adafruit boards for a while) tell your users that GPIOs and i2c on those boards are 3.3V, some 'tolerate' 5V by mistake but I wouldn't count on it.. (at least the W1 pin survived my last harakiri-attempt ) powered correctly and with the right SD card means a quality one for both ('my old phonecharger' is quite often not in this category, similarly: the cheapest SD-Card I found on aliexpress).. Otherwise threads of your users will quite often end here: https://forum.armbian.com/forum/31-sd-card-and-power-supply/  - spread the word Armbian (and the RPi guys since a while too) recommend etcher.io
but one good thing: they link to their 10$ USB-UART cable It's a bit pricey but on this part they might become friends with the Canadians.. 

I would never ever run an VPN server on an outdated 3.4 EOL kernel.. IMO there's no reason to run an OPi0 with the BSP kernel in those days (except 'high temperature issues' known on the OPi0 - I had never problems that the board doesn't run stable, others complained).. For boards with HDMI and desktop this might not be 100% true (yet - soon possible in mainline), but for headless servers just don't...
 
We don't deliver mail drivers for 'server images' and therefore it's not really accessed means 'additional consumption' might be minor. The same counts somehow for wifi, as long as you don't use it idle consumption is anyway not that high.
 
looking into schematics (https://mega.nz/#F!MKQSUIbS!reCl8EK0QqjnOoC-e2ZwBg!dPIzHLaa), you might save a bit by toggle PA20 but I never tested it (the same schematics should also be somewhere on linux-sunxi.org -  just to lazy to google it)..

I tried to 'steal' your patches.. at the moment 'ip a' shows the interface whereas ifconfig has still issues and somehow the interface doesn't come up.. I 'assume' it's currently a networkD issue. but well.. We'll see... A patch series for bringing up HDMI is also on my local repo but I don't feel comfortable to push it cause I've no possibility to test it (I don't even understand why I prepared it cause my interest in it is non-existing and my willingness to debug it in case it doesn't work is below that). Maybe tomorrow.. who knows.

If this is all, we are good considering it was wrote by Swiss and checked by Slovene

Corrected, thanks.

or frozen for cryonics... Well, we may should care sometimes a bit more.. We got this nice little ball with a thin little film of atmosphere for a limited time - means basically we rented it.. Normally you should give back rented stuff in a good shape and don't fuck it up. Not sure if humans are trusted renters... (yep there's a bit of sarcasm in it)
 
It's clear, only the experiment can tell us if those researchers assumptions work. Question is, are those assumptions worth to start such an experiment? Experiments were partly made on animals, for me it was obvious that the 'ultimate goal' will then be to  go to humans as well. Do I think it's a god idea? I assume I didn't thought long enough about it but I tend to say no at all. Genetics is a lottery.. you get it partly from your mother, partly from your father, the whole cocktail is mixed up and then you've to deal with what you got. With such a modification there's a third party involved which might be right or completely wrong with his or her assumptions what should be beneficial for you. There are genetic combinations which don't fit 'well'. E.g. couples with enhanced chances that their kids won't be healthy. Is it fair? I don't think so. Should we try to 'fix' it? I don't think so either... Well, it's easy to say that as long as you're not affected (or at least not knowingly affected) by such a 'mismatch'.
But 'playing' with life before it was even born just sounds wrong to me.
Even a baby can partly express itself if it agrees on certain actions you take as parents. A cell can't - it dies if you messed the cell up too much but otherwise there's no way for the cell to say no to your modification. Okay, there are a few 'repair mechanisms' but I would assume that such a big modification can't be 'reverted' by the cells.
 
[this part is 'a bit' speculative]
At the moment there's only the statement from the researcher claiming what he did, but as far as I followed the news, there's no proof that he actually did it. With proof I mean independent check of his research. It could also be a 'bad joke' - means he just claims he did it. It might need some time until the situation is more clear. In case they did it, I hope the Chinese government may overthink their stand point on genetics. Their laws allows much more than western countries accept but even there, such an experiment was never approved and I assume if the researcher would apply for such an experiment it would be rejected. But their 'more open' standpoint on genetic modification ended in an atmosphere where someone thought he could try it. Maybe they should make it more clear where the "red line" is so that such experiments don't happen again...
 

i've got second gmac working in 4.19 and with some advice from a DSA-Maintainer, i changed it (back) to mdio_device (johns patch uses platform_device).
 
http://forum.banana-pi.org/t/help-for-testing-4-19-on-r2/7339

tried this one?

if the required drivers for mainline would exist... we would already pack them with our images.. so you've to go back to the 3.4 kernel. Either by starting with with a legacy image e.g. with a xenial: https://dl.armbian.com/orangepiplus2e/Ubuntu_xenial_default_desktop.7z

The main porting of second gmac was done by john crispin. There was only a small mistake which we fixed (both cpu-ports need to use same mode).
 
I tried to port it to 4.19,but currently i can't get it working (eth1 is visible but dsa-ports got lost) so i stuck here without any help. I've contacted John,but he tells me he is currently busy and has not the time he need to help me.
 
https://github.com/frank-w/BPI-R2-4.14/commits/4.19-gmac
 
Have contacted dave miller as maintainer of network-part,but got no response yet

Running from eMMC http://ix.io/1rDj

My plan is to reset the kernelconfigs from common base and enable brcmfmac and IR (and ancillary config options) as modules when possible.
Devfreq support and other things were just test bits that can be left out.
 
If AP6330 firmware binaries could make into armbian firmware repository I can remove the copy work in rockchip.conf - I can arrange a pull request myself for that.

hehe had to accept that I can be fired from my mod duties today..
 
btw.
how should we deal with:
 
IMO I'm not a big fan of selling over forum.. In case somebody gets fooled they blame our forum for it. Same counts somehow for ebay links (at least, there's ebay 'in charge').

if you go higher than 60$ anyway, then I would have a look into the RK3399 based ones. Towards 'evil inside'.. it depends on your needs, I assume once HW acceleration on RK3399 works properly they may even beat the Atoms on desktop.. For me desktop means >30 tabs in browser.. No 2GB ram desktop can deal with that.. 4GB ones maybe.. For my work I just had to deal with windows 7 again.. Seems they've a crappy OOM handling there..
 
The preview picture from the RPi thread @Igor posted is an 'industrial grade' board (or at least near to industrial grade). Question here.. do you need it? This guy sent a Odroid C2 2600m deep.. For sure not an 'industrial grade' board:
an OPi Zero (with USB wifi, cause XR819 is crappy) together with a few ESPs currently manage a lot of monitoring stuff in my Lab - for sure not industrial grade, but they do what they're supposed to do. So, even a 10$ toy can do serious work..
 
RK3288/tinker is IMO outdated, performs probably not that bad for desktop scenarios due to 32bit with 2GB ram may be ok-ish. If desktop means some web-surfing and watching youtube.. I assume an android driven one may fit better, normally those SoCs are supposed to run android and hardware acceleration works there a way earlier than in Ubuntu/Debian.

https://ifixit.org/blog/11986/iphones-are-allergic-to-helium/
 
LMAO, clowns and scientists shouldn't have an iPhone.
Background, to reduce the footprint, the quatz is replaced by an MEMS timing oscillators instead of a quartz. If this thingie gets now flushed with Helium, the MEMS micro-mechanics doesn't work properly anymore and the iPhone crashes.. Only solution:
 
 
Edit: might be interesting what happens when you flush your iPhone with Argon.. (heavier than air) Someone has one spare? I can test it..

I've got a NanoPi Neo Core 2, with the NAS kit.  It lets me attach a 2.5" SATA SSD drive, all contained in an aluminium case (which elevates it above "toy", to my eyes).  The whole kit, minus SSD hard drive, was about $80 (and I'd call this a good value, worth it), however shipping from China took a long time (like a few weeks to a month).  Disk performance isn't stellar, but it doesn't suck either.  Much more performant-feeling than a Raspberry Pi.  It's adequate, to make your own personal LAN server, like say OpenMediaVault (for serving SMB file shares), or Nextcloud (DAV file shares, with SSL encryption, work great in Gnome Nautilus out-of-the-box, or Linux Mint's file manager, Nemo, once you install the package "davfs2"). 
 
Small home offices should be a good fit for this kit, where LAN file-share usage day-to-day is light-to-mediumly demanding.
 
What I love about this kit is that the H5 CPU has decent mainline kernel support.  This helps to assure me that this board won't just be a "flash in the pan", and I'll very likely be able to get kernel security updates for at least a few years into the future.
 
I mention this all to underscore my earlier point that to get something minimally sturdy, performant, long-lasting and above all useful in a way that goes beyond a tinkerer's toy (which can be a great starting point for many, don't get me wrong), then to me, this $80 kit is about the lowest I'd personally go.  For $20, I'd rather go eat a pizza or something.

I`ve got exactly the same adapter and it works immediatly here.
Armbian Bionic kernel 4.4.162-rockchip.
Are you using the volume control? Here it finds the adapter and puts the sound thru the moment I connect.

First.  Thanks for so great work in the ARMBIAN community.  Any word of gratitude will not be enough.

I have been installing Linux on different SBC.  Some of them are supported by ARMBIAN, others not.  There are some that never will be supported (as the Parallella 16).  And the ARMBIAN process it is very clean for the already refined machines.  However, when trying to bring up some other machine, it is complicated to understand what to do, how and where, as the process have been evolving for a long period of time.

Recently I began to work with @chwe on the BPI-R2, and my first job is to make the nand-sata-install to work.  So, I prepared an image to check this, to study the internal parts of the script and what is the purpose of it.  For my surprise, the script do several things, but it seems to accumulate also old stuff, maybe about previous ways to do certain things.  How to work this without breaking something else?  There, I realized how important is the /etc/armbian-release file, but also the /usr/lib/nand-sata-install directory (for all possible cards, as the ones are not a10 or a20 receive the a20 treatment).  And there is also the /usr/lib/u-boot directory with some operations that could be used in ... I suppose u-boot ..., although I am not sure in what way, as u-boot it is the first thing to run in the machine.
 
As a "reader", my perspective is that the vital system information it is not well organized.  At least it doesn't follow a unified standard, and carry the possibility of side effects as some elements could be located in not well known places.  I still need to make a catalog for all possible system parameter sources, and I figure that I will find some redundant elements in some place.  And redundancy it is not only about saving resources, but about breaking something when not following a referential methodology where any change must be system wide (i.e. universal).
 
Maybe ... and this is the reason for the discussion ... it is important to create a unified system information backbone where all processes in the system can obtain trustworthy information to work with (/proc only works with the kernel stuff).  This could also reduce the complexity of the different processes, as it could provide reusability of some information gathering functions (instead of repeating them in different scripts and or programs).  To install a system in a disk looks similar to reconfigure it in an already installed place or even to query how it have been installed.
 
What is the opinion of people here?  There are related discussions but they seems to be a little lost in time.  I am not really interested in the historical solutions (this can be written in some book), but in the actual problems and how to resolve them correctly.  There is a related thread about naming, although this one is about operating.
 
Thanks
 

Okay, so I created a working fork of RK BSP kernel. It reproduces the status at the end of August, when we created the Default images that are currently available for download. I also modified the buildscript patchset to resemble what it was back then.
 
I have tested Wifi, network, Bluetooth, GPU, VPU, all working.
 
There are two things missing:
Security patches after 4.4.132 All the features added after August 28 2018 (like some crypto modules, etc.) I'd appreciate if you guys could lend me a hand with those two things, it can be very easy for you because you already added those patches to 'master' before, but I'm a bit lost about where to start.
 
This is our forked RK kernel: https://github.com/armbian/linux/tree/rockchip-4.4
And this is the working branch of the build script: https://github.com/armbian/build/tree/rockchip-4.4

Finally, the version 2.0 for Armbian Bionic is out! Check the OP for documentation and download link.
 
CHANGELOG:
Updated all necessary packages to work with Ubuntu Bionic Updated versions of MPV and Kodi Added the GL4ES wrapper, to provide OpenGL support (thanks @jock for the tips). In order to use it, you must launch your app from command line using the wrapper "glrun" RELEASE NOTES:
I'm not sure whether the Widevine library is still working with newer versions of Chrome, and I don't have access to Netflix anymore to test it. Some feedback on this point is welcome. I'm still including the old cgminer as OpenCL example. If you want to try more recent algorithms and experiment with GPU mining just for fun, I recommend you to have a look to this sgminer for from the ODROID community (it works also with RK3288): https://github.com/hominoids/sgminer-arm As I said, just for learning, curiosity or fun. Trying to get money with a Tinkerboard is a waste of time. Plus, I think the whole crypto-mining idea is absurd, basing the value of a currency on wasting as much electricity as possible  Remember you need a default (4.4.y) kernel for HW video acceleration to work. It is not yet implemented in mainline (4.14.y).  
 

I assume it comes with SPI, so.. testing a small display on breadboard is easy.. And my famous balance example.. normally I need the measured weights when I write lab journal on my normal computer.. so, display is not really needed on the balance.. it still has one.. I just need it stored.. It somehow replaces the god old paper..  okay I'm working on a RFID implementation as well.. but that's just to have some sort of an inventory system but that's future..
 
as soon as you integrate area under signals a regular python makes things a way easier.. python has cool modules for such funny stuff. Indeed a bunch of this stuff could be achieved with ESPs but you must be somehow a masochist to do it.