vincele

What I'd do: - kernel eth driver as a module (may already be the case) - forbid this module to be autoloaded at boot time (look at blacklist files in /etc/modprobe.d) - do your stuff to get MAC@ - load module manually (modprobe)

+1, what I'd do: 1 - Add the official webmin repository to images, but default to disabled... 2 - Add a build script that checks the validity of that repo... 3 - Document the (now easy) way of installing webmin on armbian...

OK thanks. Is my proposition above the right thing to put in the release doc ? EDIT: DONE: https://github.com/igorpecovnik/lib.docs/commit/ed96d5ce1662ae2962770c04b85a9771e6e1e876

So 5.24 will never be a release number ? I was only speaking of the Release_Changelog.md file content, maybe something like that could be added in this file to avoid surprising the readers: v5.24 - not released, used for the nightly or user-built images just my 2 cts...

Hello, Looks like 5.24 was forgotten...

Hello, I think this is a good starting point: https://docs.armbian.com/Developer-Guide_Build-Preparation/ You should try to get serial console working, this is invaluable, to get u-boot & kernel output, or even to login when you don't have working network, or console...

Hello, I have opi+2e working with eth+wifi, thanks to @martinayotte, see last posts from: https://forum.armbian.com/index.php/topic/2966-opi2e-mainline-ethernet-not-working-any-more/ I'm using a self-built image from dev branch (megous github repo), just configured for debian jessie / orangepiplus2e.

I now have serial, even if it's epic getting my tiny crappy connectors hooked to the opi pins... So I was able to capture a crash happening at halt time (probably reboot too, not tested yet). Does someone suffer similar problem ?

Thanks a lot Martin, I think your DTS patch fixed it for my opi+2e. I had been trying to understand why it broke, and why the old method from above was not working any more for the last few days. I started to diff DTSes around but not really knowing what I was doing, and because of my total lack of output (no serial console, nor any HDMI) it was really painful to blindly test random changes... I'll get serial tomorrow (or at least I hope so), so it will be easier to help

Sorry, but I'm still lost... which dts should I base my comparison on ? - /boot/dtb/sun8i-h3-orangepi-plus{,2e}.dtb converted to dts ? - megous branch kernel source code - u-boot source code I think I should diff /boot/dtb/sun8i-h3-orangepi-plus{,2e}.dts Then apply this diff to sun8i-h3-orangepi-plus2e.dts in kernel or u-boot source code, but replacing the adresses by handle to the right stuff. Is that right ?

OK, mounted the sdcard on the PC, did the above and it worked. Now on to try it with the other branch & config... What woud be needed to make it work properly as "./compile [...] BOARD=orangepiplus2e" ? Copy sun8i-h3-orangepi-plus.dtb as sun8i-h3-orangepi-plus2e.dtb somewhere in userpatches ? Anything else ? Thanks

Hello, Just returning after a little while, I cannot get ethernet working on my opi+2e with mainline kernel, direct cable connection to PC, no serial console at hand, neither HDMI output, so I had the habit of blindly booting then sshing into the box... I tried my personal config + megous repo, xenial or jessie, current armbian repo nothing coming out of eth on the PC (tcpdump -i eth0). LEDs, green solid on, red heartbeating, orange eth led blinking slowly. I then reverted back to montjoie's repo (default for dev BRANCH), for identical results. Could this be the updated u-boot (I think I saw a new version being used) ? Or is this expected to be working, and thus something on my side ? Now trying to build a legacy-kernel based image, to double-check...

Hello, I know this will be a controversial subject, but I often like to see what's happening in a devel repository by browsing commits. I start by looking at the commit titles (first commit message line) to approximate the interest that particular entry is to me, then if deemed interesting, I'll read the full commit message to understand what it is about, then if still interested I'll go read the code. I think this is a fairly straightforward approach to digging in a codebase or development stream, avoiding to loose time on things outside of interest scope, and allowing to focus on specific subjects. So, in order for this workflow to be doable, the commit messages content need a minimum level of details, which is what I'm asking the community to act upon. Would it be possible to mandate a bit more work on that front ? I'm not against messages like "Whitespace fix", "Typo fix", "Better comment", anything that explains a bit what the code diff is about. WDYT ? PS: I think armbian is not so bad wrt $SUBJECT, it just needs a little bit more. I've seen far worse projects where I wouldn't even ask for better commitmsgs, so take that as an endorsement of the (already good) quality level of the work done. Thanks

I'm not sure what you want to achieve, but I think you should have a look at: $ man taskset TASKSET(1) User Commands TASKSET(1) NAME taskset - retrieve or set a process's CPU affinity [...] This will pin a process to a cpu set, but it won't be isolated from other activities (other scheduled processes, kernel activities) If you want your userspace process(es) to be shielded from OS kernel activity, this probably won't be suffcient... There's the isolcpus kernel boot option: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-parameters.txt#n1814

Add KERNEL_CONFIGURE=yes to your ./compile.sh command line, and it will launch the kernel menu configurator, where you can easily find 'FORCE_MODULE_UNLOAD' under 'enable loadable module support'...