lanefu

@lanefu Ahahah yeah it seems you are describing more a Cluster Node SBC than a NAS which is our main focus at Kobol ;-) Sorry... But yeah while for me PoE = Remote Power Supply for the big family of everything & nothing that we call IoT... I can clearly see the benefit of it for easy clustering of a small SBC compute node.
 
Maybe you should move the topic to a more general Rockchip thread, because honestly I don't think such design would be a priority for us right now... but who knows ;-)

Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
(let me know if this is a bad date, because it is around easter holiday in Germany for example)
 
Code Freeze: 2021-04-19 (Monday April 19th)
Release Date: 2021-05-09 (Sunday May 9th)
Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
Coordinator: @Heisath
 
The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
 
Open topics:
- complete desktop branch merge into master (this seems generally done, but might need fine tuning)
- enable 3D support (also done? Bugfixing)
- discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
- check if remaining boards can / have been updated to LK5.10 (some were left out last release)
- check possible u-boot updates
- complete remaining Jira issues
- cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
- late topics: 
- business meeting schedule
- kernel config changes on arm64
 
Release Planning Meeting Agenda:
 
Please add developers and more topics below, I will then also add them here.
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali

I don't follow the cluster stuff as much as you do lanefu (yet) but because of my recent interest in Pine64 I became aware they sell a CLUSTERBOARD with 7 slots for their SOPINE A64 COMPUTE MODULEs.  Now of course being A64 based these would be less powerful than what you are describing in OP (as well as having different form factor), however OTOH these are actual things you can buy in their store, right now.
 
Not sure how relevant PCIe lanes are to cluster computing, but I guess it depends what the work load is.  Especially if the workload is not CPU based, that could potentially be a killer feature.
 
I also cannot help but speculate it might be too niche a market to interest some mfr.  But what do I know.  A counter point, Pine64 are selling something already in this space, so... who knows?
 
EDIT: I was just watching some NicoD video and was reminded that ODROID N2+ might be even better for this.  The I/O is hobbled (shared USB) but has Gigabit Ethernet (not PoE though) but rates pretty high in his CPU/rendering type benchmarks.
 
Also, I know, it's a "dream" thread, so I hope you don't mind too much my mini review of current solutions (as a comparison, or in case anyone is looking now).  OK, back to "dreaming"... 

Suggestion for a (near future) product.
 
We're still lacking a good SBC out in the wild for small clusters.. Recent SoC performance is good.. Currently all the homelab and k8s nerds are just using RPI4s because they have a header for POE support.    We know there are better options.

We had pitched this to orange pi but weren't receptive. Just sharing my idea here.
 
A Lean SBC exclusively for server tasks.
"The Ultimate Homelab SBC"

Real 802.11at POE+ means only 1 cable for your compute node
Use SPI flash for custom provisioning configuration
 
Optimized for Compute
"Ready for clustering and kubernetes"
Has the Performance and Storage you need to easily deploy for clustered computing

Suggested Reference Specs
RK3399K or similar performant SoC Gigabit Ethernet 4G Dual Channel LPDDR4 16-32gig EMMC SPI flash 128mbit/16megabyte No Wifi No bluetooth No audio No CSI No HDMI USB 3 802.11af/at support or support for RPI4 style 6 pin POE hat All Ports in rear? holes for additional heatsink mounting options

We have a realtime status page for primary Armbian web resources available here:
 
https://status.armbian.com
 

We have a realtime status page for primary Armbian web resources available here:
 
https://status.armbian.com
 

https://status.uptimerobot.com
 
lol

We have a realtime status page for primary Armbian web resources available here:
 
https://status.armbian.com
 

I'll continue to help with PBP..   As you all are familiar my work usually comes in bursts..  But yeah i'd like to build kind of a specific community up for it.. almost wonder if its worth a subforum under RK3399 or osmething.

I'm getting a PBP bare motherboard that i can use for the bare metal testing of liek uboot etc... and @Rich Neesehas a PBP coming in the mail
 

I suppose my question was less where you would run it, and rather what exactly you would want to test.
 
Unit tests are great for functional libraries with known inputs/outputs, but are somewhat trickier with user interfaces.
 
Testing the individual scripts should be more possible if you're looking for actual run products (eg - changes to /etc/apt/sources, or edits to config files).

Well we have a big arm server already configured as a github runner. I suppose we could chroot an armbian rootfs or place in a container 
 
So i guess something that can test armbian-config works as expected

Follow some bash tutorials.  Maybe the advanced bash scripting guide.
 
then just use a text editor and mess with the code
https://github.com/armbian/config
 

@Piezo - did you already try "sysctl -w kernel.sched_rt_runtime_us=-1" - it works well for me for jackd ...
 
best wishes and good luck - hexdump

Since linux v5.4 armbian_build enables the CONFIG_RT_GROUP_SCHED config option.
 
Some armbian users use the soft real-time features for either real-time audio (jackd), or control (eg. klipper_host_mcu),
However, real-time group scheduling, enabled by this options complicates the user space configuration required to acquire real-time scheduling in applications and daemons.
 
Setting ulimit -r or LimitRTPRIO= is no longer enough, it is also required to allocate CPU time for RT task. In a brutal way this can be done as 
 
echo 950000 > /sys/fs/cgroup/cpu,cpuacct/{system,user}.slice/cpu.rt_runtime_us JACK documentation recommends using cgroup-tools for configuration. This is redundant with systemd's own configuration of cgroups hierarchies.
 
However, it is currently not possible to setup with systemd configs files: the team responded "wontfix, accounting rules for RT_GROUP_SCHED are too convoluted for systemd to support"
The systemd's README was updated with the follwing warning:
 
I was hesitant to open an issue on armbuild_config. The changes in the config file are quite recent (Dec 2019) and probably unintentional (kernel default).
But, I could be missing something. Surely lots of folks use RT scheduling on their board. Maybe along with an older kernel ?
Does real-time group scheduling have any use on SBC ?
Do you have simpler solution for this problem (other than CONFIG_RT_GROUP_SCHED=n) ?

So, there are GUI based dialog frontends. Where you would do something like this in dialog:
 
$ dialog --menu "Choose an option" 0 0 0 a argle b bargle  
Or whiptail ...
 
$ whiptail --menu "Choose an option" 0 0 0 a argle b bargle  
You could use a different frontend like zenity to do something similar. Obviously the arguments would change:
 
$ zenity --title "Choose an option" --column tag --column Description --list a argle b bargle  
If you could distill it down to minimum information required to populate either list, you could have a bash wrapper that just calls the specified frontend, or just defaults to the GUI version if the $DISPLAY variable is set.

As a fun little hack, here's a little example wrapper for the dialog program. Mark it executable, toss it in /usr/local/bin, and fire up armbian-config.
 
Obviously delete it afterwards. don't leave it there. That's probably a bad idea.
 
But might work as a brief tech demo of what an X11 driven armbian-config might look like ...
 

dialog

I am not a user of Armbian and do not plan to.
 
Wanted to write here and thank to whoever provided UART U-Boot files as I used them to get my EspressoBin v5 running.
 
Now it has mainline U-Boot 2021.01 and works as normal EBBR board. I plan to use OpenWRT on it and use as a router for some time.
 
Few more words: https://marcin.juszkiewicz.com.pl/2021/02/15/ebbr-on-espressobin/

Create own menu wrapper functions so menu functionality is not hard coded and we can switch between them easily.

OK. It seems we are sticking to BASH. What about desktop?
 
I open this Jira and put down few tasks, those which I am aware of at this moment. Feel free to add / remove things, so we can make some structure. Tasks are just a basic / quick draft.
 
https://armbian.atlassian.net/browse/AR-638
 
I am also cautious about not creating a project we would not be able to move forward. Which is why we have to count resources and see how we can handle this, to which extend and by when. 

Wherein I explain my conversion... 
 
Pine64 was barely on my radar in the past.  There are so many SBC and companies just trying to sell crap it can be hard to tell who is who some times, until you look into one company / board / device or another, a little more in depth.
 
I have been following Librem 5 development for a long time, so I was aware of PinePhone, but they seemed in my mind back then a bit like a "Johnny come lately" who were just trying to capitalize on whatever Purism were trying to do.
 
Then @lanefu was raving about his PineBookPro in IRC, it was only then I started really poking around their forums the last month or so, and now I must say my opinion of them have really changed a lot.
 
Now they seem to me like a really hacker mindset, hardware oriented company.  They really seem to just enjoy making and selling interesting/compelling hardware (for cheap! to get the stuff out there).  They sell spare parts for example, and have a wiki with lots of good information, and schematics, etc.  And they have a nice community forming around their devices, who are in turn, creating spin-off projects...  In short, they seem to be the genuine article (in a time where many other companies are riding on the wave of popularity of "open source" whilst in actuality being nothing of the sort).
 
Purism seem more committed to pushing the supply chain in a F/LOSS direction, but how can we know that Pine64 are not (without being mind readers)?  Well, I have always realized Pine64 are simply taking a different approach.  Some times I fear Purism may have bit off more than they can chew.  They are shipping now, but only in low numbers.  r/Purism is a cesspool of nasty, disgruntled people (maybe I expect too much, it is Reddit, after all).  But if Purism fail, I fear that will set back GNU/Linux on phones overall.  Which is the only thing I really care about.  At any rate, even if I were to order one now, it seems I would be waiting at least a year, also with a less than nil chance of never receiving the device at all, unfortunately.
 
The Pine64 approach, whilst admittedly not as appealing to my inner rms zealot , is perhaps more realistic and attainable.  The older I get, and more real world project / life experience, I start to wonder if this may be the better approach.  Smaller steps, and iteration.  Who knows where it will lead, if we can get more numbers of Linux phones actually in the hands of more people.  For example, apparently some guy already reverse engineered the PinePhone modem OS, and has it running with plain Linux, without blobs!  Amazing!
 
At some point I guess I realized that PinePhone and Librem 5 are not competing with one another, and that none of this is an either/or proposition.  In fact, both projects are advancing the state of the art of GNU/Linux phones; just in different ways.
 
Very recently, I was trying to upgrade to the latest LineageOS on my Galaxy s5.  Of course this is a pain in the arse and why I only get around to really doing it every year or two it seems.  And every time, it seems Google / carriers / whoever have tightened the noose a little bit more.  So, this time around, I finally reached the point where I became so disgusted, that I was willing to actually cancel my cellular service altogether, rather than continue dealing with this nonsense (specifically: VoLTE is becoming mandatory on US carriers, and LineageOS have said they cannot / will not support VoLTE for whatever reason).
 
Importantly, I think it's important to point out that I think any human being needs to reach some tipping point, where our disgust for ${current platform} exceeds the hassle and/or learning curve of switching to ${new platform}.  I have said this many times to people who are curious about switching from Windows -> Linux for example.  Also, this point varies for different people (I get there sooner as I care more about Freedom and have less patience for dinosaur sociopathic proprietary business models, etc.).
 
Anyway, reading some recent threads/posts at Pine64 forums revealed that the PinePhone is currently actually apparently quite usable as a "daily driver" at least for the bare minimum of things I would say that entails: phone/voice (including VoLTE(!)), SMS, and data (on most carriers in US, anyway[0]).  Which was honestly better than I was expecting.  Of course, there are many, many programs in the repositories that do not work properly (or at all) on a phone interface.  And what any individual will consider "bare minimum" acceptable will vary greatly!  But for me at least, that basic phone/data/SMS functionality is enough.  All the rest will not only come in time, if I have a PinePhone in hand I will be able to actively contribute to making it happen, sooner.
 
So, yeah, I pulled the trigger on a PinePhone.      And I plan to use it (more or less) as my "daily driver", likely with my old s5 along side for some period of time, just in case (I figure I should be able to tether it if needed, as tethering is also already working on PinePhone).
 
Long term, I think we still need to continue to push the supply chain in a more explicitly F/LOSS/H direction.  Therefore (assuming they don't go bankrupt before then) I will likely also purchase one or more Librem devices from Purism in the future to support that goal.
 
But buying a PinePhone now gets me in the game, sooner.  And I really started to like what they have going on over there.
 
Please discuss.
 
Cheers,
TRS-80
 
[0] some times requiring workarounds

That makes a lot of sense.
 
 
 
That is a great option!
 
I've now successfully installed NCP and Hass.io (docker) through softy, on a freshly installed Armbian Buster image.
 
Thank you all for all the help!
 
 
 
 

@BenCranston We have sent second version of patches for A3720 which should make 1 GHz mode finally stable. See post https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/?do=findComment&comment=117511
 
If you want to test them, download all patches from emails via (raw) button near Message-ID: line and then apply them, either via `patch -p1 -i filename` or via `git am filename` (if working you have linux sources checkouted from git).
 

For this software, I prefer to use the docker official installation method with standard linux install over docker: https://www.home-assistant.io/docs/installation/docker/

Armbian have historically been much more geared towards "server/headless" usage, for many different reasons.  It has taken a much longer time not only for upstream development of underlying graphical libraries / drivers to mature, but also for us (the Armbian project itself) to come up with a sensible implementation that would fit nicely into our existing build framework.
 
However, this work has been going on in the background for quite some time already. 
 
Announcement
 
Finally, the time is right to announce we are publishing our initial implementation of these "desktop" features!
 
Warning!

We are only announcing this here on our own forums for the time being, as this is still early days.  In fact, at this point we are still mainly looking for testers. You should consider this an alpha quality release at this time!
 
What works so far?

Features we plan to develop works, we are already hunting bugs for months, but they are certainly still present. Remember, we are not looking for bugs that are tied to specific hardware feature, but bugs that are linked to the build process, userland and basic desktop functionality. 
 
Report bugs in Armbian build framework section: https://forum.armbian.com/forum/12-armbian-build-framework/
 
Currently, the following Desktop Environments (DEs) are considered to have early "support":
 

 

 
In addition, there are more DEs which should be considered very much WIP, in other words, not really fully working (yet), but we designed a system that can have unlimited variants.
 
Help Wanted!
 
These changes are wide ranging and touch many parts of the code.  Therefore even if you don't plan on using any "desktop" features, your testing can help to find bugs, even in "server" versions (as eventually this code will be merged with master in matter of weeks).
 
If you have been looking for some opportunity to help the project by getting involved a bit more, this could be your chance!

When you notice a problem make a pull request: https://github.com/armbian/build/pulls ( currently sits on a branch "desktop" )
 
Going forward we will be looking for additional desktop maintainers.  Currently the plan is for the Armbian core team to maintain the framework and perhaps settle on 2-3 DE options.  Any which are to be considered in addition to that, will need to come with some commitment to ongoing maintenance by whoever is interested in those additional desktops.
 
Join #armbian-devel IRC channel for development level chat and strengthen the desktop team. Welcome!
 
Getting Started
 
If this is your very first time using the build scripts, start with general instructions. If you are already familiar with the basics of building, some additional detailed instructions pertaining to desktop features can be found here.  You will also need to add:
 
./compile.sh LIB_TAG=desktop EXPERT=yes  
If you don't have option or desire to build from sources, you can also check if your board has nightly images - we are compiling them from this new development branch for a few weeks now - for the desktop you want to try / see:


 
Documentation
 
For end users, if you just want to build image interactively and by choosing supported OS variants, things hasn't changed much and should just work while advanced documentation has changed significantly. Its pretty much WIP and is scattered around in those files:
 
https://github.com/armbian/build/blob/desktop/config/desktop/README.md
https://github.com/armbian/documentation/pull/125
https://github.com/armbian/documentation/pull/98
 
Additional
 
During this change we also added most recent userland(s):
 

Yep I like the idea of keeping the branch supported...  Glad to help cherry-pick fixes etc as needed etc