suberimakuri

root@nanopi-r4s:~# armbianmonitor -u System diagnosis information will now be uploaded to invalid byte sequence for encoding "UTF8": 0x80 Please post the URL in the forum where you've been asked for. Well whatever: https://paste.debian.net/1181283/
 
I disabled all patches in misc that related to bootsplash because I didn't bother sorting out which patch especially was causing building to fail.
code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } general-rkvdec_nv15.patch needed to be disabled in order to compile successful. Other patches that fail did not do harm.
 

 
Kernel config: https://github.com/EvilOlaf/build/blob/master/config/kernel/linux-rockchip64-dev.config
 
Just noticed the default zswap compressor flipped back to zstd and I hope tkaiser forgives me this flaw since this is just for testing purpose

Hmm... actually yes - is the role of Armbian to teach users about Linux? Probably not, IMHO, they're better served by the Pi Folks - Raspbian is good training wheels for folks dipping their toes into Linux
 
 
The average Armbian user is not a paying customer - there are no Service Level Agreements dictating that any bug of a defined severity level must be fixed within a specific timeframe.
 
So yes - just ignore it for the most part, step in if is sounds fairly interesting - sounds a bit mean spirited perhaps, but generally folks will step in to help out, and if it's really a bug that is directly traceable back to Armbian code - then if it pops up enough, fix it directly, or delegate it to someone who is maintaining it (better to delegate, as that person knows the code likely better).
 
So if someone has problematic hardware - "my whoflungpI Zero2W with the built in XYZ WiFi adapter doesn't work" - well, it might be crap hardware, and in the sub-$50USD field of hacker boards and TV boxes, there's a fair amount of crap - can't fix bad hardware, and there, someone will tell them, use something that does work.

True. Larger developers community is the reason we are getting somewhere in the first place. I am aware of that. Also groups around projects helps to achieve more and less work is doubled, tripled ... but relationship between creators/contributors and average users, "I am new to Linux", support is rather extreme even without dealing with Raspberry Pi herd.
 
User: I am (also) reporting that functionality X is broken. (they have no idea that this "small bug" might represent a project worth months of work)
Two days later.
User: Hey, have you fixed this?
 
If "user" would be my paying customer we would terminate the contract right away. Sadly I am seeing such daily and that's why I am upset. How to deal with this and how to do it less personal way? Just ignore?
 

Sigh...  My guess (entirely guessing, I have not looked yet), is that we or Mainline fixed the Rev 3, which broke the Rev 2.  I am not entirely pleased at the significant hardware changes made by Pine in this case, it is causing problems...

Sharing a bit of feedback:
 
I tried nightly buster minimal build with 5.3 kernel for Rock64 rev2.0 and it does not reach the state when it is accessible over the network. Both LEDs on the ethernet connector are off. I did not connected the HDMI display and moved on to other things.
 
Hope this helps.

@martinayotte@Igor
I finally found where I read about problem on some pine64+ for ethernet, it was in Librelec forums and Jernej added a patch fixing that a few weeks ago : https://github.com/LibreELEC/LibreELEC.tv/blob/9d68e4ba191d7b0bd319e1e254610917e69526e0/projects/Allwinner/devices/A64/patches/linux/03_pine64_plus_ethernet_fixes.patch
 
The last part of the patch is interesting (= could fix my problem) and was queued for kernel 5.4 : https://lkml.org/lkml/2019/9/18/714
 
Grepping for `config-magic-for-pine64` or `regulator-enable-ramp-delay = <100000>` inside armbian build source return nothing so I guess that can be it.
 
I'll try a dev build with this patch tomorrow and report here either way.

Hello, I managed to bump the rockchip-dev kernel to 5.3.y on my fork. After removing a couple of redundant patches and updating two or three of them I'm able to compile with no problems. The new kernel also boots fine on my rk3288.
Don't know if anyone is already working on this (maybe @Igor or @TonyMac32), if my work can ease someone's else fatigue I can make a merge request from my repo to main armbian repo for code review (the single commit is here) documenting the steps I did.

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

@suberimakuri:
 
____ _ | _ \ ___ _ __ ___ __ _ __ _ __| | ___ | |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \ | _ < __/ | | | __/ (_| | (_| | (_| | __/ |_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___| |___/ Welcome to ARMBIAN 5.76 user-built Ubuntu 18.04.2 LTS 4.20.13-rockchip64 System load: 0.02 0.17 0.11 Up time: 8 min Memory usage: 14 % of 1998MB IP: 10.0.0.47 CPU temp: 48°C Usage of /: 12% of 15G [ General system configuration (beta): armbian-config ] So that works, although missing a USB port (bottom USB2 is not with us).