lanefu

Hi Michale. Your best bet would be to freeze the kernel and u-boot packages. Additional you could remove the armbian apt repository. Upstream debian and ubuntu will still work as long as they're still supporting the release you're on. Older boards that don't receive much attention from the community are often dropped. Unfortunately I don't think you'll find a reason much more specific. Please take a few minutes to understand some of our project's challenges. If you're passionate about the board, and would like to test and contribute, PRs are accepted and it could get moved back to Community Supported Status.

Hahahaha thats awesome!

Hi Akash This forum only focuses on mainline kernels, not the vendor provided kernels. Unfortunately it doesn't look like there are any plans for i2s on the Allwinner Kernel Mainling Project page. Maybe you'll have better luck on the orange pi forums or perhaps you can assist the sunxi project with getting i2s to mainline.

I moved Community Support Forms above Bug Tracker. Since its the first thing they see, I'm hoping that might help users start with asking for help there, rather than flooding bug tracker.

Honestly, I think most find out about Armbian after they get one of the SBCs rather than before. For that particular section--its targeted towards already disenchanted newbs as a way to get them to calm down.... But... your point is incredibly valid... What if we spun that off into a "Introduction to SBCs" section to dive deeper into the topic and let that function as an area that could be preventive. Yep thats a good idea. I suppose it should link to their active git repos that are part of their mainlining efforts. I'll get that added if someone doesn't do it before me.

As you know Armbian has a success problem.... The project has so much recognition that we're getting less experienced users which sometimes struggle with why we can't help as much as they would like. I've touched on some our challenges in the documentation. If you come across a frustrating post from someone, perhaps just cut paste this:

Hi I wanted to pick back up on this thread as a whole. Ask #1 I'd really like it if we could publish a list of maintainers for boards or board classes. If you all can help with that on the thread, I'll get it to the documentation, and then I'll proceed with some of the next phases of my communication strategy. Since we list what needs maintainers here..... Ask #2 I'd like some feedback about work categorization. @chwe's post here had a really good breakdown of some of the types of work that needed to be done. Some of the themes I saw were: * Platform Stability / Maintenance / Operations * Code quality and Testing * Features / Enhancements * Documentation and UX Do you think the above is flexible enough that most of our work could fall into one of those 4 buckets?

So the most helpful info would be to get logs for the TTL serial console of one of the fail boards.. looks like the cluster board has some IO pins for each.. I'd assume there's the TTL console port there.... Do you have a TTL serial cable you could use... or you can even use another SBC to connect if you really needed to.

What version _were_ you running? archives here https://dl.armbian.com/pine64so/archive/ if you want to rollback

Uhh yeah i see you were ... quite generous with your logs. anyway I edited your post to encapsulate your logs in a "spoiler" to keep the forum clean.

Can you share logs and describe what troubleshooting you've done.

Now that u-boot UEFI is kind of a thing.... How will that shape armbian and the build process?

Whoa. It looks like it might be small enough to reside in SPI flash. Is that true or tried?

try nano pi neo air image... looks like has same wifi chipset

So I'm on a fresh build of a Le Potato desktop... I'm able to run at 1080p just fine, but no easy config for the higher 2k or 4k resolutions... I tried both latest dev kernel, and next kernel.... Not sure how hard I try to make it work via X config... or go kernel hunting, device tree hacking or what..... maybe the "default" kernel? eww (My Tritium H5 can do it :P... same monitor, same cables etc)

english please

So i just went through this experience last night, and banged my head against the wall constantly because I'm too stubborn to follow directions. the stupid preinstall android on the emmc is really annoying.. i wish theyd ship it bank What I should have done... the bables way 1. make a 1 gig Fat32 sd or usb card... copy the 2 magic files he has for "multiboot"... apply them as an android update 2. boot from one of bables armbian builds 3. profit? what i did: 1. made a partial mess of the emmc by typing commands in u-boot... but not enough to clean off u-boot 2. installed the bables multiboot 3. booted from babbles armbian 4. DD'd the emmc from babbles armbian 5. booted a regualr frelshly build armbian SD and then ran in the install script.

its super confusing to say the least.... here's my best understanding.. 1. If u-boot is running from SPI flash on the board (ex: espressobin).. then you're relying on the parameters stored in the flash. saveenv is how that those parameters are updated in flash. So first precedence here 2. If u-boot is being loaded from the sdcard.. then boot.scr is what is read first and "saveenv" wont be relevant.... boot.scr is generated via the mkimage command and typically using boot.cmd as the source 3. ArmbianEnv is loaded via an Armbian friendly boot.cmd. It loads only a few values in that file and treats them as variables to be used within the rest of the purpose-made boot.cmd. (see extraargs inside boot.cmd for a hint) 4. Modifying boot.cmd and then regenerating boot.scr will be the most staightforward way to make quick changes (see bottom of boot.cmd script own how to recreate) 5. Once you master above, you can probably take advantage to ArmbianEnv.txt to make changes so that the boot.scr file doesnt have to be created each time you make a change

I'm almost tempted to power it through a NC relay... I wonder if i could get the gpio to trip late enough in shutdown process to reboot

merged https://github.com/armbian/build/pull/1314 thanks a bunch... i'll keep an eye out for your next PR

yeah apparently the u-boot params don't work and needs like a hardcoded change in u-boot for the hardset to work according to the sunxi wiki. See https://forum.armbian.com/topic/9368-orangepi-3-h6-allwiner-chip/?do=findComment&comment=74731 also re: reboot... known issue

See clean_level option https://docs.armbian.com/Developer-Guide_Build-Options/ Sent from my SM-G950U using Tapatalk

Nice. Ill be inheriting a 20 core/40 thread xeon box with 128G next month. Im brainstorming on what to do with it.... Sent from my SM-G950U using Tapatalk

What are the current build server specs? Sent from my SM-G950U using Tapatalk

OMG i feel like an idiot for helping. I didnt catch that on the very first post. Sent from my SM-G950U using Tapatalk