Igor

... has been changed to https://github.com/armbian/build/blob/master/lib/main.sh#L395-L396 so this package is only board specific now. Similar variant will come for desktop.

Anyway, since release days are over, this can be moved in - if ready. FYI, there is another larger chunk of additions by @rpardini which needed review, understanding and integration. Not directly related, but imo it's wise not to merge both at once. @lanefu

I had the same issue.
 
Created a PR: https://github.com/armbian/build/pull/2818
 
Thanks for the fix olegoldtom !!
 
 

Nah, all good from here. I'll try to do the release this sunday. Might hop in the IRC if I need assistance. Release on sunday evening is good IMHO because if something critical goes wrong, we can fix on monday.

... because hardware wants to provide a working solution instead of piloting brand new SoC that might have unusable software support for years to come. We all will be frustrated, tensted, sales will go down ... WHY? 
 
It is hard to predict more without deep investigation, but users / buyers expect top notch SW support and are willing to pay nothing for that. But someone has to pay that bill. Costs of software support is enormous, much bigger than HW design and that fact doesn't allow such products to happen. That is certainly not fault of a few people that tries to create a wonderful new hardware or folks that supports users on a voluntary basis.

Even with reasonable well supported many years old RK3399 problems are still present in greater way we all would like.
 
 
Wish you fast recovery. I also need that 

... because hardware wants to provide a working solution instead of piloting brand new SoC that might have unusable software support for years to come. We all will be frustrated, tensted, sales will go down ... WHY? 
 
It is hard to predict more without deep investigation, but users / buyers expect top notch SW support and are willing to pay nothing for that. But someone has to pay that bill. Costs of software support is enormous, much bigger than HW design and that fact doesn't allow such products to happen. That is certainly not fault of a few people that tries to create a wonderful new hardware or folks that supports users on a voluntary basis.

Even with reasonable well supported many years old RK3399 problems are still present in greater way we all would like.
 
 
Wish you fast recovery. I also need that 

It’s been 3 months since we posted on our blog. While we have been pretty active on Armbian/Kobol forum for support and still working at improving the software support and stability, we have been developing in parallel the new iteration of Helios64 around the latest Rockchip SoC RK3568.
 
However things haven’t been progressing as fast as we would have wished. Looking back, 2020 has been a very challenging year to deliver a new product and it took quite a toll on the small team we are. Our energy level is a bit low and we still haven’t really recovered. Now with electronic part prices surge and crazy lead time, it’s even harder to have business visibility in an already challenging market.
 
In light of the above, we decided to go on a full break for the next 2 months, to recharge our battery away from Kobol and come back with a refocused strategy and pumped up energy.
 
Until we are back, we hope you will understand that communication on the different channels (blog, wiki, forum, support email) will be kept to a minimum for the next 2 months.
 
Thanks again all for your support.

Current situation on our test farm - except from Odroid C4 and Lepotato boot issue - power cycle is needed, things are fairly stable:

 

 

Wonderful news! I briefly checked your project and it seems to match our ideas on (unit) testing. I am Ansible newbie, know basics, while @lanefu (US) is more experienced in this and we should all come together on chat - we are hanging out here https://docs.armbian.com/Community_IRC/. Our most active hours starts from lunch break, when US people gets up and evenings, late night, CET.
 
Thanks!

The issue has been discussed and solved in a recent post for OPi PC, it should also work for Zero
 

C language was all I did - last century! I'd love to contribute any changes I need to make, but at the moment, the language is barely recognizable anymore. Such a shame.

A final note in case someone else bumps on something similar: stability problems persisted, so we returned the computer and the shop switched both CPU and motherboard. We have been running without issues since that.

Do that 1st. I tried many variants, also tried Arch out of despair when trying to get NVME working at full speed, which could be BIOS problem ... since it actually work, just sometimes doesn't. At the end settled with Ubuntu 20.04 Mate. Light desktop was anyway planned.
 

Absolutely. Ours is on (a quality) 650W (stronger is in another machine and swap was planned) and it didn't burst into the flames when overclocked to max. But UPS started to sing an overload song when I tried that.

@those who didnt make it: 
 
No problem, just check the meeting log http://meeting.armbian.de/ , the irc chat log (irc.armbian.com/logs) and the Jira issues for the next release (https://armbian.atlassian.net/secure/RapidBoard.jspa?projectKey=AR&rapidView=2)
 
@all:
 
For the next weeks, remember to try and fix Jira issues (also mark them as done), review open PRs and issues on github. And try to get your work done before the codefreeze 2021-04-19 (Monday April 19th).
 
@Igor:
Wouldn't say so. I asked about the holiday thing in first post, also with note to possible reschedule. People could've said something beforehand
 
@the new release dude:
Show yourself! It's easy and a good way to help the project without  needing to get all technical.

It seems this part is broken - currently for unknown reasons - affected all (many) A20 boards:
It seems due to regression in DT config. Possible solution: https://github.com/armbian/build/pull/2750/commits/59797c3324e5f2db4a7727126a770049d274290c

Not booting entirely by itself, but progress here on microzed branch.
 
armbianmonitor
 

Its never to late to learn something 
 
1. https://docs.armbian.com/Developer-Guide_Build-Preparation/
2. Run compilation with ./compile.sh CREATE_PATCHES="yes"
3. Skip u-boot change prompt and wait for kernel change prompt.
4. Open second terminal and edit file (under su):
 
sudo nano  cache/sources/linux-mainline/orange-pi-5.10/arch/arm/boot/dts/sun7i-a20-orangepi.dts  
also do this for its other variant
 
sudo nano  cache/sources/linux-mainline/orange-pi-5.10/arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts  
and change those bits. Save and exit.
4. When you are done go back to initial terminal and proceed with compilation.
5. If everything went well, move patch from output/patch/ to patch/kernel/archive/sunxi-5.10/name_it_somehow.patch (you can also copy the same patch for sunx-5.11 since it will almost certainly work and its needed there too)
6. Create a PR
 
This might also help
https://docs.armbian.com/Process_Contribute/
 

@piter75 I've had no issues with my M4V2 since setting the governor to "userspace" and max and min speeds set to "1416000" (and by no issues, I mean no crashes at all and I have an uptime of 20 days now), but I wonder if your fix is for the issues we've seen with the governor set to "ondemand"?

Would come handy sometimes. For the next version of our test gears perhaps.
 
https://www.armbian.com/olimex-lime-2-emmc/
160 
 

FAT is not a problem. https://github.com/armbian/build/blob/master/config/boards/odroidc1.csc#L7-L8 Build system can support weird boot processes - this way:

https://github.com/armbian/build/blob/master/config/sources/families/mvebu64.conf
https://github.com/armbian/build/blob/master/config/sources/families/include/meson64_common.inc
 

Quite a while ago developers decided to rename the dev branch to edge to reflect its purpose better: https://armbian.atlassian.net/browse/AR-233
 
This now finally happened. Our documentation has been adjusted as well. For details feel free to check these commits:
 
https://github.com/armbian/documentation/commit/6c9985c9f5a0f593ab2593eb8054b6c658445d25
https://github.com/armbian/build/commit/0cdffb29b07305209efb12cf3b5ac6032d3a1153
 
For those who do automated and/or scripted building take note to adjust it accordingly.
 

That is correct. Support: https://docs.armbian.com/#what-is-supported creates costs which are 99% covered by us, which means it will wait for a free slot. This can be stretched from days to years. You have to understand that this vendor never covered us a single minute for supporting troubles their customers have by using (one if not the best available) OS for their hardware. Nor "you" see and feel the necessity to cover support costs you make. Since none of you see value in getting help, there is no warranty we will fix this and you might need to wait months ... 
 
Workaround = use old builds.

Another things I've been playing with in my spare time. Better identification of the SoC that some of these boards use. For example my NanoPi M4V2 (RK3399) kicks back this:
 
tparys@hobbes:~$ ./arm-chip-id.sh 4x Arm Cortex-A53 @ 1416 MHz 2x Arm Cortex-A72 @ 1800 MHz  
Not sure if it's useful, but might be more descriptive for end users who don't know much about their systems, or for describing controls for each CPU cluster in their SoC (see this post). Apologies in advance the bash is a little hard to read as it's digging through sysfs topology bits.
 
It also breaks if the first CPU in a cluster is knocked offline. Not like anyone would do that, right?
arm-chip-id.sh arm-chip-id.db

@IgorPlease do not think that your efforts are unappreciated - they are, and greatly so. I was simply concerned that the board status was not what I expected. 
 
I also agree with the work-around - and thus me taking the builds and working out which would work for @robocone
 
I am also not adverse to providing workarounds when I can, and, as time allows, I will attempt to identify exactly where the problem is, and share same.
 
Once more, the efforts here are greatly appreciated (at least by myself) and I remain grateful for all of your efforts. If I can find the cause then I shall do so, but. for me. the 'free' is very valuable
 

Great! Looks promising and IMO it's probably a way to go unless there are (much) better ways?
 
Now we need someone with some spare time and some experience in managing (such) projects  
 

We also need to have a complete design, plan of actions and some definition of done per sections. Some draft was initiated https://armbian.atlassian.net/browse/AR-638 
 
 
but someone has to step up and keep an eye on the overall project execution structure and speak up when needed. I have time to help here and there, to cheer up, but can't drive development or do much of coding since I already drive too many things. My performance would be terrible and most of current contributors are also in the same situation. This should be an opportunity for fresh people which have a desire to help on community projects with their know-how and scriptfu.
 
Who can work on this and how much? Finding and calling out people that were complaining or recommending things related to this script, those who were filing an issue might also be good way to start? This is their opportunity to add their 2c directly to the code instead opening an issues that were actually never addressed.

We can't say their motivation is bad within this move, but MS loves Linux is still a wolf disguised into a sheep. As bad intention can only be classified as a speculation and it is hard to prove they are actually doing something bad, making it possible or have a direct possibility is bad enough. If folks, one don't trust, have root and if they also control your ignition ... 

Raspberry Pi OS started to secretly (!?) adding Microsoft proprietary package base, access to their servers, by default. 
 
Security consequences? tl;dr; ... Microsoft gained root access to millions of Rpi users without their consent or awareness. From the outside. This is bad, but it is actually much worse since from the inside they already have full control of your Raspberry Pi regardless of operating system of your choice. Linux/BSD/* can't boot without proprietary Microsoft owned real time OS.
 
Most of the RPi users probably just don't care, others are naively assuming they are running FOSS software. Well, a part of it is, a part not. Not as bad as Android, but still. You can peek into the code, but at the end, Google, or lets say corpo world, is/are fully in charge of our mobile devices. Mainly with services.
 
After recent Chromium improvements, this is yet another loss for (Linux) community and FOSS in general.
 
http://techrights.org/2021/02/02/microsoft-pi/
https://en.wikipedia.org/wiki/ThreadX
https://www.infoworld.com/article/3536569/inside-microsofts-latest-os-azure-rtos.html
https://www.zdnet.com/article/linux-distributors-frustrated-by-googles-new-chromium-web-browser-restrictions/