Armbian v20.05 (Kagu) Planning Thread

[sfx2000]

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]

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]

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]

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]

FYI, ayufan updated to 5.6

[martinayotte]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

[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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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