sfx2000

Based on work with OpenWRT - mostly with how the chip is ID'd Geometry is the same - I would go with Winbond myself, as it's more understood if folks run into problems.

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

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...

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

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

Because they are not one for one replacements on the SPI-NOR... sfx

I would agree that Winbond is better supported in uBoot - GD is good, but not 1 for 1 replacement.

mali touches a lot of things, some of those are very trusted, so does Mesa. I would suggest testing things on a new device, and sandbox it accordingly. sfx

Counter intuitive - don't use flow control... With Windows and USB-UART connectors - I've found that true FTDI is best, Prolific chips - there's a lot of clones out there that don't work well.

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

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.

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

I can host a Zoom Telecon - let's say 8AM PDT on 4/4 - I have a 100 seat license, so happy to share (note, this does not mean corporate sponsorship - I'm involved with Armbian on a personal/individual contributor level.) Let me know, and I can set it up. tim

MV3720 can definitely be stable at 1.0GHz with DDR3 running at 400Mhz with a fair amount of heat sinkage - but that's not espressobin Bare board - you're going to run into thermal issues straight up at 800MHz, based on experience (espressobin was our ref device for my board)

Local subnet resolution can be done outside of named (bind) or dnsmasq. Have you consider avahi and using the .local? clients also have to have avahi as well, and the GW should not be .local

SPI on most SoC's - it's pretty much what the vendor qualifies - it's when one is in a mixed environment where things get interesting - master determines the rate based on the periphs configured. There are a lot of things that can be on the SPI bus, so sit back and consider what peripherals are in use on your circuit design.

Noted - and contributed findings to that thread - with credits to you and @lanefu for the assist. power of the armbian community to sort problems - that's what make this forum great

Recently revisiting things with H5 stability under certain SMP load factors* with @5kft and assistance with @lanefu - and H5 tends to be stable around 1104Mhz CPU/504MHz DDR with a 1.3v regulator overlay, and 1008/504 at 1.1v on NanoPi NEO2 - which doesn't really use the Mali450 at all. @lanefu was using a different H5 board (Orange Pi something or other - pls comment) - but he was also able to reproduce the stability issue I noted. Might be more interesting on something that engages all cores on the CPU, and does the GPU stress as well. * openssl speed -multi 4 - which flexs the ARMv8 enhancements there, engaging more of the logical blocks in Cortex-a53 - note that the governor in use is schedutil, which tends to be a different code path than "performance" or "on demand" @5kft - has been super awesome at helping out - reproducing the issue, concurring with analysis, proposing fixes... sfx

depends on your solution - but typically for h5, kernel is master on SPI... https://linux-sunxi.org/SPIdev You'll probably need to rebuild the kernel to enable, and you'll need to have specifics on the bus from the master. best of luck, you're likely beyond the redline given current info on how folks can assist.

On another project - a53 at 40nm - it has limits, and there we did limit things to 1GHz, and DDR2 to 800 (ddr400), but that was not Allwinner H5 - all in the name of stability...

getting more interesting... https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt Default these days is schedutil - and this is perhaps a good thing, but it does make folks reconsider min-max, and dvfs curves (OPP's).... Here's a run where I changed the governor from schedutil to performance - here one can see that we're clearly hitting curves and downclocking to keep the chip cool to some degree... Since this is a different code path in the overall scheme of things - schedutil makes this a good problem to solve. Another takeaway is that Cortex-A53 at 40nm, which is what the H5 is built on - has limits - 1104 cores/504 ddr - would be interesting to see how this plays out with mali450 timing on gpu intense apps - nanopi neo2, this is obviously not possible.

Doing some checking... https://patchwork.kernel.org/cover/10787869/ Seems kind of interesting

Ok, this is interesting... limiting cpu maxspeed to 1104MHz, with DDR at 504MHz, the board both survives the test, and also... Hits the DVFS OPP's, and starts throttling to keep itself cool once it gets above 80C Interesting - this is the first time I've seen the board actually try to save itself rather than run willingly off the cliff and crash hard.

Could probably try the 1.2GHz 1.3 overlay, and use cpufreq-util to limit max freq to 1100...

DDR@504Mhz with CPU@1008 - runs clean on my board with no overlays... This is a run with byte-unixbench exercising all four cores - as you can observe towards the end, it gets pretty intense... Performance is ok, all considered...