TonyMac32

I ran it at 1.8 for about 30 minutes playing videos and keeping it clocked up, I never exceeded 65 C.  That is with the tiny Tinker heat sink, so I think it is ok.  

OK, OPi3 shows dcdca going to 1160000.  The datasheet on the AXP805 has a weird 2-stage step size, but more concerning to me is the fact it seems to suggest there are 72 steps in a  6-bit number...
 
I'll make it match Opi-3 and not mess with the opp other than to correct it's syntax to match the rest of the opps
 
@NicoD even sitting at 1.488 forever running youtube video it isn't even warming up with a Tinker factory heatsink on it.  I think we're probably in good shape heat wise, surprisingly.
 
Oh my goodness this is a nice little board...

I got a GPU RAM water block on mine...    It gets to the mid 60's even then.

Don't you have an XU4?  :-P
 
I saw written somewhere someone was mentioning it would only go to 1.488, I was just confirming, and found a good reason why.  my dmesg looks a lot cleaner, I eliminated some patches that were no longer needed but written a bit differently than the actual mainline code, so some of them half-applied.  . 

Release WIP and CSC images from their own page with very specific limitations, including, but not limited to: no kernel or u-boot updates, ideally with the kernel and u-boot package names modified with -unsupported-
 
Explain these are demo snapshot images, potentially even package a different wallpaper that has -unofficial- or something similar watermarked across it.  Maybe even use the default WM theme.

I have an original Duo for breadboard shenanigans, I just couldn't budget another one since I don't really "need" it

Sent from my Pixel using Tapatalk

Release WIP and CSC images from their own page with very specific limitations, including, but not limited to: no kernel or u-boot updates, ideally with the kernel and u-boot package names modified with -unsupported-
 
Explain these are demo snapshot images, potentially even package a different wallpaper that has -unofficial- or something similar watermarked across it.  Maybe even use the default WM theme.

Release WIP and CSC images from their own page with very specific limitations, including, but not limited to: no kernel or u-boot updates, ideally with the kernel and u-boot package names modified with -unsupported-
 
Explain these are demo snapshot images, potentially even package a different wallpaper that has -unofficial- or something similar watermarked across it.  Maybe even use the default WM theme.

RK3399 support is a total and utter mess.  When we finally fix it, it will break the upgrade path on very nearly every board, since our current patching/boot situation is impossibly convoluted.  Given the OP is not alone, and I completely understand his frustration, just imagine when that happens.  
 
Well, I did say "opinion".  I would guess it takes more than my automotive-engineering-minded release conservatism to shut down or change the direction of the entire project.  I will open a new thread on this topic, I may have a compromise in mind. 

?  Which problems?  I actually have more issues with my C2 and K2...  There is also the likelihood of that SoC (The S905) being EOL'd (if it hasn't already been)  Don't get me wrong, the C2 is a great board, but it is at best on equal support footing with the Le Potato.
 
The issues with the Rock64 are honestly more Rockchip issues, their support of that SoC hasn't really seemed to hit the level of the RK3288 or RK3399.  The RK3288 is still my favorite Rockchip for "normies" because it just works.  No games, no BS, it's about as close to plug and play as you're going to get.  Unfortunately it didn't fit enough buzzwords, so the only boards using it are the MiQi and Tinker Board, with a proper power supply the Tinker is a solid choice, and will run circles around a quad-core A53 in desktop use.  The only competitors so far desktop wise are the RK3399 (support isn't quite there yet) and the Odroid XU4.  (H6 is still pretty buggy I think)

Cleaned up the default kernel patches, clock frequencies for additional video modes, also /proc/board_info exists again (can tell if Tinker or S, might be used by some ASUS software)
 
Also if you build a dev image you have a working kernel 5.1
 

Cleaned up the default kernel patches, clock frequencies for additional video modes, also /proc/board_info exists again (can tell if Tinker or S, might be used by some ASUS software)
 
Also if you build a dev image you have a working kernel 5.1
 

I have recovered my IoT-2G board because, basically I think it can be fun to program it, I also expect an i96, I love its small size (and its price to learn basic things about kernel programming). Armbian has discarded this board, but we have alternative: buildroot, which is great and can be installed in the 512mb flash memory.
You can do things as interesting as this: DHT22+Qt5+Old SD1301
 
 

I plan from my side to bump to u-boot 2019.01, both for rock64 and rockpro64. I used them in the past, but I wanted to have power of using DDR (Rockchip one, as I'm not sure if it still supports DDR4, there was a problem with that for long time) with a custom SPL on top to bring SPI and other support
 
 
I almost rebased all my kernel patches both for 4.4 and 5.x to be very minimal set on top.
 

One Potato, two Potato:  I picked up the smaller 1gb board as a backup to my 2gb Potato running:
 
Linux lepotato 4.19.20-meson64 #5.75 SMP PREEMPT Fri Feb 8 10:08:40 CET 2019 aarch64 GNU/Linux
 
So thanks for fixing that issue for the 1gb boards!  I also pulled up a browser to push it a little, and am impressed with the swap tuning/optimization even when using just the sd card.  An emmc is in my future, but for now on a casual use basis, I can't tell much of a difference in responsiveness between either the 1 or 2gb version for medium duty use.  Nice work.  It's why I like Armbian for tweaking the internals as compared to just a standard install.  I think attention to hard core swap tuning paid off so I don't have to mess with it!
 
No problem with a wireless dongle (model EDUP-AC-1619 [Realtek RTL8811AU]), even when hotplugged.  Mind blown.  Sometimes on the 5.8g side, I'll have to connect to a "hidden" network that actually isn't hidden, and has good signal strength once connected.  Or even if the 5.8ghz signal is not detected, it *eventually* finds and connects.  Who knows if it's the network manager, driver, or whatever.  Not a showstopper, no big deal.  Small beans.
 
Monitor:  22-inch HP22CWA.  Armbian looks great with default monitor settings.
 
Note: I still power-off in the terminal (tricking the blob) using
sudo shutdown -H now
and everything shuts down nicely leaving only the red led on the Potato illuminated, and the display falls asleep.  I don't use the XFCE4 shutdown, logout, or restart functions but rely on the terminal instead.  
 
You guys are rockin' my Potatoes!
 
 

Hehe - my first calculator back when I was 12 or so...
 
http://www.vintagecalculators.com/html/novus_650_-mathbox-.html
 
So stepping into HP RPN calcs was not a problem

I see dust and overpriced coffee... 
 
I have a 50G as part of having been an EE major.  The professors wouldn't support the TI hardware.  And, since I'd done assembly coding of an 8087 math co-processor, RPN made perfect sense to me right away...    I also got the 50 and not the 49 because the 49 was complete garbage, quality wise.
 
 

Because the board is intended to work on any Pi-shaped board that can be powered via gpio, Like a Pi, Le Potato, etc. A lot of those don't pull as much as the ATB.

Sent from my Pixel using Tapatalk

My Potato is up, with the latest Armbian Stretch desktop.  Thanks to all involved - VERY nice.
 
I don't push it very hard - just an initial install, configuration (armbian-config), update, and mostly back to just keyboard and mouse and shell.  You guys made this so easy..
 
Some minor issues, but that's part of the fun.   I might see if I can slim the whole thing down using latest Busybox, which built perfectly first time out of the gate.  Not an expert at doing a busybox system wide replacement, so don't hold your breath.
 
Basically just a quick hello and thanks to everyone for the project.
 

Since 5.0.y is now committed, I'm now going back to the task of getting rid of this old U-Boot SPL 2017.09-armbian ...

You can release it. We will polish the schematic formats and release it anyway...

RockPi-4B was simply copied from RockPro64 as a template.
I was thinking the reverse, and started exploring half hour to try Mainline U-Boot v2019.01 working with RockPro64, but it doesn't seem to be trivial for now (defconfig issues).
I will investigate more later ... For now, my task is to have 5.0.y on all my RK3399 boards : RockPro64 is done, now testing OrangePi-RK3399, next will be my NanoPCT4 and RockPi-4B ...
 

Well, let's avoid other distros and their management as far as discussion topics go.  That's  a bummer, and your patches are welcome here.

@jpegxguy  For the mainline ethernet tx/rx delays, were those just copied from the Rock64 or were they empirically determined?  They're caused by trace impedance/etc, so they're tied to the specific hardware.  I'll dig up the thread/tool Ayufan and Tkaiser were using and see what I get, there might be some more to gain there, since obviously the default ones are fairly bad.
 
@Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.
 
[edit]  Fixed the lower USB port on Renegade.

Yeah I actually missed out that part. My bad.
 
However, that didn't work for me. After copying the files and rebooting I get this in dmesg.
 
$ dmesg | grep -i sdio [ 2.424208] mmc0: new ultra high speed SDR104 SDIO card at address 0001 [ 7.256738] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/9 [ 7.300520] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.txt failed with error -2 [ 8.304313] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50