Search the Community

I can confirm this issue on an old BananaPi 1 from Lemaker. It began with Kernel 6.6. After returning to the older 6.1 the stalls disappeared. Apr 13 23:02:02 eisbaer kernel: rcu: INFO: rcu_sched self-detected stall on CPU Apr 13 23:02:02 eisbaer kernel: rcu: 0-....: (5249 ticks this GP) idle=56dc/1/0x40000002 softirq=5480265/5480265 fqs=2606 Apr 13 23:02:02 eisbaer kernel: rcu: (t=5250 jiffies g=9317845 q=1167 ncpus=2) Apr 13 23:02:02 eisbaer kernel: CPU: 0 PID: 27606 Comm: htop Tainted: G C 6.6.16-current-sunxi #1 Apr 13 23:02:02 eisbaer kernel: Hardware name: Allwinner sun7i (A20) Family Apr 13 23:02:02 eisbaer kernel: PC is at stmmac_get_stats64+0x26/0x128 Apr 13 23:02:02 eisbaer kernel: LR is at 0xc2e6b000 Apr 13 23:02:02 eisbaer kernel: pc : [<c078c5ce>] lr : [<c2e6b000>] psr: 80010033 Apr 13 23:02:02 eisbaer kernel: sp : f1621c68 ip : c2e68000 fp : 00000001 Apr 13 23:02:02 eisbaer kernel: r10: f1621e68 r9 : c2ee3c48 r8 : c2e68000 Apr 13 23:02:02 eisbaer kernel: r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 80000000 Apr 13 23:02:02 eisbaer kernel: r3 : 07c697cd r2 : c2e6ae48 r1 : f1621d28 r0 : c2e68000 Apr 13 23:02:02 eisbaer kernel: Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none Apr 13 23:02:02 eisbaer kernel: Control: 50c5387d Table: 46a2c06a DAC: 00000051 Apr 13 23:02:02 eisbaer kernel: stmmac_get_stats64 from dev_get_stats+0x27/0xd0 Apr 13 23:02:02 eisbaer kernel: dev_get_stats from dev_seq_printf_stats+0x21/0x124 Apr 13 23:02:02 eisbaer kernel: dev_seq_printf_stats from dev_seq_show+0x11/0x24 Apr 13 23:02:02 eisbaer kernel: dev_seq_show from seq_read_iter+0x281/0x35c Apr 13 23:02:02 eisbaer kernel: seq_read_iter from seq_read+0x61/0x84 Apr 13 23:02:02 eisbaer kernel: seq_read from proc_reg_read+0x71/0x90 Apr 13 23:02:02 eisbaer kernel: proc_reg_read from vfs_read+0x75/0x1e4 Apr 13 23:02:02 eisbaer kernel: vfs_read from ksys_read+0x45/0x9c Apr 13 23:02:02 eisbaer kernel: ksys_read from ret_fast_syscall+0x1/0x5c Apr 13 23:02:02 eisbaer kernel: Exception stack(0xf1621fa8 to 0xf1621ff0) Apr 13 23:02:02 eisbaer kernel: 1fa0: 01141aa0 000005e8 00000004 011c7200 00000400 00000001 Apr 13 23:02:02 eisbaer kernel: 1fc0: 01141aa0 000005e8 b6e13888 00000003 0000000a bedcddd4 00000000 00000000 Apr 13 23:02:02 eisbaer kernel: 1fe0: 00000003 bedcdcd0 b6dae2bb b6d27616

Hi All, I am looking for the steps to build custom Linux preferably OpenWrt distro (otherwise Ubuntu or any other distro should be fine at this moment) for Orange Pi R1 H3. I searched it in https://www.armbian.com/download/?device_support=Community maintained&tx_maker=xunlong for the same. But did find anything for Pi R1 H3 board. Thanks in advance for helping me... Warm regards, Manoj

@dhlii Thank you so much for the detailed answer. Now I see that you are a much more experienced developer than me. The H3 and H5 processors are pin-to-pin compatible. Theoretically, it is possible to solder one and solder another processor. And it should work.😁Of course it's a joke. Therefore, comparing the DTS sun50i-h5-nanopi-r1s-h5.dts and sun8i-h3-nanopi-r1.dts, I can see many identical nodes of the same name. This comparison will not be difficult for you. I wrote buildroot as an example. There are several such build systems for embedded operating systems. From my point of view, buildroot is not the most convenient to use.

@going Thanks for the DT information. I did get my nanopi-r1s-h3 working with a nanopi-r1 armbian build. I am not sure why but it did not work the first time I tried. Regardless it is now. That reduces my motivation to start modifying things. But I will look into getting the Device Tree correct later and your directions will be useful. The nanopi-r1 is an H3 device so what I would have to address is the differences between the r1 and the r1s.

@dhlii I wish good health to the developer of embedded Linux. It will be very interesting for me to talk to you. I have a question. Do you use specialized build systems such as buildroot in your work? The first thing to do is add the target DTS to the u-boot. You can take this as a basis: u-boot> find ./arch/arm/dts/ -name '*nanopi-r1*' ./arch/arm/dts/sun8i-h3-nanopi-r1.dts ./arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts linux-stable> find ./arch/arm/boot/dts/ -name '*nanopi*' ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-duo2.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-m1-plus.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-m1.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-neo-air.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-neo.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-r1.dts ./arch/arm/boot/dts/allwinner/sun8i-h3-nanopi.dtsi This DTS must match the wiring of the pins of the printed circuit board and match the brands of soldered chips. The second good step is if you add the default u-boot configuration file. This will allow you to repeat the loader assembly by changing only the dts You can take this as a basis: u-boot> find ./configs/ -name '*h3*' u-boot> find ./configs/ -name '*nanopi*' Special attention is paid to the CONFIG_DRAM_CLK parameter. Even on identical boards but from different series, different memory chips can be soldered. After u-boot has done its job and it loads the dtb of the kernel and the kernel itself, we will be able to dynamically change the dtb using overlays. I.e., the DTB in u-boot is hard-coded, the DTB for the kernel we can change dynamically. P.S. Here I have described my own development process.

It appears that the nanopi-r1 image is working. I am an embdded linux developer. I am not expert in Armbian building. But I have built kernels from scratch, written drivers, and created complete linux installs from scratch - i.e. manually done what the Armbian build script does automatically. But I am not looking to do a huge amount of work to get a bunch of embedded linux systems up to use for other purposes. I have a very large collection of SBC's - probably half can run linux. I like Armbian, and it is pretty uptodate - though frankly I am just using these as network conneced devices to manage other systems I am developing on. Regardless they are laying arround collecting dust, they do not require much power and I do not need lots of horsepower. The bad news is that I am an embdded linux developer - so I have one or two of lots of different boards - not 10 BBB's. My 2nd question was if I choose a similar H3 device to the nanopi-r1s-h3 and I either find a nonopi-r1s-h3 device tree or I modify an H3 device tree to match the nanopi-r1s-h3 hardware and then substite that device tree in a different H3 image - that should work ? Though the question appears to be moot and the nanopi-r1 image appears to work for me.

Image for H5 certainly won't work. Different SoC, even different architecture (32 vs 64 bit). You can give R1 image a try, doesn't look that much different besides the ugly yellow case. No idea how you built r1s images from Armbian since there is no dedicated config for this board in our build system. Maybe you used some sort of fork? Btw. if you don't mind please shorten your signature, like by removing the gaps between the lines. Thanks

Description RTL8153B - does not initialize correctly on boot. Reboot is okay. Start delay work-around in the board file needs tweaking for longer boot time. Jira reference number AR-1910 How Has This Been Tested? [x] Kernel 6.1y tested on Orange Pi R1 Plus LTS [x] Kernel 6.6y tested on Orange Pi R1 Plus LTS 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

Have you tried the Orange Pi R1 builds on the download page you linked to in your first post?

Such board does not exists. It exists with H2+. Which is H3 - 4k video. Which is anyway irrelevant for this use case. Armbian support it as any other Linux distribution. https://docs.armbian.com/User-Guide_Board-Support-Rules/ This means. We don't know if images https://www.armbian.com/orange-pi-r1/ works and if you will have problems, you are on your own to fix them. As this is old and simple board, it will probably just work.

Hi @Werner Thanks a lot for quick reply. At this moment even Armbian build for Orange Pi R1 H3 should be fine. Does Armbian support it? Warm regards, Manoj

I've installed Armbian 23.11.1 Bookworm on a FriendlyElec ZeroPi. This version works flawlessly. A few days ago I updated to Armbian 24.2.1 and since then the ZeroPi crashes and hangs. Sometimes it happens after a few minutes, sometimes after a few hours. When it crashes I can't ssh to the device anymore (headless operation). Unbound, AdguardHome and cups aren't accessable, too. The last messages of the journal in an open cmdline window are: Mär 03 20:50:14 azp kernel: rcu: INFO: rcu_sched self-detected stall on CPU Mär 03 20:50:14 azp kernel: rcu: 2-....: (5249 ticks this GP) idle=16bc/1/0x40000002 softirq=20679/20679 fqs=2625 Mär 03 20:50:14 azp kernel: rcu: (t=5252 jiffies g=33709 q=4 ncpus=4) Mär 03 20:50:14 azp kernel: CPU: 2 PID: 489 Comm: systemd-network Tainted: G C 6.6.16-current-sunxi #1 Mär 03 20:50:14 azp kernel: Hardware name: Allwinner sun8i Family Mär 03 20:50:14 azp kernel: PC is at stmmac_get_stats64+0x26/0x128 Mär 03 20:50:14 azp kernel: LR is at 0xc561b000 Mär 03 20:50:14 azp kernel: pc : [<c078c5ce>] lr : [<c561b000>] psr: 80030033 Mär 03 20:50:14 azp kernel: sp : e1411990 ip : c5618000 fp : 00000001 Mär 03 20:50:14 azp kernel: r10: 00000000 r9 : c9b4d180 r8 : 00000000 Mär 03 20:50:14 azp kernel: r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 80000000 Mär 03 20:50:14 azp kernel: r3 : 0000c625 r2 : c561ae48 r1 : c352aef4 r0 : c5618000 Mär 03 20:50:14 azp kernel: Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none Mär 03 20:50:14 azp kernel: Control: 50c5387d Table: 4362006a DAC: 00000051 Mär 03 20:50:14 azp kernel: stmmac_get_stats64 from dev_get_stats+0x27/0xd0 Mär 03 20:50:14 azp kernel: dev_get_stats from rtnl_fill_stats+0x25/0xb0 Mär 03 20:50:14 azp kernel: rtnl_fill_stats from rtnl_fill_ifinfo+0x4cd/0xde0 Mär 03 20:50:14 azp kernel: rtnl_fill_ifinfo from rtnl_dump_ifinfo+0x1ff/0x49c Mär 03 20:50:14 azp kernel: rtnl_dump_ifinfo from netlink_dump+0xcd/0x270 Mär 03 20:50:14 azp kernel: netlink_dump from __netlink_dump_start+0x15b/0x1ec Mär 03 20:50:14 azp kernel: __netlink_dump_start from rtnetlink_rcv_msg+0x177/0x25c Mär 03 20:50:14 azp kernel: rtnetlink_rcv_msg from netlink_rcv_skb+0x75/0xb0 Mär 03 20:50:14 azp kernel: netlink_rcv_skb from netlink_unicast+0x1c1/0x204 Mär 03 20:50:14 azp kernel: netlink_unicast from netlink_sendmsg+0x185/0x354 Mär 03 20:50:14 azp kernel: netlink_sendmsg from __sock_sendmsg+0x27/0x48 Mär 03 20:50:14 azp kernel: __sock_sendmsg from __sys_sendto+0x7f/0xac Mär 03 20:50:14 azp kernel: __sys_sendto from __sys_trace_return+0x1/0xc Mär 03 20:50:14 azp kernel: Exception stack(0xe1411fa8 to 0xe1411ff0) Mär 03 20:50:14 azp kernel: 1fa0: be9068dc 00000080 00000003 00baffa0 00000020 00000000 Mär 03 20:50:14 azp kernel: 1fc0: be9068dc 00000080 00000001 00000122 be9069c4 be906a28 00000001 004b8cf4 Mär 03 20:50:14 azp kernel: 1fe0: 00000122 be9068b0 b6c85e71 b6bee616 I fear I have to go back to 23.11.1. Any help possible?

Armbian Jammy (Minimal CLI) boots/works fine from an SD Card. (Armbian_23.5.2_Nanopi-r1_jammy_current_6.1.30_minimal.img.xz) apt update && apt upgrade -y && apt autoremove apt install armbian-config -y armbian-install I choose option #2 - Boot from eMMC - System on eMMC Accept the warning. I choose option #1 - ext4 The install appears to move along smoothly. I choose the "Power Off" option. Pull the power, remove the SD Card. Reconnect the power. I never see the "heartbeat" on the "System"(red) LED. The NanoPi never boot or obtains an IP address.

Description Fixed the problem that nanopi r1 cannot boot from emmc. The reason is that uboot uses nanopineo's defconfig and dts when compiling so that it lacks the mmc2 definition. A topic on the forum about this issues: https://forum.armbian.com/topic/28704-nanopi-r1-emmc-install-fails-to-start How Has This Been Tested? Build and update u-boot Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] 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

Description stmmac ethernet driver is in use on all rockchip SoCs; its statistics system has been revised on kernel 6.6, but something is not working correctly right now on 32 bit platforms and a lock contemption happens very often when an userland process tries to read the statistics of the ethernet device. One of the most common victim is vnstat daemon, which often gets stuck hogging a cpu core and skyrocketing the average load. This also makes the whole kernel angry, RCU complains, processes hang, and so on... The patch provides a horrible workaround (remove the mutual exclusion in the reader) to fix the problem temporarely. This may break ethernet statistics that can supply freaky numbers, but at least fixes the problem for the time being. This is the kernel dump from the hung task: [ 696.614056] Sending NMI from CPU 0 to CPUs 2: [ 696.614071] NMI backtrace for cpu 2 [ 696.614079] CPU: 2 PID: 24 Comm: migration/2 Tainted: G C 6.6.12-current-rockchip #25 [ 696.614088] Hardware name: Generic DT based system [ 696.614092] Stopper: multi_cpu_stop+0x0/0x128 <- stop_machine_cpuslocked+0x118/0x180 [ 696.614113] PC is at rcu_momentary_dyntick_idle+0x44/0xc4 [ 696.614122] LR is at multi_cpu_stop+0xe4/0x128 [ 696.614130] pc : [<b0197d74>] lr : [<b01e03b4>] psr: 60070113 [ 696.614135] sp : f0889ed0 ip : 00000000 fp : f0889edc [ 696.614140] r10: 00000001 r9 : 00000000 r8 : 00000000 [ 696.614143] r7 : b1505058 r6 : f093dddc r5 : 00000001 r4 : f093ddf0 [ 696.614148] r3 : ee6b7598 r2 : 2aaeeb3c r1 : 00000000 r0 : 3d234000 [ 696.614153] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 696.614160] Control: 10c5387d Table: 6f38806a DAC: 00000051 [ 696.614163] Backtrace: [ 696.614167] rcu_momentary_dyntick_idle from multi_cpu_stop+0xe4/0x128 [ 696.614181] multi_cpu_stop from cpu_stopper_thread+0x78/0x148 [ 696.614200] r10:f093ddf4 r9:ee6b606c r8:ee6b6074 r7:f093dddc r6:b01e02d0 r5:b9322b00 [ 696.614204] r4:ee6b6068 [ 696.614207] cpu_stopper_thread from smpboot_thread_fn+0xc0/0x15c [ 696.614223] r10:00000000 r9:00000002 r8:b15dd06c r7:00000001 r6:b9322b00 r5:b927dcc0 [ 696.614228] r4:00000000 [ 696.614231] smpboot_thread_fn from kthread+0xe8/0x104 [ 696.614246] r10:00000000 r9:f0821d8c r8:b927df00 r7:b927dcc0 r6:b014e190 r5:b9322b00 [ 696.614250] r4:b927de00 r3:00000000 [ 696.614254] kthread from ret_from_fork+0x14/0x28 [ 696.614263] Exception stack(0xf0889fb0 to 0xf0889ff8) [ 696.614269] 9fa0: 00000000 00000000 00000000 00000000 [ 696.614277] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 696.614283] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 696.614292] r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:b0149778 r4:b927de00 [ 696.615072] CPU: 0 PID: 1258 Comm: vnstatd Tainted: G C 6.6.12-current-rockchip #25 [ 696.615084] Hardware name: Generic DT based system [ 696.615091] PC is at stmmac_get_stats64+0x38/0x1a0 [ 696.615104] LR is at 0x1 [ 696.615115] pc : [<b098c188>] lr : [<00000001>] psr: 20000013 [ 696.615123] sp : f2d6dbf4 ip : f2d6dc20 fp : f2d6dc1c [ 696.615130] r10: 01000001 r9 : b96a0000 r8 : b633e4c8 [ 696.615138] r7 : 00000001 r6 : 00000000 r5 : b098c150 r4 : b96a3000 [ 696.615146] r3 : 000370b7 r2 : b96a2e48 r1 : f2d6dcc8 r0 : b96a0000 [ 696.615155] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 696.615164] Control: 10c5387d Table: 6f08006a DAC: 00000051 [ 696.615170] Backtrace: [ 696.615180] stmmac_get_stats64 from dev_get_stats+0x44/0x168 [ 696.615203] r10:01000001 r9:b96a0000 r8:b633e4c8 r7:b1087af8 r6:b96a0000 r5:b098c150 [ 696.615210] r4:f2d6dcc8 [ 696.615216] dev_get_stats from dev_seq_printf_stats+0x34/0x178 [ 696.615241] r9:b96a0000 r8:b633e4c8 r7:f2d6de20 r6:00000000 r5:b633e4b0 r4:b96a0000 [ 696.615247] dev_seq_printf_stats from dev_seq_show+0x18/0x34 [ 696.615264] r5:00000000 r4:b633e4b0 [ 696.615271] dev_seq_show from seq_read_iter+0x3cc/0x50c [ 696.615288] seq_read_iter from seq_read+0x8c/0xbc [ 696.615310] r10:f2d6df68 r9:00000400 r8:00000000 r7:00004004 r6:00000400 r5:b2f38600 [ 696.615319] r4:f2d6df68 [ 696.615326] seq_read from proc_reg_read+0xb4/0xd8 [ 696.615347] r8:01c70fa0 r7:b2f38600 r6:00000000 r5:b0343274 r4:b9448c00 [ 696.615355] proc_reg_read from vfs_read+0xb8/0x2dc [ 696.615374] r10:b0395cb4 r9:b56ba040 r8:01c70fa0 r7:f2d6df68 r6:b2f38600 r5:00000400 [ 696.615381] r4:00000000 r3:f2d6df68 [ 696.615388] vfs_read from ksys_read+0x68/0xec [ 696.615406] r10:00000003 r9:b56ba040 r8:b01002c8 r7:00000000 r6:00000000 r5:b2f38600 [ 696.615415] r4:b2f38600 [ 696.615420] ksys_read from sys_read+0x10/0x14 [ 696.615436] r7:00000003 r6:a6f425a0 r5:000005e8 r4:01c571a8 [ 696.615443] sys_read from __sys_trace_return+0x0/0x10 [ 696.615457] Exception stack(0xf2d6dfa8 to 0xf2d6dff0) [ 696.615468] dfa0: 01c571a8 000005e8 00000004 01c70fa0 00000400 00000000 [ 696.615480] dfc0: 01c571a8 000005e8 a6f425a0 00000003 0000000a aed87604 00000000 00000000 [ 696.615489] dfe0: 00000003 aed874f0 a6d339a7 a6cadb06 Important notes: this issue may affect other 32 bit platforms as well! stmmac driver is in most SoCs supported by armbian, with the curious exception of Allwinner H3. Meson8/Meson8b (S802/S805) also use it and may be affected by the same problem. 64 bit platforms are not affected, since the locking mechanism is a no-op on 64 bit archs. Jira reference number AR-2048 - Celebrate 2^11th ticket :smile_cat: How Has This Been Tested? [x] Kernel 6.6 compiled and tested on live system [x] Kernel 6.7 compiled 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

Description The 32-bit Allwinner dtb files are under /boot/dtb and not under /boot/dtb/allwinner as expected by u-boot because of the current board config. Fixed dtb location by removing the allwinner/ prefix for nanopi-r1 and nanopi duo2 boards. This issue seems to have already reported on the forums as well - https://forum.armbian.com/topic/28117-nanopi-duo-2-hang-on-boot/ How Has This Been Tested? Tested by creating edge image with the changes included in the pull request. The stable image still doesn't boot because of the ongoing issue with the 6.1.30 kernel image, but 6.2.16 kernel from edge image works [x] Created edge image and booted on nanopi duo2 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

When I first saw the iKOOLCORE R1 I was fascinated that a mini PC of similar size to the smallest fully functional ones available (think Chuwi LarkBox, GMK NucBox or ECS LIVA Q Series) could be equipped with four 2.5 gigabit Ethernet (2.5GbE) ports. I approached iKOOLCORE who kindly provided an R1 for review and I’ve looked at performance running both Windows 11 and Ubuntu 22.04 and dabbled with using hypervisors on this mini PC through Proxmox virtual environment. iKOOLCORE R1 specifications iKOOLCORE list the R1 specifications on their website as: Of note are the ‘EC, FCC, RoHS’ certifications indicating both European conformity and approval for use in the US. Technically ‘EC’ refers to an ‘EC declaration of conformity’ which is not a certificate, however, the ‘EC declaration of conformity’ is called a ‘CE statement’ or ‘CE certificate’ which is why you often see this abbreviated as ‘CE’. The rest [...] The post iKOOLCORE R1 review – A quad 2.5GbE mini PC tested with Windows 11, Ubuntu 22.04, Proxmox appeared first on CNX Software - Embedded Systems News. View the full article

Arduino GIGA R1 WiFi board brings the STM32H7 dual-core Cortex-M7/M4 microcontroller found in the Portenta H7 boards to the larger Arduino Mega/Due form factor with up to 76 GPIO pins. As its name implies, the board also comes with a WiFi 4 (and Bluetooth 5.1) module, as well as an audio jack, a USB Type-C port for programming, a USB 2.0 Type-A host port, and extra connectors for a display and a camera. Arduino GIGA R1 WiFi board specifications: Microcontroller – STMicro STM32H747XI Cortex-M7 @ 480 MHz + M4 @ 200 MHz MCU with 2MB dual-bank Flash memory, 1 MB RAM, Chrom-ART graphical hardware accelerator System Memory – 8MB SDRAM Storage – 16MB QSPI NOR flash Connectivity – 2.4GHz WiFi 802.11b/g/n up to 65 Mbps and Bluetooth 5.1 BR/EDR/LE via Murata 1DX module Display – 20-pin header (J5) Camera – 20-pin Arducam camera header (J6) USB 1x USB Type-C port [...] The post Arduino GIGA R1 WiFi board launches with STM32H7 MCU, up to 76 I/O pins appeared first on CNX Software - Embedded Systems News. View the full article

I'm attempt to do two simple switches via GPIO on OrangePi R1 LTS Plus using RK3328 using .Net Core and here my code snippet. GpioController ioc = new GpioController(PinNumberingScheme.Logical, new RockchipDriver(gpioRegisterAddresses: new uint[] { 0xFF21_0000, 0xFF22_0000, 0xFF23_0000, 0xFF24_0000 })); int iPin=RockchipDriver.MapPinNumber(???) // where do I find the information to do logical pin number mapping? ioc.OpenPin(iPin); ioc.SetPinMode(iPin, PinMode.InputPullUp); PinValue v=ioc.Read(iPin); Thanks for reading and any suggestion is appreciated.

Hi, i am beginner in SBC other than Rapsberry Pi and i just got my NanoPi R1 with case. I try power the board without SD card for the first time and i see that friendlyWRT already installed but i would like to use a general OS. Since i can't download the official OS from friendlyelec, i saw that armbian is another way and might be better. I follow all step in quick start guide page, and can't even get my board boot up. Below is the list of OS that i try with SD card: - Armbian_22.11.1_Nanopi-r1_jammy_current_5.15.80_minimal - Armbian_22.11.1_Nanopi-r1_bullseye_current_5.15.80 - Armbian_22.11.1_Nanopi-r1_bullseye_current_5.15.80_minimal - Armbian_22.02.1_Nanopi-r1_bullseye_current_5.15.25 - Armbian_21.08.1_Nanopi-r1_buster_current_5.10.60 - Armbian_21.08.1_Nanopi-r1_bullseye_current_5.10.60 - Armbian_21.05.1_Nanopi-r1_buster_current_5.10.34 - Armbian_21.02.1_Nanopi-r1_buster_current_5.10.12 - Armbian_22.08.1_Nanopi-r1_bullseye_current_5.15.63 - Armbian_22.05.4_Nanopi-r1_bullseye_current_5.15.48 - Armbian_22.02.1_Nanopi-r1_focal_current_5.15.25 In each sd card flash, i always format the sd card using SD Card Formatter. There are different outputs from all image above: No output at all Happen in 5.10.12 Stuck in "starting kernel.." Happen in 5.10.34 , 5.10.48 and 5.10.25 images U-Boot SPL 2021.10-armbian (Feb 27 2022 - 08:49:47 +0000) DRAM: 1024 MiB Trying to boot from MMC1 U-Boot 2021.10-armbian (Feb 27 2022 - 08:49:47 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi R1 DRAM: 1 GiB MMC: mmc@1c0f000: 0, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial Out: serial Err: serial Net: phy interface7 Error: ethernet@1c30000 address not set. No ethernet found. starting USB... Bus usb@1c1a000: USB EHCI 1.00 Bus usb@1c1a400: USB OHCI 1.0 Bus usb@1c1d000: USB EHCI 1.00 Bus usb@1c1d400: USB OHCI 1.0 scanning bus usb@1c1a000 for devices... 1 USB Device(s) found scanning bus usb@1c1a400 for devices... 1 USB Device(s) found scanning bus usb@1c1d000 for devices... 1 USB Device(s) found scanning bus usb@1c1d400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3964 bytes read in 2 ms (1.9 MiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 237 bytes read in 2 ms (115.2 KiB/s) 11387894 bytes read in 473 ms (23 MiB/s) 8303240 bytes read in 347 ms (22.8 MiB/s) Found mainline kernel configuration 33828 bytes read in 7 ms (4.6 MiB/s) 504 bytes read in 6 ms (82 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost0.dtbo 504 bytes read in 6 ms (82 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost1.dtbo 502 bytes read in 5 ms (97.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-uart1.dtbo 4185 bytes read in 6 ms (680.7 KiB/s) Applying kernel provided DT fixup script (sun8i-h3-fixup.scr) ## Executing script at 45000000 Kernel image @ 0x42000000 [ 0x000000 - 0x7eb288 ] ## Loading init Ramdisk from Legacy Image at 43400000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 11387830 Bytes = 10.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. Loading Ramdisk to 49523000, end 49fff3b6 ... OK Loading Device Tree to 494b2000, end 49522fff ... OK Starting kernel ... Everything is timeout and open some kind of console It happen in 5.15.80 and 5.10.60 images U-Boot SPL 2022.07-armbian (Nov 30 2022 - 10:45:40 +0000) DRAM: 1024 MiB Trying to boot from MMC1 U-Boot 2022.07-armbian (Nov 30 2022 - 10:45:40 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO DRAM: 1 GiB Core: 60 devices, 17 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0 Loading Environment from FAT... Unable to use mmc 0:1... In: serial Out: serial Err: serial Net: phy interface1 eth0: ethernet@1c30000 starting USB... Bus usb@1c1a000: USB EHCI 1.00 Bus usb@1c1a400: USB OHCI 1.0 Bus usb@1c1d000: USB EHCI 1.00 Bus usb@1c1d400: USB OHCI 1.0 scanning bus usb@1c1a000 for devices... 1 USB Device(s) found scanning bus usb@1c1a400 for devices... 1 USB Device(s) found scanning bus usb@1c1d000 for devices... 1 USB Device(s) found scanning bus usb@1c1d400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 4021 bytes read in 2 ms (1.9 MiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 229 bytes read in 2 ms (111.3 KiB/s) 11798171 bytes read in 489 ms (23 MiB/s) 8393496 bytes read in 349 ms (22.9 MiB/s) Found mainline kernel configuration Failed to load '/boot/dtb/allwinner/sun8i-h3-nanopi-r1.dtb' libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! 504 bytes read in 6 ms (82 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost0.dtbo No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! 504 bytes read in 6 ms (82 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost1.dtbo No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! 502 bytes read in 6 ms (81.1 KiB/s) Applying kernel provided DT overlay sun8i-h3-uart1.dtbo No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! Error applying DT overlays, restoring original DT Failed to load '/boot/dtb/allwinner/sun8i-h3-nanopi-r1.dtb' Kernel image @ 0x42000000 [ 0x000000 - 0x801318 ] ## Loading init Ramdisk from Legacy Image at 43400000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 11798107 Bytes = 11.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree SCRIPT FAILED: continuing... No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image Device 0: unknown device sun8i_emac_eth_start: Timeout missing environment variable: pxeuuid Retrieving file: pxelinux.cfg/01-02-81-6c-b0-b3-e0 sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/00000000 sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/0000000 sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/000000 sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/00000 sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/0000 sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/000 sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/00 sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/0 sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/default-arm-sunxi-sunxi sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/default-arm-sunxi sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/default-arm sun8i_emac_eth_start: Timeout Retrieving file: pxelinux.cfg/default sun8i_emac_eth_start: Timeout Config file not found sun8i_emac_eth_start: Timeout sun8i_emac_eth_start: Timeout => I don't know this info matter or not, but the red led on the board is blinking, same pattern when the image output stuck in "starting kernel" and when SD card is not attached. Also, i even flash the SD with dietpi OS, but it has the same output with stuck in "starting kernel". I wait multiple times but nothing happen in after "starting kernel". Any help appreciated! Thank you!

Hi guys, in my job they bought a orangepi r1+LTS. i trying install armbian any version (last Debian and Ubuntu) but this don’t work. When boot system nothing happens… the led red still off and port Ethernet freezing(two lights on). Already installed Debian and Ubuntu of the official page orangepi, and system working without problems im using good sd card and official charger of the raspberrypi 4 How to solve this problem? In internet I don’t found much information thank u for read me

Hey there since i got a Bananapi-R1 recently ive started to notice that there are no up to Date Images out there. Official support is over since 2016 and none of the Images later than Ubuntu 16.04 i found started booting or even have a working Download Link! So i had to figure out how i could get a later Version installed on my Board by myself! I have compiled a Bullseye Image that works fine, the only things ive noticed are missing OTG and WirringPi Support! Maybe someone knows a way how to get it working?? As i wrote before i couldnt find any recent Images out there, so i compiled some with this well documented Compiler by Armbian. SSH is enabled by default, only Bullseye and Buster are tested! ______________________________ Login: root Password: 1234 ______________________________ Armbian Sid: Download Armbian Bullseye: Download Armbian Buster: Download ______________________________ Ubuntu Jammy: Download Ubuntu Impish: Download Ubuntu Focal: Download ______________________________ Kernel: Linux 5.15.32 Build date: 04.04.2022

@jock Just an update about booting HK1 rbox r1 having a crappy emmc (cannot erase the bootloader using multitool nor dd) I initially spent some time trying to fill the gap between the multitool boot process and other images since I was able to boot multitool from sdcard but not armbian nor libreelec. Provided that I'm still far from a deep understanding of the whole boot process, I saw that - simply overwriting u-boot on the sdcard - then both armbian and libreelec can boot even if the emmc still have its bootloader in place, that is when I remove the sdcard I can see the original boot splash screen. All credits go to gausus at https://dietpi.com/forum/t/dietpi-on-rk3328-rk3318-tvbox/15587 Following his steps, I simply extract uboot from multitool image, then copy it in two chunks to the sdcard (I can provide full steps here in case someone is interested) This way I can boot Armbian_23.08.0-trunk_Rk3318-box_bookworm_edge_6.3.13_minimal.img without further changes, while for LibreELEC-RK3328.arm-11.0.3-a1.img I had to place rk3318-box.dtb on the sd and change the FDT entry on /extlinux/extlinux.conf

Fix description. Remove trailing spaces and extra line feed to improve parser compatibility. No functional changes. Add space before bracket in code. Jira reference number AR-1480 [x] bullseye tested on orangepi-r1-plus-lts Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] 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

I almost forgot to mention. The HK1 RBOX R1 has a reset button buried at the back of the 3.5mm TRS audio jack which this YouTube video demonstrates being used for some kind of DFU-esque flashing procedure using Rockchip's tools. That's all I know about it so far. EDIT: While I was waiting for these posts to be approved, I also figured out the LED: If you want the blue LED to stop blinking, you need to change the value of /sys/class/leds/working/trigger from "timer" to another setting. The brightness setting is backwards, so anything that's supposed to have it normally off and then blink it on briefly will do the opposite. Here are the choices which actually produced an effect during my tests rather than just keeping the LED on: Turn the LED off: echo "default-on" > /sys/class/leds/working/trigger (Alternatively, set it to "none" and then write a 1 to /sys/class/leds/working/brightness if you have plans to control it manually.) LED on except when a button is pressed on the remote: echo "rc-feedback" > /sys/class/leds/working/trigger LED on normally. Blink off to denote CPU activity above some threshold: echo "activity" > /sys/class/leds/working/trigger UPDATE: I may or may not bother trying to get the LED clock display working since I didn't keep a backup of the original firmware once I confirmed Debian was working, I only now realize it may be needed to determine which GPIO are hooked up, and I'm not particularly enthused about downloading and trying to boot one of the stock firmware images off an SD card for a display that I'd just leave off anyway because I don't like piercing blue lights in my bedroom. (My main interest was in getting it to say "boot" once more so I know when it's ready for me to SSH in, and I can get that just by turning off the blinking LED on boot completion... with the added benefit that it'll turn on steady to signal shutdown completion.)