sfx2000

Seems like the 1.3v might be the problem... with the 504MHz DDR timing, and removing the overlays for overclocking, board survives the test...

yes

@5kft - travel challenges, but finally home... This is really odd, and I'm thinking maybe this board just doesn't like being overclocked on the 1.3v regulator - even with 408MHz DDR timing... And this crashes the board hard...

My time is valuable - so let's spend it wisely... Do you have a real-world use-case where there is value or not?

remote this week - can give the board a kick, but no console...

My board - still hangs up hard with the 1.2GHz overlay on the openssl stress test... verbosity=1 console=both overlay_prefix=sun50i-h5 overlays=usbhost1 usbhost2 gpio-regulator-1.3v i2c0 cpu-clock-1.2GHz-1.3v rootdev=UUID=c87503e2-838a-42db-8208-a5293ae03ad5 rootfstype=ext4 extraargs=net.ifnames=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Getting better overall performance though with the lower clocks without the overlay... Screenshots with the overlay below... hard crash on the 1.2GHz overlay,,, sun50i-h5-cpu-clock-1.2GHz-1.3v.dtbolinux-u-boot-current-nanopineo2_20.05.0-trunk_arm64.deb

Try disabling WebGL https://peter.sh/experiments/chromium-command-line-switches/#disable-3d-apis

Curious as to why one wants to apply the patches for preempt-rt in the first place? Do you have a reason/application that would benefit? Most times, one can see an overall decrease in application performance, and to take advantage of preempt-rt, the application must call pthreads in a very specific way - which means that many times, the app must also be rebuilt. My reason for asking - if preempt-rt was so awesome, it would already be in the upstream linux kernel mainline and not require the patch. Avoiding politics around preempt-rt - many of the benefits here can be done without the patches, by selecting an appropriate scheduler - schedutil looks fairly interesting at the moment. I work on networking oriented applications that have hard deadlines, on MIPS, PowerPC, ARM (both 32bit ARMv7a and 64-bit), and never had a need to apply the preempt-rt patches. By networking oriented applications - I'm saying 20mSec framing for SIP-RTP (VoIP apps), along with 3GPP/UMTS signalling - if that ain't close to real-time, I don't know what is.

Sounds good - and folks should test around the 504MHz DDR clock, along with the overlay to upclock on boards that support the 1.3V regulator... both at 1.2 and 1.3 GHz.

Yep...

In any event, the clock diffs from "stable" to "unstable" - performance overall isn't enough to justify the risks, unless one looks at specific benchmarks... I'm not into benchmarking - I've got an interest in operational usage of the device. just my thoughts... sfx

Seems like it doesn't under certain loads...

I did the FA image as a quick test, and then overwrote that card with the current Armbian to get a baseline - as my armbian card is a few months old (custom work for the oled hat, other things) IIRC, FA was pushing CPU up to 1.2, but didn't note the DDR clocks. Anyways, link to that image is in the thread I agree that stability is better than overall performance - stability is it's own performance benchmark. I'd rather err on the side of safety. Neo2 Black - different board, eh?

Looks like Sunxi-mainline-kernel-4.14 is 504 MHz for the DDR clock for H5 on Neo2 http://wiki.friendlyarm.com/wiki/images/a/af/Sunxi-mainline-kernel-4.14-features.xlsx

Are you doing a level detect or a trigger detect on the pin?

ok - so the stock FA image also crashes on the same test - it behaves differently than the Armbian image, as it kills off the threads when it tries to do a privileged memory access... since we're working with armv8-a, we have kernel space (EL1) and user space (EL0) - hence the data abort, as the memory is marked as EL1, and an EL0 task cannot access that. I think that overclocking the CPU exposes a bug that is latent, even without the overlay, and this goes not to device tree, but to uboot and DDR ram init vectors there. The stress test (openssl) can show the bug, but this isn't the real problem, and the overlay just enables it to happen faster - getting board temp to around 60c, which on a small board like this, includes not only the SoC, but the DDR, can accelerate this issue, as some DDR can get a bit unstable at that temp. I don't have much time right now to debug further, as I'm in the middle of sfx's North America Tour - last week Austin, TX, next week Miami, FL, Atlanta, GA, Denver, CO, and a short trip to Salt Lake City, UT - about a week of downtime in the SAN, then back to Austin for a week. @5kft -- Gnarly problem to sort, eh? But spending time might help other AW H5 targets... @Igor -- something to watch maybe

self deleted for brevity/clarity...

Installed the overlay... Outcome not good when putting the board with the new overlay when stressing it with openssl speed -multi 4 Board crashes with a hard hangup - have to pull power. Should note this is a v1.1 board with the , which I didn't mention earlier.. This is the kit with the OLED hat and the cute little aluminum case...

been on biz travel over the last few days - jobby job stuff Rolled back the overlay that was in place, and Neo2 is again stable. I'll check out the update for the overlay... I'm in recovery mode - 3 cities in 4 days across the USA - more time in planes than in meetings,

Just wanted to note this - target NanoPi NEO2 - task at hand is Byte-UnixBench.... https://github.com/sfx2000/byte-unixbench more to follow...

With their private OpenWRT*, performance is fairly good - NAT over 1Gb is 900 Mb up/down - WG is around 240 Mb... (OpenWRT 19.07, their private release is 3.102) As mentioned - It's a MV3720 design, but carefully done, they've peeled off the non-essentials, e.g. the PCIe socket and SATA ports that were problematic on eBin Again - working uboot with failsafe recovery, a working ubuntu device tree, and a working ubuntu image - so work would be around on-boarding to Armbian, with support for Armbian tools/configs, and the build platform. I can do the work, just can't do it right now, day job is taking most of my time. @Igor - I think a huge amount of damage around this SoC was a result of GlobalScale and to some point Marvell with shifting sands and a lack of support from the Board Vendor The fact that GL-iNet has built a device on this SoC platform is significant in where it sits in their product line, and they've been extremely open on their docs to support the board.

Confirmed - 3V3, the SoC is 1.8, but they level shift it up.

Post u-boot log for linux bootup (openwrt)

They do have the UART pins soldered in, which is handy... I'll have to check on the levels, whether they're 3v3 or 1v8, but typically GL-iNet has done 3.3vdc there for other devices... @Igor - getting Armbian on this box might not be so hard, as they already offer Ubuntu 18.04LTS images on their github - bit tricky, but easy enough. I could probably do the port myself, but rather, I would introduce you to my contact there, and you can sort things. https://github.com/gl-inet/mv1000-ubuntu-image Note that the default u-boot does appear to use the pepe-2k mod for reflash, but there, one can only flash OpenWRT image, but with notes above, one can get back into ubuntu. Their current firmware is based on OpenWRT 19.07 on their private branch, but the 3.102 testing build is fairly solid, NAT routing is wire speed, and they've recently pulled in support for a USB based RTL8811AU/RTL8821AU and RTL8812AU devices

@ebin-dev They've got the thermals pretty much sorted... As we both know, MV3720 can be a bit of a challenge with thermals, but the team at GL-iNet have that fairly sorted...