5kft

I just pushed a patch with the test changes for this to my local repo: https://github.com/5kft/build/commit/b75929e99f67a5d628bc031a1c4e73ab287c7df7. This patch is against the "sunxi-current" target. I can make a PR for this change, but again I don't have an H6 board to test any of this on, and I'd rather not do a PR until we know it works. Also, I'm not sure what the appropriate critical temperature is for the H6, so in this patch I left it at 105C just like for the H3/H5. It'd be great if you could give this a try on your OPi1+. You should be able to change directory to "/sys/class/thermal/thermal_zone0", and see the six new trip points. To test these changes on my H3s and H5s, I used "armbianmonitor -m" in "screen", with both "stress" and the appropriate "cpuburn" for the architecture (see https://github.com/ssvb/cpuburn-arm). The reported CPU clock rate should change appropriately when the temperature passes the various trip points. If this works I'd be happy to submit a PR for this change.

Unfortunately I don't have any H6 boards, so I've never looked into this for the H6... However I just took a quick look at the DT include "sun50i-h6.dtsi" (in ".../arch/arm64/boot/dts/allwinner/") and it appears to be missing the same thermal-zones definitions as needed for the H3 and H5 to throttle down: thermal-zones { cpu-thermal { polling-delay-passive = <0>; polling-delay = <0>; thermal-sensors = <&ths 0>; trips { cpu_hot_trip: cpu-hot { temperature = <80000>; hysteresis = <2000>; type = "passive"; }; cpu_very_hot_trip: cpu-very-hot { temperature = <100000>; hysteresis = <0>; type = "critical"; }; }; cooling-maps { cpu-hot-limit { trip = <&cpu_hot_trip>; cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; }; }; }; If someone were to want look into this, I would suggest creating a patch containing the appropriate changes like I did for the H5 and see if it works for the H6 (at least if I had an H6 I would try this first...) E.g., see https://github.com/armbian/build/blob/master/patch/kernel/sunxi-current/update-correct-h3-h5-thermal-zones.patch. I hope this helps!

Fixed! I marked this as Done (both sunxi-current and sunxi-dev, tested on both for H5 and H3)

@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": 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":

Yes, that's it! The "cooling-device entries" map to the CPU clock frequencies to use - this is what makes it clock down and cool off. With these missing, it's just going to overheat and hit critical...

I wouldn't think that would be the case... I would really need to refresh my memory on this area, but in doing a quick check of the DTs it seems that the cooling maps are much smaller/simpler than they were previously (?) - e.g., thermal-zones { cpu_thermal: cpu-thermal { polling-delay-passive = <0>; polling-delay = <0>; thermal-sensors = <&ths 0>; trips { cpu_hot_trip: cpu-hot { temperature = <80000>; hysteresis = <2000>; type = "passive"; }; cpu_very_hot_trip: cpu-very-hot { temperature = <100000>; hysteresis = <0>; type = "critical"; }; }; cooling-maps { cpu-hot-limit { trip = <&cpu_hot_trip>; cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; }; }; }; IIRC, there used to be more passive trips that would keep the CPU cooler earlier before hitting critical, weren't there? I was thinking of going to go back in time and look at some older ones to compare...I figure starting there might help provide some insight.

@Igor - in case this is helpful, might this be fixed for the Duo2 by making the same/a similar change like I did for the R1? See my change here: https://github.com/armbian/build/commit/88023e0eccbf25c8a22d6365d20d9bc4df78003b. I believe the Duo2 uses the same power circuit as the R1. By adding the correct regulator entry for the MP2143DJ then the correct CPU clock values will be used. (I didn't make this change originally as I don't have a Duo2 to verify the changes on.)

Totally agree!! There are faster/more powerful boards, but the NEO form-factor is super nice - the Plus2 is awesome as it has eMMC + Wi-Fi, and the Black is awesome because of the eMMC socket and variable-voltage regulator (allowing up to 1.4GHz operation), and perhaps most importantly the tiny 40mm^2 size. Their small metal cases for all of these are super nice as well. I only hope that they continue with the tiny form-factor with the replacements...!!

Given that all of these platforms are showing the same issue, it seems likely that you may have a hardware issue with the board...?

@nikolatesluh. I agree with sfx2000 - can you capture the u-boot process from the serial console and provide it on this thread? Did it show this problem under Ubuntu Core? I've never seen this happen on any of my NEO Plus2s. I just updated to a latest top-of-tree build, and it still shows 1GB RAM, e.g., [ 0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Memory: 872848K/1048576K available (10942K kernel code, 728K rwdata, 2812K rodata, 768K init, 292K bss, 44656K reserved, 131072K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] rcu: Hierarchical RCU implementation. ... total used free shared buff/cache available Mem: 1013188 109144 786436 2980 117608 829460 Swap: 506592 0 506592

Agreed Agreed as well!

Interesting...this reminds me of a post from my OrangePi overclocking thread: https://forum.armbian.com/topic/6866-orange-pi-zero-plus2-h5-hardware-oddity-in-vdd_cpux-power-circuit/?do=findComment&comment=52485, where @Da Xue notes:

Yes these look quite familiar... It'd be great if they were pushed upstream, it could reduce our patchset size. I wonder why they were never taken?

Yes, it's working just as it should

@sfx2000 Well, considering where this all started, it is great to see it stable at least If you're interested, we could try clocking the CPU at 1.1GHz at 1.3v. Let me know and I could create a test overlay.

Strange...I would imagine that it should have some stability at a higher clockrate and 1.3v CPU VDD... Luck of the draw...?

Just to make sure...this is a v1.1 board, correct?

No problem - whenever you get a chance. If it doesn't work, it'd be helpful to verify that this test bootloader was properly flashed/booted.

@sfx2000, unfortunately I can't repro any crashes at 1.2GHz (w/the DDR clock at 504MHz)...but after some quick searching it seems that the original FA H5 clock default was 408MHz. Could you try the attached bootloader? This version has the DDR clock lowered to 408MHz. Install it via my instructions above, and make sure the bootloader was written to flash correctly by checking the build date in the console when it boots ("Mar 09 2020 -14:48:34"): U-Boot SPL 2019.10-armbian (Mar 09 2020 - 14:48:34 +0000) DRAM: 512 MiB Trying to boot from MMC1 NOTICE: BL31: v2.2(debug):03ea84c-dirty NOTICE: BL31: Built : 14:47:31, Mar 9 2020 NOTICE: BL31: Detected Allwinner H5 SoC (1718) NOTICE: BL31: Found U-Boot DTB at 0x4094d90, model: FriendlyARM NanoPi NEO 2 INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller NOTICE: PMIC: Assuming H5 reference regulator design INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied NOTICE: PSCI: System suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 U-Boot 2019.10-armbian (Mar 09 2020 - 14:48:34 +0000) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: mmc@1c0f000: 0 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial Out: serial Err: serial NanoPi NEO2 v1.1 detected Net: phy interface7 ... It'll be interesting to see if this makes a difference...! linux-u-boot-current-nanopineo2_408_MHz_20.05.0-trunk_arm64.deb

How are you managing power to the GNSS radio and the LTE modem? If you're just sending the GNSS data out over the LTE modem, it seems like you could use a simple MCU w/a couple of UARTs to interface with the radios (i.e., a whole SBC as the bridge seems like overkill...?).

I'm not clear about your use case...does your SBC-based solution need to be powered off of a battery?

By default the Fire3 doesn't really have a "sleep" mode per se; it's actually powered off. The PMIC MCU always remains powered via the USB and will power the system back on (resulting in a cold boot) after the wake timer expires or when the PWRKEY button is pressed. In the powered-off state, my board draws about 15mA via the USB power interface (measured with a Ruideng UMC25C) - so it's actually drawing quite a bit of current. From what I can tell, the RTC battery is only used to power the RTC in the S5P6818. (However I don't have a LiPo and haven't tried this feature at all.)

Changes checked in: https://github.com/armbian/build/commit/42201fd3fc1386c6dc8785c4f85db35289bfe2db After building a new u-boot, you can copy it to your board, then install it to the filesystem via "dpkg -i ...": root@nanopineo2:~/tmp# dpkg -i linux-u-boot-current-nanopineo2_20.05.0-trunk_arm64.deb (Reading database ... 33567 files and directories currently installed.) Preparing to unpack linux-u-boot-current-nanopineo2_20.05.0-trunk_arm64.deb ... Unpacking linux-u-boot-nanopineo2-current (20.05.0-trunk) over (20.05.0-trunk) ... Setting up linux-u-boot-nanopineo2-current (20.05.0-trunk) ... root@nanopineo2:~/tmp# Then, to install it to your SD/eMMC, run "armbian-config". In the menu, select "System and security settings", then "Install to/update boot loader", then "Install/Update the bootloader on SD/eMMC", then "Yes" at the WARNING prompt. Exit armbian-config, then reboot.

OK well that answers that... I think it's clear that the memory tests used back in 2017 weren't sufficient to determine the stability of this clock. Why don't I go ahead and set it to 504MHz as that's the FA default, then if desired people could look at overclocking this further.

Unfortunately not - the DDR clocks are set in u-boot... However users could feel free to build their own u-boots that use higher DDR clocks.