Dysmas

@LiX, could you make your work available somewhere ? Either the full build or the things you have modified and some short indications to help me build, I am not familiar with armbian yet. I know the R5S version works on the R5C, but with the problems of the leds and the ethernet ports names.

This image works very well on R5S. Thanks. Is there any plan to add support to R5C which is very close (Friendly Elec offers the same software for both devices) ? Or must I try to adapt? R5C boots well on this image, and at first glance, the two points which are not working well are the names of ethernet ports, which can be fixed by an udev rule, and the Leds which remain off. This also can probably be fixed by Udev. How are the Leds handled on R5S ?

I installed Armbian on my R5s Armbian 23.8 Bookworm Kernel 6.5, Size: 479Mb, Release date: Sep 18, 2023 On this version, I find the classical problem : a module I want to build does not build. Reason ? apt says : Coundn’t find any package by glob ‘linux-headers-6.5.3-edge-odroid’ And make creates an error because “build” directory is not found. I can find the linux-headers-6.5.3 : https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.5.3.tar.gz But where can I find the odroid version ?

Hello @9bx154, I had to use the Ubuntu 20 version given by the vendor, and upgraded to 22. The leds are off. I am trying to use the udev solution you provided above, but nothing works. SUBSYSTEM=="leds", KERNEL=="green:lan1", ACTION=="add", ATTR{trigger}="netdev", ATTR{device_name}="eth0", ATTR{link}="1" ATTR{rx}="1" ATTR{tx}="1" In this distribution, the leds are in /sys/class/leds/lan1_led (or lan2_led, wan_led, sys_led). In these directories there is a "uevent" file which content is : OF_NAME=led-1 OF_FULLNAME=/gpio-leds/led-1 OF_COMPATIBLE_N=0 What do you suggest to have it work ?

About the renaming of network interfaces, I ended with this solution which could be good for a default : renaming the interfaces with the name printed on the box. SUBSYSTEM=="net", ACTION=="add", DRIVERS=="rk_gmac-dwmac", NAME="WAN" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8169", KERNEL=="eth0", NAME="LAN1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8169", KERNEL=="eth1", NAME="LAN2" After that I use /etc/network/interfaces to rename the interfaces to eth0 and eth1 as I need. rename WAN=eth0 rename LAN1=eth1

Interesting. I tried to remove net.ifnames=0 and indeed, the names are what you indicate. But I was surprised to see that SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8169", KERNEL=="enp1s0", NAME="eth1" did not work. I still had to write : KERNEL=="eth0" enp1s0 is already a rename. Kernel names are given in the order the kernel discovers the hardware and I think there is nothing to do about it. I must use the rename procedure. Thanks to have given me the tools for it.

Yes, it works thanks. But it works perfectly if I use different names, but using the same names (eth0, etc.) creates confusion. Presently it works like a dirty workaround, but I understand from what you write that the difference of behaviour between Ubuntu and Debian is that rk_gmac-dwmac is treated after r8169 and not before. I guess systemd should be able to change this.

@9bx154 , you propose udev rules to help with the leds. Would it be possible to add udev rule to name the ethernet ports ? I need WAN = eth0

Progress : I found the reason for which method 1 was not working. The wiki says : dd if=/dev/zero of=/dev/mmcblk2 bs=8M count=1 because in FriendlyElec images, the eMMC is mmcblk2. But in Armbian there is no mmcblk2, and the eMMC is mmcblk1. I corrected the command : dd if=/dev/zero of=/dev/mmcblk1 bs=8M count=1 And then the Nanopi booted on the SD card, with the eMMC available. And so I could load an image on the eMMC. This makes things more complex, but at least it works.

It is quite similar to what you say. The images for the R5S are present here: https://drive.google.com/drive/folders/1l6wnh_eXG-udXZC1C7G0-e4V6PEVdY_L In the subdirectory 02_SD-to-emmc images, the images contain the eflasher. You have also the code separatly somewhere, I do not remember where. On a card which has this utility, it is possible to make a backup "as is" of the full emmc. It is also possible to put different images, raw or gz, and they can be loaded to the emmc. Small defect of this utility : it does not compress the backup. You will not be able to use it on a different machine without modifying it, I think, because it is designed for the R5S.

I have another problem which is not a bug, so probably its place is here. Friendly Elec offers a very useful eflasher utility, with a one click backup. This utility requires that the system starts on the SD card, and the emmc is available. Unfortunately, due to the slightly strange way boot order is handled on this machine, this seems no longer possible. https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R5S#The_Boot_order_between_eMMC_and_SD_card As far as I understand, when Armbian is loaded on the eMMC, we are in the situation where the eMMC has an Image with Mainline U-boot. And in this case, whatever is present on the SD card, boot is always done on the eMMC. Method 1 does not give any result, because the file created is trashed on reboot. Method 2 (MaskROM) masks the eMMC, which makes impossible the backup of the eMMC, or the loading of a new image, with this utility. If I understand well the table, the only way to overcome this problem would be to make the image recognized as a FriendlyElec image. I have no idea if it is possible and how.

OK thanks. I hope I put the issues in the right place, because I was not sure of the meaning of : defconfig -> rockchip64-rk356x_defconfig Just for information of the reader, two other issues are for keyboard configuration, and start on microSD card.

Thanks for the login. Everything is working fine until now, thank you. I found only a problem : the order of eth0, eth1, eth2 is strange. In the Linux (Ubuntu 20) given by Friendly Elec, the order is : eth0 = WAN (right) eth1 = LAN1 (middle) eth2 = LAN2 (left) In the Armbian tested we have : eth0 = LAN1 (middle) eth1 = LAN2 (left) eth2 = WAN (right) this creates some confusion, because the order of ports from right to left (R5S box is designed like that) is eth2, eth0, eth1. The choice of the constructor was better.

@Cornelius I used your last image and loaded it to emmc. It starts fine, but I don't know the login and password to use. To load to emmc, I had to uncompress the xz file. I recompressed with gz (but this step is not necessary). Then I copied the file to a microSD card which contains their eflasher. Then install was fine.

I understand, you may not have the answer. I was just wondering if someone could know the existence in the software loaded in this image of something new which could interfere, like apparmor. Thank you anyway for the answer. I have not found the real reason, but I have been able to solve the problem by moving some files. You can close or delete the topic.

This message is on-topic, but for an unknown reason, it is not possible for me to create a message in Help wanted. So I post here. I have used Armbian for two years, I think, on several devices, and I have given some money to support it. Thanks for the job. I recently upgraded to the last version with Debian 11. Everything fine but one point which is probably not a bug, that's why I don't post in "bugs". I use Unbound which is the heart of my soft. And I use a python script which is loaded by Unbound. Until now, there was no problem. With the last version, I ran in several read problems. The first reason I found is apparmor, which prevented the script to open a module in /usr/local/lib. I removed apparmor and this solved this problem and another one. But when the scripts must open (read) /home/rock64/unbound.conf, I get a permission denied, even if the file and the directory has 777 permission. I made a lot of tests. I can read the file if copied on some directories, and not in others. I don't understand the logic. I suppose there is another program like apparmor, but I cannot find it. What can prevent Unbound from reading a 777 file ? Thanks if you have an idea.

There was an error in the downloaded sources. It is fixed. steps 1, 2 and 3 were made carefully (adding the line in Kconfig and Makefile). Step 5 (staging) was done. perhaps I misunderstood this line. I have Realtek devices, and it is selected. And inside this section, after making your modifications, I have a new line : REALTEK 8723B SDIO or SPI WiF I selected by Y [*] which was perhaps not the good option. I compiled, installed and rebooted. Still the same problem. But there is still a point to discuss. I have no longer time this week, I'll explain next week. But I have made good progress and I hope we will manage it in the end. And after that I will try to obtain that the modification is pushed in armbian. Thanks for your help.

Because this is the kernel source, the tree structure with all the directories and files you are speaking of : ".../drivers/net/wireless/realtek/Kconfig" ".../drivers/net/wireless/realtek/Makefile" with the lines like the one you mention : obj-$(CONFIG_RTL8723BS) += rtl8723bs/ and so on. And the simplest way to have it in armbian, is using armbian-config. But never mind, I'll find someone to help. Thank you for your work. Update : I had not, but now yes, I tested with this tutorial and a standard linux and the kernel built without errors : https://www.cyberciti.biz/tips/compiling-linux-kernel-26.html I think this is exactly what I did with armbian. Get the tarball and extract (done by armbian-config) on a linux machine (the Tinker board is the best I have, running Debian Buster), and so on. The steps are OK. Maybe I made a mistake somewhere. I'll try again.

I have tried to do what you say. For anyone who would like to do the same, the first step is to install the tree on the Tinker Board. install armbian-config install libncurses-dev log in as root in armbian-config select Software / kernel headers in armbian-config select Software / kernel source Then you have the full tree in linux-headers-5.4.28-rockchip, and the directory linux-source-5.4.28-rockchip contains a single file, .config. Running make menuconfig in the "source" does not gove anything this is not surprising. Running make menu in the "headers" directorcy, which contains the full tree works fine, but arrived in the Wireless LAN page, there is nothing to choose 8723bs. Nevertheless, I notice that in the .config file, I have a line CONFIG_RTL8723BS=m So perhaps everything is fine. Try make. This leads quickly to an error : no rule to make target arch/arm/tools/syscall.tbl needed by arch/arm/include/generated/uapi/asm/unistd-common-h arch/arm/Makefile:325: archheaders Error 2 This line is : archheaders: $(Q)$(MAKE) $BUILD=arch/arm/tools uapi I fear the task is too difficult for me. But thanks for the help, I hope I will find someone who is able to do the job.

OK thanks. When making, I get the following error : Makefile:244 /ha1/phydm/phydm.mk: no such file or directory make: *** No rule to make target '/ha1/phydm/phydm.mk'. Stop The reason is at line 156 : export TopDIR ?= $(src) because src has not been defined before. If I fix this,I get a new error : make[1]: *** /home/android_sdk/Allwinner/a64/android-51/lichee/linux-3.10/ : Aucun fichier ou dossier de ce type. But I am in Linux, not in Android. So I fear I will not be able to use your work.

Maybe my question is stupid, but where can I find this bs driver ?

One year later, I have exactly the same problem with the ASUS Tinker board S. This error appears the first time I try to connect, once the proper password has been entered. The next time I try to connect, I get only the line : RTL8723BS: ap recv disassoc reason code(8) sta:<my mac address> Has there been any progress on this question since last year ? Someone suggested an incompatibility with wpa_supplicant. If I uninstall it, the error no longer appears, but there is still no connection.

In the second message of this thread, the author recommends to disable also ramlog in cron.d and cron.daily. But you are right to think the problem may be elsewhere. There is no obvious reason for the reboots in the log file. Maybe you could let your Pi run with htop on screen, and see if something happens with the memory. Otherwise reinstalling may be the good solution.

This shows that at this stage everything is OK. I found nothing useful in the attached file. It is very strange that there are so few log lines at the moment of the problem. But if the log system is responsible, it may be understandable. At this stage, unfortunately, I have no idea but the first one : Try to follow the steps of the first messages in this topic to disable armbian-ramlog. If the problem persists, at least you know this is not the source. Computers are sometimes frustrating.

Then could you attach here your /var/log/syslog file after a fail / reboot and (very important) indicate at what hour the problem occurred ? Somehow this file is preserved between reboots.