chwe

probably not...

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...

I may need a more maintainable mechanism to add new boards... It's currently a hacky solution..

at least on your photos for those boards there's a axp8036 on it. This one can't regulate so it will stay at 1.2V.

likely none cause axp8036.. same as libre uses in their boards.

I don't care towards my sensors.. but burned boards cause the SoC pins aren't 5V tolerant is a bigger issue.. normally, they put exact the same stuff on the board than adafruit or who ever released it first... Why? It's probably easier to design the pcb.. Only difference I spot.. they mostly don't care towards resistors.. E.g. putting a 5% resistor as a shunt which should be at least an 1% one.. It was never an issue that adafruit boards arent 3.3/5V capable.. But the SBC might not be..

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.

you mean Method 2: How to Burn ISO Image to USB Drive Using RMPrepUSB sounds exactly what people want... or Method 1: Burn ISO Image to USB Drive with WizISO? which doesn't mention disk verification anywhere? Doesn't make sense too.

and that's not true at at all.. even the cheap often intel based 'minicomputers' are mostly based on eMMC. some numbers to think about: Allwinner H3 is from 2014 Rockchip RK3399 is from 2016 Allwinner H6 is from 2017 those chips aren't the newest when they enter the SBC market. If a boardmaker limits his board to SSDs he'll limit himself to a specified market so I'm quite confident that this won't happen. Why should he? Wiring out and SDIO interface (for SD or eMMC) costs him a few cents and he'll catch a few or a bunch of customers as well (depending on the price of the board in question). e SDIO is an rather simple interface and common for TV boxes (eMMC). Those SoCs are mostly used for TV-Boxes so you might need to order 'a few 100k' SoCs until an SoC maker is interested to ramp up a 'special version' for your purpose. Except the fruit Pi board armbian doesn't support there aren't/isn't (m)any SBC makers which sell so many boards. You want it doesn't mean everyone wants it.. Currently if you don't want all this 'hardware bloat' go for an AMD/intel based thingie.. Arm boards are more for those who want GPIOs, who want the freedom to boot from different medias, sometimes who want an camerainterface etc. A cheap PC replacement based on ARM is currently not really the most obvious use-case. And even then, I would never suggest they should go for an SSD-boot only board. IMHO SPI NOR is the way to go and guess what (this list doesn't claims to be complete): OrangePi Zero: 2MB SPI flash ROC-RK3399-PC: 16MB SPI flash ROCKPro64: 16MB SPI flash La Frite: 16MB SPI etc.. Put your bootloader there and when *random interface* is supported by u-boot you can boot your linux from it.. The BROM on SoC is likely never touched by the boardmakers. As long as a SoC maker doesn't have 'desktop replacement' as a use-case it will not happen. proof for your claim? or only reading specs? cause 1&2 is more or less the same.. both are SDIO interfaces (which are not that different from SPI) whereas 3 is a complete different story.. just a kind remember.. This suggestion was to avoid this bloated discussion which is senseless as long as you don't understand how an SBC boots.. http://www.orangepi.org/ there you'll find it on the bottom... It's not our job to give you stuff you'll find by visiting the boardmakers web-site..

I made bacteria lightening green years ago.. Am I god now? The gene came from some animals living in the ocean and expressed in a bunch of different cells.. mostly bacteria like E. Coli... If you now freak around with this gene-sequence you'll end like this: but it's not just joking around making pictures with bacteria you normally find in your toilet... Normally you add those GFP gene-sequences to something interesting. E.g to a protein of interest. With a fluorescence-microscope you can now look were this protein is: or when attached to cells in animals it looks like this: and no, that's not photoshop... those mice 'light' up green when exposed to UV light. Normally such experiments are strictly controlled, you're not allowed to manipulate a mouse without clearance from the govt. You write a proposal and govt. and people related to ethics check it if it's ethically acceptable and if it's worth. In china the 'bars' for such an approval are lower that's why a lot of researcher in this field moved to China. I've never worked with animals so I never had to deal with such proposals.

probably in most countries around the world. China has the most liberal laws when it comes to genetics.. Might be a reason why a bunch of researchers in this area moved to China.. Depends on definition. As far as I know (and I'm neither an expert in genetics nor crispr), crispr as a technique should be save.. But I would assume we're far away from a complete understanding of our DNA... So we might 'cut out' peaces which shouldn't be cut out. [this part may be a bit 'too general' but I think it's better not going too much into details here...] Our DNA is the 'blueprint' for all the proteins and they organize then 'more or less' everything else. 3 nuclebases (T, A, C, G - called a codon) from our DNA coding for one amino-acid and a bunch of amino-acids 'glued' together together (sometimes) with some modifications form a protein. There's some more stuff involved (e.g. RNA) but let's be simple here. Except Methionine (Met) there's always more than one combination which ends in for the same amino acid - nature is smart here, we've redundancy... But there are still possibilities which are not here in this list (e.g. AAA) this parts were called 'junk DNA' in the past before we figured out that it isn't junk... At least not all of it.. It's still not fully clear what the purpose of those non-coding areas of our DNA is for.. We might need it even when we don't understand (yet) what it is for. Also knock out a protein which might save this kids from HI-Virus might not be 'as cool' as you think.. Maybe the same protein has another job which we still need.. Well, only time can tell us if it was a 'good idea'. I personally think we shouldn't mess too much with stuff we don't understand. Interestingly, in a lot of tech-forums/ tech-sites the comments below such articles were more open to modify ourselfs.. Partly arguing with stuff like: humans don't have evolution pressure anymore that's why we should start to 'optimize' ourselfs cause nature can't help us anymore.. What an arrogant position and IMO complete bull shit! There's still evolutionary pressure, maybe not the same kind of pressure a bacteria has.. But not the same doesn't mean ours is weaker.. It's just a different one. Personally I think let humans be humans, rice be rice and corn be corn, I'm not a big fan of GMO food (and newly GMO babies) but our American friend here might have a different opinion on this.. It solves us some problems, but it might open new ones in the future (a bit like nuclear plants ).. well but he's still the first.. I think this liberal stand-point on genetics 'motivated' researcher to try something like that. If you think you don't have to fear the consequences for doing something like that, you might do it. Let's see what happens.

and that's why I said: without the bootloader (u-boot) our arm boards can't boot from *random media* most of them can boot either over SDIO (means SD-Card or eMMC) or SPI (means a little SPI flash with 2-16MB space)... That's a way before Initrd comes into the game.. Those SoCs are (mostly) made for cheap TV-boxes.. we just have to keep this in mind sometimes...

Guilty... It was a quick one... But good to know. People actually read it!

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...

https://www.popsci.com/crispr-twin-babies-genetic-engineering we finally made it!!! just give people the right tools and they'll take care that we start to play with our genes... I'm a bit surprised that it happened that fast.. I expected that they'll wait a bit. But 'seems' it's never early enough to mess with stuff we don't fully understand.. Well one one hand it's like flying to moon in the 60thies.. I'm quite sure they weren't sure 100% if it works but their goal was to be first.. Same counts for crispr babies.. Speculation it might be 'interesting' came up quite soon as the 'proof of concept' that this technique works was there. For the crispr Cas technique you should read wikipedia: https://en.wikipedia.org/wiki/CRISPR They're better in explaining that I could probably do it... The concept and the technique which came up with crispr/cas9 is amazing and a great piece of science but it has the potential to be dangerous/misused and it seems this first takes it all mentality ended now in twins which may or may not be resistant to the HI virus, but for sure they've to deal with it and nobody could ask them if they agree on such a 'modification'..

highly appreciated! I'll have a look into it as soon as time allows it. http://forum.banana-pi.org/t/bpi-r2-new-image-armbian-with-kernel-4-19-y-2018-11-5-support-by-armbian/7193/46 USB attached storage is also recognized and will be investigated. I had issues as well with the el cheapo inostar USB-SATA bridge.. It worked.. I cleaned up the kernel, and then it doesn't work anymore... an normal 64GB USB stick worked.. So I thought it's just an issue of the crappy cheap USB-SATA bridge I used.. I may go through the commit history to figure out what caused it.. Not sure anymore but I assume it happened here during 4.17 clean up..: https://github.com/armbian/build/commit/065ee2a58cdec9cf73db600a88329db7bd1e83fd#diff-739e1697912e608c5c6406a65c271ad7

Isn't that simply because of the way initrd/initramfs has been written? - I know, let's get the bootloader from the slowest/most unreliable device we have. You may need to get familiar with the bootprocess of ARM boards compared to x86... there's no BIOS in armworld.. http://linux-sunxi.org/Boot_Process can be a starter.. Quality SD cards aren't that unreliable (for sure not comparable with quality SSD cards.. but ok-ish).. but if you go for the cheapest.. well I would call it a 'not our problem'.. Speed. define speed, speed at boot doesn't really matter IMO.. if it's 10 seconds or 30seconds until your board is up and running.. does it really matter? Armbian is normally up within >20 seconds expect first boot.. I'm more interested in speed once it booted up.. also known as performance.. https://libre.computer/products/boards/roc-rk3399-pc/ the pc-a-like model... the cheapest one you can find.. a mail-server for a few mail addresses shouldn't be as resource hungry.. e.g. all H3 oranges or bananas or Libre Computers or nanopis or A20 boards or whatever you want to use.. BPi R1, BPiR2, Clearfog PRO, Clearfog base, Espressobin every board which works fine with an RT kernel.. beagle bones etc. I don't think that's really an use-case but for sure there's a RPi HAT for something like that..

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.

you would have to change the config: https://github.com/armbian/build/blob/1396d775a39176280734382a5ba434b4a72d8e12/config/boards/pcduino3.eos#L8-L10 to something like that: https://github.com/armbian/build/blob/1396d775a39176280734382a5ba434b4a72d8e12/config/boards/orangepizero.conf#L15-L17 and then test if it works... you've to test it.. I would go for the first one.. which is likely with less pain..

A heretic would say you don't need coding at all to bring up a new board... Indeed, hardware wise beagles have some nice features. Possible one of the few boards where I would assume without checking that they might be 'industrial grade'.. Support wise beagles have the potential to be a nightmare.. As far as I know, a lot of the hardware related stuff happens in userspace (e.g. accessing the PRUs?). So there would be some digging around to get this stuff properly packed to the images. I've a beaglebone 'original' (the white one, and a beagle board) but never thought seriously about supporting them by Armbian (mostly cause they collect dust since years - my interests shifted more into software than hardware since then) and my time is very limited at the moment (only a few hours at weekends for serious digging around SBCs). So the board bring up part would be 'your part'. I (we) might give you some hints here and there but I don't see that any developer has enough time to do the first steps. I recently did it for the MT7623 and BananaPi R2 board (e.g. new SoC combined with new Board) and if you're patient enough you can do it as well. When you start you think you'll never get things working but over time you'll understand how 'the buildscript works' (not that I understand every part of it but it gets more and more.. ). https://github.com/armbian/build/pull/1151/commits might be a 'good starter' to see how a new SoC enters Armbian (in the beginnings I tried to have meaningful commit messages - the last ones are a bit lazy - shame on me... ). At least your board is well documented so this should be straightforward... You need u-boot, with a u-boot config, a kernel a kernel defconfig, time and you need to be patient enough to keep going in case you fail (and you will fail 'a few times' until it works)... Testing is a nice offer, but no dev ever here will bring up a new SoC which he doesn't has at hand.. I probably built more than 50 images for the R2 until it booted without major issues (okay.. that was my first board with a new SoC and building was sometimes 'cheaper' than think seriously if this can work.. ). As @TonyMac32 pointed out, we're more in a resize and drop support for various boards/kernels phase of the project so new boards will only show up if new devs step up. Beagles are interesting cause they cover a new area for SBCs (e.g. real time applications etc.) but the current devs may not be as interested in this particular use-case (doesn't mean that this couldn't be part of Armbian in the future - but devs with an interest in this field and willingness to bring stuff up and running must join the project to let this happen).

tried this one?

NM ignores all wired interfaces for the R2 in the current config. no chances to to it similar to the 4.4 kernel.. for MT7530 only a DSA driver exists in mainline..

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