All Activity

I found an incredibly roundabout way of doing this. ./compile.sh \ kernel \ BOARD=$OPT_ARMBIAN_BOARD \ BRANCH=$OPT_ARMBIAN_KERNEL \ CLEAN_LEVEL=make,alldebs,images,cache \ EXPERT=yes \ PREFER_DOCKER=yes \ KERNEL_GIT=shallow KERNEL_CONFIG=$(find $KERNEL_DIR/cache/sources/linux-kernel-worktree -name .config) if [ ! -f $KERNEL_CONFIG ] then echo "Failed to find .config" exit 1 fi FULL_KERNEL_VERSION=$(cat $KERNEL_CONFIG | grep "Kernel Configuration" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+') if [ "$FULL_KERNEL_VERSION" == "" ] then echo "Failed to get full kernel version." exit 1 fi

Thanks for the detailed description! Very useful post, especially for those who are just starting to tinker with Armbian on TV boxes. I had a similar situation with another S905X3 box - neither Wi-Fi nor Bluetooth worked, and there was trouble with HDMI audio. Special thanks for the advice on disabling unattended-upgrades and systemd-networkd-wait-online, I just encountered problems with long loading, now I understand where the legs are growing from. Regarding USB audio - an excellent solution, I didn't even know that it was so easy to bypass the lack of built-in sound. I will try with a similar adapter. If you have a chance, tell me later whether you managed to set up Wi-Fi via a USB adapter or in another way. And I wonder if you tried other window environments besides XFCE? LXQt, for example? In any case - a great guide, thanks for your work!

Look at your board config file: config/boards/orangepi5b.csc In there you will find the board family, which in your case is: BOARDFAMILY="rockchip-rk3588" Then look at the corresponding board family config file: config/sources/families/rockchip-rk3588.conf There you will find a section for each branch (i.e vendor, current, edge) that will specify which kernel source is used: For BRANCH=vendor that would currently be: KERNELSOURCE='https://github.com/armbian/linux-rockchip.git' KERNELBRANCH='branch:rk-6.1-rkr5.1' KERNELPATCHDIR='rk35xx-vendor-6.1'

i.e. git clone -b main --depth 1 https://github.com/armbian/build.git cd build # I want to find out what kernel my board is building befor here. ./compile.sh kernel BOARD=orangepi5b BRANCH=vendor EXPERT=yes PREFER_DOCKER=yes KERNEL_GIT=shallow I need to do this so I can apply patches based on the selected kernel verison (e.g. 5.10, 6.1, 6.12) as they are all different patches due to Makefile changes. I don't see a clean way to do this with the builder unless I build the kernel first, search the kernel sources and then determine the kernel that way.

Hi ... thanks for your hint. Actually I forced on the old system sata speed to 3.0 GB ... which I did not on the new installation. Setting also the link speed to 3.0 GB did however not solve the issue, I had to set it down to 1.5 GB. Now the issue seems to be gone. Performancewise it is not noticeable for harddisks, but for the SSD I have it is - need to look further into it. I'm just wondering what (still) the difference is. Forcing link speed down to 1.5 GB was not needed before ... I'm tending to exclude "hardware" as source of issues, as the hardware is in both cases identicial, no single cable touched. CU Alex

Description The idea is to introduce the possibility to cache downloads from GH runners to lower downstream bandwidth used and increase overall speed. Especially on machines with lots of runner this could save quite some bandwidth while sacrificing disk space. http caching has been tested and seem to work nicely. https caching is a lot more tricky and may be introduced later. This PR has two parts: set apt repository to http instead of https where possible. Packages are signed anyways. Pass various proxy environment variables to docker so it respects those. Doesn't make sense not to pass them since when using PREFER_DOCKER=no and any of these variables are set beforehand they just work. So this more or less just harmonizes overall behavior. There is still an issue on line 4838 caused by https://github.com/armbian/build/blob/c0da65087aad628ba0714f23d8d29800f152d97c/lib/functions/rootfs/apt-install.sh#L67 due to absence of apt proxy setting there. Not sure why this is not added here? How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] build random image: https://paste.armbian.de/xopitiguyo , look for 10.100.0.87 to see where it is used [x] built the same random image but having all proxy env variables unset beforehand: builds just fine as well: https://paste.armbian.de/ozidivugor Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Hi, without owning this board, chatgpt is pointing out to an initialisation issue of the bluetooth system caused by the GPIO pin not being correctly handled at boot. [ 6.024062] WCN: marlin chip en dummy pull up -- need manually set GPIO The correct solution would be to handle the init in the dtb file, but you can try the following systemd initialisation as a workaround to see if it works. Create (as root) the following service file /etc/systemd/system/bt-gpio.service with the contents: [Unit] Description=Enable GPIO for Bluetooth chip Before=bluetooth.service [Service] Type=oneshot ExecStart=/bin/sh -c 'echo 225 > /sys/class/gpio/export || true; echo out > /sys/class/gpio/gpio225/direction; echo 1 > /sys/class/gpio/gpio225/value' [Install] WantedBy=multi-user.target Then enable it (as root): systemctl daemon-reexec systemctl daemon-reload systemctl enable bt-gpio.service Reboot and check if the bluetooth starts correctly. Post the boot log if it does not.

Description Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. This PR adds the RT kernel config file for TI devices. If RT_KERNEL=yes is passed as an argument to ./compile.sh, a PREEMPT_RT image is built. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. Tested this on SK-AM62B. Test 1: boot test: the board successfully booted Test 2: uname -a test: PREEMPT_RT string was present in the output, thus suggesting that its indeed an RT image Test 3: zcat /proc/config.gz | grep -i RT: Further confirmed that the PREEMPT_RT config is enabled in the running image Checklist: Please delete options that are not relevant. [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] My changes generate no new warnings cc: @glneo @Grippy98 @nmenon @sadik-smd View the full article

direct boot from nvme isn't possible. Boot loader (u-boot to say) must be present on SPI, eMMC or microSD.

try: sudo gpg --keyserver keyserver.ubuntu.com --recv-keys 93D6889F9F0E78D5 sudo gpg --export 93D6889F9F0E78D5 | sudo tee /etc/apt/trusted.gpg.d/armbian-configng.gpg > /dev/null

sudo armbian-config

Put a multi meter on the PSU you are using to power the pi a flakey PSU can cause strange intermittent issues same for router.

Related issue: https://github.com/armbian/build/issues/8261 Currently resolved for the beta repository. Now it's possible to switch to beta, update base-files and switch back to `apt.armbian.com`. Fixing for stable marked as "todo".

Ok that is a promising start at least. Are the 'BUG: bad page state messages' every boot or occasionally? The route cause will probably be difficult to find, possibly a deep route kernel or hardware issue. I tend to find that sometimes I will get the bad page state messages and then on another occassion get no kind of faults. You shouldnt need to enter any credientials on first boot, that only applies to setup over network connection. Once you have been able to login and if wireless works then you can install memtester to see if that picks up an errors. not a problem, looking forward to hearing your progress Ryzer

Are you trying to boot from spi with system on nvme? or trying to boot another system on a sd card?

Hi pcduino2user, Nice to see a fellow Pcduino user, I guess not many people interested in over a decade old hardware at this point. I try my best, I am by no means an expert, most of my current changes are just corrections to the device tree. Anyway, there appear to breaking changes in kernel 6.12 which breaks hdmi output. The intial patches for adding the hdmi display nodes are in my pcduino2-and-3-improvements branch however they are for much older kernel versions so need to be re-created, something I plan to do within the coming week. Additional the display driver needs a minor tweak. I currently have a userpatch derived from: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241130-hdmi-mode-valid-v5-10-742644ec3b1f@linaro.org/ Thanks Ryzer

Hi, Did you also make sure that you copy any ata options from your old installation? e.g. For my own Helios64 I have had similar issues and those were resolved by limiting the SATA link speed to 3Gbps: extraargs=libata.force=1:3.0G,2:3.0G,3:3.0G,4:3.0G The internets say that those ATA errors are caused by the the disk not responding to a controller request in time. Mostly it is advised to replace the [S]ATA cables and to make sure contacts are clean and no crosstalk/EMI can occur. A reduction in the ATA link speed also helps, which in my case sure did. Do keep in mind, that if you have regular spinning drives, the most throughput you will get out of your drives will be around 100~140 MB/s, which translates to roughly 1.5 Gb/s. So decreasing the linkspeed will not cause any slowdown, your drive's throughput will remain the performance bottleneck. For my Helios64, I have had some issues with the left-most (or top) disk, as the connectors did not protrude well enough, or had a little too much flex which caused the left-most disk from sometimes not being detected at all. Reseating and pressing on the connector from the rear helped that issue. As the internets mention these errors are the ATA driver complaining about not hearing from the drive(s) in time (or at all), you might want to experiment with a lower CPU frequency, or perhaps not using any of the dynamic freq scaling governors, but sticking to the powersave or performance one. Groetjes,

Hi @zital debian, Some things you could also try: Replace cables - again. I've had similar issues where the NIC of SBC would drop to 10Mbe half duplex, persistently after using different cables. In the end it was all the cables i had lying around that were not of good quality. Replaced the cat "5e" ones with cat 6 and the issues went away. Disable autoneg on your NIC or only advertise 1Gbe. Try a different switch port, switch or router. Check if you have some of those green options on your router/switch enabled, i think it's called EEE. I had some issues with and my Orangepi zero SBCs in combination with those bad cat "5e" ethernet cables. Groetjes,

Servus! I'm running an "old" Helios64, still with debian buster and kernel 5.9.14-rockchip64 ... pretty much the same installation, as I had setup the Helios64 years ago. So far it is running great, with no real issues. I have ZFS running on it, with 3 disks. Today I decided to upgrade to something new - and installed Armbian 25.5.1 / Nobel - with kernel "6.12.32-current-rockchip64". Helios64 boots up and everything seems to work fine. I was able to import my ZFS pool and it was accessible - however, when I do heavy i/o, e.g. md5sum on a big file, I get a lot of these errors: Jun 08 20:06:36 helios64 kernel: ata2.00: failed command: READ FPDMA QUEUED Jun 08 20:06:36 helios64 kernel: ata2.00: cmd 60/80:90:40:3a:2f/00:00:06:00:00/40 tag 18 ncq dma 65536 in res 41/84:00:00:00:00/00:00:00:00:00/00 Emask 0x12 (ATA bus error) Jun 08 20:06:36 helios64 kernel: ata2.00: status: { DRDY ERR } Jun 08 20:06:36 helios64 kernel: ata2.00: error: { ICRC ABRT } Jun 08 20:06:36 helios64 kernel: ata2: hard resetting link Jun 08 20:06:36 helios64 kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Jun 08 20:06:36 helios64 kernel: ata2.00: configured for UDMA/133 Jun 08 20:06:36 helios64 kernel: ata2: EH complete Jun 08 20:07:04 helios64 kernel: ata2: limiting SATA link speed to 1.5 Gbps Jun 08 20:07:04 helios64 kernel: ata2.00: exception Emask 0x2 SAct 0x202003 SErr 0x400 action 0x6 Jun 08 20:07:04 helios64 kernel: ata2.00: irq_stat 0x08000000 Jun 08 20:07:04 helios64 kernel: ata2: SError: { Proto } Jun 08 20:07:04 helios64 kernel: ata2.00: failed command: READ FPDMA QUEUED Jun 08 20:07:04 helios64 kernel: ata2.00: cmd 60/00:00:98:55:7f/08:00:07:00:00/40 tag 0 ncq dma 1048576 in res 41/84:00:00:00:00/00:00:00:00:00/00 Emask 0x12 (ATA bus error) Jun 08 20:07:04 helios64 kernel: ata2.00: status: { DRDY ERR } Jun 08 20:07:04 helios64 kernel: ata2.00: error: { ICRC ABRT } This is for ata2, but this happens also for ata3 and ata4 - so all three disk of my ZFS. Interesting so, ZFS itself does not detect any read / write errors - but if you e.g. copy files, you see a noticeable drop in throughput, disk access hangs for a moment. I have installed 25.5.1 on SD card, so I was able to switch back to my original system ... and voilá, no such errors anymore. So it seems to be related to 25.5.1. Does anyone know this problem? Is there a solution or anything I'm missing? Thanks Alex

I have orange pi 3b, that has one NVME ssd. This boots hybrid from SD card and system is on NVME. I tried to make boot it without SSD but no luck as of now. my nvme is fast and supports 5GBS speed. /dev/nvme0n1 /dev/ng0n1 AA250310076 FIKWOT FN955 2TB 0x1 2.00 TB / 2.00 TB 512 B + 0 B X0430P00 Its avg benchmark speed is 415mbps which is very slower than avg. sudo lspci -vv | grep -i "LnkSta" LnkSta: Speed 5GT/s, Width x1 LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded) LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- Not sure, if this is due to power management, or due to hybrid approach while booting or some problem with board itself. can some one help me ?

now is at 1000 again, I have bought a switch to check if is about router... When it will arrive I will post again with results, thank you all zital@s-400 /tmp> rsync -avzhP --delete /tmp/a/ pi@opi5:/tmp/a/ sending incremental file list deleting D01.mp4 ./ D04-01.mp4 1,24G 100% 111,51MB/s 0:00:10 (xfr#1, to-chk=0/2) sent 1,23G bytes received 49 bytes 98,55M bytes/sec total size is 1,24G speedup is 1,00

@usual user But the filesystem was never currupt and the issue was only with the boot partition which is not a journaling filesystem. The Odruids is also known to work reliably without UPS.

Mmmmm no, comes back to 100, wtf [ 12.809646] systemd-journald[666]: Received client request to relinquish /var/log/journal/7e1079e7649a45d2ab1ccbdeff6468de access. [ 16.329124] rk_gmac-dwmac fe1c0000.ethernet end1: Link is Up - 1Gbps/Full - flow control rx/tx [ 16.329146] IPv6: ADDRCONF(NETDEV_CHANGE): end1: link becomes ready [ 16.674304] platform mtd_vendor_storage: deferred probe pending [ 18.300250] loop6: detected capacity change from 0 to 8 [ 18.667832] ttyFIQ ttyFIQ0: tty_port_close_start: tty->count = 1 port count = 2 [ 830.033971] rk_gmac-dwmac fe1c0000.ethernet end1: Link is Down [ 849.288915] rk_gmac-dwmac fe1c0000.ethernet end1: Link is Up - 100Mbps/Full - flow control rx/tx

OK, I had the fan disconnected, I have connected the fan into gpio pins and reboot system, now is 1000Mb/s, and maybe is an GND issue as eselarm commented, thank you guys

Description Update odroidxu4-current kernel to 6.6.93. How Has This Been Tested? [x] Reboot of my Odroid HC1 Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article