Igor

A quick look at the shell code makes me think that it is a different purpose compared to how I use virtualization. I use only HW accelerated based virtualization, so -enable-kvm flag is missing, but might be added by virt-install. Also mostly Arm on Arm although I also use x86 on x86 as well. I do not use qcow2, but just flat images or a physical SD-card or NBD or LVM.
 
Before I got my Rock3A, I downloaded the Armbian Noble image for it (was 6.6.62) but put a 6.12 *rk3588 kernel on it as well. With the default Armbian U-Boot for QEMU I could then prepare everything and already 'run' my Rock3A as a VM on NanoPi-R6C like this:
taskset --cpu-list 0-3 qemu-system-aarch64 \ -M virt -cpu host -enable-kvm -m 2048 -smp 4 \ -bios u-boot.bin \ -drive if=none,file=rock3a.img,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev bridge,id=hn1 -device virtio-net,netdev=hn1,mac=xx:xx:xx:xx:xx:xx \ -nographic The taskset is needed if host runs 6.1.x  vendor kernel and also makes it more realistic w.r.t. speed as then the VM gets 4x Cortex-A55, same as real Rock3A.
The 6.12/rk3588 kernel (inside the VM) was needed as that one has all included w.r.t. machine virt (same as vanilla Debian Bookworm kernel).
 
A note is that I later on added Btrfs support to a custom build u-boot for QEMU and converted Ext4 in rock3a.img into Btrfs, but principle is the same. Btrfs offers online shrink and differential snapshots that I use for remote backups. And with a MAC-address equal to the real Rock3A, it is easy flipping between real and VM.
 
Also note is that the following file needs to be created on the host, assuming it uses br0 as base for network I/O:
# cat /etc/qemu/bridge.conf allow br0  
To use full graphics in VM and for multi-year running VM on my RPi4B, I also use virsh and UEFI. But usually only CLI is needed.

hi @jock
 
I agree that changing the SMD 0201 parts is a real challenge - for this reason I used 0402's soldered them direct to the level shifter and run a tiny wire to the 5V source.
I'm thinking that an SoC side strong pull-up would do the trick eventually and remove R90611/12 entirely. But I haven't test this - but will do that with the next PCB I get on my table.
 
The Level-shifter is a Texas Instruments TX0102DCU with and with OE is high the internal 10K pull ups are enabled.  That might me not enough for the external monitor so the 6.8k has been applied.
Same for the SoC side, 10K only , so I support the internal SDA/SCL lines with the light diving strength of 2ma.
Datasheet:
8.3.5 Pullup or Pulldown Resistors on I/O Lines Each A-port I/O has an internal 10-kΩ pullup resistor to VCCA, and each B-port I/O has an internal 10-kΩ pullup resistor to VCCB. If a smaller value of pullup resistor is required, an external resistor must be added from the I/O to VCCA or VCCB (in parallel with the internal 10-kΩ resistors). Adding lower value pull-up resistors will effect VOL levels, however. The internal pull-ups of the TXS0102 are disabled when the OE pin is low.  
I would say it doesn't hurt to add the changes to the DTS for the i2c7_xfer pinctrl. But without fixing the Pull-up value on the 5V it will not improve anything.
 
Yes it is tiny tiny.

Do the same for max:
https://github.com/armbian/os/commit/45e7773d8fa023f3c5fb3c9c1402bf3616c59031
and wait for next automated rebuild cycle of community maintained images.
 
Then download pre-configured Gnome desktop image and forget about any other browser then preinstalled one. Also forget general understanding about desktop Linux on PC ... this is embedded Linux / custom hardware world, where things are "a bit" different. Developing and keeping functional desktop image was already on the level of miracle considering that we are operating with big negative budget and absolute absence of any support from HW dealer that makes big sales ... which are crushing ability of making things better. For you and for us.
 
Or dive into https://docs.armbian.com/Developer-Guide_Overview/

Make them build & boot able within the build framework
https://github.com/armbian/build
When you confirms, open a PR https://github.com/armbian/build/pulls and change config file from .eos to .csc and automation will become to produce images.

Successfully tested on the Orange Pi 5 with Ubuntu Noble minimal mainline image. Note that this image kernel panics every now and then on bootup (something to do with power management and interrupts). Disabling networking seems to solve the issue
 
The automated script now supports configuring the network interface on the target using ifupdown. This is primarily useful for statically configured setups

Thank you for quick reply. Haven't even thought it's not supported.
 
PS: I wanted to thank the developers for such build / config tool! It worked like a charm as I decided to upgrade from Ubuntu xenial.

Wow, unbelievable. But happy to see it is so actively maintained.
I don't mind being on beta for time being and I am fine with updating this often. I actually enjoy receiving updates, since I decided to switch to beta and keep the kernel unfrozen.
Worst case scenario - if some beta breaks my back, I will just restore whole SD card to a few month old backup and update to latest stable.
I do not have anything useful on my board that changes over time.
 
Lets consider this topic closed.

After applying patch from previous post, it updated to latest version without complaining about unhealthy status:

Link removed. That's all i can do for the time being.
 
@darkside40 Thanks!

Copy that, @Igor. Just learning my way around here.
 
Hopefully my donation will help a little!
 
I appreciate you and your team. Armbian is a great gift to the SBC community.

Key is not deprecated, method is. On Noble / Sid and future.
 
sudo wget https://apt.armbian.com/armbian.key -O key sudo gpg --dearmor < key | sudo tee /usr/share/keyrings/armbian.gpg > /dev/null sudo chmod go+r /usr/share/keyrings/armbian.gpg sudo echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com $(lsb_release -cs) main $(lsb_release -cs)-utils $(lsb_release -cs)-desktop" | sudo tee /etc/apt/sources.list.d/armbian.list apt update  

Key is not deprecated, method is. On Noble / Sid and future.
 
sudo wget https://apt.armbian.com/armbian.key -O key sudo gpg --dearmor < key | sudo tee /usr/share/keyrings/armbian.gpg > /dev/null sudo chmod go+r /usr/share/keyrings/armbian.gpg sudo echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com $(lsb_release -cs) main $(lsb_release -cs)-utils $(lsb_release -cs)-desktop" | sudo tee /etc/apt/sources.list.d/armbian.list apt update  

Tutorial has been updated to include support for GPT-partitioned images

You already have best possible desktop on this hardware. Simple and fast XFCE. Changing desktop environment won't make any vivid difference. 
https://docs.armbian.com/#key-advantages
 
XUbuntu is more or less identical to Armbian Ubuntu with XFCE subtracted for some Canonical proprietary stuff.

LXDE vs. XFCE ... not worth the troubles maintaining yet another desktop. Difference is too small. We only keep XFCE, Gnome, Cinnamon and KDE Neon in good shape. The rest waits for enthusiast https://github.com/armbian/build/tree/main/config/desktop and you can always start with a minimal CLI image and build on top any desktop you want.

You already have best possible desktop on this hardware. Simple and fast XFCE. Changing desktop environment won't make any vivid difference. 
https://docs.armbian.com/#key-advantages
 
XUbuntu is more or less identical to Armbian Ubuntu with XFCE subtracted for some Canonical proprietary stuff.

LXDE vs. XFCE ... not worth the troubles maintaining yet another desktop. Difference is too small. We only keep XFCE, Gnome, Cinnamon and KDE Neon in good shape. The rest waits for enthusiast https://github.com/armbian/build/tree/main/config/desktop and you can always start with a minimal CLI image and build on top any desktop you want.

Try to rework the script:
https://github.com/armbian/build/blob/main/packages/bsp/nanopim4/nanopim4-pwm-fan.sh#L316
Perhaps expand it to support selecting CPU / hard drive ?

Key is not deprecated, method is. On Noble / Sid and future.
 
sudo wget https://apt.armbian.com/armbian.key -O key sudo gpg --dearmor < key | sudo tee /usr/share/keyrings/armbian.gpg > /dev/null sudo chmod go+r /usr/share/keyrings/armbian.gpg sudo echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com $(lsb_release -cs) main $(lsb_release -cs)-utils $(lsb_release -cs)-desktop" | sudo tee /etc/apt/sources.list.d/armbian.list apt update  

It should not be a problem. I already align my patches with armbian/main so this board is ready for 6.6 and 6.12. And testing images for major kernel bumps should not be a problem neither.
 
OK, I will try to do this.

The problem behind their promotion statement is that its a scam. Dietpi is bloated with proprietary scripts and they are removing packages that are dependencies for everything ... so it makes no sense at the end, just first installation of anything takes longer. But they can claim images has few MB less ... which is "better" and most of end users have no ability / interest to understand they have been conned.
https://docs.armbian.com/#comparison
Damages they create to open source, by playing dirty, that is beyond commenting.
 
 
This should also work OOB then
https://www.armbian.com/uefi-riscv64/
and you don't need to remove anything (from minimal Bookworm OS image, which is significantly lighter then Dietpi).
 
If you / anyone can confirm they are working well, we can move this to Supported section.

I just created a pull request for this. Apologies if I got the request wrong, it's been a long time since I created a PR on anything.

This was moved under a switch to prevent users for switching into kernels that are not meant for end-users.
https://github.com/armbian/build/blob/main/config/boards/rock-5b.conf#L7
 
And this
https://github.com/armbian/configng/blob/main/tools/modules/system/switch_kernels.sh
is the logic for anyone that might to change / improve this.

Hi,
 
I am trying to update the patch for kernels 6.10 and 6.11 (same code).
My first try was not successful (compile error), I will try again, I think I've understood what the patch will do, but there are a lot off differences between kernel versions 6.6 and 6.10, maybe some new lines need to be patched too.

Once it compiles and runs fine on my helios 4, I will provide the patch 😉
 
Kind regards,
Xavier.

Also documentation (related to this topic) is now in right state of mind: https://docs.armbian.com/User-Guide_Armbian-Software/#adding-example 
 
It is hard to add software title we never tried, installed and / or know nothing about, then expert user of this software adding it to (armbian-config) installer. We focused to make this task as simple as possible, to encourage you doing that and not opening us tasks (we already have 1000 x too many and won't ever complete).
 
We added popular titles to the system, which have some value for us, while everything else is mocked by more important tasks in other sections. 
 
But mechanism is there - use it, its user / developer friendly. Also its a nice and easy way to contribute to the open source.

We are cleaning those builds as they have very little value. But you were lucky:
https://github.com/armbian/community/releases/tag/24.11.0-trunk.351

When you cloned our repo, you got 10 years of specific work on common work and that was contributed by 500+ people. Most of people are resolving their specific problems, yes, but we all try to do it the way that is reusable, that person behind has less work. We also got a lot of things prepared. Doing things universal should always be considered. Also because you might get help from someone. Which has absolutely same problems, but is having hardware from another vendor.
 
In our world, SoC defines how things work, not the one that put SoC on PCB and name / sell it. This means that most of the drivers are the same, especially this area is shared - low level communication protocols such as GPIO, I2C, SPI. This is always shared among boards with the same SoC. This goes further. It is shared among same families and we also already have some common generic top level API / libraries that can be used. https://docs.kernel.org/driver-api/gpio/consumer.html (but here my understanding ends, I am not updated with the state of this)
 
 
Yes, it has no point poking into. WiringPi library is a dead project for many years and its no point dealing with this. What vendors do here is, trying to be "as Rpi as possible", so they are doing their quick and dirty assemblies of that, always with partial functionality and absolute absence of maintenance. Their goal is to sell, regardless what is the quality of software. Is that your goal? I doubt.

I am not an expert in this field, so those are general tips, but there are people on and around this forum that knows this stuff well, as they developed those libraries.
 
 
I am just giving you some ideas / tips. Decision what you will do with your time is yours.

Another one that came into my mind, while replying: https://github.com/eclipse/mraa