Marco Schirrmeister
Members-
Posts
55 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by Marco Schirrmeister
-
Final comment for the sshd start problem on some systems during the first boot. That should probably discussed in its own thread though. It really seems to come down to the start time of the armbian-firstrun service. I guess it starts too early. Either of the following changes in the armbian-firstrun.service file will have it started later and avoids the issue. [Service] Type=idle or [Unit] After=multi-user.target
-
I know now why sshd is not running. The directory /run/sshd is missing. dpkg-reconfigure openssh-server or service ssh restart from armbian-firstrun delete the directory if it is there. Just restarting sshd via the console recreates it (as defined in its service). sshd -t Missing privilege separation directory: /run/sshd It can easily reproduced by enabling the armbian-firstrun service and a reboot. It runs through its things on the next boot and the directory is gone. I assume it has to do with the way the sshd restart is executed. Something where it is executed in a script, that in turn is executed via a systemd service during a boot. If you restart it via the console shell where you logged in, it works just fine.
-
In my case, they are not always empty. Maybe early on, I don't know. Have not tried to mount the disk after each first boot to see the status. They keys are often fine, after I ran through the first boot setup wizard (armbian-firstlogin). Then a restart of the daemon or a reboot is all to get it started. The other day when I looked at it, I found this one. https://github.com/armbian/build/issues/3771 In the armbian-firstrun script are the commands to delete the keys, re-create them and restart the service. Given that this commands are run in serial, I wonder if the "dpkg-reconfigure openssh-server" can fail in a why to generate 0 byte files. But given that they are most of the time ok, I don't understand why a restart of the service later in the script would fail. Unless there is something else besides the firstrun script that tries to do the same thing.
-
@adr3nal1n27, for you initial question #3. If you want poweroff working on the OPi5(+), then you need to patch your system for now. This patch here from the Rock 5b seems to work on the OPi5(+) as well. https://lore.kernel.org/lkml/170389050012.2630399.8754217298577818519.b4-ty@sntech.de/T/ Maybe the Armbian maintainer will add these things at one point. Otherwise it might eventually show up upstream in the mainline kernel.
-
@David Pottage, like Werner said, ssh is enabled, but it does not start. From what I have seen it fails to start because there is a problem with the ssh host keys. They are 0 bytes. At least this was the case for me, when I tried to debug this. If you do not want to go through the first setup wizard via the console, then try to delete the host key files in the /etc/ssh/ directory, when you mount your sd card on another machine. Or check if they are indeed 0 bytes and if so, delete them. Then try to boot again. It should re-create them automatically. No idea what why they are empty. There is an armbian-firstrun script, which seems to delete and re-configures sshd, but no idea what or if it is even invoked.
-
OrangePi 5 Plus - rtc hym8563 - irq issue
Marco Schirrmeister replied to Marco Schirrmeister's topic in Orange Pi 5 Plus
After some more searching, I found this patch, which looked to me interesting. At least from the little description https://patchwork.kernel.org/project/linux-rockchip/patch/20231202071212.1606800-1-CFSworks@gmail.com/ The RK1 module is also RK3588 based and has a HYM8563 chip as well. No idea what this is or what is different on the various boards and their components. But I thought I give it a try. I implemented the hym8563 patch line on the edge-6.7.1 version to see what happens. Result is, it made a change on the OPi5+. No more high cpu usage or heavy interrupt increases with the change from none to up, when the hym8563 driver is loaded. Since I am not a hardware guy, I have no idea what this is or what it does. If it is good or bad or whatever. -
I want to share some information about an issue that I see on my OPi5+. Since I got it I am messing around with it and everything works great so far with the edge 6.7 kernel. One thing I noticed though was, that right after installation with nothing connected and when idle, there was one kernel process that was constantly consuming around 10% CPU time and the load stays at 1. The process was irq/136-hym8563. The number varies of course after each boot. Kernel driver is rtc_hym8563. Since it is build into the kernel I was not able to unload it as a first test. Side node, the issue is not seen on the Rock5b, so it seems OPi5+ hardware specific. Even if both are relative similar. I have not found anything useful so far on the internet. Don't know if it is just my device or if others are seeing a similar thing on their OPi5+ with the 6.7 edge kernel. IRQs going up like crazy for a few interrupts, compared to when driver rtc-hym8563 is not there. arch_timer rk_timer fec80000.i2c hym8563 Here are some debugging information. top output. root@orangepi5-plus ~# top -b -n 4 -p (pgrep hym) top - 16:30:43 up 3 min, 1 user, load average: 1.08, 0.63, 0.27 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 1.2 sy, 0.0 ni, 97.6 id, 0.0 wa, 1.2 hi, 0.0 si, 0.0 st MiB Mem : 15718.1 total, 15299.5 free, 422.6 used, 212.1 buff/cache MiB Swap: 7859.0 total, 7859.0 free, 0.0 used. 15295.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 438 root -51 0 0 0 0 D 0.0 0.0 0:16.90 irq/136-hym8563 top - 16:30:46 up 3 min, 1 user, load average: 1.08, 0.63, 0.27 Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.7 sy, 0.0 ni, 97.9 id, 0.0 wa, 1.3 hi, 0.0 si, 0.0 st MiB Mem : 15718.1 total, 15299.5 free, 422.6 used, 212.1 buff/cache MiB Swap: 7859.0 total, 7859.0 free, 0.0 used. 15295.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 438 root -51 0 0 0 0 R 7.7 0.0 0:17.13 irq/136-hym8563 top - 16:30:49 up 3 min, 1 user, load average: 1.07, 0.63, 0.27 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.7 sy, 0.0 ni, 97.9 id, 0.0 wa, 1.3 hi, 0.0 si, 0.0 st MiB Mem : 15718.1 total, 15299.5 free, 422.6 used, 212.1 buff/cache MiB Swap: 7859.0 total, 7859.0 free, 0.0 used. 15295.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 438 root -51 0 0 0 0 D 8.0 0.0 0:17.37 irq/136-hym8563 top - 16:30:52 up 4 min, 1 user, load average: 0.99, 0.62, 0.27 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.8 sy, 0.0 ni, 97.9 id, 0.0 wa, 1.3 hi, 0.0 si, 0.0 st MiB Mem : 15718.1 total, 15299.5 free, 422.6 used, 212.1 buff/cache MiB Swap: 7859.0 total, 7859.0 free, 0.0 used. 15295.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 438 root -51 0 0 0 0 D 8.0 0.0 0:17.61 irq/136-hym8563 Interrupt increase over 1 minute. 100k for hym8563 and 1million for fec8000.i2c root@orangepi5-plus ~# uptime && date && cat /proc/interrupts | grep -iE "(hym|fec80000|_timer)" && sleep 60 && date && cat /proc/interrupts | grep -iE "(hym|fec80000|_timer)" 17:28:15 up 35 min, 1 user, load average: 1.01, 1.07, 1.00 Mon Jan 22 05:28:15 PM CET 2024 19: 26038 125123 73155 438814 46260 13649 3574 299665 GICv3 26 Level arch_timer 25: 22900 83767 54823 279426 36468 15155 10963 9513 GICv3 321 Level rk_timer 48: 0 0 0 0 0 0 0 30250774 GICv3 355 Level fec80000.i2c 136: 0 0 0 0 0 0 0 5041747 rockchip_gpio_irq 8 Level hym8563 Mon Jan 22 05:29:15 PM CET 2024 19: 26366 125128 91142 438815 46849 13652 3574 307458 GICv3 26 Level arch_timer 25: 23366 84133 67225 279722 37149 15171 10976 9752 GICv3 321 Level rk_timer 48: 0 0 0 0 0 0 0 31073437 GICv3 355 Level fec80000.i2c 136: 0 0 0 0 0 0 0 5178856 rockchip_gpio_irq 8 Level hym8563 irq cpu time is also visible in mpstat root@orangepi5-plus ~# mpstat -P ALL Linux 6.7.1-edge-rockchip-rk3588 (orangepi5-plus) 01/22/2024 _aarch64_ (8 CPU) 07:43:50 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 07:43:50 PM all 0.13 0.00 0.68 0.01 1.33 0.03 0.00 0.00 0.00 97.82 07:43:50 PM 0 0.03 0.00 1.30 0.01 0.98 0.08 0.00 0.00 0.00 97.61 07:43:50 PM 1 0.03 0.00 0.26 0.01 0.18 0.02 0.00 0.00 0.00 99.51 07:43:50 PM 2 0.03 0.00 3.06 0.01 2.46 0.07 0.00 0.00 0.00 94.37 07:43:50 PM 3 0.02 0.00 0.77 0.01 0.58 0.02 0.00 0.00 0.00 98.60 07:43:50 PM 4 0.59 0.00 0.11 0.01 0.03 0.02 0.00 0.00 0.00 99.24 07:43:50 PM 5 0.22 0.00 0.05 0.01 0.01 0.01 0.00 0.00 0.00 99.70 07:43:50 PM 6 0.06 0.00 0.01 0.01 0.01 0.00 0.00 0.00 0.00 99.91 07:43:50 PM 7 0.04 0.00 0.02 0.01 6.49 0.03 0.00 0.00 0.00 93.42 procinfo output shows as well the high number for irq 136 and 48. root@orangepi5-plus ~# procinfo Memory: Total Used Free Buffers RAM: 16095284 585248 15510036 22584 Swap: 8047640 0 8047640 Bootup: Mon Jan 22 16:53:14 2024 Load average: 1.29 1.09 1.02 1/231 9335 user : 00:01:51.76 0.1% page in : 238872 nice : 00:00:00.03 0.0% page out: 118633 system: 00:09:19.33 0.7% page act: 59088 IOwait: 00:00:09.19 0.0% page dea: 0 hw irq: 00:18:07.58 1.3% page flt: 1335085 sw irq: 00:00:24.98 0.0% swap in : 0 idle : 22:09:57.44 97.8% swap out: 0 uptime: 02:51:46.79 context : 142704160 irq 18: 0 irq 66: 0 427819017 Edge ae irq 19: 4672570 irq 77: 0 570425352 Edge PC irq 20: 0 irq 78: 0 570425353 Edge ae irq 23: 0 irq 89: 0 285212680 Edge PC irq 25: 2504720 irq 90: 0 285212681 Edge ae irq 31: 0 irq 91: 2 irq 32: 15 irq 92: 0 irq 33: 1 irq 93: 32 irq 34: 0 irq 94: 0 irq 35: 0 irq 95: 75881 428343296 Edge en irq 36: 0 irq 96: 0 570949632 Edge en irq 37: 0 irq 97: 0 irq 38: 0 irq 98: 0 irq 39: 0 irq 99: 0 irq 40: 0 irq 100: 0 irq 41: 2 irq 101: 514 irq 43: 653459 irq 102: 0 irq 44: 2278 irq 119: 0 irq 45: 1346 irq 130: 0 8 Edge PCIe PME irq 46: 203 irq 131: 0 9 Edge aerdrv irq 47: 41964 irq 132: 99660 irq 48: 141047548 irq 133: 56265 irq 49: 108 irq 135: 0 irq 50: 0 irq 136: 23507838 irq 51: 0 irq 137: 324 irq 52: 2 irq 138: 0 irq 53: 0 irq 139: 0 irq 54: 0 irq 140: 0 irq 65: 0 427819016 Edge PC Since I do not need the RTC on my system, my idea was to create an own custom image, where rtc_hym8563 is build as a module. Where I can disable the module in the hope the process is gone and nothing is consuming cpu time when idle. It turns out that worked for me and I am running it like this for now. Here are my steps. Change kernel config in the build system. # config/kernel/linux-rockchip-rk3588-edge.config CONFIG_RTC_DRV_HYM8563=y After new image is installed and booted, it is indeed now a module. root@orangepi5-plus ~# zcat /proc/config.gz | grep -i hym CONFIG_RTC_DRV_HYM8563=m Disabling the rtc_hym8563 driver echo "blacklist rtc_hym8563" > /etc/modprobe.d/blacklist-rtc.conf update-initramfs -u reboot I just wanted to share this information in case someone else see this. For now I will live with my workaround and keep an eye on the kernel development to see, if there will be a change. In case there is some hardware expert and has some other tips, please feel free to share. Cheers, Marco
-
Still pay attention on how things behave, since all the rk3588 code in 6.x is new. I for example still experience some strange behaviour on the OPi5+ with latest edge kernels, where irq / rtc-hym8563 process uses constantly around 10% cpu. I have not tried to look into it yet, but it is for sure not normal that IRQs are used nonstop like crazy.
-
I took my OPi5+ apart and inserted the M.2 to SATA to see how it goes with the edge 6.7 image. Works just fine. See below. I did not do anything special, since PCIe3 support is there. It should work with the 5.10 kernel too. If it does not get recognized for you, maybe the adapter is dead. Try it in another system. Kernel info root@falcon ~> uname -a Linux falcon.home.marco.cx 6.7.0-edge-rockchip-rk3588 #1 SMP PREEMPT Sun Jan 7 20:18:38 UTC 2024 aarch64 GNU/Linux M.2 to SATA - ASM1166 root@falcon ~# lspci | grep -i asm 0000:01:00.0 SATA controller: ASMedia Technology Inc. ASM1166 Serial ATA Controller (rev 02) root@falcon ~# lspci -s 0000:01:00.0 -vv | grep -E "(LnkCap:|LnkSta:|Kernel)" LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us LnkSta: Speed 8GT/s, Width x2 Kernel driver in use: ahci I also did a test with another adapter I had still laying around. M.2 to SATA - JMB585 root@falcon ~# lspci | grep -i jmb 0000:01:00.0 SATA controller: JMicron Technology Corp. JMB58x AHCI SATA controller root@falcon ~# lspci -s 0000:01:00.0 -vv | grep -E "(LnkCap:|LnkSta:|driver)" LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM not supported LnkSta: Speed 8GT/s, Width x2 Kernel driver in use: ahci And here is what my production setup looks like. M.2 to PCIe - PCIe to M.2x2 (ASM2812) - M.2 to SATA ASM1166 root@falcon ~# lspci | grep -i asm 0000:01:00.0 PCI bridge: ASMedia Technology Inc. Device 2812 (rev 01) 0000:02:00.0 PCI bridge: ASMedia Technology Inc. Device 2812 (rev 01) 0000:02:08.0 PCI bridge: ASMedia Technology Inc. Device 2812 (rev 01) 0000:03:00.0 SATA controller: ASMedia Technology Inc. ASM1166 Serial ATA Controller (rev 02) root@falcon ~# lspci -s 0000:02:00.0 -vv | grep -E "(LnkCap:|LnkSta:|driver)" LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us LnkSta: Speed 8GT/s, Width x2 Kernel driver in use: pcieport root@falcon ~# lspci -s 0000:03:00.0 -vv | grep -E "(LnkCap:|LnkSta:|driver)" LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us LnkSta: Speed 8GT/s, Width x2 Kernel driver in use: ahci Which are basically this 3 products. https://www.amazon.de/gp/product/B07YDH8KW9 https://de.aliexpress.com/item/1005003908630199.html https://www.amazon.de/gp/product/B0B6RQHY4F
-
I have no idea what this rk3588-sata2 overlay is supposed to do. But I don't think you need it. For you adapter, I guess you have one of this M.2 to sata adapters like this? https://www.amazon.de/gp/product/B0B6RQHY4F I am pretty sure I tried to use this adapter directly some time ago and it was visible too. But that was the classic Orange Pi 5. In lspci, you should see something like this. 05:00.0 SATA controller: ASMedia Technology Inc. ASM1166 Serial ATA Controller (rev 02) Try to load the edge kernel 6.7 image. That one has received a lot of hardware support for the rk3588. All what it needs is the ahci driver. I do something similar on my OPi5+. I have a M.2 to PCIe riser card. In there is a pcie switch card with a ASM2812 chip. This card has 2 M.2 slots. In there are M.2 to SATA3 adapters with an ASM1166 chip (each 6 ports).
-
@Endian, yes bootsize=512 creates a bigger boot partition. The old default is to small when you run an upgrade. It typically runs out of disk space when you do kernel upgrades. Thats why I made it bigger on my test builds.
-
Without knowing what you did exactly, the following creates a bootable image. ./compile.sh BOARD=rock-5b BRANCH=collabora RELEASE=bookworm KERNEL_CONFIGURE=no BUILD_MINIMAL=no BUILD_DESKTOP=no COMPRESS_OUTPUTIMAGE=img BOOTSIZE=512 You may also need to clear whatever is in your SPI flash.
-
how could I setup wifi headlessly for orange pi 5B?
Marco Schirrmeister replied to Carl Hung's topic in Rockchip
Getting a ethernet cable is the easiest thing for the initial setup. Otherwise you can use a serial connection and do the first boot setup via serial. Armbian images are not like the Raspian images, where you have a fat partition, that you can easily mount and store some files on it. You could of course do some hacky stuff like mounting the boot or root partition from the img file and pre-configure some stuff, if you know what to do. It will definitely not as easy as just creating an empty file. -
I love the Collabora kernel. Finally PCIe 3.0 support. Have a PCIe card connected via a M.2 to PCIe riser adapter. π marco@loop ~> ssh -l pi 192.168.2.212 ____ _ ____ ____ | _ \ ___ ___| | __ | ___|| __ ) | |_) / _ \ / __| |/ / |___ \| _ \ | _ < (_) | (__| < ___) | |_) | |_| \_\___/ \___|_|\_\ |____/|____/ Welcome to Armbian 23.08.0-trunk Bookworm with Linux 6.5.0-rc1-rockchip-rk3588 No end-user support: built from trunk System load: 1% Up time: 8 min Memory usage: 2% of 7.76G IP: 192.168.2.212 Usage of /: 9% of 29G RX today: 12.4 MiB root@rock-5b ~# neofetch root@rock-5b ------------ β β β β β β β β β β β OS: Armbian (23.08.0-trunk) aarch64 βββββββββββββββββββββββ Host: Radxa ROCK 5 Model B ββββ ββββ Kernel: 6.5.0-rc1-rockchip-rk3588 ββββ βββββββββββ ββββ Uptime: 1 min ββββ ββ ββ ββββ Packages: 538 (dpkg) ββββ ββ ββ ββββ Shell: fish 3.6.0 ββββ ββ ββ ββββ Terminal: /dev/pts/0 ββββ βββββββββββββ ββββ CPU: (8) ββββ ββ ββ ββββ Memory: 178MiB / 7944MiB ββββ ββ ββ ββββ ββββ ββ ββ ββββ ββββ ββββ βββββββββββββββββββββββ β β β β β β β β β β β root@rock-5b ~# lspci 0000:00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0000:01:00.0 PCI bridge: ASMedia Technology Inc. Device 2812 (rev 01) 0000:02:00.0 PCI bridge: ASMedia Technology Inc. Device 2812 (rev 01) 0000:02:08.0 PCI bridge: ASMedia Technology Inc. Device 2812 (rev 01) 0000:03:00.0 SATA controller: JMicron Technology Corp. JMB58x AHCI SATA controller 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0004:41:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) root@rock-5b ~# lspci -s 01:00.0 -vv | grep -E "(LnkCap:|LnkSta:)" LnkCap: Port #0, Speed 8GT/s, Width x8, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us LnkSta: Speed 8GT/s, Width x4 (downgraded) root@rock-5b ~# lspci -s 02:00.0 -vv | grep -E "(LnkCap:|LnkSta:)" LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us LnkSta: Speed 8GT/s, Width x2 root@rock-5b ~# lspci -s 02:08.0 -vv | grep -E "(LnkCap:|LnkSta:)" LnkCap: Port #8, Speed 8GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us LnkSta: Speed 2.5GT/s, Width x1 root@rock-5b ~# lspci -s 03:00.0 -vv | grep -E "(LnkCap:|LnkSta:)" LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM not supported LnkSta: Speed 8GT/s, Width x2 root@rock-5b ~# lsblk -f -d -o NAME,MAJ:MIN,RM,HOTPLUG,MODEL,SIZE,ROTA,TYPE,TRAN,SUBSYSTEMS,VENDOR | grep -E '(^sd.+)' sda 8:0 0 0 ST2000DM008-2FR102 1.8T 1 disk sata block:scsi:pci:platform ATA sdb 8:16 0 0 ST2000DM008-2FR102 1.8T 1 disk sata block:scsi:pci:platform ATA sdc 8:32 0 0 ST2000DM008-2FR102 1.8T 1 disk sata block:scsi:pci:platform ATA Next step is, ordering a card with an ASM2824 chip and attaching 4 M.2 ASM1166 cards. The Rock 5B is getting closer to be NAS ready.
-
Armbian images are now available for Rock 5b!
Marco Schirrmeister replied to Igor's topic in Rockchip
Looks like you use an image from balbes150. You may want to ask in this thread here, which is about his images. But before asking, read the important comments a few times. -
Rene, with an installation of the official image like Bullseye with the 5.10 kernel, it should work. Maybe you did some modifications? If so, try it with a fresh installation. Without any changes I can see "ttyS6". After enabling all uart in armbian-config, I can see more after a reboot. root@rock-5b ~# ls -la /dev/ttyS* crw--w---- 1 root tty 4, 66 May 24 08:55 /dev/ttyS2 crw-rw---- 1 root dialout 4, 67 May 24 08:55 /dev/ttyS3 crw-rw---- 1 root dialout 4, 68 May 24 08:55 /dev/ttyS4 crw-rw---- 1 root dialout 4, 70 May 24 08:55 /dev/ttyS6 crw-rw---- 1 root dialout 4, 71 May 24 08:55 /dev/ttyS7 In the images from balbes150, with some 6.x kernel, I think you can see more ttyS by default.
-
Same or similar was asked here. You will probably not get a good answer. Be prepared for some harsh words. π My experience from the past is, that this images work sometimes and sometimes not. Even if words like "stable" are mentioned in the rolling release section, don't count on it. I have seen this error in the past as well, when I tried for fun one of the nightly images, but my troubleshooting did not get my anywhere. Only thing I remember is that the UUID that was mentioned was at least correct in terms that it was in the fstab and armbianEnv.txt. It might have something to do with the SPI and what is in there. Maybe also not, who knows.
