chwe

I don't think so, IMO the nanopi duo was somehow 'useless' due to crappy wifi. So without a carrier board you didn't had a sane solution to drive it headless. AP6212 will fix this mostly. Having a board which is breadboard capable by default makes it quite easy to set up some testing. And once your small 'pet project' works as expected you can even solder it to something like this:

or you etch your custom pcb for a few bucks (it's a way cheaper than it was in the past). Those RPi compatible headers always need an adapter or a custom made adapter or PCB to get it usable for such tasks. Still wonder why breadboard like hats aren't default for all those boards. IMO something like this:

should be in every boardmakers store by default (with the default size for their RPi a like boards). Sell them for 5 bucks each and you'll sell a bunch of them.
Don't get me wrong, the ESP32 is a great board (especially some of the drawbacks on the ESP8266 were properly solved, e.g 512kb ram is a great enhancement for micro-python on it). It's even possible now to have somehow a 'nice' web-interface on it. Storing data on the SPI 'somehow' works but it's not as convenient as on a 'average Armbian board'. My ESPs mostly cache data only for a short time and then send them over mqtt to a linux machine where you've great frameworks for handling those data.. most of it would be possible with an ESP as well (there's not much fancy numbers crushing) but I'm simply to lazy to program such stuff in micro-python or 'C++' (aka arduino for ESPs). As soon as you want a more enhanced web-interface you're soon getting to the ESPs limits (e.g. user authentication, graphs, getting out logs - everything is possible, but it needs a lot of work to achieve). Storing on SD-Cards on ESPs is somehow archaic.. It works but my I like to pull data from my stuff without rejecting the SD-Card and doing this on ESPs is IMO hacky.
 
+ camera interface
 
To summarize, it's a BPi-M2-Zero with different pinheader...

Issue solved, btw. A wrong capacitor was mounted on our power supply assembly (SMD, unmarked).
We got a small dip on +5V rail, disconnecting the USB ethernet adaptor. It was reenumerated, but in brown out, so the USB interface showed up again, but the network part was dead.
Changing the capacitor, and adding some smart power regulation for another switched load fixed the issue.

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.

there you go..
 
https://forum.armbian.com/forum/29-reviews/
and
https://forum.armbian.com/forum/26-research-guides-tutorials/
 
is always a good starting point to get useful informations.

some combination just don't like each other... Sometimes for no reason.

there you go.

OK, to close all issues I came across, same fix as for the toolchain key, aptly repo key successfully imported when given the full URL and port 80.  updated as well.  Will need to be done manually for people with running installs, should straighten out any new installs that had this problem.

Today I installed AdvancedTomato firmware on my Router (Netgear R8000) which had stock firmware prior, and now the OrangePiZero's get an IP assinged after flash, So I guess it was a network problem all along.
Thanks for your help @chwe.

as far as I can see, the same wifi chip as for the firefly is populated on this board.. so by using the same drivers, and ensure it's properly defined in DT chances are high(er) that it should work 'as expected'. Using the same kernel as @hjc used for the firefly..
 
GbE is also the same, then it should be just adjustments in case DT definition changed slightly..  And if it performs badly:
https://github.com/ayufan-rock64/linux-build/blob/master/recipes/gmac-delays-test/range-test
 
well you've to be in case you want to give it a try.. I'll only help you.. build and test is then up to you... I prefer to mess with DT rather than fixing then broken things after the image is created.. From the sources, this is mostly a reference board with a few additional stuff populated (http://vamrs.com/sapphire-excavator).. There's not much an reason why things should not work. 
 
doesn't need years, DT is good enough described in the documentation to learn it.. 

doesn't need FEL, bootorder for H3 is SD-->NAND-->SPI if I've it right in mind.. The print-screens from the opi-zero image show clearly that he's booting armbians 2018 u-boot..  
 
But without the 16GB 'ROM' the most interesting part of this board IMO disappears.. A 16GB eMMC 2GB RAM box with an acceptable wifi chips for 30 bucks in an nice looking case could be interesting. NAND and  XR819 makes it rather uninteresting (at least for me)..
 

interesting that they want to dive into the Intel world.. Well I assume it's less work to maintain (e.g. just fire up a recent ubuntu and you're done no hacky arm digging in u-boot or kernel ). CPU reminds me to the old AMDs 10/15 years ago where you always had to be afraid to kill it by mounting the cooler (kill one of those small caps on it and silver thermal paste was the standard so shorting was also an option ). A nice homeserver/NAS thingie for those who don't want to deal with arm. They planed funny cases.. e.g 'iteration iv':

 
but consumption looks IMO impressive (I've to admit, I've no clue how much recent intel low-level CPUs normally need - my last intel was a 7'' atom tablet with 16GB ram and a crappy display for 40$ on discount  the tablet collects dust and the USB charger is used to power an OPi Zero - they sent it with a good powering cable  ) 
 

bumping is normally the best way to get a warning... 
 
that's why h5 is marked testing.. nobody knows..
 
nothing to care about... that's normal.. 
 
 
probably related to this one:
no idea, I don't follow H5 development close enough....
 

and a lot of reading might give you a clue what's and how stable things are working on h5 for *random usecase*.. H5 and H6 are in development phase. 
 
@Igor I think our download-page here is 'part of the problem'. 

 
I suggest that we mark those images as wip not supported. The only kernel we provide is in experimental or at least testing phase.. The exceptions from supported are higher than WIP.. 

Add your ideas to the list "Download UX". Then it might not get lost. 
https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/?do=findComment&comment=64049
 
 

Safe to ignore. They are mostly not even errors.

COM3 or COM4? at which COM-port is your USB-TTL-UART?
9600 Baud isnt right - you have to use 115200
 
1.) Card could be a problem if it is a fake.
Test your card with h2testw from https://www.heise.de/download/product/h2testw-50539
Format you card with SD Memory Card Formatter 5.0 from https://www.sdcard.org/downloads/formatter_4/
and write your image to the card with etcher (v1.44) from https://etcher.io/
(ensure to enable verify in etcher settings)
 
2.) power supply could be a problem, but sometimes its one the MicroUSB-cable (too thin wires) - swap this
 
3.) if the router reject LAN Conenctions - that could be a problem. Try to enable a big enough DHCP-IP-Pool
Does the NAS get an IP or did you use a static IP on the NAS?
 
4.) these images arent too new to get it bootet on this sbc - which image did you use (URL?)
 

I saw that you tested a SanDisk Extreme Pro 64GB - A2 card with ext4 and didn't get the expected results (https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md)
 
I tested my SanDisk Extreme Pro A2 256GB micro with A2 logo (bought beginning of October 2018), formatted ExFAT under MacOS 10.14 (iozone installed via homebrew). I thought this might be interesting for you:
 
Test 1:
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 71735 74819 750573 769362 416685 61419 102400 2 72975 74808 1324810 1342211 787443 65213 102400 4 74887 76056 2067185 2154206 1440308 67627 102400 16 75828 76580 3978854 3807129 3004696 70542 102400 128 70181 75891 5519047 5797444 4493592 70074 102400 512 76834 76954 5866896 5991461 5061787 71180 102400 1024 79300 79602 5903994 4940446 5571237 72008 102400 16384 82960 82502 6244310 5044075 6105069 75332  
Test 2:
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 72111 74632 706436 714325 388037 60997 102400 2 75580 74301 1283544 1363348 783629 64232 102400 4 76621 75244 2168159 2201398 1419623 66416 102400 16 76340 77138 4087649 3789092 3370748 69204 102400 128 75380 75991 5518693 4827877 5774217 71572 102400 512 63009 77769 5990458 5759273 5894918 66458 102400 1024 73595 68298 5961108 5981698 6634301 62683 102400 16384 72310 72862 5990121 6236754 6470780 68542  
Test 3:
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 72706 72637 767523 787172 422875 61073 102400 2 73304 73348 1330300 1374293 800613 64702 102400 4 72564 74550 2140561 2198186 1445840 67664 102400 16 72701 76324 4004190 3749432 3430462 69190 102400 128 74825 76603 5780123 5851070 4953780 70198 102400 512 76477 76923 5890148 5900993 5225541 71628 102400 1024 77942 80417 5930079 5984115 5487737 72037 102400 16384 82740 82455 5965766 5569606 6449524 74115  
 

After all those bad news.. It's time again to show a nice one.  
https://solar.lowtechmagazine.com
They host their blog now on an olimex lime2 with Armbian and a solar cell. Besides switching to a static website they also used dithering to reduce the image size (and a nice retro look for those who like it).  I really appreciate that they provide a detailed article with the technical details as well:
https://homebrewserver.club/low-tech-website-howto.html
with how to's and a bunch (or everything?) of scripts open-sourced. For me it looks like a well crafted setup. But I'm neither a EE nor @tkaiser (for the OS related reduction of power consumption) to give a proper statement. But they're open for improvements, so let them know if you spot something.  
 

then it should be a real 'proposal' with an intention to contribute to the board bring up process.. If it's just an 'I want armbian on it' but don't even summarize specs and a pro/cons, better keep it here..  @constantius thread was merged from development subforum (but not board bring up) by myself to this one cause it didn't make sense to have a second thread with the same infos yo get here.  We have a search engine to spot such threads before you've to open a new one:

 
Before the board isn't on the table it IMO doesn't make sense to discuss a 'board bring up'.. 

then it should be a real 'proposal' with an intention to contribute to the board bring up process.. If it's just an 'I want armbian on it' but don't even summarize specs and a pro/cons, better keep it here..  @constantius thread was merged from development subforum (but not board bring up) by myself to this one cause it didn't make sense to have a second thread with the same infos yo get here.  We have a search engine to spot such threads before you've to open a new one:

 
Before the board isn't on the table it IMO doesn't make sense to discuss a 'board bring up'.. 

moved the thread to p2p.. Probably TV boxes subforum would also fit.. 
 
Well I do in organic chemistry.. Before we're arguing back and forth for days we collect the infos we think are needed and then go to the bench and start an practical experiment.. Sometimes I feel dump that I missed something mostly I get more information to babbling/working with.. The original goal was running 'Armbian' on it:
and @gounthar realized that dram initialization with the default armbian bootloader seems to fail:
 
well at least for @lucastriches, seems that @gounthar never provided a bootlog but that's why I said:
 
Allwinner is failsafe! you can try whatever you want without messing up the stock OS... Insert some SD-Card try it and if it fails.. shit happens, next bootloader, next idea.. It doesn't matter if this is some sort of a new iteration of H3 (IMO unlikely but can be..). Or how good the Android support is.. If the goal is still bringing up 'Armbian' you shouldn't waste time with hypothetical issues.. First try the obvious ones.. Search for an UART cause debugging low-level issues without is blind flying.  Start with the lowest possible DRAM clock speed assuming that routing on the board is crap.. and try do extract the device tree to see if you get some information from there cause it will be the only source of information you'll likely get for this thingie.. As long as you're not an expert on 'board bring up' you'll probably fail 10 times before you get a step further but it doesn't matter.. You'll learn from your failures.. 
After: 
and:
you're done with android... 
The first tells you it is an H3/H2+ the second tells you (likely) it's based on this kernel:
https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/blob/ddcfef77177e66f73db94c9be4090ab6ff9ccef8/Makefile#L1-L3
so there's not much interesting left here.. (expect an DT). Boot loader is likely based on this bits here:
https://github.com/Allwinner-Homlet/H3-BSP4.4-bootloader
 
Everything was there with the third post.. after then.. it was mostly babbling but not much progress..
 
IMO now it's time to open this thingie and get access to a UART otherwise.. Have fun with blind flying.. Most of the interesting stuff happens before HDMI is initialized.. 
 
Before you build up your dreams what it could be, you need to know what it actually is.. At the moment it's an boring Android box with an outdated 4.4.55 kernel which likely never gets updates....

I still fail to understand what you want to achieve... 
A correct DTB, together with 2-3 pictures of the opened box (e.g. wifi chip, eMMC or nand - in case nand forget about the 16GB 'storage' cause nand not supported in mainline) and you're done. You may then adjust the DTB to mainline-style and finished. Assuming AW 4.4 kernel is really based on DT not some fex style anymore (the had it with 3.4, but from what I've in mind 4.4 is now also DT based). You now that this thingie is H3 based, so it's only figuring out where and how stuff is connected to it... 

I think the Forum is generally more read than changelog (I don't have stats to back this claim.. ). Our goal is more contribution and better communication. For me the change-log shows decisions already made. A 'Board seeks new maintainer' thread is an announcement. We plan to drop support for *random board/kernel* if you disagree you've to step in cause as soon patches related to it fail we will drop them (e.g. moving them to a EOS sub-folder or delete them) and new images are not longer provided (or images are not longer provided at all? - reduces 'infrastructure coast' keep them in 'seed our torrents' only could be a good idea. Community is responsible to keep them 'online').
 
I assume at least @TonyMac32, @lanefu and @martinayottes english is better than mine. But for sure, I can have a look.
 
@Tido the discussion happens in public. Make your list public and I may fill in it there as well..  For me it sounds reasonable to only monitor one thread and Igors PR. As soon as we 'extract' actions out of it they get their dedicated threads (at least the bigger tasks/projects --> e.g. the release naming which happens on github).
 
 

Injection molded housing: cheap as hell when you produce enough
Aluminium/metal housing: not that cheap
 
As a premium tv box SoC, you either make a SoC which has high decoding capabilities with low heat generation or you force the tv-box makers that they do it properly (means higher housing costs due to metal cases)..  IMO there's a market for such devices either implemented in the TV or as a standalone box in addition. 
 
For the buy as cheap as possible fraction, you're right they buy by the bigger the better.. But as on other fields, there's a 'premium sector' where people care about things work properly and things get updated for a longer therm.. The only reason I would ever buy an Iphone again is the fact that I get a phone which is updated at least for the next 2 to 3 years... If you don't want to be a premium SoC supplier, fine cheat your customers sell it to every shitty TV-Box maker which doesn't give a fuck about updates and make your bucks there.. 
 
I guess, and that's just a guess that also their closed source SoCs benefit from the expertise they have now inside the company how to do it properly.. They might or might not cheat you with the closed source ones (I've no clue). But at least their in-house knowledge is grown. Google may switch to fuchsia to solve this problem with the shitty 'phone get's no update' situation or make it harder to install the google app store, e.g only if the SoC and the installed kernel fulfills some requirements. And google showed it on other fields that they can be harsh when they decide that something has to change (e.g Symantec in case of https). Mess up with google is for sure not fun for an SoC maker which is focused on android devices and I think google will use this power more and more to solve some of the issues they have. 
People start to care when they realize that their dick pic collection isn't save anymore cause there's a security hole which makes your data accessible for others [^1]...  
It's clear to me that the average user doesn't care what works behind the scenes/ opensourceness (as a 'windows for my daily tasks' -user, I'm also not part of the 'Stallman Church'). But more and more people are concerned about their data and how save they are... Solutions like home cloud, own cloud (whatever cloud which is not hosted by google or dropbox ) may get more attention.
Premium users may not pay attention to 'stupid specs' as long as the thing works the way work as they expect but they care about other things. Otherwise nobody would buy an macbook pro anymore cause from specs the xiaomi mi pro notebook throws every macbook in the bin, except display resolution (16gb ram, Samsung SSD + second m2 slot, i7-8550U and NVIDIA GeForce MX150 2GB for ~1000$) and it also looks 'somehow similar': 
 
But your apple macbook pro does the things you want and you don't care about maximum performance as long as it performs well on OSX. From a homecloud/nas/tv-box thingie in the higher price range you expect that it performs well for tv streaming, a little bit of BS gaming and that your dick pics are save. The easiest way to achieve this is by don't have your box open to the internet (which makes it shitty for a streaming box with integrated cloud thingie) or you have a your code peer reviewed by others who care about security... And I think the cheapest way to peer review your kernel code is to have it mainlined.  You need developers which code properly (higher costs) so that your PRs are accepted by the kernel maintainers but you get a peer review for free (lowers costs).
In the science world where I'm involved you've to possibilities to get your results published. You can either pay a fee to the journal so that they do the peer review process for you (normally ~2000-3000$ per article) or they do it for free but then every reader has to pay a fee to read your article (and those fees are horrible high around 5-10$ for read once or 50$ to get a pdf)..  Or you publish it in a low reputation publication where nobody will notice your results... Free open access journals with a good reputation barely exists (and mostly they're part of a series where you have to pay for all their other journals)... 
 
 
[^1]:
 
 
Edit: Maybe we should rename the topic again, moving it to General chit chat? Cause It's hijacked again for a lot of other stuff...  

An idea which came up during coffee when I read through our documentation (I'll update it partly).. Why not implement an 'unbricker' as well?  
http://docs.armbian.com/User-Guide_Advanced-Features/#how-to-unbrick-the-system
e.g. check which one is installed and then give the user the opportunity to choose an older one. 
 

@botfap made an initial push to restructure network configuration prior to first boot. I didn't test it on my own yet but I assume the wifi part should work and perfectly fit for your needs.
https://github.com/botfap/armbian-image-config
quite sure he's happy to get some response from people actually used it.  You might give it a try? 

smart!   the connector the user normally only touches once (HDMI, Network, Powering) is on the back-side and connectors which are touched more often (USB) are on the front (assuming IR is normally on the front side). A bit risky but IMO interesting is to throw out the microSD slot. It may solve a bunch of those support questions which end normally here: https://forum.armbian.com/forum/31-sd-card-and-power-supply/ (at least the SD related ones ) and 12MB SPI flash is more than enough.  IMO an important 'what if' question:
What if I mess up the bootloader and brick it? I'm not familiar with enough with Amlogic SoCs, are they 'failsave' to unbrick SPI once it's messed up (e.g. something like RKs recovery tools?). I've a talent in messing up u-boot, luckily this only happened on SD-card (of fail-save sunxi) yet, where it wasn't much an issue. I probably pledge for a 1gb version if there are still some left for 19$ when I'm back at home..  Not that I'm interested in Kodi on Linux stuff, still a mystery to me why people want Kodi on Linux (anyway, I don't need to understand everything)..  But I appreciate your contribution towards mainline support for hardware accelerated video en/decoding and it could be a cute little IoT end-node for systems where you can't trust that your device doesn't magically disappears (others would call it someone steals your stuff). At least potential confidential information of this node is not in the wrong hands as soon as they cut power. A cute little toy to get a feeling for PXE related stuff.