TRS-80

I found the reason this happens. Its not the eMMC itself, the boot from eMMC or booting from FAT vs EXT4. It's the much faster system boot speed from eMMC and the network configuration that leads to this bug.
 
The device that consumes the additional idle power is the Realtek RTL8125 2.5GbE NIC when left in an bugged unmanaged/unconfigured/off state.
 
When using stock Armbian with Network-Manager it seems to depend on the image, software distribution and the system boot speed with how often the Realtek NIC gets into this bugged state. Properly configuring the NIC in Network-Manager prevents this from happening.
 
 
When using Armbian Bullseye with OpenMediaVault installed with the OMVExtras InstallScript this can be reproduced 100%. The InstallScript (without using the option -n to skip network configuration) removes Network-Manager and lets systemd-networkd and OpenMediaVault/Netplan manage the network.
 
Since the MAC of the Realtek RTL8125 2.5GbE NIC is not fixed and changes every boot systemd-networkd with the policy "MACAddressPolicy=persistent" (default in /usr/lib/systemd/network/99-default.link) automatically adds a persistent MAC address to the Adapter. At the same time OpenMediaVault creates netplan files that assign network configuration based on this added MAC address.
 
This leads to a race condition in systemd-networkd. If systemd-networkd adds the persistent MAC to the adapter before it tries to assign the configuration matched to this persistent MAC everything works as expected. When the system boots faster systemd-networkd tries to match the configuration to a MAC that is not added yet to the adapter and that leaves the adapter off, unmanaged and bugged.
 
(In these code parts eth0 = GMAC & Realtek RTL8211F 1GbE and Realtek RTL8125 2.5GbE NIC = enP3p49s0)
 
Random MAC adresses:
Aug 28 09:53:57 nanopi-r6s kernel: r8125 0003:31:00.0 (unnamed net_device) (uninitialized): Invalid ether addr 00:00:00:00:00:00 Aug 28 09:53:57 nanopi-r6s kernel: r8125 0003:31:00.0 (unnamed net_device) (uninitialized): Random ether addr 4e:54:94:b5:ad:c7  
OMV Netplan file (matching with mac!):
root@nanopi-r6s:~# cat /etc/netplan/20-openmediavault-enP3p49s0.yaml network: ethernets: enP3p49s0: match: macaddress: de:d1:aa:55:c9:bf accept-ra: true dhcp4: yes dhcp4-overrides: use-dns: true use-domains: true dhcp6: yes dhcp6-overrides: use-dns: true use-domains: true  
Netplan auto generated systemd-networkd .network:
root@nanopi-r6s:~# cat /run/systemd/network/10-netplan-enP3p49s0.network [Match] MACAddress=de:d1:aa:55:c9:bf [Network] DHCP=yes LinkLocalAddressing=ipv6 IPv6AcceptRA=yes [DHCP] RouteMetric=100 UseMTU=true UseDomains=true  
When booting from slow microSD status of enP3p49s0 is ok:
root@nanopi-r6s:~# networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether routable configured 3 enP3p49s0 ether no-carrier configuring 3 links listed. root@nanopi-r6s:~# networkctl status enP3p49s0 ● 3: enP3p49s0 Link File: /usr/lib/systemd/network/99-default.link Network File: /run/systemd/network/10-netplan-enP3p49s0.network Type: ether State: no-carrier (configuring) Path: platform-fe180000.pcie-pci-0003:31:00.0 Driver: r8125 Vendor: Realtek Semiconductor Co., Ltd. Model: RTL8125 2.5GbE Controller HW Address: de:d1:aa:55:c9:bf HW Permanent Address: 4e:54:94:b5:ad:c7 MTU: 1500 (min: 68, max: 9194) QDisc: mq IPv6 Address Generation Mode: eui64 Queue Length (Tx/Rx): 4/4 Auto negotiation: yes Speed: n/a Port: tp DHCP6 Client DUID: DUID-EN/Vendor:0000ab1166a0671791d79f890000  
When booting from much faster eMMC enP3p49s0 is left in a bugged state:
root@nanopi-r6s:~# networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether routable configured 3 enP3p49s0 ether off unmanaged 3 links listed. root@nanopi-r6s:~# networkctl status enP3p49s0 ● 3: enP3p49s0 Link File: /usr/lib/systemd/network/99-default.link Network File: n/a Type: ether State: off (unmanaged) Path: platform-fe180000.pcie-pci-0003:31:00.0 Driver: r8125 Vendor: Realtek Semiconductor Co., Ltd. Model: RTL8125 2.5GbE Controller HW Address: de:d1:aa:55:c9:bf HW Permanent Address: 92:f6:18:f3:59:af MTU: 1500 (min: 68, max: 9194) QDisc: noop IPv6 Address Generation Mode: eui64 Queue Length (Tx/Rx): 4/4 Auto negotiation: yes Speed: n/a Port: tp  
The fix is to install OpenMediaVault without re configuring the network with InstallScript option -n. That keeps Network-Manger and doesn't add the ethernet adapters to the OMV database.
 
Another option is to remove Network-Manager and also remove the matching by MAC address from OMV netplan files by editing "/srv/salt/omv/deploy/systemd-networkd/netplan/files/ethernet.j2" and deleting:
match: macaddress: {{ mac_address }} After saving and applying the new network configuration in OMV webgui the MAC address matching is gone and adapters get only matched by name.
 

I am submitting my **original artwork** for the Armbian Wallpaper Contest.
**Artwork Details:**

- **Title:**Penguin Planets in Armbian Universe
- **Description:**I wrote a little program to create this image. The background, the penguins and the icons can be customized by making small changes to this program. A wall paper generator web page could be made available for this purpose as well.  To encourage vendor support for this project, the penguins (icon, penguin size and location) can be customized per vendor needs. Linux penguins as planets is my original idea (I did not find or copy anything from google). Since the image can be easily recomputed, they are not important any more only the idea remains. The background image is found by searching google images for royalty free universe images. Another background image can be substituted easily if need be.

I hereby confirm and certify that this artwork is an original piece created solely by me. By submitting this artwork to the Armbian Wallpaper Contest, I agree to release it under the [Creative Commons Zero (CC0) license](https://creativecommons.org/publicdomain/zero/1.0/legalcode) (CC0 1.0).
 

 
 
 

dear friends
i remark that we continue to give help to someone that is not willing to listen and perhaps THIS IS FRUSTRATING and not the fact that the box is not booting

After discovered that IF ONLY HE had followed all the instructions that very kindly the users of this 3ad suggested instead of trying other magic combinations, and after we  already said thet we need uart logs and so now I  would like remember  we said to him to stay on legacy kenel that is 4.4.xxx

And guess !!

He flahsed Armbian_22.11.1_Rk322x-box_jammy_current_5.15.80_xfce_desktop.img.xz
in other words a 5.15.80 kernel

Do we need other words?

 

@n3o  The members trying to help you are highly experienced. The important point here is for you not to treat their specific instructions as merely "suggestions" after which you go off and do your own thing.   That is where the frustration lies. 
 
Based on the energy other users and you have spent on this, I would just buy some other TV box or SBC that is already known to run Armbian without any issues instead of trying to resurrect an old tired piece of hardware.   Unless you are really short on cash,  this is what I would do.  However, if you really are so short on cash that you cannot afford another $20USD on something else, then I believe your priorities are all wrong.
 
I have an H20 RK3228A tv box that is in transit that has some documented booting issues with Armbian.  In a way, I am happy to see how this whole episode has progressed.  I'm happy because now I know what NOT to do.

In my experience (T95X/AmLogic s905x) it's best to re-flash the stock Android using the AmLogic USB Burning Tool first before trying to boot Armbian from SD card.
You need to explain in more detail exactly what you're doing, how you're preparing the SD card, how you are trying to boot it, what if any output/errors you get on trying to boot it etc.

Why not buy an Armbian supported SBC? Most TV-Boxes are crap. Overheating and low-quality. For better quality you also pay a lot more. So then why not buy a good SBC?

RK3399 ain't that expensive and has great IO. RK3588 is high end so cost more, but it's future proof.
OrangePi5+ should be best value. I don't have it, so can't say much about it. 
NanoPi R6S/R6C isn't that expensive. The C has NVMe and USB3, and very fast CPU.
 
If you want to use full sized HDD's then look at the Odroid HC4. It has the S905X3. As powerful as RPi4(when not OC) and 2 SATA for full sized HDDs. But no USB3 or other IO. It does have HDMI.
 
RK3568 is also a SoC that has great IO and not too expensive. Not sure if there are Armbian supported boards with it.
RK3566 less IO but still better than any RPi.

I only had one ok TV-Box from a bunch. The Mecool KM6 with S905X4, but that doesn't have Armbian support. S905X3 should have better support. But you are never certain all hardware will work.
TV-box manufactures ofter use different components for the same model TV box. So some people might have wifi working, but others don't.

# Pinebook Pro testing
 
## Armbian_23.5.0-trunk.219_Pinebook-pro_jammy_current_6.1.29_gnome_desktop
- Boots live disk [x]
- Installs to eMMC - ext4 [x]
   - Fn keys works [] : NOTE F9 and F10 are swapped
      - Fn1 [x]
      - Fn2 [x]
      - Fn3 []
      - Fn4 [x]
      - Fn5 [x]
      - Fn6 [x]
      - Fn7 [x]
      - Fn8 []
      - Fn9 []
      - Fn10 []
      - Fn11 []
      - Fn12 []
   - Wi-Fi works [x]
   - Bluetooth works []
   - Touchpad works [x]
      - Ports
      - USB-C - data [x]
      - USB-C - power [x]
      - USB-A - data [x]
BUG: Screen locking does not work without GDM.
## Armbian_23.5.0-trunk.219_Pinebook-pro_jammy_current_6.1.29_xfce_desktop
- Boots live disk [x]
- Installs to eMMC - ext4 [x]
   - Fn keys works [] : NOTE F9 and F10 are swapped
      - ESC []
      - Fn1 [x]
      - Fn2 [x]
      - Fn3 [x]
      - Fn4 []
      - Fn5 []
      - Fn6 []
      - Fn7 [x]
      - Fn8 []
      - Fn9 []
      - Fn10 []
      - Fn11 []
      - Fn12 []
   - Wi-Fi works [x]
   - Bluetooth works []
   - Touchpad works [x]
      - Ports
      - USB-C - data [x]
      - USB-C - power [x]
      - USB-A - data [x]
 
BUG1: Ubuntu artwork is being used instead of Armbian during live disk boot once in the desktop. Shows the Ubuntu artwork during boot once installed to eMMC, it does show Armbian artwork at login screen/desktop.
BUG2: Touchpad is very jumpy.
 
## Armbian_23.5.0-trunk.219_Pinebook-pro_jammy_current_6.1.29_i3-wm_desktop
- Boots live disk [x]
- Installs to eMMC - ext4 [x]
   - Fn keys works [] : NOTE F9 and F10 are swapped
      - Fn1 [x]
      - Fn2 [x]
      - Fn3 [x]
      - Fn4 []
      - Fn5 []
      - Fn6 []
      - Fn7 [x]
      - Fn8 []
      - Fn9 []
      - Fn10 []
      - Fn11 []
      - Fn12 []
   - Wi-Fi works [x]
   - Bluetooth works []
   - Touchpad works [x]
   - Ports
      - USB-C - data [x]
      - USB-C - power [x]
      - USB-A - data [x]
 
BUG1: Battery indicator says no battery, I have opened a report of it here: https://armbian.atlassian.net/browse/AR-1756
BUG2: Touchpad is very jumpy.
 
# Not tested yet
## Armbian_23.5.0-trunk.219_Pinebook-pro_jammy_current_6.1.29_minimal
- Boots live disk []
- Installs to eMMC []
   - Fn keys works []
      - Fn1 []
      - Fn2 []
      - Fn3 []
      - Fn4 []
      - Fn5 []
      - Fn6 []
      - Fn7 []
      - Fn8 []
      - Fn9 []
      - Fn10 []
      - Fn11 []
      - Fn12 []
   - Wi-Fi works []
   - Bluetooth works []
   - Touchpad works []
      - Ports
      - USB-C - data []
      - USB-C - power []
      - USB-A - data []

With free samples nobody can pay for their living.
https://www.armbian.com/partner-contact-form/
https://forum.armbian.com/subscriptions/

Although I have not yet tested the Moonlight-QT build on the Orange Pi 5, I plan to do so tonight.  I will be contacting amazingfate regarding the bounty. I consider this to be the best $1000 I have ever spent, and I hope it marks the beginning of a long-term relationship between Maximumsettings and the Orange Pi 5 Armbian community. The Pi 5 will provide us with  one the most affordable and superior streaming device available in the market.

Just so you know, our organization has many ideas, but we lack the internal resources to implement them. I am optimistic that we can create a situation where everyone benefits, a win-win scenario.  I am hopeful  that the approach of offering bounties for adding new features and fixing bugs will be successful within the Armbian community.

In the following thread I essentially did all the steps I had mentioned above.  Proceeding slowly and carefully, I felt confident to flash the SPI, once I had determined that indeed it was empty.
 
In the end you were right, the key is putting tow-boot on the SPI.  I mean, that is certainly the easiest way I think.  And the way I did it, I did not even have to open the case (which I was getting very tired of doing by this point, LOL).  I have got Armbian working now both via SD card (the other day) and/or eMMC (just tonight).  Detailed instructions can be found here:
 
https://forum.armbian.com/topic/27598-getting-armbian-working-on-second-batch-mid-2022-pinebook-pro/

Hello!
 
I don't really have a question, but just wanted to report I tried out the generic UEFI arm64 image on a Pinebook Pro, and it installed emmc and booted just fine!
 
This was possible because I had installed Tow-Boot to the SPI flash, which supports UEFI booting.
 
I had tried using the Pinebook Pro build of armbian, which worked fine when booting off the sdcard, but installing it to the emmc wasn't working.
 
I'm using Tow-Boot 2021.10 then arbmian image Armbian_22.08.7_Uefi-arm64_jammy_current_5.15.74 .
 
There's a few rough edges in the grub menu, but it boots the OS off the emmc just fine.
 
Should the be mentioned on the Pinebook Pro page? Personally, having Tow-Boot installed to SPI is all around a much more "normal" laptop experience, so it seems like a good idea in general.
 
 

Honestly I would not have flashed Tow-Boot into the SPI except that at some point a U-boot update made my PBP unbootable. So I had no choice.

I had to actually open the case to do this (and it took a few tries to get everything working) so it's certainly not for the faint of heart.
 
I really wish Pine64 had shipped these things with a more reasonable boot loader from the start.

Looks like you asked awhile ago, hopefully this is still relevant.
 
I've been successfully running Armbian off of EMMC on my Pinebook Pro. Before installing Armbian I actually flashed Tow-boot onto the PBP's SPI (replacing the built-in boot loader). Then I was able to run the Armbian installer and installed directly to the EMMC.

This set up seems to work fine for me. Hope this helps, good luck!

You are not using Armbian.  You have downloaded software from a site that is a fork of Armbian and uses the Armbian name without permission.  They do not participate in Armbian development, nor do they participate in these forums.  We can't help you here as we don't produce the code you are running.  You need to log your question with those you downloaded your software from.

#!/bin/bash TOP=/home/share/video/music if [ -n "$1" ]; then TOP=$1 fi OLDIFS=$IFS IFS=$'\n' find $TOP -name "*.[maowf][povgklm][gvim]" -print | shuf -n 100 > randomplaylist mpv -fs -vf=pp=de --playlist=randomplaylist rm randomplaylist IFS=$OLDIFS This will play 100 randomly selected files from /home/share/video/music and subdirectories or whatever directory you pass on the command line.

Please don't take it personal.  It only takes a few people pestering, looking for (free, immediate, personalized) support to get on the nerves of some people around here.  There are very few of us, against a sea of them, so that is how we decided to deal with it, to stem the tide.
 
Further, some threads move extremely slow.  Maybe not this one, but I have seen many times where someone replies months, maybe even years later.  Different people come along, move some issue forward by inches, and on it goes.  Such is the way of progress some times.
 
Welcome to the forums.

I can only imagine how happy @rpardini will be not needing to re-base any more. 
 
Jokes aside, kudos to you, you must be thrilled all your hard work will be seeing the light of day, finally.  Thanks for sticking with it all that time.

I have been building this project for a long time.
And at the moment, I don't see an alternative for the ARM architecture for real-time core operation with short response times.
@Igor The Xenomai4 project is already working well for sunxi today.
 
 
 
lsdiff patch-6.2-rc3-rt1.patch These are some basic changes. I don't see the necessary changes specific to rockchip, meson or sunxi files here.
In order for this patch to work, you need to add a lot of additional changes yourself.
 
And this is for working only in user space.
In any case, you will have to reassemble the entire chain for industrial production. kernel -> lib & modules -> linuxcnc

Hello community,
 
I have just been successful building my own image of Ubuntu focal + preempt_rt (kernel 5.15.76-rt53) for my Rock64 board for the first time (a bit of additional background at the end of my post). Exciting! I had a few hiccups along the way, and I need to figure out a few more things. So far I'm happy and impressed with the project.
 
However, given I want to share my work (and the resulting image(s)) I would like to ask for some pointers on what is the best way to go in regards of forking armbian/build and the changes I found myself doing.
 
I have added my kernel compilation flags to config/kernel/linux-rockchip64-current.config but I feel like maybe I should create a new file, something like 'linux-rockchip64-current-rt.config' but I do not know if the compile.sh will find it (or how to make it find it) if I do so. What would be the best way to go about it? I added the PREEMPT_RT patches to patch/kernel/rockchip64-current , but again, there should probably be a folder for RT maybe? (I wonder how to make compile.sh find it). I created userpatches/lib.config with the content 'KERNELBRANCH='tag:v5.15.76'' to use the latest PREEMPT_RT compatible kernel, ideally this could be scripted to use the latest closest to 'current', which also would avoid needing to modify the patch/kernel/BOARD_NAME folder. I also needed to remove the box64 package cause it would stop building my image (GPG key outdated?) is this package necessary for a minimal installation? I don't think I found I needed it so far. I left a comment about it in this github issue: https://github.com/armbian/build/issues/3968#issuecomment-1310390875 I needed to add a couple of additional cmdline flags, I edited by hand (after booting the board) the resulting /boot/armbianEnv.txt with 'extraargs=nohz_full=3 isolcpus=3' and that worked, but I'd like to create the image with that already done. What would be the best place to do that? userpatches/customize-image.sh ? If I place anything in userpatches/customize-image.sh am I able to run the build just from there?  
Thank you very much for any pointers you can give me about best practices to go about it, anything I did wrong, or templates to follow.
 
My first goal is to provide a reproducible build of ubuntu focal + preempt_rt for the rock64 board (which I'm very close!), but I'd be happy to extend the work to be able to apply the PREEMPT_RT patches to any board saving people a bit of the guess work I needed to do (at least for as long the patches are not part of the kernel by default!).
 
Additional background: I need to use Ubuntu as my plan is to use ROS 2 on it, and the officially supported distro is Ubuntu (and focal happens to be the most useful for my use-case). I am aiming, in conjunction with some members of the ROS real-time working group, to ease the entry barrier of learning to make real-time apps for robotics. I am using a Rock64 board because it's similar to a Raspberry Pi 4, as I am unable to source a Raspi4 and I believe it is the same for everyone.
 
Bonus: a quick test (running 10min) of cyclictest with stress on the system provided the following plot on latency (74us max, 15us min, about 20ish us average):

 
 

Since I've no slides, a terrible sense of humor, and nothing else to post, here's a git shortlog of the changes since last week.
 
Ricardo Pardini <ricardo@pardini.net> (99): armbian-next: `CLEAN_LEVEL=make-kernel` now does `git clean -xfd` instead, faster and 100% clean armbian-next: better logging for early apt installs during `prepare_host_basic()` armbian-oleg: handle error during host deps installation (Oleg has a mangled sources.list?) armbian-oleg: introduce `DOCKER_SIMULATE_CLEAN=yes` so I can pretend to be Oleg, but using Docker armbian-oleg: split hostdeps again, full of ifs, and reduce the minimum set of pkgs for Oleg-conditions while trying to keep Docker full armbian-next: `apt-cacher-ng` is now optional and activated via `MANAGE_ACNG=yes`; drop `NO_APT_CACHER` armbian-next: remove old template Dockerfile, -next does not use this at all armbian-oleg: `junk`: drastically reduce host-side dependencies / "remove junk" armbian-next: curb down wget logging for ORAS tooling download armbian-next: curb down `git fetch` logging; be verbose if user on terminal & not logging armbian-next: curb `aria2c`'s complaining a bit armbian-next: curb `free_loop_device_retried()`'s logging on first try armbian-next: long overdue split of `logging.sh` armbian-oleg: logging: new logfile format; `SHOW_LOG=yes` default; introduce `DEBUG=yes` armbian-next: fix quoting of retry var (cosmetic) armbian-oleg: better logs; only include non-empty .log files armbian-oleg: curb `apt-get`'s logging with `-q` / `-qq` armbian-oleg: curb Python launcher logs armbian-oleg: curb `rsync` logging during bsp armbian-oleg: drastically curb `update-initramfs` logging, unless SHOW_DEBUG=yes armbian-oleg: drastically curb `boot_logo()` logging armbian-oleg: drastically curb `apt-get` logging when running in chroot armbian-oleg: make `chroot_sdcard_apt_get_install_dry_run()` logging more useful by filtering the noise out armbian-oleg: if commands fail, write to log in bright red armbian-next: split `compilation/debs.sh`; `compile_xilinx_bootgen()` moved to family armbian-oleg: curb logging from building `armbian-firmware` armbian-oleg: curb logging from building `armbian-plymouth-theme`; do it in a logging section, like the others armbian-next: logging: reinit logging after processing cmdline parameters armbian-next: cli: half-assed, legacy based, `kernel` and `u-boot` cli commands armbian-next: `odroidxu4` vs kernel: move firmware hack to family using extension hook armbian-oleg: logging: drastically curb / make more useful kernel packaging logging armbian-oleg: logging: disable debugging (set -x) of generated postinst/etc kernel scripts (board-side, but also chroot logging) armbian-next: kernel: deterministic `.config` mtime handling; kernel build logging sections reorg armbian-next: remove `REPO_STORAGE` and `REPO_CONFIG` -- unused armbian-next: consider "Provided" installed packages when determining what is missing from host-side dependencies armbian-next: completely remove `acl` (which provided `getfacl`) and it's usages (basic deps) armbian-next: don't copy the host's `keyrings` to image armbian-next: Python tooling: use consolidated+hashed+cached pip base/pycache; don't pip during Dockerfile build, nor cli-requirements armbian-next: add core extension `c-plus-plus-compiler` which hostdeps on `g++-aarch64-linux-gnu` and enable it in JetHub family armbian-next: core extensions for `xfs` / `f2fs` / `brtfs` / `LUKS/cryptroot` hostdeps; enable in main-config armbian-next: Docker: abstract away and only run "docker info" once, it's very expensive armbian-next: `rootfs`: bunch'o'fixes, introduce `disable_systemd_service_sdcard()` to stop repeating incantantion armbian-next: don't warn about using extlinux armbian-next: a bunch of checks for Darwin; use brew's GNU coreutils first in PATH, so we get the correct utils; give instructions armbian-next: better logging for `kernel_prepare_bare_repo_from_oras_gitball()`; remove dead code armbian-next: fix re-launching of CLI commands under sudo (Docker was ok) armbian-next: `patching`: don't complain about missing files when the patch parsed OK and file was actually deleted armbian-next: `patching`: don't rewrite empty desc as "None" armbian-next: `patching`: remove quotes from author name during parsing armbian-next: `patching`: avoid mangling valid utf-8 from mbox'es armbian-next: `patching`: parse renamed source files, don't swallow them during rewrite armbian-next: optimize `config_source_board_file()`, now 600x faster by not reusing (slow) code from interactive armbian-next: optimize for `CONFIG_DEFS_ONLY=yes`, skipping stacktraces/git info armbian-next: introduce `POOR_MAN_PROFILER=yes` (under `ANSI_COLOR=none`) armbian-next: `docker`: fix Dockerfile output indentation & warning msgs about generation armbian-next: make sure temporary `kernel` and `u-boot` CLI commands always build a kernel/u-boot even if cached `risc-v`: correctly include `debian-ports-archive-keyring` in Risc-V CLI packages `risc-v`/`starfive`: use mainline kernel 6.1.y, with StarFive's rebased patches against `v6.1.5` `risc-v`/`starfive`: update kernel config, sans changes `risc-v`/`starfive`: `CONFIG_MOTORCOMM_PHY=m` for the onboard Ethernet `risc-v`/`starfive`: switch kernel config to `savedefconfig`'s output, cos that's what it should be `odroidm1`: enable working userland `fw_setenv`, so users can go back to Petitboot & otherwise tweak u-boot env from Armbian `odroidm1`: bump to 6.2-rc3; look ma, no patches. `odroidhc4`: pre-configure `fancontrol` so fans work right out of the box armbian-next: debug note about fstab with tmpfs in chroot armbian-next: mark Vagrant CLI as unimplemented armbian-next: `docker`: use dash-lines before/after launching docker; set `ARMBIAN_INSIDE_DOCKERFILE_BUILD=yes` when it is so armbian-next: `traps`: allow for cleanup handlers with arguments; unify around `run_one_cleanup_handler()` armbian-next: `ccache`: show more in ccache debugging armbian-next: make superglobals readonly (`DEST/WORKDIR/LOGDIR/SDCARD/MOUNT` and others) armbian-next: introduce `tmpfs-utils.sh`; put `LOGDIR` and `WORKDIR` under tmpfs; set `CCACHE_TEMPDIR` under `WORKDIR` armbian-next: split `prepare_host()`, fix `.tmp` reset trap armbian-next: do basic host checks before config if interactive, or during prepare-host if not armbian-next: tmpfs-utils: last-resort debugging, to stderr, of failed tmpfs unmount armbian-next: logging: squash nasty leaking file descriptor bug due to "tee" armbian-next: bring back `swig` hostdep -- needed for some u-boot's armbian-next: severe bug, countdown counted up armbian-next: kernel: cleanup bundle after patching succeeded, not after build success armbian-next: firmware: don't build `-full` firmware if not on CI/noninteractive and board's not going to use it armbian-next: `chroot_sdcard_apt_get_update()` to replace and better log `chroot_sdcard_apt_get update` armbian-next: extensions: rename `kernel-localmodconfig` to just `lsmod` armbian-next: docker: remove old code armbian-next: try harder to get `en_US.UTF-8` logging armbian-next: drop dead/duplicated code for bootsplash and mark kernel-drivers.sh (which includes bootsplash) as dead code armbian-next: extract `move_images_to_final_destination()` and optimize for fast-move when src/dst on same filesystem armbian-next: tune logging: unmounting, u-boot prep/source/install; traps; extensions armbian-next: don't leak `.raw` image if failure before move; show rootfs-tmpfs info armbian-next: `mktemp` and `tmpfs` related utility functions with automatic cleanup handlers armbian-next: small cleanups: squash typos / add function keyword / add types / mark dead code armbian-next: small cleanups: squash typos / add function keyword / add types / mark dead code armbian-next: add logging with size of actual built rootfs in MiB; debug tmpfs in trap & after pkgs done armbian-next: still fighting `tee` leaking under duress, and I think I won armbian-next: `compile_firmware()`: use new temp dir helpers (saves 2Gb+ in WORKDIR), fix typos armbian-next: severe bug, there was no prefix-emoji for Windows armbian-next: allow shortcut `EXT=` to the overly-long and plural `ENABLE_EXTENSIONS=` armbian-next: use retries for downloading ORAS tooling WiP: aggregation.py vs create-cache.sh: better hashing, much desktop WiP: patching.py vs decent logging: better, but not there yet ------------------------ armbian-next END marker ----------------------------- Richard Neese <r.neese@gmail.com> (1): `risc-v`: switch from `grub` to `extlinux`; add Debian Ports keyring hostdep to strap Debian riscv64 from ports Tony <tonymckahan@gmail.com> (1): armbian-next: officially support WSL2; pester user for UTF-8 terminal  

That was very infomative.
Can't add much to the discussion. I agree that forum used to be a lot better and more important. Because of the use of Discord, irc, Jira... there is more fragmentation.

We used to use the forum also to chat between devs/users/mederators. Now that is done on discord, irc or github. So the fun is out of the forum.
Nothing of what is said on discord is of value in the future. While what is said on the forum keeps its value and is easy to find.

Github is good for bugreports and discussion on how to go ahead. But it is a developers tool and not for regular users.
Discord is good to chat. It added features we didn't have on the forum like being able to do voice chats or video chat. But it takes away the focus from the forum for many.

I don't check the forum as much as I used to. Only see if there is anything interesting in the notifications. But I miss a lot because I'm not present as much. And what happens on the forum isn't communicated much about on discord.

Maybe a discord/irc room where forum posts can be seen. Just the titles would be enough to sparkle curiosity.

For me there is too much to have to keep up with. I've got my YT channel, reddit, facebook groups, forum, discord, twitter, ...
Quality decreases when too much is going on. Nobody can keep up with it maybe except Igor. (he seems to see it al )

Watched at 1.25x.

Added alpha version of image build support for RISC-V.
So far, this is an early version and some of the functions do not work in it.
Currently, support has been added for the StarFive model.
 
https://rvspace.org/
 
Details can be seen in this topic.
 
https://forum.rvspace.org/t/armbian-for-starfive-build-system-ubuntu-debian/468
 
 
Added support for Nezha D1 and Lichee RV (Dock) with Allwinner D1 RISC-V chip. To start the system. Download the image, unpack it, burn it to the SD card.  Connect the SD card to the device and turn on the power. Further steps for initial setup are similar for all Armbian systems.
 
For the Nezha D1 model, HDMI, LAN, USB, analog audio via 3.5 jack works.
For Lichee RV Dock  works HDMI WiFi USB USB-LAN
 
Link to download images.
https://disk.yandex.ru/d/da8qJ8wyE1hhcQ
 
https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-risc-v-module-gets-5-carrier-board-with-hdmi-and-usb-ports-optional-wifi/
 
forum MangoPI
https://forum.mangopi.org/

Hi,
 
I'm a SW developer with experience in:
linux, bash, systemd java, c, c++, python, spring-boot, spring-data, jpa openapi Virtualbox, Vagrant cryptography: openssl, X509, publik-key (rsa, ec) IAM: keycloak, spring security, JWT, spring cloud  
I would like to help.
 
BR,
Sandor
 

Hello,
I would like to help out. I have never been involved in open source community and this has been a dream of mine to collaborate.
 
Little bit about me.
1. I have 3 years of working in Yocto projects. During this time I have supported and developed on NXP chips and Raspberry pi.
2. I have written device side divers for them.
3. I have a masters in Electrical engineering and have been working in embedded Industry for 6 years.
4. I have a very good understanding of the Linux system been working and supporting one for more than 4 years.
5. And I am not afraid of VIM (I have a list of cheat sheets in front of my desk )
 
I am more comfortable in supporting and collaborating for Linux but open to learn and help in whatever way I can
 
Thanks
 
 
 
 

Nice chart!  So nice, in fact, that I will spare you the rms sermon.