Armbian v20.05 (Kagu) Planning Thread

sfx2000 · April 4, 2020

On 3/30/2020 at 11:28 PM, Igor said:

@sfx2000 @gprovost I would like not to deal with more gadgets at this point

Concur - it was just an offer - some folks are not IRC aware, so offering the bridge was an alternative.

Consensus says thanks for the offer, but let's keep it simple - all good

sfx2000 · April 4, 2020

On 3/30/2020 at 11:54 AM, Igor said:

I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

With the thread - might be good to set a clear agenda going in.

Not sure how useful I'll be at the moment - helping out with AW-H5, and proposing a new Marvell 3720 target...

Been very busy with an older Qualcomm Snapdragon that nobody has ever heard of these days - insight there might be helpful with other Qualcomm SoC's, but likely not as those targets are not presently supported, and no bandwidth to add them.

1PM GST is pretty early in the morning for me out here on the US West Coast, so might be late to join.

Igor · April 4, 2020

5 hours ago, sfx2000 said:

Concur - it was just an offer - some folks are not IRC aware, so offering the bridge was an alternative.

Agree, which is why I put a discussion to meeting agenda. I am not sure IRC is the best format, but let's give it a try.

It was planned to be the first question, but since you will be late, I will shift it to be among the last.

5 hours ago, sfx2000 said:

With the thread - might be good to set a clear agenda going in.

Agenda:

check meeting attendees (if nick is not self explanatory, add your forum/github handle. Just say hi or something)
choose upcoming release officer (so far it was me and Lane) He has to follow https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md
present tasks, bugs or project you are working on (open discussion if there will not be much people, otherwise meeting officer call you out) and you want that they come to this (and next release). Jira should be open in not already. We need it at minimum for release making and planning.
cycle Jira backlog: (Jira is only partially public, you need access also to read certain parts - we have low Jirafu to set all this)
- discuss task / bug (one at a time)
- assign to person / release / tag
- re-prioritise
cycle open issues and PR on build engine
board status update on download pages and build engine (wip, supported, eol)
change (build) branch protection rule to "Require pull request reviews before merging"
decide upon best meetings hours and technology
misc / open discussion

Tips:

when you got a voice, be concise (1-2 min) and make it clear when you stop. ("No more, I'm done")
channel is recorded so a summary and adjustments to Jira can made afterwards, ideally along with the meeting

There are ofc more stuff to sort out, but we have to start with something managable.

Igor · April 4, 2020

For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work.

Thank you all for attending the meeting!

MaxT · April 4, 2020

FYI, ayufan updated to 5.6

martinayotte · April 4, 2020

1 hour ago, MaxT said:

FYI, ayufan updated to 5.6

That interesting ...

Last time I checked, he didn't even manage to complete 5.4.0-rcX, and I ask him around Christmas if he will update 5.4.0 without RC and also start 5.5.y, and he answered me "after holidays", which he didn't ...

sfx2000 · April 5, 2020

Sorry I missed the meet up on IRC... Between shipping devices out for regulatory approval on Friday, and something hitting me hard like a truck healthwise - woke up around 10AM PDT to an angry cat that missed his morning noms...

Only concerns would be as follows:

1) Armbain EOL images - should still be available - note they're end of support

2) Armbian EOS policy - hard stop for Armbian, but this doesn't mean the upstream Debian/Ubunto packages - those will continue for the life cycles of those distros

3) Bootloader support for devices that have SPI-NOR, eMMC, or naked NAND - uBoot and failsafe recovery

4) Bootloader thought 2- @balbes150 efforts here for getting to a common uboot - it's a very good idea, and worth supporting

5) New Device Onboarding - set min requirements for bringing a device in - not just member/community interest, but also stating reqt's for vendor commitments

6) Armbian Build Platform - one, remove dependency on having sudo/root access, second being that some of the packages to support the build platform are flaky

Some of this might have been out of scope for the meeting this morning.

sfx

Igor · April 5, 2020

8 hours ago, sfx2000 said:

1) Armbain EOL images - should still be available - note they're end of support

2) Armbian EOS policy - hard stop for Armbian, but this doesn't mean the upstream Debian/Ubunto packages - those will continue for the life cycles of those distros

Perhaps main download pages would need some RFC that by default it shows supported + WIP. In case we leave them all it soon gets very cluttered. Once the board falls out of https://github.com/armbian/build/blob/master/config/targets.conf BSP packages are not build anymore while kernel (since its common) does. In rare cases this breaks the board functions ... and since we don't test we don't know.

A solution to this is to come out with a "last BSP package" which differ even rebuild it will always alter welcome prompt "This is EOL image" (now this is unchanged AFAIK) and freeze u-boot, kernel, BSP packages. Meaning no more update to the unknown. Perhaps this is the way to proceed or just leave as is ...

8 hours ago, sfx2000 said:

Bootloader support for devices that have SPI-NOR, eMMC, or naked NAND - uBoot and failsafe recovery

Sorting out all this is a serious project for a few people, perhaps not as serious as this https://mender.io/ but close.

8 hours ago, sfx2000 said:

New Device Onboarding - set min requirements for bringing a device in - not just member/community interest, but also stating reqt's for vendor commitments

If people around armbian has no time & interest, there is little to be done. I have no intention to push on anyone or try to build up a professional team on a hardware vendor behalf that contribute absolutely nothing. We already cover too much and we should perhaps kick out some hardware that is on the bottom of acceptance or has very little vendor support. Support costs is already insane high and adding more is more like a suicide. We have no choice but provide best effort support. If we can't allocate big enough resources its pointless to start with a new board or family.

8 hours ago, sfx2000 said:

Armbian Build Platform - one, remove dependency on having sudo/root access, second being that some of the packages to support the build platform are flaky

It would be nice to fix this. Its one of those - it works, don't touch

balbes150 · April 5, 2020

17 hours ago, Igor said:

For those who couldn't made it, meeting logs:

Unfortunately, not knowing the language, I can only be an observer and read the discussion (through a computer translator) after the fact.

sfx2000 · April 5, 2020

14 hours ago, Igor said:

22 hours ago, sfx2000 said:

1) Armbain EOL images - should still be available - note they're end of support

2) Armbian EOS policy - hard stop for Armbian, but this doesn't mean the upstream Debian/Ubunto packages - those will continue for the life cycles of those distros

Perhaps main download pages would need some RFC that by default it shows supported + WIP. In case we leave them all it soon gets very cluttered. Once the board falls out of https://github.com/armbian/build/blob/master/config/targets.conf BSP packages are not build anymore while kernel (since its common) does. In rare cases this breaks the board functions ... and since we don't test we don't know.

A solution to this is to come out with a "last BSP package" which differ even rebuild it will always alter welcome prompt "This is EOL image" (now this is unchanged AFAIK) and freeze u-boot, kernel, BSP packages. Meaning no more update to the unknown. Perhaps this is the way to proceed or just leave as is ...

Maybe another stage - EOS - for the legacy devices in a tested/known config - don't need to do nightly builds and no fixes moving forward for Armbian items

sfx2000 · April 6, 2020

14 hours ago, Igor said:

22 hours ago, sfx2000 said:

Bootloader support for devices that have SPI-NOR, eMMC, or naked NAND - uBoot and failsafe recovery

Sorting out all this is a serious project for a few people, perhaps not as serious as this https://mender.io/ but close.

recognizing the team's efforts here - there is a lot of problems to solve - and it deserves attention

sfx2000 · April 6, 2020

14 hours ago, Igor said:

22 hours ago, sfx2000 said:

New Device Onboarding - set min requirements for bringing a device in - not just member/community interest, but also stating reqt's for vendor commitments

If people around armbian has no time & interest, there is little to be done. I have no intention to push on anyone or try to build up a professional team on a hardware vendor behalf that contribute absolutely nothing. We already cover too much and we should perhaps kick out some hardware that is on the bottom of acceptance or has very little vendor support. Support costs is already insane high and adding more is more like a suicide. We have no choice but provide best effort support. If we can't allocate big enough resources its pointless to start with a new board or family.

This is likely a document on what is required for Armbian to support a new board for OEM's that desire to have distro support.

We've seen this over and over again - as part of that effort, we need an internal sponsor, and clear guidance on how to get a board supported, along with the LOE of the board vendor to get there...

sfx2000 · April 6, 2020

14 hours ago, Igor said:

23 hours ago, sfx2000 said:

Armbian Build Platform - one, remove dependency on having sudo/root access, second being that some of the packages to support the build platform are flaky

It would be nice to fix this. Its one of those - it works, don't touch

That is probably another discussion - as this is long term ache on the this project - folks work around it in different ways

Igor · May 8, 2020

2020.05 must be finished in 05. month. How are with the time / resources?

Is there anyone that want to assist / learn / get familiar with the release process, that we @lanefu and @Igor can in the future give some load away and do the process review / improvements only? Its really helpful that we share this work. We are not sure this process is already the best, but we are trying the best. Ideas are welcome!

Let's check if something critical is left
https://armbian.atlassian.net/projects/AR/issues/?filter=allopenissues

https://github.com/armbian/build/issues
... otherwise IMO we should proceed to RC when possible.

Igor · May 8, 2020

@TonyMac32 I am chatting with @lanefu with a possibility to move meson current to 5.6.y ... already for this release (better C4 / N4 support, better multimedia) ... any objections from your side?

guidol · May 8, 2020

27 minutes ago, Igor said:

to move meson current to 5.6.y ... already for this release (better C4 / N4 support, better multimedia)

for non-multimedia: got a Pihole on a C2 Armbian Buster with Linux 5.6.8-meson64 without problems
"sleeping" idle at 33 degree

package bsp-kernel[20.05.0-trunk] u-boot[20.05.0-trunk] dtb [20.05.0-trunk]
firmware [20.05.0-trunk] config[20.05.0-trunk] branch [dev]

TonyMac32 · May 9, 2020

[mention=4652]TonyMac32[/mention] I am chatting with [mention=1231]lanefu[/mention] with a possibility to move meson current to 5.6.y ... already for this release (better C4 / N4 support, better multimedia) ... any objections from your side?

I don't see any reason not to, the patchset is a lot of backported stuff anyway.

I have a cranky Asus board here that kernel panics on boot with our 4.4 (sounds familiar), I might scab the device tree into something mainline likes and skip legacy for the moment.
@Lanefu, we need to make sure the big patch isn't "undoing" any of the other patches, I got most of it cleaned up, but not all.

Sent from my Pixel using Tapatalk

Igor · May 15, 2020

I am slowly pushing things forward, so we could slowly make .1 build.

Nightly images are out and are now identical to stable in term of availability. If some variant is missing in nightly, it will miss on stable. In case you see a missing one or you think it should be there, please add missing variants to https://github.com/armbian/build/blob/master/config/targets.conf

Must solve bugs:
https://armbian.atlassian.net/browse/AR-239

Remaining bugs to solve hopefully within this release:

https://bit.ly/3bBGP8k

Need help on testings:

- upgrades from older builds

Testing procedure:

- armbian-config -> system -> switch to nightly builds
- reboot
- armbian-config -> system -> Default desktop install

Hardware that is not so important to test - our automated test rig:

https://dl.armbian.com/_test-reports/2020-05-14_05.54.16.html

guidol · May 16, 2020

10 hours ago, Igor said:

Must solve bugs:
https://armbian.atlassian.net/browse/AR-239

@Igor @RussianNeuroMancer for the chronyd-bug with ubunutu focal you could take a look here
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1878005
where they found a problem/solution:

 * Chrony can't start on platorms that map gettimeofday to
   clock_gettime64()

 * This is due to syscall filtering being correct on some but generic
   enough to cover all areas.

as a temporary solution they wrote:

So we will need to whitelist the clock_gettime64() system call in chronyd’s seccomp filter.
I’ll send a patch upstream.

Meanwhile, you can disable the seccomp filter by running (as root):
# sed -i '/DAEMON_OPTS=/s/"-F -1"/"-F 0"/' /etc/default/chrony
# systemctl restart chrony.service

BTW: My NanoPi A64 with armbian focal kernel 5.6.12 is running
chronyd v3.5-6ubuntu6 normally:

Spoiler

dpkg -l|grep chrony
ii chrony 3.5-6ubuntu6 arm64 Versatile implementation of the Network Time Protocol

systemctl status chrony.service
● chrony.service - chrony, an NTP client/server
Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2020-05-16 08:58:30 +03; 7min ago
Docs: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
Process: 1053 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OPTS (code=exited, status=0/SUCCE>
Process: 1106 ExecStartPost=/usr/lib/chrony/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
Main PID: 1090 (chronyd)
Tasks: 2 (limit: 1014)
Memory: 2.3M
CGroup: /system.slice/chrony.service
├─1090 /usr/sbin/chronyd -F -1
└─1099 /usr/sbin/chronyd -F -1

Mai 16 08:58:30 npi-a64-116 systemd[1]: Starting chrony, an NTP client/server...
Mai 16 08:58:30 npi-a64-116 chronyd[1090]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +S>
Mai 16 08:58:30 npi-a64-116 chronyd[1090]: Loaded seccomp filter
Mai 16 08:58:30 npi-a64-116 systemd[1]: Started chrony, an NTP client/server.
Mai 16 08:58:39 npi-a64-116 chronyd[1090]: Selected source 91.189.94.4
Mai 16 08:58:39 npi-a64-116 chronyd[1090]: System clock wrong by -1.316089 seconds, adjustment started
Mai 16 08:58:38 npi-a64-116 chronyd[1090]: System clock was stepped by -1.316089 seconds
Mai 16 08:58:40 npi-a64-116 chronyd[1090]: Selected source 194.27.222.5

ps -ef|grep chronyd
_chrony 1090 1 0 08:58 ? 00:00:00 /usr/sbin/chronyd -F -1
_chrony 1099 1090 0 08:58 ? 00:00:00 /usr/sbin/chronyd -F -1
root 1509 1445 0 09:21 pts/0 00:00:00 grep --color=auto chronyd

System diagnosis information has been uploaded to http://ix.io/2mbU

Igor · May 16, 2020

Yesterday stress test https://dl.armbian.com/_test-reports/2020-05-15_19.45.41.html was fatal for OPi Lite 2. Board powered off ... probably throttling is not working well (on all H6 ?) and critical temperature was reached.

@guidol Thanks.

Igor · May 16, 2020

Today stress test killed:

"Orange Pi Zero Plus"
"Orange Pi Prime"
"NanoPi Neo"
"Pine H64"

... Houston, We Have a Problem. @megi Before I start to dig in ... do you think this is generally broken or is it a consequence of our improvements?

megi · May 16, 2020

46 minutes ago, Igor said:

Before I start to dig in ... do you think this is generally broken or is it a consequence of our improvements?

Not sure. I'm running my 5.6 and 5.7 branches on various orange pis and throttling seems to work for me. (Just tested on H6 (Opi3) and H5 (Opi PC 2), and H3 (Opi One), to be sure)

So maybe it's some extra patch in armbian.

Igor · May 16, 2020

3 hours ago, megi said:

Not sure. I'm running my 5.6 and 5.7 branches on various orange pis and throttling seems to work for me. (Just tested on H6 (Opi3) and H5 (Opi PC 2), and H3 (Opi One), to be sure)

So maybe it's some extra patch in armbian.

Checking ... it works perfectly correct here too (H3 / Nanopi Neo, no heatsink) http://ix.io/2mf8 but it still reaches critical temperature (100°) which initiates shutdown.

@megi How to tune things to go lower than 1008Mhz since temps go up and up ... to the 100?

Igor · May 20, 2020

Today's stress testings: https://dl.armbian.com/_test-reports/2020-05-19_20.25.35.html

Victims - boards that didn't survive:

"Orange Pi Lite"
"Orange Pi Lite 2"
"Rock 64"
"NanoPi Neo"
"Pine H64"
"NanoPC T3+"
"Orange Pi+ 2E"

Investigation follows ...

Igor · May 20, 2020

Test report: https://dl.armbian.com/_test-reports/2020-05-20_17.14.00.html

- apt update + upgrade
- iperf lan & wifi
- iozone and reboot

Spotted problems:

https://armbian.atlassian.net/browse/AR-244
https://armbian.atlassian.net/browse/AR-275

Devices that didn't survive this:

Opi Lite

6 tasks to go:

https://armbian.atlassian.net/projects/AR/versions/10002/tab/release-report-in-progress
https://armbian.atlassian.net/projects/AR/versions/10002/tab/release-report-todo

Myy · May 21, 2020

If anyone could test the following pull request, with a Tinkerboard and a screen supporting resolutions like 1366x768, this should settle the HDMI issues with RK3288 boards for now :

https://github.com/armbian/build/pull/1887

Note : I prepared a Debian Bullseye image with the patches reworked here : https://miouyouyou.fr/static/Armbian_20.05.0-trunk_Tinkerboard_bullseye_dev_5.5.19_desktop.img

Since it uses the reworked patches, and not the patches as provided in the pull request, if that doesn't work, give the pull request patches a try !

The reworked patches are available here : https://github.com/Miouyouyou/build/tree/Rework/patch/kernel/rockchip-dev (4005 to 4012)

Igor · May 21, 2020

Help.

https://armbian.atlassian.net/browse/AR-213 (a ordinary user will have .xz image now, while our docs are telling him to unpack 7z)

https://armbian.atlassian.net/browse/AR-244 (https://forum.armbian.com/topic/13993-nanopiduo2-not-booting-after-intense-processing-task/

belfastraven · May 22, 2020

Igor, re your first request, I looked at the linked page, but didn't see anywhere there anything that indicates that the compressed file would be 7z. It says to use 7-zip or p7zip to uncompress the file, which should also work for xz files. Did you want to indicate that the compressed files would be .xz? Do you have a preference that a different tool be used?

Werner · May 22, 2020

The compression algoryhm has been changed to xz a few weeks/month ago as AFAIR it has the benefit that the compressed image can directly be fed into an image writer tool.

5kft · May 23, 2020

On 5/16/2020 at 12:42 PM, Igor said:

How to tune things to go lower than 1008Mhz since temps go up and up ... to the 100?

@Igor - I just checked in a new patch that fixes the thermal throttling issues (see https://github.com/armbian/build/commit/cc55d03a7b306e80f6fae1e16de1942af5fe9701). I have tested it extensively on the H5 (Nano Pi NEO2 Black) and throttling works great now.

Example run after several minutes of "cpuburn-a53":

Spoiler

00:49:15: 960MHz 3.69 100% 0% 99% 0% 0% 0% 89.8°C 5/8
00:49:20: 816MHz 3.72 100% 0% 99% 0% 0% 0% 89.8°C 6/8
00:49:25: 816MHz 3.74 100% 0% 99% 0% 0% 0% 90.3°C 6/8
00:49:30: 960MHz 3.76 100% 0% 99% 0% 0% 0% 90.0°C 5/8
00:49:35: 816MHz 3.78 100% 0% 99% 0% 0% 0% 88.8°C 6/8
00:49:40: 816MHz 3.80 100% 0% 99% 0% 0% 0% 90.3°C 6/8
00:49:45: 648MHz 3.81 100% 0% 99% 0% 0% 0% 88.4°C 6/8
00:49:50: 816MHz 3.83 100% 0% 99% 0% 0% 0% 91.1°C 6/8
00:49:55: 816MHz 3.84 100% 0% 99% 0% 0% 0% 92.0°C 6/8
00:50:00: 816MHz 3.86 100% 0% 99% 0% 0% 0% 91.7°C 6/8
00:50:06: 816MHz 3.87 100% 0% 99% 0% 0% 0% 90.7°C 6/8
00:50:11: 816MHz 3.88 100% 0% 99% 0% 0% 0% 90.9°C 6/8
00:50:16: 816MHz 3.89 100% 0% 99% 0% 0% 0% 91.6°C 6/8
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St.
00:50:21: 816MHz 3.90 100% 0% 99% 0% 0% 0% 91.7°C 6/8
00:50:26: 816MHz 3.91 100% 0% 99% 0% 0% 0% 91.3°C 6/8
00:50:31: 816MHz 3.91 100% 0% 99% 0% 0% 0% 93.5°C 6/8
00:50:36: 816MHz 3.92 100% 0% 99% 0% 0% 0% 91.0°C 6/8
00:50:41: 816MHz 3.93 100% 0% 99% 0% 0% 0% 91.3°C 6/8
00:50:46: 816MHz 3.93 100% 0% 99% 0% 0% 0% 93.5°C 6/8
00:50:51: 816MHz 3.94 100% 0% 99% 0% 0% 0% 92.9°C 6/8
00:50:57: 816MHz 3.94 100% 0% 99% 0% 0% 0% 92.6°C 6/8
00:51:02: 816MHz 3.95 100% 0% 99% 0% 0% 0% 93.8°C 6/8
00:51:07: 816MHz 3.95 100% 0% 99% 0% 0% 0% 92.6°C 6/8
00:51:12: 816MHz 3.96 100% 0% 99% 0% 0% 0% 94.2°C 6/8
00:51:17: 816MHz 3.96 100% 0% 99% 0% 0% 0% 93.6°C 6/8
00:51:22: 816MHz 3.96 100% 0% 99% 0% 0% 0% 92.9°C 6/8
00:51:27: 816MHz 3.97 100% 0% 99% 0% 0% 0% 94.8°C 6/8
00:51:32: 816MHz 3.97 100% 0% 99% 0% 0% 0% 93.2°C 6/8
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St.
00:51:37: 816MHz 3.97 100% 0% 99% 0% 0% 0% 93.3°C 6/8
00:51:42: 816MHz 3.97 100% 0% 99% 0% 0% 0% 93.3°C 6/8
00:51:48: 816MHz 3.98 100% 0% 99% 0% 0% 0% 94.1°C 6/8
00:51:53: 816MHz 3.98 100% 0% 99% 0% 0% 0% 94.1°C 6/8
00:51:58: 816MHz 3.98 100% 0% 99% 0% 0% 0% 94.6°C 6/8
00:52:03: 648MHz 3.98 100% 0% 99% 0% 0% 0% 95.1°C 7/8
00:52:08: 648MHz 3.98 100% 0% 99% 0% 0% 0% 95.1°C 7/8
00:52:13: 816MHz 3.99 100% 0% 99% 0% 0% 0% 92.7°C 6/8
00:52:18: 816MHz 3.99 100% 0% 99% 0% 0% 0% 93.6°C 6/8
00:52:23: 816MHz 3.99 100% 0% 99% 0% 0% 0% 94.5°C 6/8
00:52:28: 816MHz 3.99 100% 0% 99% 0% 0% 0% 94.5°C 6/8
00:52:33: 816MHz 3.99 100% 0% 99% 0% 0% 0% 90.9°C 6/8
00:52:38: 816MHz 3.99 100% 0% 99% 0% 0% 0% 91.4°C 6/8
00:52:44: 816MHz 3.99 100% 0% 99% 0% 0% 0% 93.0°C 7/8
00:52:49: 816MHz 3.99 100% 0% 99% 0% 0% 0% 91.4°C 6/8
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St.
00:52:54: 816MHz 3.99 100% 0% 99% 0% 0% 0% 92.7°C 6/8
00:52:59: 816MHz 4.00 100% 0% 99% 0% 0% 0% 91.7°C 6/8
00:53:04: 816MHz 4.00 100% 0% 99% 0% 0% 0% 93.9°C 6/8
00:53:09: 816MHz 4.00 100% 0% 99% 0% 0% 0% 92.7°C 6/8
00:53:14: 816MHz 4.00 100% 0% 99% 0% 0% 0% 92.6°C 6/8

The new patch includes the same changes for the H3, and I tested on an Orange Pi Zero H2+ with no heatsink, using both "stress" and "cpuburn-a7", and it works great. Here's an example run using "cpuburn-a7":

Spoiler

14:17:05: 480MHz 3.83 11% 6% 4% 0% 0% 0% 67.6°C 0/4
14:17:10: 480MHz 3.52 1% 0% 0% 0% 0% 0% 65.6°C 0/4
14:17:15: 480MHz 3.24 1% 0% 0% 0% 0% 0% 65.6°C 0/4
14:17:20: 480MHz 2.98 2% 1% 0% 0% 0% 0% 63.9°C 0/4
14:17:26: 480MHz 2.74 1% 1% 0% 0% 0% 0% 63.7°C 0/4
14:17:31: 480MHz 2.52 2% 1% 1% 0% 0% 0% 63.7°C 0/4
14:17:36: 480MHz 2.32 1% 1% 0% 0% 0% 0% 62.6°C 0/4
14:17:41: 1008MHz 2.13 2% 0% 1% 0% 0% 0% 64.8°C 0/4
14:17:46: 480MHz 1.96 3% 1% 1% 0% 0% 0% 62.2°C 0/4
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St.
14:17:51: 480MHz 1.89 1% 1% 0% 0% 0% 0% 62.1°C 0/4
14:17:57: 480MHz 1.67 1% 1% 0% 0% 0% 0% 61.5°C 0/4
14:18:02: 480MHz 1.54 1% 0% 0% 0% 0% 0% 62.2°C 0/4
14:18:07: 480MHz 1.41 2% 1% 0% 0% 0% 0% 61.5°C 0/4
14:18:12: 1008MHz 1.30 11% 4% 5% 0% 0% 0% 63.7°C 0/4
14:30:56: 480MHz 1.19 1% 1% 0% 0% 0% 0% 61.0°C 0/4
14:31:01: 480MHz 1.10 1% 1% 0% 0% 0% 0% 60.5°C 0/4
14:31:06: 480MHz 1.01 1% 0% 0% 0% 0% 0% 60.8°C 0/4
14:31:11: 480MHz 0.93 1% 0% 0% 0% 0% 0% 60.2°C 0/4
14:31:16: 480MHz 0.85 1% 1% 0% 0% 0% 0% 60.3°C 0/4
14:31:22: 480MHz 0.79 2% 1% 0% 0% 0% 0% 60.7°C 0/4
14:31:27: 1008MHz 0.72 10% 3% 5% 0% 0% 0% 64.1°C 0/4
14:31:32: 480MHz 0.66 0% 0% 0% 0% 0% 0% 60.5°C 0/4
14:31:41: 816MHz 0.93 92% 0% 91% 0% 0% 0% 77.3°C 2/4
14:31:52: 648MHz 1.48 100% 0% 99% 0% 0% 0% 79.9°C 3/4
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St.
14:32:06: 648MHz 2.18 100% 0% 99% 0% 0% 0% 80.2°C 3/4
14:32:19: 648MHz 2.73 100% 0% 99% 0% 0% 0% 80.8°C 3/4
14:32:34: 648MHz 3.07 100% 0% 99% 0% 0% 0% 81.2°C 3/4
14:32:49: 648MHz 3.42 100% 0% 99% 0% 0% 0% 82.6°C 3/4
14:33:03: 648MHz 3.69 100% 0% 99% 0% 0% 0% 83.8°C 3/4
14:33:17: 648MHz 3.90 100% 0% 99% 0% 0% 0% 84.4°C 3/4
14:33:32: 648MHz 4.07 100% 0% 99% 0% 0% 0% 85.4°C 3/4
14:33:47: 648MHz 4.19 100% 0% 99% 0% 0% 0% 84.9°C 4/4
14:34:02: 480MHz 4.36 100% 0% 99% 0% 0% 0% 84.0°C 3/4
14:34:17: 648MHz 4.43 100% 0% 99% 0% 0% 0% 85.1°C 3/4
14:34:33: 480MHz 4.47 100% 0% 99% 0% 0% 0% 84.8°C 4/4
14:34:49: 648MHz 4.51 100% 0% 99% 0% 0% 0% 84.6°C 3/4
14:35:05: 648MHz 4.54 100% 0% 99% 0% 0% 0% 85.5°C 3/4
14:35:21: 480MHz 4.64 100% 0% 99% 0% 0% 0% 84.9°C 4/4
14:35:36: 648MHz 4.67 100% 0% 99% 0% 0% 0% 86.0°C 3/4
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St.
14:35:52: 648MHz 4.80 100% 0% 99% 0% 0% 0% 85.1°C 4/4
14:36:08: 480MHz 4.77 100% 0% 99% 0% 0% 0% 84.8°C 3/4

Edited May 23, 2020 by 5kft
Tested on an H3 board and added results of test run

Sign In

Armbian v20.05 (Kagu) Planning Thread

Recommended Posts

sfx2000

sfx2000

Igor

Igor

MaxT

martinayotte

sfx2000

Igor

balbes150

sfx2000

sfx2000

sfx2000

sfx2000

Igor

Igor

guidol

TonyMac32

Igor

guidol

Igor

Igor

megi

Igor

Igor

Igor

Myy

Igor

belfastraven

Werner

5kft

Forums

My Activity Streams

Download

Store

Important Information