Igor

Instruction on how to use wireless WoL (Wake on LAN) using RTL8189FS example in Armbian 23.x Bookworm
(This wireless WIFI adapter is installed in Oprange Pi Lite/Oprange Pi Plus(2E)/Orange Pi Zero Plus/Oprange Pi PC Plus/Oprange Pi 2/etc...)
 
1. First of all we need to change the device tree configuration file dts file for our single board. The point is that for most WIFI drivers for SDIO interface there is a normal configuration of single board wake-up via interrupt and therefore there is no need to go into dts. In the driver for RTL8189FS (aka RTL8189FTV) there is NO such feature as "host-wake" interrupt and we will have to make small changes to wake up the single board when Magic packet (WoL) is detected through the "gpio-keys" button module.
The same method will most likely work for the related RTL8189ES (aka RTL8189ETV) adapter, but keep in mind that here you will most likely need other settings in the dts file, since the gpios (for wifi_rst and wifi_wake) for your single-board adapter will be under a different number.
 
 
2 The second step is to compile and install a new driver for RTL8189FS with WoL function enabled, I will do it on the single board itself. You can also do cross compilation (do it on your computer).
 
 
3. How to use WoL.
 
 
4. Additionally.
 
 
wol-wakeup-for-rtl8189fs.dts.txt
QuickStartGuideforWOW.399483868.pdf
Link to original source

Hello, First of all, thank you very much for your support and your work on the system. I can imagine how much work goes into this project. As feedback, I would like to share my findings. As I said, I have little knowledge of Linux. But maybe they will help others. The downgrade to kernel 5.4 was unsuccessful under "jammy". It just didn't work. I loaded “bookworm” and it worked there without any problems. Of course I'm not an expert, but I followed the same steps. Anyway, just for information. You were right, under kernel 5.4 the "rc.local" is evaluated with the hdparm command and works. I continued testing. On kernel 6.1 I uninstalled "hdparm" and installed "hd-idle". Under Kernel 6.1 "hd-idle" works without problems. I'm excited. So from my point of view the following conclusion: Kernel 5.4 "hdparm" does not work under Kernel 6.1. I continue to use Kernel 6.1 and send my hard drives to sleep with "hd-idle". You can certainly assess or classify my findings better. In any case, my problem is solved with your support. Thank you for that!!! I found out that “plex” can be installed under armbian-config. My system runs very smoothly with Armbian + Plex on my XU-4. Thank you!!!!

I just want to add a few comments to this whole dtb overlay discussion.
 
First I want to thank all of you involved in this discussion.  You all have different view points and I think are tackling a very difficult problem to which there is no perfect solution.  What comes out of this discussion should be applied to the other soc families as well, as they all suffer from some form of this issue as there is no standard in place that works for all use cases well.  From what I have seen, good minds are thinking this through and I expect a good result to follow.
 
The reason I am commenting at all, is because in my role as forum moderator, the basic question: "How do I enable feature x on my board" is one of, if not the most commonly asked question by end users of the forum.  And when the answer is 'just write a dtb overlay', you have lost 95% of those users as they do not have the skills/knowledge to do that.  The status of the dtb overlay's across Armbian supported and community maintained boards is poor.  There is no standardization from family to family or board to board.  And no testing of what does exist to ensure that it works.  Now I'm not saying that all of this needs to be solved in what comes out of this design discussion.  I'm just saying from my perspective as a moderator that this is an area that can use some attention, and in doing so, please try to make the end result usable by the typical end user of an sbc, trying to do common things.  I realize also that I'm saying this when I only use these boards as servers and don't personally need any of the functionality the overlays provide.  But as a forum moderator, I see the mismatch between what is being done and some common use cases that end users are looking for.

here is some 2 cents comments, if you are meaning NPUs like these:
 
https://github.com/rockchip-linux/rknpu2
 
- hardware interfaces are kept as trade secrets and not published anywhere
 
1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs
it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source)
and there is no hardware documentation any where about the technical details, registers etc. 
if that at least those are published, one could possibly start coding something to test things on the NPU.
 
then that for things like ethos-n78
https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78
you can find some info here
https://developer.arm.com/Processors/Ethos-N78
but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them.
 
- IO / cpu scheduling 
 
cpu frequency scaling / governors are well documented
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
https://docs.kernel.org/scheduler/schedutil.html
https://www.kernel.org/doc/html/latest/scheduler/
and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain.
but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer.
and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well.
Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate.
 
and if one wants to do some manual scheduling there is the plain old "nice" command
https://www.scaler.com/topics/linux-nice/
 
----
well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues.
 
The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them.
You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions.
 
This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling).
 
And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is  unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.
 

Download Armbian with HA
Then boot the image, wait few minutes and login via http://ip_address_of_armbian_running_ha:8123 (official onboarding manual)
 
Home Assistant Supervised is, more or less, a full blown Home assistant.
 


Main difference between HA OS and Armbian with HA is that underlying OS here is clean Armbian Debian Bookworm and there is custom dedicated buildroot OS that is provided for a few single board computers, primarily for Raspberry Pi. We provide HA on a small selection of single board computers, but in theory, its possible to run this on (almost) all that are possible to build.
 

I am running HA on Odroid N2+ and it works without any problems. I have z-wave network with sensors and switches, air humidifier, Android TV, Android phones, dishwasher, ... Things works flawlessly, much better then few years back when I started with home automation for a first time, with OpenHab. This time it was setup from scratch and in a matter of days, most of devices are in function, playing with automation.
 
Tested on:
Odroid N2/N2+ Odroid M1 Nanopi R4S Uefi-x86 Khadas VIM1S Khadas VIM4 (Amlogic vendor kernel trouble, failing / need inspection) Bananapi M2 Pro  
Provided for but untested (images you find on board downloads locations, seek them here https://www.armbian.com/download/😞

 
 
DIY

Contribute
 
Support:
single board computer hardware https://www.armbian.com/bugs home assistant functions https://community.home-assistant.io/

Hi,
after update to stable v23.11 branch i cannot build anymore under WSL2
 
i get the following error when the process starts to create the image:
 
"Error: Partition(s) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/loop0 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes."

here's the full log:
https://paste.next.armbian.com/kilubovuru
 
Any help would be very much appreciated.
Thanks
 
 
 
EDIT: solved by replacing the kernel with the armbian one ( https://github.com/armbian/build/pull/5978#issuecomment-1826840715 ) 

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  

Raspberry Pi OS started to secretly (!?) adding Microsoft proprietary package base, access to their servers, by default. 
 
Security consequences? tl;dr; ... Microsoft gained root access to millions of Rpi users without their consent or awareness. From the outside. This is bad, but it is actually much worse since from the inside they already have full control of your Raspberry Pi regardless of operating system of your choice. Linux/BSD/* can't boot without proprietary Microsoft owned real time OS.
 
Most of the RPi users probably just don't care, others are naively assuming they are running FOSS software. Well, a part of it is, a part not. Not as bad as Android, but still. You can peek into the code, but at the end, Google, or lets say corpo world, is/are fully in charge of our mobile devices. Mainly with services.
 
After recent Chromium improvements, this is yet another loss for (Linux) community and FOSS in general.
 
http://techrights.org/2021/02/02/microsoft-pi/
https://en.wikipedia.org/wiki/ThreadX
https://www.infoworld.com/article/3536569/inside-microsofts-latest-os-azure-rtos.html
https://www.zdnet.com/article/linux-distributors-frustrated-by-googles-new-chromium-web-browser-restrictions/

I use 154! I understand it will use C.UTF-8 as locale. That's what I've been using forever, and it just works... 

You should not advise to buy shit, they are cheaper because:
* they are made of scrap parts, that often break after very short usage (see the emmc in the rk3318 thread)
* they have no kind of warranty
* the power supply is a joke, made of cheap components and very lousy - switching power supplies are one of the thing the more they weight the better; confront with a quality 5V/2A power supply and see the difference
* the HDMI cable is crap quality, often not capable to transfer CEC or collects any kind of interference at 1080p/4K
* the case is a bit of plastic, with little to no design for heat dissipation - right now I have a rk322x board here withing its case that reaches 97°C while simply installing a package with apt...
* many sorts of limitations to keep them as cheap as possible: no sd card UHS mode, no real shutdown/suspend, USB ports have limited power: be prepared to have headaches if you try to attach something that requires just a tiny bit more power like an external hard drive.
* wifi is a lottery and clearly tells you the general quality: you can find freshly made boards with wifi chips discontinued years ago!
 
Most of all: they have absolutely no software support; if you are able to run armbian on your tv boxes it is because some people within armbian and other projects spent their time for the fun of making it.
Tv box makers don't care at all, they just need to sell their cheap shit to make some profit. Some (not all) SBC makers at least in some way provide support, but tv box makers are mostly parasitic and should not be endorsed.
 
Now that you stated that about 20 pcs of different tv boxes run armbian, may I also ask you what you did in change for that for armbian? Because tv box makers obviously did nothing for armbian, still keeping up the servers infrastructure and the general maintenance cost real money to real people, and who pays that?

Perhaps it doesn't work. More resources / ideas / background:
https://www.google.com/search?q=blacklist+USB+UAS+armbian
https://www.cnx-software.com/2020/08/12/how-to-fix-unreliable-usb-hard-drives-stalled-transfers-linux-windows/
https://leo.leung.xyz/wiki/How_to_disable_USB_Attached_Storage_(UAS)

@Igor I created pull request for this issue https://github.com/armbian/build/pull/6057.

armbian-install
https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-sata-nvme-usb
 
using orangepi docs for Armbian is like using the manual of your toaster for your forklift.

Yes, suggesting those images is our bug. I am aware that sorting doesn't work right but this is yet another problem we have to deal with. I have asked that this is fixed and since we don't have professional support It can take several weeks, perhaps a month. I can't fix it, I can just patch it, so I have removed those images for good and they will be gone from index within several hours. More then this its not possible to do.
 
 
I am using this image for several months in production. Any many other people. We share this joy with you. 
 
Mainline based support functions rarely gets to full completion as its very expensive to brought things up and maintain with no budget. Adjust expectations, use old kernel, share findings with others, but don't expect anything, especially not answering questions. It can easily take hours, which is not at end users level.

At the very bottom of Orangepi 5 download page https://www.armbian.com/orangepi-5/

"Rolling releases from CI pipeline"
 
 
 

"Virtual disk images (such as VHD and VMDK) are intended to be used for cloud computing,"
https://en.wikipedia.org/wiki/IMG_(file_format)#Comparison_to_ISO_images

Our build framework can generate cloud images directly https://github.com/armbian/build/blob/main/extensions/image-output-vhd.sh in case you need to automate this and you don't want to mess with additional scripting.
 
./compile.sh ENABLE_EXTENSIONS="image-output-vhd"  
 
Try using dd and copy entire image from USB to /dev/vdi or whatever disk device is.
 
Please provide armbianmonitor -u and if you want to look into & help in this context, here are sources. You are also welcome to open a ticket and we both can hope someone will fix this soon. Even its probably just one-line fix, someone needs to find that line, test it to make sure it works and open a pull request. 

If you don't power it via powered hub, its almost certainly this. Those USB ports are not delivering sufficient power.

We registered the #armbian channel on the OFTC IRC network. It has been added to the bridge so message will be relayed to Libera and Discord.
Depending on how frequently it will be used other channels like those for SoC or off-topic will be added later. Thanks @yang for the suggestion

I can assure you ZFS from Arbmian repo works perfectly fine. We are using it on two production grade servers.
 
odroidhc4:~:# modinfo zfs filename: /lib/modules/6.0.12-meson64/updates/dkms/zfs.ko.xz version: 2.1.6-0york1~22.04  

@IgorI think the problem is caused by the way the packages are published. I think we ran the build for bookworm and jammy, but when publishing we updated the Package list of bullseye as well. Thats how bullseye is now getting armbian-bsp-cli package for 23.11 version. As build was not run for bullseye, the bullseye specific base-files package didn't got updated. I think we need to modify our repo updating job to also take account of what distributions to be updated, instead of updating all of the distributions. That should fix these kind of upgrade issues when we drop support for older OS. Lets disccuss this further in today's meeting 

Hi, thank for the answer, the serial is really useful!
The problem was the screen, i had used an HDMI/DP converter.
I changed the monitor with one with HDMI and now it works perfectly.
 
Thank you very much, you saved me a lot of hours!

It was caching. I cleared the `cache/initrd/` folder and rebuilt Armbian, then it worked fine.
 
@Igor I created a Pull Request go get this change into main.
https://github.com/armbian/build/pull/5901
 

Use Gnome. I think it doesn't work with Cinnamon.

i've managed to create DRM driver for that display.
https://lore.kernel.org/linux-devicetree/20230807121022.1871-2-viteosen@gmail.com/
that was impressive jouney
pcd8544.c pcd8544-drm-spi.dts

Yeah, it tried to add some sarcasms. Not sure if it worked