It worked! Thank you very much. May I ask you how you built U-Boot?
Best regards Pierre Louis Le 2025-08-20T15:50:48.000+09:00, Kevin Lo <[email protected]> a écrit : > Hi, > > I've been running an R4S as a firewall with OpenBSD for several years. > You can use the idbloader.img and u-boot.itb I built from U-Boot 2025.07: > https://www.kevlo.org/r4s/idbloader.img > https://www.kevlo.org/r4s/u-boot.itb > > Follow the instructions here to flash U-Boot onto a uSD card: > https://github.com/openbsd/src/blob/master/distrib/notes/arm64/prep#L129 > > The re(4) driver requires this patch: https://www.kevlo.org/r4s/re.diff > After applying the patch, you will need to build the kernel. > > Hope that helps, > Kevin > > On Sat, Aug 16, 2025 at 09:54:00PM +0900, Pierre Louis Aublin wrote: >> Hi Please forgive me to revive this old thread, but I faced the >> same issue on my newly acquired R4S and OpenBSD 7.7. This email is >> divided in 2 parts: 1. Solution to the boot problem 2. Kernel >> panic when using the LAN network interface 1. Solution to the boot >> problem ------------------------------- I managed to boot the >> kernel after installing the system by copying >> `rk3399-rockpro64.dtb` instead of `rk3399-nanopi-r4s.dtb` to the >> `/rockchip` folder on the boot partition. The idea came from this >> post (in Chinese, but used Google Translate): >> https://blog.starry-s.moe/posts/2022/nanopi-r4s/ . Here are some >> relevant lines observed during the boot process: ``` [...] dwmmc0 >> at mainbus0: 50 MHz base clock sdmmc0 at dwmmc0: 4-bit, sd >> high-speed, mmc high-speed, dma [...] scsibus0 at sdmmc0: 2 >> targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: <SD/MMC, 00000, >> 0000> removable sd0: 59640MB, 512 bytes/sector, 122142720 sectors >> vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root >> scsibus2 at softraid0: 256 targets root on sd0a >> (3ee1d4d5039301c4.a) swap on sd0b dump on sd0b [...] Automatic >> boot in progress: starting file system checks. pf enabled starting >> network reordering: ld.so [http://ld.so] libc libcrypto sshd >> sshd-session sshd-auth ssh-agent. starting early daemons: syslogd >> pflogd ntpd. starting RPC daemons:. savecore: no core dump >> checking quotas: done. clearing /tmp kern.securelevel: 0 -> 1 >> creating runtime link editor directory cache. preserving editor >> files. starting network daemons: sshd smtpd sndiod. starting local >> daemons: cron. Sat Aug 16 20:37:38 JST 2025 OpenBSD/arm64 >> (openr4s.my.domain [http://openr4s.my.domain]) (console) ``` It >> seems the following lines are missing from >> >>`https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/src/arm64/rockchip/rk3399-nanopi-r4s.dtsi` >> (used among others by >> `https://github.com/Tosainu/nanopi-r4s-u-boot` to create the dtb >> file): ``` +&sdmmc { +?? ?? ?? ?? status = "okay"; +}; ``` Besides >> the problem detailed below, I have not encountered any other >> problem while using OpenBSD. 2. Kernel panic when using the LAN >> network interface >> ---------------------------------------------------- The kernel >> panics when running iperf with another machine over the LAN >> network interface (re0). This does not happen with the WAN network >> interface (dwge0). While the MAC is set to 00:00:00:00:00:00 by >> default as the board doesn't have the chip to store it, I've set >> it to a valid, random value before the test. ``` # panic: >> pool_cache_item_magic_check: mcl9k cpu free list modified: item >> addr 0xf fffff801ecbd500+16 0x400000c9000045!=0xc3b51ecae9362bf1 >> Stopped at?? ?? ?? panic+0x140:?? ?? cmp?? ?? ??w21, #0x0 ?? ?? >> TID?? ?? PID?? ?? UID?? ?? ??PRFLAGS?? ?? ??PFLAGS?? CPU?? COMMAND >> ??438354?? 35240?? ?? ?? 0?? ?? ?? ?? ??0x3?? 0x4000000?? ?? 4?? >> iperf ??202876?? 99382?? ?? ?? 0?? ?? ??0x14000?? ?? ?? 0x200?? ?? >> 1?? softnet0 db_enter() at panic+0x13c panic() at >> pool_cache_get+0x264 pool_cache_get() at pool_get+0x54 pool_get() >> at m_clget+0x1c8 m_clget() at re_newbuf+0x44 re_newbuf() at >> re_rxeof+0x390 re_rxeof() at re_intr+0xc0 >> >>> ddb{0}> trace >> db_enter() at panic+0x13c panic() at pool_cache_get+0x264 >> pool_cache_get() at pool_get+0x54 pool_get() at m_clget+0x1c8 >> m_clget() at re_newbuf+0x44 re_newbuf() at re_rxeof+0x390 >> re_rxeof() at re_intr+0xc0 re_intr() at agintc_irq_handler+0x104 >> agintc_irq_handler() at arm_cpu_irq+0x44 arm_cpu_irq() at >> handle_el1h_irq+0x68 handle_el1h_irq() at cpu_idle_cycle+0x28 >> cpu_idle_cycle() at sched_idle+0x218 sched_idle() at >> proc_trampoline+0xc ``` By any chance, would you have any idea to >> debug or solve this problem? Best regards Pierre Louis
