TonyMac32

I have a short update on the latest patches RK sent to BSP upstream. As of this morning we have a Rock64 image that doesnt lock up anymore  after 20 minutes and ayufan found a hotfix for the GbE issues by turning off tx-offloading (no TX/RX paramters tuned yet) and that seems to work well at least for him (930Mbit both directions) with one CPU core loaded since integrity calculations are now done on the CPU. Currently we boot the 2GB and 4GB with one firmware loader at 768Mhz DRAM frequency. The u-boot patches to autodetect DRAM size seem to work so far, havent heard back from someone with a 1GB board yet. RK also should push a DRAM init blob for 933Mhz soon...
 
https://github.com/ayufan-rock64/linux-build/releases - new images and deb packages for system upgrade

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?

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.

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)

It works for me to, cubox-next, ath10 and brcmfmac.
 
@tonymac32
Reboot reboots.
http://sprunge.us/CaOj
U-boot on eMMC:
U-Boot SPL 2017.05-rc3-armbian (May 04 2017 - 15:10:29)
Returning to boot ROM...
U-Boot 2017.05-rc3-armbian (May 04 2017 - 15:10:29 +0200)
 

HP50G!!  Will update my post with a photo later...

Most of us probably do some electronics along with the small computers, I've been part of "what does you desktop look like?" threads (terrible, by the way), thought I'd put up (the electronics part of) my workbench:
I wasn't about to lie and clean it up before hand...
 

This isn't helping me not want one.  ;-)
 
I'm paging through the mainline kernel support, hopefully more of these make it out of the Rockhchip patchwork and into 4.12 (like RK805 support).  As it stands I think mainline support is possible, if not extremely convenient.

XU4 easily outperformed by my new arrival ROCK64. Testing with an Samsung EVO840 (the same as above) with ext4, UAS enabled, a 4.4.70 kernel (ayufan build) and an external JMS567 disk enclosure:
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 19727 23938 25879 24231 18475 23886 102400 16 67302 80160 87210 87008 68301 79484 102400 512 278860 292958 292461 301834 292974 291585 102400 1024 297825 310695 313499 324097 316276 313253 102400 16384 325951 330928 340258 351640 352109 323207 That's sequential write performance of +325 MB/s and read even better at ~345 MB/s. So now let's wait and see how pricing will look like (I guess we get the 1GB variant for less than $25).
 
Debug log here (I simply used arm64 OMV rootfs from ODROID-C2): http://sprunge.us/HURC

It is frustrating, it's also universal human nature.  I sold car parts while going to college, people always wanted to buy the generic parts instead of the original equipment and then got mad when they lasted 2 months instead of 5 years.  
 
Even now working with Automotive companies, sometimes I have to explain the laws of physics and why my products can't defy them.
 
So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero?  I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions.
 
Example:. "Why can't my nanopi neo transcode 6 video streams simultaneously while cooking me breakfast?"
 
From moderator:. "post moved to "collection of insane and redundant questions.  See FAQ in OP of thread."

It is frustrating, it's also universal human nature.  I sold car parts while going to college, people always wanted to buy the generic parts instead of the original equipment and then got mad when they lasted 2 months instead of 5 years.  
 
Even now working with Automotive companies, sometimes I have to explain the laws of physics and why my products can't defy them.
 
So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero?  I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions.
 
Example:. "Why can't my nanopi neo transcode 6 video streams simultaneously while cooking me breakfast?"
 
From moderator:. "post moved to "collection of insane and redundant questions.  See FAQ in OP of thread."

To be honest, I didn't need to talk to anyone before contributing/trying to contribute.  The Tinker Board is an excellent example of a board that has some pretty severe vendor-caused support issues in general, ticking off nearly every box from some of the earlier posts.  In this case I had one, I cloned the build system after following the proper documentation to set up a VM on my main computer, and got to work.  I then submitted pull requests on github with my changes.  I don't think a discussion about officially supporting a board is frictional to getting new devs, but I think seeing devs get dogpiled for support requests is.  That was my 100% biggest concern about getting involved, the questions I simply can't answer because I'm a low-level (firmware, micros, assembly, etc) programmer, not necessarily even a well-versed linux kernel guy (learning quickly, but there is a lot there to learn). 
 
 
I'm afraid that's impossible to stop.  "Joe SBC" will invariably try to make a $8 device do the work of a $50 device.  Managing expectations is most likely more difficult than supporting hardware.  While it will upset the low-information DIY-er, I think you'll find collecting such requests/feedback into dedicated "rubbish threads" that link to the FAQ and disclaimers won't be detrimental to the project.  More moderator work.
 
For supporting new boards, as long as the user community (those with no intention to develop) understands and respects that the dev users (anyone willing to code/organize/troubleshoot/brainstorm/document have final say over supporting a board (their work, their decision), then all transparent discussion is of course the preferred method.  I do like the headstone method of having an OP of a thread contain the status/updates/issues of a board, then mark it as EOL and maybe lock the thread.  
 
@tkaiser, I like the OP in this thread, and considering improved moderation that would be a good way to get the information.  It can be done just as easily publicly as privately, getting the weigh-in of the typical dev, I just know that sometimes I have opinions of things that may offend vendors or even users, e.g. "Well if you're stupid enough to do that, I'm not going to be any help" .
 
I've been dabbling with websites and projects for almost 20 years now (I started young), the biggest problem I see with the free exchange of ideas that is the forum is burying data in clutter.  A 20 page thread will have, literally, 2 pages of useful content.  This is simply due to agreement, question, additional thought, etc.  This is why Forums are terrible archived documentation/reference sources.  It's very easy to blame it on the user when they re-pose questions, since a proper search can find the information, but often it turns into wading through pages of nonsense and unrelated tidbits to get the command, or parameter, or info you wanted.  I believe a more constructive method involves the Forum as an idea development/collaboration platform that said information is then culled from and formalized in some manner.  I would recommend something like below:
 
For a new Board, exactly as tkaiser opened the discussion, updating as new information becomes available.  Once a decision has been made by the team (I would assume a dev or two would have to more or less "adopt" the board in question for hardware support), close the thread, maybe clean it of extraneous info if mods haven't been doing that actively, and archive it as reference on a wiki, or transfer its information to a wiki and link to an archived PDF/html/whatever of the original, maintaining the conversation, but not allowing it to get buried or cause a huge amount of "pinned" topics you have to drill through to get to "live" discussions.
 
Upon officially declaring a board to be supported, have a subforum for the board (I know, huge effort organizing), then open a discussion/debugging thread for each release.  Lock that thread upon release and open a bugfixing thread, etc.  Keep the last release or two on the forum as immediate reference, archive the rest as HTML/PDF/Whatever available via a Wiki page for the board.  A "Hardware Support Status" table on a wiki would be ideal, just simple Green/Yellow/Red next to the supported bits per kernel, a simple visual aid goes a long way.  I would include an * or <- or some other mark with a note about special patching if it's needed (WiFi on Tinker Board Kernel 4.4 as an example)
"Official" Forum threads need to be consistently titled (example/proposal):
 
[Pre-Release 5.31] Hardware Feature Request
[Release Candidate 5.31] Bug Reporting
[Release 5.31] Continuing Support  
 
 
Now, boards may come about that initially seem like a great idea, check the boxes, but which later turn out to be piles of garbage.  I would recommend having a mandatory "trial period" for a board before committing to support it, no matter how perfect it might seem.  (Call it "Maybe-an"?  )  Again, personal experience here, the Tinker Board BT, SD power supply, and MAC address issues all require hacking up the kernel in a not easily supportable way or writing our own drivers.  Some of that wasn't obvious until the Rockchip/ASUS team released the source for their kernel.  In a situation like this, a discussion needs to happen concerning how to support and if/why to support moving forward.  I would personally wait another cycle for the next release and see if any more mainline work is done on the part of the vendor.  If not, we need to decide if something as ridiculous as making the board capable of rebooting properly is our responsibility/interest.  Other boards, I'm sure, are similar.
 
My apologies for rambling.

They are hardware I2C peripherals, so they have buffers/control registers/etc, they are not software implementations that can be disrupted by other tasks.  Worst case you overflow a buffer before reading it.

Yes, it is a reflex that a hobbyist has, "to collect all the things".  Especially when one looks like it should be shinier than the others.  BSP's, true performance, driver catastrophes, kernel defilement doesn't show up in the advertisements for these devices.  It is not helped that the "flagship" SBC in most people's minds out there is the Pi 3, a micro-usb powered usb-hub throttled VPU-constrained machine with very poor resources.  Compared to that, anything with high clock numbers or extra "RAM Chips" looks like an amazing deal, people tend to take the community support over there for granted.
 
I do like the Wiki idea, however in a less ambitious sense:  We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board.  For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.
 
 

Yes, it is a reflex that a hobbyist has, "to collect all the things".  Especially when one looks like it should be shinier than the others.  BSP's, true performance, driver catastrophes, kernel defilement doesn't show up in the advertisements for these devices.  It is not helped that the "flagship" SBC in most people's minds out there is the Pi 3, a micro-usb powered usb-hub throttled VPU-constrained machine with very poor resources.  Compared to that, anything with high clock numbers or extra "RAM Chips" looks like an amazing deal, people tend to take the community support over there for granted.
 
I do like the Wiki idea, however in a less ambitious sense:  We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board.  For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.
 
 

This can be done in the "Private" subforum (IMO no outside interference before the final decision is a must, this thread is a good example), and then the thread can be moved to a visible subforum, either locked or open for discussion and for merging threads/posts related to this board in case it won't be supported.

If my reading over the boot method of these devices is correct, you should be able to trigger it to boot from an SD card via shorting a couple wires together, I think the UT3S uses that recovery button to do it.  Similar buttons probably exist on the cheapies.

Can anyone with a MiQi verify they can correctly reboot using kernel 4.4 ?  @Myy reported that the attempt to implement the Tinker Board reboot change on the 4.12 kernel made the MiQi have reboot issues.  @IgorThis change has not been rolled out on the 4.12 kernel at Armbian, it has been so far unsuccessful, the device is hanging in BootROM mode because the SoC bootloader does not support high speed SD (1.8V) and the kernel does not reset everything before going for reboot.  Another fun Tinker Board issue, one that I'm looking at other devices to see if there are solutions.  Oh, to have my $60 back...    That said, if anyone has an extra MiQi laying about...
 

I'm afraid I can't speak to this issue, although I have tried installing autofs on 4.4 and I got the error you did.  I then tried it on 4.12, and had no errors.  If you don't have a specific requirement for the 4.4 kernel, I'd recommend trying the 4.12.

Thanks tkaiser, I obviously didn't look around hard enough.  :-/
 
*update*
 
wifi firmware added, kernel config updated, and device tree patched.  Anyone using 4.12 should be able to happily use wifi.
 
4.11 may not be worth the effort due to it not having any driver support for the rtl8723bs.  You would have to patch in the driver/etc.

Thanks tkaiser, I obviously didn't look around hard enough.  :-/
 
*update*
 
wifi firmware added, kernel config updated, and device tree patched.  Anyone using 4.12 should be able to happily use wifi.
 
4.11 may not be worth the effort due to it not having any driver support for the rtl8723bs.  You would have to patch in the driver/etc.

@Ruslan Dzanmahmudov I need the patch tested, so the request is directed to anyone using nightly builds or building themselves.  :-).  
 
Interesting micro USB plugs, remember of course the limitations of the pin/pin contact of the USB itself limiting the current to ~1.8 Amps continuous.

Right, but like I've said before, my setup cools quite well, I used a thermal epoxy since there's no hope of a nice mechanical attachment. (25x50 mm heatsink with a little notch to clear that inductor beside the codec), this processor is simply capable of some serious dissipation.  It was unlikely mine would go clear to shutdown, although I didn't let it either way, it was simply significantly exceeding the trip points. I also have no such issues with 4.11 or 4.12.  ;-)  I've made the adjustments to the dtb and am testing.  Definite improvement, however I need to look at the hysteresis values I think, it's jumping to higher clocks prematurely.
 
[edit]
 
Forgot to say, no fan, only larger heatsink I'm seeing 75 C maximum (25 minutes test).  I hit 85 C within 5 minutes before stopping the test before the patch to the tree.  I'm also evaluating the core voltages used here.
 
[edit]  Patch with updated polling and trip points in, voltages will not be experimented with until proper stability testing is performed. 
 
The system was up for just over 2 hours running minerd with the patch, temperature never climbed above 75 C with or without fan.  Try it out, I don't have the same cooling solution as the rest of you, I want the feedback. 

I remember that they had a repository named "rootfs", which had Debian packages for the proprietary drivers and their video codecs libraries. I see that they renamed it rk-rootfs-build. Their packages worked when I tested them, however they were only generated for one specific version of Debian (Debian 9 I think, if I'm not mistaken), and so they tend to depend on specific outdated components versions sometimes.
 
Also, since the drivers provided by the ARM Mali team seem to have better support for some technologies, at some points, I made my little aliases scripts to juggle with the different drivers.
 
That said, on my Gentoo system, I tried to use their drivers to run different KMS/DRM and Wayland GL benchmarks and they work fine. Using mutter and qtwayland was a mess, but I blame these projects for providing terrible error messages and poorly written documentation.

Yes, with kernel 4.4.67, I built it from git two days ago. I could see it throttling fine for a few minutes on rpimonitor
 
Edit: After replacing the heatsink it hasn't shut down. It may have been due to low thermal mass and slow temperature polling frequency. It's still throttling but the temperature is much more stable in the low 70's.
 
Looking back over the rpimonitor stats, with the old heatsink it peaked at 85+ 3 times before the shutdown