sfx2000

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.