pfeerick

I've copied the same xenial mate into eMMC, tweak the /boot/extlinux/extlinux.conf to point to mmcblk1, and now it boot from eMMC.
 

Welcome !
I had to manually use parted and resize2fs to get all it's space ...
 

That extra 10/100 ethernet seems like a good place to put an HDHomerun if you were running a TVHeadend server...

Yes, this needs to be solved first, we should also wait whether there's one DRAM initialization solution for all 3 DRAM variants since dealing with users reporting bricked boards since downloading the wrong OS image is just boring.
 
On a related note wrt kernel version: TL Lim introduced a few guys a week ago to Kever being some sort of an open source activity representative at RK (most probably I got it wrong, doesn't matter that much since at least he knows who's in charge of what at RK solving issues). Yesterday I informed them about promising USB3 performance but also 'I think we need to add a quirk for UAS to work reliably, please compare with dmesg output 'ERROR Transfer event for disabled endpoint or incorrect stream ring' (http://sprunge.us/HURC) and Hans de Goede's approach for a similar problem with an older ARM SoC who's most probably using an older version of the same USB3 IP as now in RK3328.'
 
Let's wait and see. What I expect is a fix first in their BSP kernel but then also submitting patches upstream so we can tick the 'USB3/UAS working flawlessly' checkbox soon.

I mean as long as u-boot, SPL and DRAM configuration and issues are solved, it doesn't really matter what kernel to try - pure mainline or 4.4 BSP.

First, let me make a guess and say that you are representing Mediatek here. Then - welcome.
 
Second, to summarize and rephrase @tkaiser's quite emotinal posts in this thread:
Armbian is not about building OS images for any available board (that we can get in our hands), it's about level of support that we try to provide to our users. This level of support depends on the level of support the board maker can provide to the community (including the Armbian team). 
Also when deciding to support a board, we are trying to evaluate different factors, including software support status (kernel, u-boot, additional libraries), quality of documentation, board pricing compared to similar devices on the market, etc.
MT7623N can be a good SoC for a NAS or a router board, it can even be very good if it will have competitive pricing for board makers and good software support from the SoC vendor. But here it's up to the board maker (sinovoip) to make a good use of all SoC features, to provide correct documentation (like board schematics, PCB size and position of mounting holes), to advertise the board to their end users properly by releasing correct specifications, to support their end users by releasing good enough software images. Will all of this happen? Judging by the previous boards released by them, higly unlikely.
 
Will there be Armbian images for boards based on Mediatek SoCs? Possible.
Will there be official supported Armbian images for the Banana Pi R2? Probably not, unless this board doesn't have any design flaws and gets full mainline support before it is too late.

That's not really a problem. Even if their drunken copy&paste monkey responsible for this nonsense collected on Gitbook is able to write 6 different powering options here and there anyone will get that it's 12V/2A with the usual 5.5/2.1mm barrel plug. It will only be annoying for those who order the R2 together with their usual PSU (4.4/1.6mm barrel plug and wrong voltage) since then they can throw the PSU away (but hey, since Sinovoip sold something someone at least made some money!).
 
They're also talking about a 'PoE option' (Power over Ethernet -- not documented since... why?) and according to schematic PHY0 (that's the WAN port combined with external Magnetics) can be used for that combined with an optional 'PoE' module (active so full GbE can be used). Two more questions immediately come to my mind:
If the above 'specs' of 12V/2A are real then we're clearly not talking about PoE (IEEE 802.3af, limited to ~13W max in reality) but PoE+ instead (IEEE 802.3at, limited to ~22W in reality) If the PoE+ option can only be used with the WAN port what topologies do they have in mind? 'Simple' PoE+ injectors are fucking expensive, the injector has to be placed where the other end of the WAN cable will be inserted (modem? Gbit modem? WTF?). That's just brain damaged.  

but you're still their Nr.1  (sry for the off-topic)
 
IMO it 'sounds' like a nice product from the product page, so a lot of server ideas will come up by various users. I'm not really interested in server applications on a SBC and my knowledge on this field is more than limited (I'm more the IoT intrested guy, than the server guy). But my main question is, compared to boards that are still on market, is there really a benefit compared to other boards on hardware side? Imagine every thing will work properly on software side. Will the comunity have a (real) benefit compared to other boards? Since it seems a lot of work to get this board to work (SoC without that much community support in the past etc.), I think weighting the benefits compared to the workload should be kept in mind.

That they ignore the meaning of 'open source' (or maybe simply don't understand what this means) is only part of the problem.
 
The people who try to help those brain damaged retards now for over 2 years still know what a shit show situation with 'the predecessor' Lamobo R1 was: you couldn't use a SATA disk, you couldn't use the network switch, there was not a single usable OS image and documenation was totally lacking (details with sources -- someone has my post unhidden and I don't think they'll delete my post another time). You could not make any use of this paperweight in the beginning and it took community unnecessarily long to fix all their stupid mistakes since they did not only not cooperate but were actively sabotaging our efforts (schematics have been released a year after the product went to market).
 
We know about MTK that (just until recently?) you didn't get sources from them unless you signed an NDA (preventing you from sharing/opening the sources) and these NDAs are pretty expensive.
 
Given the great reputation of this vendor, the amazing history of fails and their documented willingness to cheat on you as much as they can: why should we believe them they will open up sources? That's one of the most basic requirements to be able to just evaluate whether we want to invest time and efforts on this device or not.
 
But they do not even get why opening sources is important. Same with their understanding of 'documentation'. If I look today through the results of their drunken copy&paste monkey sitting on his keyboard and biting into the mouse (considering this 'writing technical documentation') then depending on which part of this 'documentation' I consult I get R2 power requirements that read either 12V/2A, 5V/2A or even just 5V/700mA and the power connector is either 5.5/2.1mm barrel, 4.4/1.6mm barrel or Micro USB. And it would take you insane amounts of time and efforts to get this information corrected since between you spotting the obvious mistake and their 'technical documentation' a brain damaged retard is sitting preventing any improvements.
 
Do we want to support devices where it's hard to get even most basic required information? Where technical documentation is just wrong all the times and will never get fixed?
 
Especially if we compare with other hardware vendors who don't behave like retards all day long. FriendlyELEC for example releases a new piece of hardware. Usually their engineers at the same time update the device's wiki page with schematics already released and of course version history. It takes just a single public complaint and their CEO writes you an email asking for details. You show them numbers, explain shortly what UAS is and why that matters, they phase out the old product and within 4 weeks there's a new and improved one.
 
You explain to FriendlyELEC people shortly why they should drop support for shitty old Allwinner kernels and use mainline kernel instead, CEO understands immediately that he doesn't understand details (not affected by Dunning-Kruger!), so their kernel dev is in CC:, it's easy to convince him to focus on mainline kernel and how to get there (just a few emails between Icenowy, me and them). In parallel you write the CEO that their kernel dev needs some time so please no pressure on him and days later we're here: https://github.com/friendlyarm/linux/tree/sunxi-4.11.y (still not perfect, but everything happens in the open, even 'community peer review' works as it should)
 
That's the difference between board vendors who respect and cooperate with community and able to learn/improve and brain damaged retards that do not even understand how horribly they actively hinder community to help them.

Sure, it requires you knowing what you do, an Armbian image you have to 'disassemble' yourself, then write the relevant parts to SD card, partition the USB device and follow the steps nand-sata-install is doing. You'll most probably fail a few times but will finally succeed if you have some technical understanding. In way less time you can also write the image to SD card, boot it and run nand-sata-install the usual way
 
BTW: In the past I thought multiple times about starting to work on something that would allow to do exactly what you want but everytime decided against since waste of resources. Wrt boot situation we could already convince a few board makers to start to solder relevant amounts of SPI NOR flash to their devices. Goal is to ship SBC with a device specific boot loader in the SPI NOR flash so OS images can be device agnostic and living anywhere (SD card, eMMC, USB stick, network, whatever). And yeah, that's a long-term goal still 'a bit' away
 
From an Armbian perspective something that would really be desirable would be a 'forked' nand-sata-install that is able to clone installations (the average user will call this 'backup') to allow people to insert another SD card in a card reader, call 'clone-armbian' and get a bootable clone on the external SD card 'just in case'. But when thinking about this such a cloning functionality living in initrd would be better since then able to work 100% perfectly.

https://wikidevi.com/wiki/MediaTek
There is one router board based on similar (but I guess different enough) chip, but it's also not very well supported.
 
There are (only) few ARM based NAS / router boards which are good enough to consider dealing with: Clearfog pro, base and upcoming Espressobin. Serious (open source oriented) vendors would stay away from Mediatek chips in first place.

Exactly and that's the reason I will only recommend Etcher from now on. It's absurd to waste time on 'bug reports' all the time that are caused by broken burning processes or SD cards.
 
As soon as other burning tools implement a mandatory verify after burning I'm open for other suggestions again.

In my opinion NOT since this thread here contains a lot of confusing discussions that are Armbian internal and only reflect a specific situation now. I'll repost soon in new 'Board Bring Up' subforum, copy&paste the hardware part, the software support part and try to summarize dev thoughts on current situation as neutral as possible.
 
IMO it's important to keep 'Board Bring Up' threads focused on the board if we want to use this later as 'landing pages' for users (Google is pretty fast: 'armbian banana pi r2' search already lists new thread as hit N° 2)

Yeah I am following the mainlining process for some time now, and some new things went into 4.12.x , we'll see at what pace that continues. As for the documentation there are only the datasheets (SOC+RK805), Part 1 of the user manual and the schematics right now. Tl is trying to get the Part 2 of the user manual released, but I am not sure what is actually in there. RK just today provided some more patches for the 4.4.x BSP, maybe the Rock64 can now stay up longer than 20 minutes :-)
 
On the hardware front Tl was looking for last suggestions regarding schematic changes or board layout changes, I think the plan is to go into production as soon it is confirmed that 933Mhz DRAM works on all three (1/2/4GB) variants...
 
@TonyMac32 I can ask Tl if he can send you a board sample if you like

The mainlining (is that a word?) looks like it just started not too long ago, and given the 4.4 kernel is the one directly from Rockchip, and the... unique coding style I've come across for some of their workarounds, I'd agree for now.  At the very least for mainline the RK805 needs supported, it's a non-start without it.
 
If given a board I'd help support if/when the time comes, as much as I'd like to I don't think purchasing one is on my radar just yet, and it would be hard to justify having 2 SBC's that don't actually do anything but absorb my working time...  ;-)
 
As a note to Mods, should this be put in the "Board Bring-up" sub-forum?

Speaking of vendors changing hardware, we have Beelink X2 listed as a "supported" device even though if I remember correctly they changed wireless chip model in later revisions.
 
Getting back on topic, I received the Rock64 some time ago (thanks TL Lim), but current software situation to me looks like "blobs, blobs everywhere" + not a lot of low-level documentation + not a lot of mainlining progress, so I probably won't try to integrate it in Armbian for some time.

Well, I'm a cyborg, and I still run on 2.6.  . 
 
I may have been grounded by the wife after I bought the Tinker Board and then had to buy another box to take up it's intended position in the living room...  :-/  Getting one of these may not be in the cards unless someone has pity on me.  I'm certainly more gunshy at this point, The nanoPi's went so well I got careless and wasted some money.  On the bright side, I've learned an awful lot about a lot of things I wouldn't have gotten myself into before hand, and I'm glad to be learning more.
 
Now, speaking of, time to go work on cleaning up Tinker Board messes.  I need to "unfix" something that is reportedly messing with the MiQi and try out Myy's attempt at getting BT working (involves a Rockchip custom rfkill driver)  And figure out if my MAC address is actually stable on the thing or not with Igor's U-boot patch.  I saw more than one value, but I need to make sure I'm not just hallucinating due to distress over the general state of the board.

BTW: If anyone wants to spend a little bit of time on collecting maybe 10 'SD card was the issue' threads, here's an IMO perfect one (since short, some explanation and quick confirmation): https://forum.armbian.com/index.php?/topic/4563-orange-pi-zero-logout-after-password-change/
 
(this is another one where confirmation is yet missing -- 'Authentication token manipulation error' is read-only rootfs most probably related to SD card crappiness). If such a collection exists (same with power supply troubles) it gets a lot more easy and less time consuming to encourage users to focus on basics first instead of blaming software.

And in each SoC subforum (Allwinner A10/A20, Allwinner H2/H3, etc.) we could create a pinned locked thread named like "List of boards supported in this subforum" to improve navigation.

Unattended upgrades will be the first thing to disable since even without actual upgrades package lists will eat enough traffic (use "sudo apt remove unattended-upgrades" to do that).

Oops! I didn't spot that one either!  Sorry @chwe ... better move it before Igor decides to cut our pay!!!

Well, also I could reproduce on Hummingboard when trying to connect wireless - it instantly crashed on 4.11.5 while working fine on 4.9.33 ... 
 
 
Of course there is risk when upgrading, especially u-boot, because worse case boot breaks ... but kernel upgrades are more flexible since it "only" breaks some part of functionality at worse. Like in this example. Perhaps this upgrade procedure should be divided and provide more selective relevant upgrades. That should limit down problems. 
 

Also possible to apply it to images by default and we gain stability - user must act to get latest updates. Like on deprecated boards.

What about thinking about (discussing) update procedures? Armbian has default, next and dev variants while the distros are horribly outdated (stable, stable, stable) but for whatever reasons Armbian tries to introduce update drama every few months. Why exactly?
 
I'm a big fan of users testing stuff if they have been warned they're using experimental software. But if users choose to use something called 'stable' why can't Armbian provide something stable?
 
What about differentiating between next (somewhat stable LTS release) and dev (latest and greatest mainline kernel)? Applies even more to u-boot updates (this one -- BTW users and 3rd party image builders don't get it if we remain polite, they simply ignore the contents of the message)

Hi folks !
 
I'm overwelmed with daily job as well as looking at this thread ...
Not even been able to do diagnonal reading ...
 
"Time is the missing indredient"  !
 
BTW,  I' ve received today my Rock64 (Thanks @TLLim, but don't expect upcoming work/effort until my  overwelmed situation is cleared out)
 

This job is for anyone with minimal inside knowledge. Related or unrelated to Armbian.
 
Again - "no support" means we will not provide any information regarding state and problems of moving experimental things. It's expensive and provide negative results. Double negative from our perspective.
 
When things are good enough for bare server usage, similar kind of report is found at download page - this and that is not working, ... Currently there are too much problems and no one out of five active developers would like to have yet another burden. We don't want that experimental images are used by end users in first place. Some even use those unfinished work in production and are saying that we are losers and idiots, because upgrade break their wonderfully working system. Yes it happens. It happens way to often and there is no compensation. They don't support as in any way but expect full support from us.
 
We came to conclusion that we will not share any information (for end users) regarding WIP work. Developers can find and acquire information from Github commits, from ours an upstream. Everything relevant is written there, but to write a summary ... anyone can.