Search the Community

I know Lamobo-r1 has many problems and that the support ended, but it works fine for me. Everything works fine with kernel 4.14.84-sunxi, however, when I update the kernel, the b53 switch does not work anymore. I need to update the kernel to add another wifi usb dongle that seems to work only with newer kernels (https://github.com/aircrack-ng/rtl8812au/issues/272#issuecomment-467983704). Anybody experiencing the same problem? Any ideas for a workaround?

What gives with the Armbian website links? Links to all previous versions Armbian for the OrangePi R1 Plus LTS have been removed. The links to SHA hash and PGP signature do nothing. I was hoping to use an image that was based on Debian Bullseye, but that link has been recently removed. It is possible to create my image, but I would spend my time working on my code, not wading through the options to create an image.

Having used YOCTO for a couple of years at work I assumed that creating my own Armbian image was going to be difficult. However to my suprise I was able to create a Bullseye image for the Orange Pi R1+ LTS in less than 1 hour. And, .... it actually runs correctly on the target board. That is pretty good.

http://paste.armbian.com/icedujiguw.yaml Hello everyone, trying to give new life to this old Orange Pi+ 2. Here is described what hapens when i try to boot up latest image. Can anyone help. Thanks in advance. Armbian 23.8 Bookworm Kernel 6.2.y, Size: 421Mb, Release date: Jun 3, 2023 SBC gets stuck after the request Sense .. and doesnt booy up, if i plug a device in usb ports, it bootloops .. see below using same sd-card and a diffrent image file works with no issues . hardware : grounded out pin 9 of the SD card slot (checked with multimeter and works) U-Boot SPL 2022.07-armbian (Jun 03 2023 - 19:37:25 +0000) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2022.07-armbian (Jun 03 2023 - 19:37:25 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus / Plus 2 DRAM: 2 GiB Core: 65 devices, 18 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@1c28000 Out: serial@1c28000 Err: serial@1c28000 Net: phy interface9 eth0: ethernet@1c30000 starting USB... Bus usb@1c1b000: USB EHCI 1.00 Bus usb@1c1d000: USB EHCI 1.00 scanning bus usb@1c1b000 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 2 USB Device(s) found scanning bus usb@1c1d000 for devices... Device NOT ready Request Sense returned 02 3A 00 SBC gets stuck after the request Sense .. and doesnt booy up, if i plug a device in usb ports, it bootloops .. see below U-Boot SPL 2022.07-armbian (Jun 03 2023 - 19:37:25 +0000) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2022.07-armbian (Jun 03 2023 - 19:37:25 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus / Plus 2 DRAM: 2 GiB Core: 65 devices, 18 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@1c28000 Out: serial@1c28000 Err: serial@1c28000 Net: phy interface9 eth0: ethernet@1c30000 starting USB... Bus usb@1c1b000: USB EHCI 1.00 Bus usb@1c1d000: USB EHCI 1.00 scanning bus usb@1c1b000 for devices... Device NOT ready Request Sense returned 02 3A 00 undefined instruction pc : [<bbf93980>] lr : [<bffa3391>] reloc pc : [<4600b980>] lr : [<4a01b391>] sp : bbf5e848 ip : 0000001c fp : bffde94a r10: bffe5c00 r9 : bbf67ec0 r8 : 00000000 r7 : 00000000 r6 : bbf93b18 r5 : a0000000 r4 : bbf93b80 r3 : bbf93980 r2 : 00000000 r1 : 00000000 r0 : bbf93b80 Flags: NzCv IRQs off FIQs off Mode SVC_32 Code: bbf68cc8 00000000 00000000 00000000 (ffffffff) Resetting CPU ... resetting ... U-Boot SPL 2022.07-armbian (Jun 03 2023 - 19:37:25 +0000) DRAM: 2048 MiB Trying to boot from MMC1

Hello, I am in a project where I need to use armbian on an OrangePi R1 Plus, but I realized that it is not yet available on the site. Any prevision?

Description Mainline kernel 6.3 and above implements yt8531 driver. This pull request removes the legacy driver patch and fix the device tree for Orange Pi 4 LTS and other devices to use that driver. Note: this PR has a "dependency" upon this other PR (https://github.com/armbian/build/pull/5290) - these two PRs are unrelated, but the PR-5290 bug does not allow me to easily test without having conflicts later. This is just a note, everything should go on flawlessy once PR-5290 is merged. Jira reference number AR-1774 How Has This Been Tested? [x] Tested dtb on a live Orange Pi 4 LTS system [ ] Tested on Orange Pi R1 LTS (@schwar3kat) 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] 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

I have one of these boards: http://www.orangepi.org/Orange%20Pi%20R1%20Plus/ https://photos.app.goo.gl/1otMwG4totvNbGo88 It's kept cool with a heatsink, and fan (30-35c). Currently, I'm running the orange pi supplied version of openwrt. It's a snapshot version, so the kernel isn't compatible with some packages. My question then is, is there a script out there that can transform armbian into a router, with a firewall, web interface, and easy to use? I'd like to give it a try if such a thing exists. Sent from my Redmi Note 9S using Tapatalk

Hi, We've built a network experimentation system using NanoPi R1 modules, but when load testing the system with iperf3, we are seeing the on-board RTL8152 interface enter a state where it does not seem to be responding until the board is power cycled. The system consists of 32 NanoPi modules connected in a torus, with the 1Gig interface connected to its neighbour's 100Mbit interface. An additional USB Ethernet dongle functions as a control interface. The modules are powered from a Ubiquiti PoE switch, using this type of isolated PoE splitter. Eyeballing the switch UI, power consumption per node seems to hover between 2.3W-3.5W, depending on load. We're using the latest Ubuntu-based image, with kernel 5.4.28. Under light loads, the system works fine, but when performing load tests, we're seeing the RTL8152 entering some kind of lock-up state. As can be seen from the system logs, first the netdev watchdog triggers, then the kernel tries to reset the USB device, finally reporting that it is unable to enumerate the device. After encountering this problem, if the node is rebooted, the USB device can still not be enumerated, and will remain unresponsive until it is powercycled. The external USB Ethernet dongle stays working through all of this, so it seems that the USB host controller and subsystem works OK. We haven't seen any issues with the 1Gig interface. Searching the net, I have found reports with similar backtraces, but they seem to be either several years old, or related to the RTL8153 chip, which shares the same driver. In either case, none of them seem to offer any answers as to what's going on, or if there is any fix. Has anyone else seen this? Any ideas if it's a driver or hardware issue? Relevant bit from the kernel log: Full diagnostic dump:

I'm trying to load Armbian on my NanoPi R1, but it doesn't boot. I've been able to boot it successfully with https://www.friendlyarm.com/ official image, and also various (unsupported) DietPi images. I tried Armbian_21.02.3_Nanopi-r1_focal_current_5.10.21.img.xz using Balena Etcher to copy it to the SDCard on a Macbook laptop. Instead of seeing the uboot startup, the terminal remains completely empty. No idea where to start on debugging this. Please help! Thanks!

Orangepi zero plus Images boot, network connection functions (iperf3). USB ports function. Orangepi R1 Images boot, both ethernet ports and wifi function as expected (iperf3).

Orangepi R1 Plus LTS (RK3328) - networking issue AR-1747. Caused by one of the network interface logical names changing from eth0 to end0. I can can submit a PR to fix this with a rename in /etc/udev/rules.d/70-rename-lan.rules which is already created from a hook in the board config file (to rename the other network interface). Already tested and works as expected on current and edge, Ubuntu and Debian. Before I take this route, I'm just wondering if anyone knows a reason for this happening that could possibly lead to a better fix? I didn't find anything obvious in the PR's.

I use NANOPI R1 in one of my projects. Now I need to develop a board to make a physical watchdog from NANOPI R1 itself and an RTC (the NANOPI R1 RTC does not work). I have two possibilities: One is to use the already integrated UART, or use a USB - I2C converter. Using the UART I would communicate the NANOPI with a 328P microcontroller, and from there I would collect the RTC information (with i2c between 328P and RTC), in addition to sending the frequent information to the 328P to keep the watchdog active. Using the I2C, the RTC would be connected to the I2C BUS and I would do the direct query via NANOPI R1, as well as send the frequent information via I2C to the 328P or ATTINY85 (I can use this CI - it have I2C) to keep the watchdog active. I want an opinion: I would like to know how you would do that? Would it be using I2C or using UART? If they were going to use UART, I need the two ports available on NANOPI R1 (because I already use a Nextion HMI on a UART port). So can i use UART_DBG too? What problems can I face?

I'm a newbie to Armbian, just a hobby user, no company behind me. While building Armbian for my Banana Pi R1 (aka Lamobo R1) [Allwinner A20, sunxi] the build system gave the following warnings originating from the U-Boot project. I think some maintainers and/or experienced users should take a look at the following. ===================== WARNING ====================== This board does not use CONFIG_DM_MMC. Please update the board to use CONFIG_DM_MMC before the v2019.04 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_SCSI. Please update the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_VIDEO Please update the board to use CONFIG_DM_VIDEO before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== Here's also the full content of the file ./cache/sources/u-boot/v2019.01/doc/driver-model/MIGRATION.txt :

rockchip64/edge/6.3: rebase/rewrite patches against v6.3.1; do archeology for mbox-less patches; materialize overwrites After the work done by @amazingfate on #5140 it is now viable to rebase all rockchip64 edge patches. This "admits" all the overwrites (full replacement) as actual patches -- it does not change the contents. materialized overwrites: add-board-helios64.patch add-board-orangepi-r1-plus.patch add-driver-for-Motorcomm-YT85xx+PHYs.patch add-board-rk3328-roc-pc.patch Special attention: wifi-4003-uwe5622-adjust-for-rockchip.patch @paolosabatino this patch is done on top of the wifi drivers patches exclusively, and fails to apply on a pure mainline tree. we should probably consider moving this into the wifi drivers patch harness, not in the rockchip tree. tl;dr: this changes this: https://rpardini.github.io/linux/armbian-next-rockchip64-6.3-20230505.html kernel patching: 119 total patches; 119 applied; 95 with problems; 4 overwrites; 54 not_mbox; 73 needs_rebase into this: https://rpardini.github.io/linux/armbian-next-rockchip64-6.3-20230506.html kernel patching: 119 total patches; 119 applied; 0 with problems View the full article

Hi forum, I want use my R1 board as a switch and if possible to run some services as the same if possible. Now when I look in /etc/network I do see a lot of different .conf files in that folder, but I do not really know how to use or them. Therefore my questions. 1. can I use my board as switch and can I run as the same services. 2. How do I use these config files and how do I interpret the results. Thx,blub4747

I'm a newbie. Got the NanoPi R1 that sports a UART but no Video Output. Now when I want to read the output of the serial console I need a 3-wire cable and a converter, that much I know. But what is the baud rate? Where is this configured on the armbian NanoPiR1 image (on my raspberry Pi I just checked and found the file /boot/cmdline.txt with that settings, in my case it's 115200) Why is the baud rate nowhere documented? On the download page https://www.armbian.com/nanopi-r1/ it is stated that "serial console is enabled on UART1, which is exposed on chasis" , but no hint about which speed to use. There neither is any info about the baud rate on the friendlyelec site where they provide various OS images for download. Plenty of documentation on how to wire the serial cable though. Is there a kind of industry standard that everyone knows and therefore it is not necessary to include it in the how-to guides. Or are we supposed to try every rate from 9600 upward until we get readable output? Thanks. So far I couldn't get my NanoPi to work, it just blinks red, and I haven't seen anything on the console too. It's a brick, possible defective hardware.

Hi. I'm using "Orangepi-r1_focal_current_5.8.5" Armbian. I'm connected to it via Wifi. Everything working fine, but after few hours, I notice that it is no longer showing on my network. If I connect by cable I can ssh to it via ethernet without any issue and it stays available for several days without disconnecting. Any idea why this happens? when Wifi disconnects I will have to reboot to show it again. And I am not running any program on it. Is orange pi r1 wifi like orange pi zero wifi suffering from poor software support?

Hello! My problem is with paying for OrangePi Plus 2 (not E), but I haven't found a suitable section. Dear administrators, please fix the split if I made a big mistake. I was installed image orangepiplus/Bullseye_current (Nov 30, 2022) in eMMC. All works is normal. In armbian-config I was run Firmware (Update all packages and firmware). Afeter this the board are not loading from eMMC or external CD with current image Armbian. The Ubuntu from site orangepi.org the loading is normal. In debug-uart I see a cyclical reboot with: <0xdd>!␊ ␊ <0xea><0xfc>q<0xb9><0xf6>Core: 65 devices, 18 uclasses, devicetree: separate␍␊ WDT: Not starting watchdog@1c20ca0␍␊ MMC: mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1␍␊ Loading Environment from FAT... Unable to use mmc 1:1...␍␊ In: serial@1c28000␍␊ Out: serial@1c28000␍␊ Err: serial@1c28000␍␊ Net: phy interface9␍␊ eth0: ethernet@1c30000␍␊ starting USB...␍␊ Bus usb@1c1b000: USB EHCI 1.00␍␊ Bus usb@1c1d000: USB EHCI 1.00␍␊ scanning bus usb@1c1b000 for devices... 2 USB Device(s) found␍␊ scanning bus usb@1c1d000 for devices... Device NOT ready␍␊ Request Sense returned 02 3A 00␍␊ prefetch abort␍␊ pc : [<fffffffa>]⇥ lr : [<bffaa4b3>]␍␊ reloc pc : [<8a077ffa>]⇥ lr : [<4a0224b3>]␍␊ sp : b8a99728 ip : bbf6c038⇥ fp : bffdec47␍␊ r10: ffffffff r9 : bbf67ec0⇥ r8 : b8a99780␍␊ r7 : 00000000 r6 : 00000001⇥ r5 : e59ff014 r4 : 00000000␍␊ r3 : b8a99780 r2 : 00000001⇥ r1 : 00000000 r0 : e59ff014␍␊ Flags: nzcv IRQs off FIQs off Mode SVC_32 (T)␍␊ Code: 0000 0000 0000 0000 (0000) 0000 ␍␊ Resetting CPU ...␍␊ ␍␊ resetting ...␍␊ The problem is that the board no longer wants to load with EXT4, and now it loads only with FAT32. Please tell me how to teach the board to boot from EXT4 again.

Hi, I have a few questions about the NanoPi R1 system. 1) The (USB > TTL) debug serial port is that 3.3v or 5v? I need to get the correct adapter. 2) Hooking up a serial debug cable is there enough room to close the front plate? 3) Can the system run from eMMc and get software upgraded from the SD-Card? 4) I could not not find clear procedures for this. Am not familiar with OpenWRT. 5) Can the Ethernet port be used to talk to a P.C. running Windows (putty) or would the micro-USB to P.C. be better? 6) I would eventually use WiFi for remote access and updates. 7) Can the NanoPi R1 run Apache WEB server? 8) Can this run Debian or Ubuntu? If so where would the downloads be found? Looks like a fine product. If it works out I may buy several. I do have experience with Linux (several flavors) and the Beaglebone. My history goes back to 1974 and Unix from Bell Labs.

esd electronics CAN-PCIeMiniHS/402 is a half-size mini PCIe card with four CAN FD Interfaces designed for embedded systems with one model adding extended temperature range support from -40C to 85°C. The company also introduced the CAN-Mini/402-4-DSUB9-150mm adapter to more easily connect the four CAN network interfaces via DSUB9 connectors. It comes with four individual small adapter boards, each equipped with a DSUB9 plug and a jumper for selectable onboard CAN termination, as well as 150 mm long wires. CAN-PCIeMiniHS/402 highlights: 4x CAN FD interfaces according to ISO 11898-2, no galvanic isolation, bit rates from 10 Kbit/s up to 8 Mbit/s Bus mastering and local data management by FPGA (Intel Cyclone IV EP4CGX) PCIe Mini interface according to Mini Card Electromechanical Spec. R1.2 Supports MSI (Message Signaled Interrupts) HW-Timestamp capable Dimensions – 30 mm x 27 mm (Half-size mini PCIe form factor) Temperature Range Standard – 0°C … +75°C Extended range: [...] The post Half-size mini PCIe card adds up to 4 CAN FD interfaces to embedded systems appeared first on CNX Software - Embedded Systems News. View the full article

Description A user from the forum reports that a new rockchip rk3288-based board Tinkerboard S R2.0 has no wifi (see discussion here). After some talk, it seems that this board revision uses a Realtek rtl8723ds chip, whereas the R1.01 board uses rtl8723bs. This PR enabled the rtl8723ds wifi module that curiously was previously enabled in kernel 5.15 but somehow has been disabled in the advancement to 6.1. Current and edge kernel on rockchip family are both on 6.1 right now. The board actually is in a limbo where probably much of the design is shared with regular Tinkerboard/S, but other differences are unknown. Enabling a kernel module to let wifi work is a relatively straight and simple task that makes an user happy. Jira reference number AR-1619 How Has This Been Tested? [x] kernel deb packages have been complied with success 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] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

I have the same problem with my orange pi R1 plus LTS on armbian. Floating problem. In some cases pc rebooting normally, but in 3/4 of cases it stucks. Bullseye/jammy 22.04 UPDATE: Something info about this problem in my case. I had this problem, when ive been used concrete TF cards - Smartbuy 10 class 32 gib. When i changed TF to Mirex 10 class 8 gib - problem solved. So, in user manual was info about that - all tests passed with TF SanDisk. But who reads man before working. Therefore, this card working clearly with other platforms (OPI ZERO, OPI ZERO 2 e.x.).

Hi, Wifi stops working after some time. Output from armbianmonitor -u : https://paste.armbian.com/iqukawifes Only reboot help. In dmesg I see: [ 6793.969484] WCN: stop_loopcheck [ 6806.513278] sprdwl:[WIFI_CMD_TX_DATA]timeout [ 6806.514120] sprdwl:ctx_id:0 cmd: WIFI_CMD_TX_DATA[72] rsp timeout (mstime = 6802912), num=3304 [ 6809.589395] sprdwl:[WIFI_CMD_TX_DATA]timeout [ 6809.589823] sprdwl:ctx_id:0 cmd: WIFI_CMD_TX_DATA[72] rsp timeout (mstime = 6805981), num=3305 [ 6812.661554] sprdwl:[WIFI_CMD_TX_DATA]timeout [ 6812.661979] sprdwl:ctx_id:0 cmd: WIFI_CMD_TX_DATA[72] rsp timeout (mstime = 6809057), num=3306 [ 6812.662786] sprdwl:sprdwl_atcmd_assert ctx_id:0, cmd_id:72, reason:3, cp_asserted:0 [ 6812.663492] WCN: mdbg_assert_interface:[CMD] WIFI_CMD_TX_DATA, [REASON] CMD_RSP_TIMEOUT_ERROR [ 6812.663505] sdiohal:carddump flag set[1] [ 6812.663931] sdiohal:disable rx int for dump [ 6812.663956] sdiohal:chn8 tx push old, cmdid=72, mstime=6805981, record_time=6805982 [ 6812.663984] chn8 tx push old: 00 00 00 00 10 48 46 00 dd d9 67 00 00 00 00 00 .....HF...g..... [ 6812.663995] sdiohal:chn8 tx denq old, cmdid=72, mstime=6805981, record_time=6805982 [ 6812.664012] chn8 tx denq old: 00 23 00 08 10 48 46 00 dd d9 67 00 00 00 00 00 .#...HF...g..... [ 6812.664022] sdiohal:chn22 rx dispatch old, cmdid=5, mstime=6788866, record_time=6788867 [ 6812.664038] chn22 rx dispatch old: 3f 06 00 0a 00 05 0c 00 02 97 67 00 00 24 00 00 ?.........g..$.. [ 6812.664048] sdiohal:chn8 tx push new, cmdid=72, mstime=6809057, record_time=6809057 [ 6812.664064] chn8 tx push new: 00 00 00 00 10 48 46 00 e1 e5 67 00 00 00 00 00 .....HF...g..... [ 6812.664074] sdiohal:chn8 tx denq new, cmdid=72, mstime=6809057, record_time=6809057 [ 6812.664090] chn8 tx denq new: 00 23 00 08 10 48 46 00 e1 e5 67 00 00 00 00 00 .#...HF...g..... [ 6812.664100] sdiohal:chn22 rx dispatch new, cmdid=5, mstime=6788901, record_time=6788906 [ 6812.664116] chn22 rx dispatch new: bf 06 00 0a 00 05 0d 00 25 97 67 00 00 26 00 00 ........%.g..&.. [ 6812.664384] WCN: dap_sel_btwf_lite DJTAG_DAP_SEL:0x0 [ 6812.664592] WCN: dap_sel_btwf_lite DJTAG_DAP_SEL:0x2 [ 6812.664793] WCN: dap_sel_btwf_lite 2:DJTAG_DAP_SEL:0x2 [ 6812.664991] WCN: apb_eb_lite APB_EB:0x463 [ 6812.665193] WCN: apb_eb_lite APB_EB:0x463 [ 6812.665393] WCN: apb_eb_lite 2:APB_EB:0x463 [ 6812.665689] WCN: check_dap_is_ok :0x24770011 [ 6812.665704] WCN: btwf dap is ready [ 6812.667995] WCN: read_core_reg ****R[0]: 0x0**** [ 6812.669144] WCN: read_core_reg ****R[1]: 0x0**** [ 6812.670487] WCN: read_core_reg ****R[2]: 0x8001000c**** [ 6812.671644] WCN: read_core_reg ****R[3]: 0x0**** [ 6812.672794] WCN: read_core_reg ****R[4]: 0x4083c000**** [ 6812.674078] WCN: read_core_reg ****R[5]: 0x1e694c**** [ 6812.675222] WCN: read_core_reg ****R[6]: 0x3**** [ 6812.676359] WCN: read_core_reg ****R[7]: 0x0**** [ 6812.677545] WCN: read_core_reg ****R[8]: 0x40130000**** [ 6812.678703] WCN: read_core_reg ****R[9]: 0x10d69c**** [ 6812.679842] WCN: read_core_reg ****R[10]: 0x40088000**** [ 6812.680985] WCN: read_core_reg ****R[11]: 0x1e6954**** [ 6812.682309] WCN: read_core_reg ****R[12]: 0x11fc64**** [ 6812.683457] WCN: read_core_reg ****R[13]: 0x1a0ef8**** [ 6812.684605] WCN: read_core_reg ****R[14]: 0x1e605b**** [ 6812.685831] WCN: read_core_reg ****R[15]: 0x1e67ee**** [ 6812.686971] WCN: read_core_reg ****R[16]: 0x6100000b**** [ 6812.688108] WCN: read_core_reg ****R[17]: 0x1a0ef8**** [ 6812.689248] WCN: read_core_reg ****R[18]: 0x117bd8**** [ 6812.689262] WCN: ------------[ ARM REG ]------------ [ 6812.689269] WCN: [R0 ] = 0x00000000 [ 6812.689278] WCN: [R1 ] = 0x00000000 [ 6812.689287] WCN: [R2 ] = 0x8001000c [ 6812.689295] WCN: [R3 ] = 0x00000000 [ 6812.689303] WCN: [R4 ] = 0x4083c000 [ 6812.689312] WCN: [R5 ] = 0x001e694c [ 6812.689320] WCN: [R6 ] = 0x00000003 [ 6812.689329] WCN: [R7 ] = 0x00000000 [ 6812.689337] WCN: [R8 ] = 0x40130000 [ 6812.689345] WCN: [R9 ] = 0x0010d69c [ 6812.689353] WCN: [R10] = 0x40088000 [ 6812.689362] WCN: [R11] = 0x001e6954 [ 6812.689371] WCN: [R12] = 0x0011fc64 [ 6812.689379] WCN: [R13] = 0x001a0ef8 [ 6812.689387] WCN: [R14] = 0x001e605b [ 6812.689395] WCN: [R15] = 0x001e67ee [ 6812.689403] WCN: [PSR] = 0x6100000b [ 6812.689412] WCN: [MSP] = 0x001a0ef8 [ 6812.689420] WCN: [PSP] = 0x00117bd8 [ 6812.689428] WCN: ------------[ ARM END ]------------ [ 6812.689874] WCN: marlin_hold_cpu reset reg val:0x0 [ 6812.690269] WCN: CP DCACHE ENABLE [ 6812.718084] WCN: section[0] [0x100000 0x1e73ff 0x240] [ 6812.718121] WCN: section[1] [0x40880000 0x40880053 0xe7640] [ 6812.718133] WCN: section[2] [0x4083c000 0x4083c353 0xe7694] [ 6812.718146] WCN: section[3] [0x40130000 0x401303ff 0xe79e8] [ 6812.718157] WCN: section[4] [0x40088000 0x4008828b 0xe7de8] [ 6812.718169] WCN: section[5] [0x40844200 0x40844343 0xe8074] [ 6812.718180] WCN: section[6] [0x40844000 0x40844047 0xe81b8] [ 6812.718192] WCN: section[7] [0x40140000 0x4014ffff 0xe8200] [ 6812.718203] WCN: section[8] [0x400f0000 0x400f011f 0xf8200] [ 6812.718214] WCN: section[9] [0x400f1000 0x400fe0ff 0xf8320] [ 6812.718226] WCN: section[10] [0x40300000 0x4034a7ff 0x105420] [ 6812.718238] WCN: section[11] [0x400a0000 0x400a0057 0x14fc20] [ 6812.718250] WCN: section[12] [0x400b0000 0x400b0387 0x14fc78] [ 6812.718261] WCN: section[13] [0x400b1000 0x400b1153 0x150000] [ 6812.718273] WCN: section[14] [0x400b2000 0x400b2a8b 0x150154] [ 6812.718284] WCN: section[15] [0x400b3000 0x400b30af 0x150be0] [ 6812.718295] WCN: section[16] [0x400b4000 0x400b4a6f 0x150c90] [ 6812.718307] WCN: section[17] [0x400b7000 0x400b7617 0x151700] [ 6812.718318] WCN: section[18] [0x40240000 0x402408f3 0x151d18] [ 6812.718329] WCN: section[19] [0x40246000 0x40246737 0x15260c] [ 6812.718341] WCN: section[20] [0x40248000 0x4024809f 0x152d44] [ 6812.718352] WCN: section[21] [0x4024a000 0x4024a21b 0x152de4] [ 6812.718364] WCN: section[22] [0x4024f000 0x4024f30f 0x153000] [ 6812.718375] WCN: section[23] [0x40200000 0x402001ff 0x153310] [ 6812.718386] WCN: section[24] [0x40204000 0x402041ff 0x153510] [ 6812.718398] WCN: section[25] [0x40208000 0x402092a3 0x153710] [ 6812.718409] WCN: section[26] [0x40200c00 0x4020c343 0x1549b4] [ 6812.718420] WCN: section[27] [0x40210000 0x40212fff 0x1600f8] [ 6812.718432] WCN: section[28] [0x40214000 0x40216fff 0x1630f8] [ 6812.718443] WCN: section[29] [0x40218000 0x402182cf 0x1660f8] [ 6812.718454] WCN: section[30] [0x4021c000 0x4021c5bf 0x1663c8] [ 6812.718466] WCN: section[31] [0x40241000 0x402413ff 0x166988] [ 6812.718478] WCN: section[32] [0x40242000 0x402423ff 0x166d88] [ 6812.718489] WCN: dumpmem_rx_callback [ 6812.722261] WCN: dumpmem_rx_callback [ 6812.722298] WCN_ERR: dumpmem_rx_callback open error no.-21 retry:1 [ 6812.726612] WCN: dumpmem_rx_callback [ 6812.730406] WCN: dumpmem_rx_callback [ 6812.734087] WCN: dumpmem_rx_callback [ 6812.737727] WCN: dumpmem_rx_callback [ 6812.741301] WCN: dumpmem_rx_callback [ 6812.745201] WCN: dumpmem_rx_callback [ 6812.749095] WCN: dumpmem_rx_callback [ 6812.752831] WCN: dumpmem_rx_callback [ 6812.756544] WCN: dumpmem_rx_callback [ 6812.760444] WCN: dumpmem_rx_callback [ 6812.764345] WCN: dumpmem_rx_callback [ 6812.767988] WCN: dumpmem_rx_callback [ 6812.771603] WCN: dumpmem_rx_callback [ 6812.775420] WCN: dumpmem_rx_callback [ 6812.779174] WCN: dumpmem_rx_callback [ 6812.782903] WCN: dumpmem_rx_callback [ 6812.786607] WCN: dumpmem_rx_callback [ 6812.790268] WCN: dumpmem_rx_callback [ 6812.793926] WCN: dumpmem_rx_callback [ 6812.797536] WCN: dumpmem_rx_callback [ 6812.801115] WCN: dumpmem_rx_callback [ 6812.805021] WCN: dumpmem_rx_callback [ 6812.808953] WCN: dumpmem_rx_callback [ 6812.834246] WCN: dumpmem_rx_callback [ 6812.838115] WCN: dumpmem_rx_callback [ 6812.919411] WCN: dumpmem_rx_callback [ 6812.923281] WCN: dumpmem_rx_callback [ 6812.951213] WCN: dumpmem_rx_callback [ 6812.951259] WCN: mdbg dump ram 947200 ok! [ 6812.951523] WCN: dumpmem_rx_callback [ 6812.951538] WCN: mdbg dump aon ahb 84 ok! [ 6812.951878] WCN: dumpmem_rx_callback [ 6812.951892] WCN: mdbg dump aon_apb 852 ok! [ 6812.952176] WCN: dumpmem_rx_callback [ 6812.952191] WCN: mdbg dump btwfahb 1024 ok! [ 6812.952497] WCN: dumpmem_rx_callback [ 6812.952511] WCN: mdbg dump btwfapb 652 ok! [ 6812.952768] WCN: dumpmem_rx_callback [ 6812.952781] WCN: mdbg dump aonclk 324 ok! [ 6812.953006] WCN: dumpmem_rx_callback [ 6812.953020] WCN: mdbg dump predivclk 72 ok! [ 6812.962557] WCN: dumpmem_rx_callback [ 6812.968142] WCN: dumpmem_rx_callback [ 6812.968189] WCN: mdbg dump sdio 65536 ok! [ 6812.968421] WCN: enable_cp_pll rd CLK_CTRL0 reg val:0x2fdf [ 6812.968839] WCN: enable_cp_pll enable CLK_CTRL0 val:0x2fdf [ 6812.969464] WCN: check_wifi_power_domain_ison CHIP_SLP reg val:0xc430 [ 6812.969488] WCN: WIFI MAC have power down [ 6812.971279] WCN: check_wifi_power_domain_ison WIFI_ENABLE reg val:0xa023 [ 6812.971315] WCN: WIFI_en and wifi_mac_en is disable [ 6812.972007] WCN: dumpmem_rx_callback [ 6812.976547] WCN: dumpmem_rx_callback [ 6812.979493] WCN: dumpmem_rx_callback [ 6812.983143] WCN: dumpmem_rx_callback [ 6812.986775] WCN: dumpmem_rx_callback [ 6812.991332] WCN: dumpmem_rx_callback [ 6812.994996] WCN: dumpmem_rx_callback [ 6812.998628] WCN: dumpmem_rx_callback [ 6813.002260] WCN: dumpmem_rx_callback [ 6813.005868] WCN: dumpmem_rx_callback [ 6813.009414] WCN: dumpmem_rx_callback [ 6813.014692] WCN: dumpmem_rx_callback [ 6813.018279] WCN: dumpmem_rx_callback [ 6813.021871] WCN: dumpmem_rx_callback [ 6813.021895] WCN: mdbg dump wifi 360448 ok! [ 6813.022129] WCN: dumpmem_rx_callback [ 6813.022143] WCN: dump cp reg section[11] ok! [ 6813.022490] WCN: dumpmem_rx_callback [ 6813.022508] WCN: dump cp reg section[12] ok! [ 6813.022824] WCN: dumpmem_rx_callback [ 6813.022839] WCN: dump cp reg section[13] ok! [ 6813.023408] WCN: dumpmem_rx_callback [ 6813.023422] WCN: dump cp reg section[14] ok! [ 6813.023641] WCN: dumpmem_rx_callback [ 6813.023655] WCN: dump cp reg section[15] ok! [ 6813.024195] WCN: dumpmem_rx_callback [ 6813.024209] WCN: dump cp reg section[16] ok! [ 6813.024623] WCN: dumpmem_rx_callback [ 6813.024636] WCN: dump cp reg section[17] ok! [ 6813.025234] WCN: dumpmem_rx_callback [ 6813.025247] WCN: mdbg dump fm 2748 ok! [ 6813.025791] WCN: dumpmem_rx_callback [ 6813.025806] WCN: mdbg dump btacc 2292 ok! [ 6813.026218] WCN: dumpmem_rx_callback [ 6813.026232] WCN: mdbg dump btjal 1848 ok! [ 6813.026448] WCN: dumpmem_rx_callback [ 6813.026462] WCN: mdbg dump bthab 160 ok! [ 6813.026733] WCN: dumpmem_rx_callback [ 6813.026746] WCN: mdbg dump btlejal 540 ok! [ 6813.140006] sdiohal err:dt read fail ret:-110, system_addr=0x4024f000 [ 6813.140636] sdiohal:sdio dump_aon_reg entry [ 6813.140738] sdiohal:pmu sdio status:[0x140]:0x6b [ 6813.140807] sdiohal:pmu sdio status:[0x141]:0x3c [ 6813.140871] sdiohal:pmu sdio status:[0x142]:0xe1 [ 6813.140936] sdiohal:pmu sdio status:[0x143]:0x0 [ 6813.141000] sdiohal:pmu sdio status:[0x144]:0x0 [ 6813.141065] sdiohal:pmu sdio status:[0x145]:0x0 [ 6813.141115] sdiohal:pmu sdio status:[0x146]:0x0 [ 6813.141165] sdiohal:pmu sdio status:[0x147]:0x0 [ 6813.141215] sdiohal:pmu sdio status:[0x148]:0x60 [ 6813.141266] sdiohal:pmu sdio status:[0x149]:0x0 [ 6813.141317] sdiohal:pmu sdio status:[0x14a]:0x0 [ 6813.141366] sdiohal:pmu sdio status:[0x14b]:0x0 [ 6813.141414] sdiohal:pmu sdio status:[0x14c]:0x0 [ 6813.141463] sdiohal:pmu sdio status:[0x14d]:0x0 [ 6813.141513] sdiohal:pmu sdio status:[0x14e]:0x0 [ 6813.141623] sdiohal:pmu sdio status:[0x14f]:0x0 [ 6813.141830] sdiohal:cm4d haddr 0:[0x144]:0x0 [ 6813.141885] sdiohal:cm4d haddr 0:[0x145]:0x60 [ 6813.141938] sdiohal:cm4d haddr 0:[0x146]:0x19 [ 6813.141990] sdiohal:cm4d haddr 0:[0x147]:0x0 [ 6813.142198] sdiohal:cm4i haddr 1:[0x144]:0xf8 [ 6813.142251] sdiohal:cm4i haddr 1:[0x145]:0x67 [ 6813.142302] sdiohal:cm4i haddr 1:[0x146]:0x1e [ 6813.142355] sdiohal:cm4i haddr 1:[0x147]:0x0 [ 6813.142556] sdiohal:cm4s haddr 2:[0x144]:0x4c [ 6813.142608] sdiohal:cm4s haddr 2:[0x145]:0x0 [ 6813.142660] sdiohal:cm4s haddr 2:[0x146]:0x1e [ 6813.142712] sdiohal:cm4s haddr 2:[0x147]:0x40 [ 6813.142913] sdiohal:dmaw haddr 3:[0x144]:0x0 [ 6813.142964] sdiohal:dmaw haddr 3:[0x145]:0x0 [ 6813.143016] sdiohal:dmaw haddr 3:[0x146]:0x0 [ 6813.143067] sdiohal:dmaw haddr 3:[0x147]:0x0 [ 6813.143270] sdiohal:dmar haddr 4:[0x144]:0x0 [ 6813.143323] sdiohal:dmar haddr 4:[0x145]:0x0 [ 6813.143376] sdiohal:dmar haddr 4:[0x146]:0x0 [ 6813.143427] sdiohal:dmar haddr 4:[0x147]:0x0 [ 6813.143640] sdiohal:aon_to_ahb haddr 5:[0x144]:0x0 [ 6813.143692] sdiohal:aon_to_ahb haddr 5:[0x145]:0x0 [ 6813.143743] sdiohal:aon_to_ahb haddr 5:[0x146]:0x0 [ 6813.143795] sdiohal:aon_to_ahb haddr 5:[0x147]:0x0 [ 6813.143998] sdiohal:axi_to_ahb haddr 6:[0x144]:0x4 [ 6813.144050] sdiohal:axi_to_ahb haddr 6:[0x145]:0xf0 [ 6813.144102] sdiohal:axi_to_ahb haddr 6:[0x146]:0x24 [ 6813.144153] sdiohal:axi_to_ahb haddr 6:[0x147]:0x40 [ 6813.144361] sdiohal:hready_status haddr 7:[0x144]:0xcf [ 6813.144415] sdiohal:hready_status haddr 7:[0x145]:0xff [ 6813.144467] sdiohal:hready_status haddr 7:[0x146]:0xf9 [ 6813.144519] sdiohal:hready_status haddr 7:[0x147]:0x50 [ 6813.144532] sdiohal:val:0xc [ 6813.144653] sdiohal:after reset hready status:[0x144]:0xcf [ 6813.144704] sdiohal:after reset hready status:[0x145]:0xff [ 6813.144752] sdiohal:after reset hready status:[0x146]:0xf9 [ 6813.144803] sdiohal:after reset hready status:[0x147]:0x50 [ 6813.144814] sdiohal:sdio dump_aon_reg end [ 6813.144821] sdiohal:sdiohal_abort [ 6813.144829] sdiohal:carddump flag set[1] [ 6813.144905] sdiohal:disable rx int for dump [ 6813.144914] sdiohal:chn8 tx push old, cmdid=72, mstime=6805981, record_time=6805982 [ 6813.144935] chn8 tx push old: 00 00 00 00 10 48 46 00 dd d9 67 00 00 00 00 00 .....HF...g..... [ 6813.144945] sdiohal:chn8 tx denq old, cmdid=72, mstime=6805981, record_time=6805982 [ 6813.144961] chn8 tx denq old: 00 23 00 08 10 48 46 00 dd d9 67 00 00 00 00 00 .#...HF...g..... [ 6813.144972] sdiohal:chn22 rx dispatch old, cmdid=5, mstime=6788866, record_time=6788867 [ 6813.144989] chn22 rx dispatch old: 3f 06 00 0a 00 05 0c 00 02 97 67 00 00 24 00 00 ?.........g..$.. [ 6813.144999] sdiohal:chn8 tx push new, cmdid=72, mstime=6809057, record_time=6809057 [ 6813.145015] chn8 tx push new: 00 00 00 00 10 48 46 00 e1 e5 67 00 00 00 00 00 .....HF...g..... [ 6813.145024] sdiohal:chn8 tx denq new, cmdid=72, mstime=6809057, record_time=6809057 [ 6813.145040] chn8 tx denq new: 00 23 00 08 10 48 46 00 e1 e5 67 00 00 00 00 00 .#...HF...g..... [ 6813.145049] sdiohal:chn22 rx dispatch new, cmdid=5, mstime=6788901, record_time=6788906 [ 6813.145066] chn22 rx dispatch new: bf 06 00 0a 00 05 0d 00 25 97 67 00 00 26 00 00 ........%.g..&.. [ 6813.145077] WCN_ERR: mdbg_dump_data dump memory error:-110 [ 6813.145652] WCN: mdbg dump bt modem 0 ok! [ 6813.145664] WCN_ERR: read HCI_ARM_WR_RD_MODE reg error:-1 [ 6813.146184] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 6813.146674] WCN: mdbg dump bt_cmd buf 0 ok! [ 6813.146696] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 6813.150664] WCN: mdbg dump btevent buf 0 ok! [ 6813.150702] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 6813.151207] WCN: mdbg dump bt_lmp_tx_buf 0 ok! [ 6813.151229] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 6813.151717] WCN: mdbg dump bt_lmp_rx_buf 0 ok! [ 6813.151739] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 6813.152227] WCN: mdbg dump bt_acl_tx_buf0 ok! [ 6813.152249] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 6813.152736] WCN: mdbg dump bt_acl_rx_buf 0 ok! [ 6813.152757] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 6813.153244] WCN: mdbg dump bt_sco_tx_buf 0 ok! [ 6813.153265] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 6813.153790] WCN: mdbg dump bt_sco_rx_buf 0 ok! [ 6813.153817] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 6813.154309] WCN: mdbg dump bt_bb_tx_buf 0 ok! [ 6813.154330] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 6813.154818] WCN: mdbg dump bt_bb_rx_buf 0 ok! [ 6813.201603] WCN: dumpmem_rx_callback [ 6813.201629] WCN: dump str finish! [ 6813.201637] WCN: mdbg dump memory finish [ 6813.201733] sprdwl:sprdwl_atcmd_assert ctx_id:0, cmd_id:72, reason:3, cp_asserted:1 [ 6813.202462] sprdwl:sprdwl_atcmd_assert ctx_id:0, cmd_id:72, reason:3, cp_asserted:1 [ 6814.325605] ------------[ cut here ]------------ [ 6814.325632] NETDEV WATCHDOG: wlan0 (unisoc_wifi): transmit queue 0 timed out [ 6814.325759] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:478 dev_watchdog+0x390/0x398 [ 6814.325798] Modules linked in: tls tcp_diag inet_diag xt_nat xt_tcpudp veth wireguard libchacha20poly1305 poly1305_neon libcurve25519_generic ip6_udp_tunnel udp_tunnel xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge aufs algif_hash algif_skcipher af_alg bnep hci_uart btqca btrtl btbcm btintel bluetooth dw_hdmi_i2s_audio dw_hdmi_cec snd_soc_hdmi_codec hantro_vpu(C) rockchip_vdec(C) rockchip_iep v4l2_h264 rockchip_rga videobuf2_dma_contig v4l2_mem2mem videobuf2_dma_sg videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_soc_simple_card snd_soc_rockchip_i2s fusb302 videobuf2_common snd_soc_es8316 snd_soc_rockchip_pcm snd_soc_simple_card_utils tcpm snd_soc_core typec snd_pcm_dmaengine snd_pcm videodev snd_timer mc snd soundcore cpufreq_dt lz4hc lz4 sch_fq_codel zram sprdwl_ng cfg80211 sprdbt_tty rfkill ramoops pstore_blk reed_solomon [ 6814.326338] pstore_zone ip_tables x_tables autofs4 panfrost motorcomm gpu_sched dwmac_rk stmmac_platform stmmac pwm_bl pcs_xpcs adc_keys [ 6814.326430] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G C 5.15.80-rockchip64 #22.11.1 [ 6814.326448] Hardware name: OrangePi 4 LTS (DT) [ 6814.326458] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 6814.326475] pc : dev_watchdog+0x390/0x398 [ 6814.326493] lr : dev_watchdog+0x390/0x398 [ 6814.326509] sp : ffff800009de3d60 [ 6814.326516] x29: ffff800009de3d60 x28: ffff000008c4dc80 x27: 0000000000000004 [ 6814.326545] x26: 0000000000000140 x25: 00000000ffffffff x24: 0000000000000003 [ 6814.326573] x23: ffff800009a97000 x22: ffff000008d6141c x21: ffff000008d61000 [ 6814.326601] x20: ffff000008d614c0 x19: 0000000000000000 x18: 0000000000000000 [ 6814.326629] x17: ffff8000ee035000 x16: ffff800009de4000 x15: 000000000000096d [ 6814.326656] x14: ffff800009de3a70 x13: 00000000ffffffea x12: ffff800009b2fd10 [ 6814.326685] x11: 0000000000000003 x10: ffff800009b17cd0 x9 : ffff800009b17d28 [ 6814.326713] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 [ 6814.326740] x5 : ffff8000ee035000 x4 : 0000000000000000 x3 : 0000000000000103 [ 6814.326767] x2 : 0000000000000102 x1 : 01cf58aa292ccd00 x0 : 0000000000000000 [ 6814.326795] Call trace: [ 6814.326803] dev_watchdog+0x390/0x398 [ 6814.326821] call_timer_fn+0x30/0x1d0 [ 6814.326840] run_timer_softirq+0x27c/0x518 [ 6814.326855] _stext+0x160/0x3f8 [ 6814.326870] irq_exit+0xc8/0x100 [ 6814.326890] handle_domain_irq+0x94/0xd8 [ 6814.326909] gic_handle_irq+0xb8/0x134 [ 6814.326925] call_on_irq_stack+0x28/0x54 [ 6814.326942] do_interrupt_handler+0x58/0x68 [ 6814.326958] el1_interrupt+0x30/0x78 [ 6814.326974] el1h_64_irq_handler+0x18/0x28 [ 6814.326988] el1h_64_irq+0x74/0x78 [ 6814.327001] arch_cpu_idle+0x18/0x28 [ 6814.327016] default_idle_call+0x40/0x184 [ 6814.327037] do_idle+0x1fc/0x270 [ 6814.327054] cpu_startup_entry+0x24/0x68 [ 6814.327070] secondary_start_kernel+0x154/0x168 [ 6814.327089] __secondary_switched+0x90/0x94 [ 6814.327105] ---[ end trace acf1365498026f79 ]--- My wife use 2.4 and 5 GHz. Please help me to fix this problem. Thank you!

Hello, I have a smart speaker, RK3229CPU, and the sound card is AMK’s AK7755EN. The firmware of the box can be flashed normally, but there is no sound driver. How can I recognize the AK7755EN normally? If it needs to be developed separately, I am willing to pay for the relevant fees . Thank you very much. The following is the introduction of this speaker: https://www.52audio.com/archives/534.html AK7755EN ak7755_f01e.pdf (akm.com) I extracted the dts file of smart speaker android for your reference. my email is：2823609@qq.com smart speak R1 android.dts

Two of the most popular projects providing images for Arm and RISC-V single board computers have released new updates with Armbian 23.02 adding Linux 6.1-based Debian and Ubuntu images, and DietPi 8.14 adding experimental RISC-V support for the StarFive VisionFive 2 SBC and new Arm boards. Armbian 23.02 Quoll Linux 6.1 is the latest LTS kernel, so Armbian is now providing Ubuntu 22.04 Jammy and Debian 11 Bullseye images based on Linux 6.1.y for boards that support it, as well as the first development images based on Debian 12 Bookworm and Ubuntu 23.04 Lunar. I could not find any new boards added in the changelog, but the release brings several improvements and bug fixes to some of the already supported SBCs including the Raspberry Pi 3, Orange Pi R1 Plus LTS, ROCK Pi S, ROCK Pi 4, NanoPi R2S, NanoPi NEO3, and Banana Pi BPI-M2 Pro. The announcement also highlights [...] The post Armbian 23.02 out with Linux 6.1, DietPi 8.14 adds experimental RISC-V support appeared first on CNX Software - Embedded Systems News. View the full article