lanefu

I like the compromise, I think it's lead to a better solution. There's a time and a place for big changes, I don't think this is one of them. We really need to build up more strength as a team before taking on any big changes. We need small wins and improvements to build that strength.

Fair point. I like. I can certainly agree to that. I see where you're coming from, and I do feel like that's a 4th category in the context of certain boards... (sunxi) as somewhere in between next and dev... and sometimes ahead. For dev we only use out of tree branches when there's additioanl forward ports being applied by a maintainer.. as mentioned that's mostly sunxi. for most other boards, its generally a mainline checkout.

Hey Petruccs we'll accept community contributions. This doc exists, but it needs more detail. https://docs.armbian.com/Process_Contribute/ to contrbute, you'd want to be able to build an image and test that it works, make adjustments to kernel config, patches, tweaks etc as needed.

Im a devops consultant and fluent in Ansible so I think im Obligated in that regard. I can at least handle the plumbing hopefully others can implement the more granular testing once the framkework is in place.

@hijax dude that is way awesome! Thanks 1000% for working on this

Currently I feel like NEXT is the most confusing type out of all--Especially with Sunxi.... As far as default.. we ought to default to a stable mainline I really like @Tido thoughts regarding the debian-style convention: Legacy - Vendor / Legacy / BSP abomination Stable - A kernel that at least follows a recent lts mainline version, even if fork, and patched accordingly (this should be the one we should use as our default image build) Unstable - Dev Kernel.

I'm definitely in favor of switching u-boots.. As far as why we'd want to use Hardkernel's kernel repo... a TON of it works out of the box:

In boot.ini's defense its super easy to work with and the board is totally sweet. But yeah should remain CSC until proper u-boot and mainline exist.

Actually the EMMC ext4 installer didnt work nor BTRFS root Emmc works if you write image directly to it.

Armbian build with default kernel worked great--Desktop and everything, after a slight u-boot change https://github.com/armbian/build/pull/1498

Sometimes it depends on their production cycle. They often wait and do large runs. Ex opi prime is often unavailable but it comes back Sent from my iPad using Tapatalk

nmtui

I got my N2.. it's awesome. Using hardkernels Image right now. I did a few armbian builds but they didn't seem to boot. (no dhcp lease, no console) I have to make a JST -> dupont adapter for my serial console.

Im not sure there are any alternatives other than attaching to the usb serial console and following the process described.

See conversation in this commit for background The current default, Next, Dev naming convention for the kernel source trees is confusing, and a bit inconsistent. I think it's time to rename them and provide clear definitions of what they are supposed to provide. I'll start with some ideas here: Vendor This Kernel is currently called Default . The Vendor kernel would be the BSP-derived kernel or vendor maintained kernel. Typically there for basic functionality early in a boards life. Armbian can supply patches for these kernels LTS This kernel is currently called Next. The LTS kernel would follow a LTS version of mainline or fork. Ex: 4.19 of Megous's branch for orangepi, mainline:4.19 for espressobin. This should be our flagship kernel and the only one we "support" for end users. Armbian can supply patches for these kernels Unstable This kernel is currently called Dev. The Unstable kernel would follow a recent branch or fork of a kernel. Armbian can supply patches for these kernels. Mainline This is new. It would follow mainline:master. Its purpose is to provide a 100% mainline experience when practical. No patches will be supplied by Armbian.

Fyi i ordered an N2 over the weekend hopefully ill have mine to help test soon

Not an armbian specific thing. Persue the udev solutions mentioned in your links

okay off-topic... but i was searching for mutliviewer and found the ultimate tribute to Radio Shack product design

Okay that sounds pretty awesome. most of the boards should come up on the network anyway, so really the serial console is hopefully just for logging and debugging rather than test automation. Being able to validate an image can boot successfully will be huge

so i'm getting a little confused about the muxing and level shifting for console So the board itself won't have a UART, and its going to mux/switch TTL consoles to a single UART on the Master SBC?

nto sure wha tall supports the enviornent proxy vars but you may need ALL_PROXY HTTPS_PROXY HTTP_PROXY NO_PROXY=127.0.0.1,localhost and do lowercase versions as well

that's so not cool.

Sorry for your loss; congrats on your upgrade.

@Hijax awesome. If you're cool with it can i submit a test print to jlcpcb and order components?

Fantastic question...and one thats important. From an iterrative standpoint, achieving 1 & 2 is a great start. Although i'd isolate uboot and kernel. As we currently have the capanility to test over NFS which lets us accurately test kernel and high level things on rootfs, just not uboot because thats a current config. With your multiplexer we could still test nfs boot, and given we just need the sdcard for uboot we can probably mux to next system once booted. Pretty cool! IMHO this board would be standalone rather than a hat so that its flexible with what master SBC is attached. MVP version would be a strong power source feeding a relay board with USB-A ports for power and uart ports as like JST ports.or something so we can use a JST-to-dupont for our serial console breakouts. And just static sdcards in board for nfs uboot.