Code Monkey home page Code Monkey logo

nanopi-r5's Introduction

nanopi-r5

Stock Debian ARM64 Linux for the NanoPi R5C & R5S

This stock Debian ARM64 Linux image is built directly from official packages using the Debian Debootstrap utility, see: https://github.com/inindev/nanopi-r5/blob/main/debian/nanopi-r5c/make_debian_img.sh#L126

Being an unmodified Debian build, patches are directory available from the Debian repos using the stock apt package manager, see: https://github.com/inindev/nanopi-r5/blob/main/debian/nanopi-r5c/make_debian_img.sh#L355-L365

If you want to run true up-stream Debian Linux on your ARM64 device, this is the way to do it.


debian bookworm setup


1. download the appropriate image

(R5C) wget https://github.com/inindev/nanopi-r5/releases/download/v12.0.3/nanopi-r5c_bookworm-1203.img.xz
(R5S) wget https://github.com/inindev/nanopi-r5/releases/download/v12.0.3/nanopi-r5s_bookworm-1203.img.xz

2. determine the location of the target micro sd card

  • before plugging-in device
ls -l /dev/sd*
ls: cannot access '/dev/sd*': No such file or directory
  • after plugging-in device
ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 Mar 19 21:08 /dev/sda
  • note: for mac, the device is /dev/rdiskX

3. in the case above, substitute 'a' for 'X' in the command below (for /dev/sda)

sudo sh -c 'xzcat nanopi-r5s_bookworm-1203.img.xz > /dev/sdX && sync'

when the micro sd has finished imaging, eject and use it to boot the nanopi r5c or r5s to finish setup


4. login account

user: debian
pass: debian

5. take updates

sudo apt update
sudo apt upgrade

6. create new admin account

sudo adduser <youruserid>
echo '<youruserid> ALL=(ALL) NOPASSWD: ALL' | sudo tee /etc/sudoers.d/<youruserid>
sudo chmod 440 /etc/sudoers.d/<youruserid>

7. lockout and/or delete debian account

sudo passwd -l debian
sudo chsh -s /usr/sbin/nologin debian
sudo deluser --remove-home debian
sudo rm /etc/sudoers.d/debian

8. change hostname (optional)

sudo nano /etc/hostname
sudo nano /etc/hosts


booting from internal eMMC


Imaging the internal eMMC device involves booting from a removable MMC card and imaging the internal eMMC device. When booted, the removable MMC device is seen as /dev/mmcblk0 and the internal eMMC device is seen as /dev/mmcblk1


1. boot from removable MMC

Using the steps in the first section above, create a removable MMC card and boot using it. Note: If the internal eMMC device already has a bootable image on it, it will prefer to boot from that. To force the nanopi5 to boot from the removable MMC card you just made, hold the mask button down before applying power. Once successfully booted to the removable MMC, you will be able to see this by using the df command which will show /dev/mmcblk0p1 as the booted partition.


2. download the appropriate image to the booted MMC card and image the internal eMMC

(R5C) wget https://github.com/inindev/nanopi-r5/releases/download/v12.0.3/nanopi-r5c_bookworm-1203.img.xz
(R5S) wget https://github.com/inindev/nanopi-r5/releases/download/v12.0.3/nanopi-r5s_bookworm-1203.img.xz
sudo su
xzcat nanopi-r5s_bookworm-1203.img.xz > /dev/mmcblk1

Once imaging completes, shutdown, remove the MMC card and it will then boot using the internal eMMC device.

Note: Once booted, sudo apt update then sudo apt upgrade to get the latest updates from the debian repositories.



booting from internal NVMe (r5s only)


Imaging the internal NVMe device involves booting from a removable MMC card and imaging the internal NVMe device. When booted, the internal NVMe device is seen as /dev/nvme0n1


1. boot from removable MMC

Using the steps in the first section above, create a removable MMC card and boot using it. Note: If the internal eMMC device already has a bootable image on it, it will prefer to boot from that. To force the nanopi5 to boot from the removable MMC card you just made, hold the mask button down before applying power. Once successfully booted to the removable MMC, you will be able to see this by using the df command which will show /dev/mmcblk0p1 as the booted partition.


2. download the image to the booted MMC card and image the internal NVMe

wget https://github.com/inindev/nanopi-r5/releases/download/v12.0.3/nanopi-r5s_bookworm-1203.img.xz
sudo su
xzcat nanopi-r5s_bookworm-1203.img.xz > /dev/nvme0n1

3. install u-boot to internal eMMC

The last step is to prepare the internal eMMC to host u-boot. The eMMC must not contain a bootable partition or it will be preferred for boot over the internal NVMe. Start by downloading the two u-boot files:

wget https://github.com/inindev/nanopi-r5/releases/download/v12.0.3/idbloader-r5s.img
wget https://github.com/inindev/nanopi-r5/releases/download/v12.0.3/u-boot-r5s.itb

Erase the internal eMMC (the device is actually /dev/mmcblk1 but X is placed where 1 belongs to prevent a copy paste mistake)

sudo dd if=/dev/zero of=/dev/mmcblkX bs=1M count=1024

The internal eMMC is now erased, install u-boot (again, change X to 1):

sudo dd bs=4K seek=8 if=idbloader-r5s.img of=/dev/mmcblkX
sudo dd bs=4K seek=2048 if=u-boot-r5s.itb of=/dev/mmcblkX

4. setup is now complete and the system is ready for use

shutdown the device, remove the external mmc card, and restart the device

Note: Once booted, sudo apt update then sudo apt upgrade to get the latest updates from the debian repositories.



building debian bookworm arm64 for the nanopi r5c / r5s from scratch


The build script builds native arm64 binaries and thus needs to be run from an arm64 device such as a raspberry pi4 running a 64 bit arm linux. The initial build of this project used a debian arm64 odroid m1, but now uses a nanopi r5s running stock debian bookworm arm64.


1. clone the repo

git clone https://github.com/inindev/nanopi-r5.git
cd nanopi-r5

2. run the debian build script

(R5C) cd debian/nanopi-r5c
(R5S) cd debian/nanopi-r5s
sudo sh make_debian_img.sh
  • note: edit the build script to change various options: nano make_debian_img.sh

3. the output if the build completes successfully

mmc_2g.img.xz

nanopi-r5's People

Contributors

ajayramaswamy avatar inindev avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nanopi-r5's Issues

NVME is not functional

After boot no NVME devices found. If I trigger pci rescan via echo 1 > /sys/bus/pci/rescan NVMe device is found but non-functional:

[   46.034631] pcieport 0002:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[   46.035741] pci 0002:01:00.0: [15b7:5006] type 00 class 0x010802
[   46.036483] pci 0002:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[   46.037312] pci 0002:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff 64bit]
[   46.039350] pci 0002:01:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0002:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[   46.052298] pci_bus 0002:01: busn_res: [bus 01-ff] end is updated to 01
[   46.053043] pcieport 0002:00:00.0: BAR 14: assigned [mem 0xf0300000-0xf03fffff]
[   46.053764] pci 0002:01:00.0: BAR 0: assigned [mem 0xf0300000-0xf0303fff 64bit]
[   46.054522] pci 0002:01:00.0: BAR 4: assigned [mem 0xf0304000-0xf03040ff 64bit]
[   46.097927] nvme nvme0: pci function 0002:01:00.0
[   46.098444] nvme 0002:01:00.0: enabling device (0000 -> 0002)
[  107.508575] nvme nvme0: I/O 12 QID 0 timeout, completion polled
[  168.958145] nvme nvme0: I/O 8 QID 0 timeout, completion polled
[  230.391719] nvme nvme0: I/O 13 QID 0 timeout, completion polled
[  242.664114] INFO: task kworker/u8:4:167 blocked for more than 120 seconds.
[  242.664761]       Not tainted 6.1.0-12-arm64 #1 Debian 6.1.52-1
[  242.665290] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  242.665983] task:kworker/u8:4    state:D stack:0     pid:167   ppid:2      flags:0x00000008
[  242.666733] Workqueue: events_unbound async_run_entry_fn
[  242.667225] Call trace:
[  242.667449]  __switch_to+0xf0/0x170
[  242.667771]  __schedule+0x340/0x940
[  242.668129]  schedule+0x58/0xf0
[  242.668421]  schedule_timeout+0x14c/0x180
[  242.668785]  __wait_for_common+0xd4/0x254
[  242.669148]  wait_for_completion+0x28/0x3c
[  242.669519]  __flush_work.isra.0+0x180/0x2dc
[  242.669907]  flush_work+0x18/0x2c
[  242.670209]  nvme_async_probe+0x24/0x44 [nvme]
[  242.670636]  async_run_entry_fn+0x40/0x1e0
[  242.671010]  process_one_work+0x1f4/0x460
[  242.671375]  worker_thread+0x188/0x4e0
[  242.671715]  kthread+0xe0/0xe4
[  242.672025]  ret_from_fork+0x10/0x20
[  242.672407] INFO: task (udev-worker):706 blocked for more than 120 seconds.
[  242.673027]       Not tainted 6.1.0-12-arm64 #1 Debian 6.1.52-1
[  242.673554] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  242.674245] task:(udev-worker)   state:D stack:0     pid:706   ppid:277    flags:0x0000080d
[  242.674992] Call trace:
[  242.675214]  __switch_to+0xf0/0x170
[  242.675535]  __schedule+0x340/0x940
[  242.675851]  schedule+0x58/0xf0
[  242.676169]  async_synchronize_cookie_domain+0xe8/0x150
[  242.676645]  async_synchronize_full+0x20/0x30
[  242.677041]  do_init_module+0x160/0x1f4
[  242.677390]  load_module+0x1cb8/0x2220
[  242.677730]  __do_sys_finit_module+0xac/0x130
[  242.678123]  __arm64_sys_finit_module+0x28/0x34
[  242.678530]  invoke_syscall+0x78/0x100
[  242.678874]  el0_svc_common.constprop.0+0xd4/0xf4
[  242.679299]  do_el0_svc+0x34/0xd0
[  242.679601]  el0_svc+0x34/0xd4
[  242.679905]  el0t_64_sync_handler+0xf4/0x120
[  242.680298]  el0t_64_sync+0x18c/0x190
[  263.763473] systemd-journald[243]: Oldest entry in /var/log/journal/69fd1ff5339ee7c1931e562d64ac7bcc/system.journal is older than the configured file retention duration (1month), suggesting rotation.
[  263.765169] systemd-journald[243]: /var/log/journal/69fd1ff5339ee7c1931e562d64ac7bcc/system.journal: Journal header limits reached or header out-of-date, rotating.
[  291.833349] nvme nvme0: I/O 9 QID 0 timeout, completion polled
[  353.274913] nvme nvme0: I/O 14 QID 0 timeout, completion polled
[  353.276365] hwmon hwmon2: temp1_input not attached to any thermal zone
[  363.499229] INFO: task kworker/u8:4:167 blocked for more than 241 seconds.
[  363.499892]       Not tainted 6.1.0-12-arm64 #1 Debian 6.1.52-1
[  363.500427] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  363.501129] task:kworker/u8:4    state:D stack:0     pid:167   ppid:2      flags:0x00000008
[  363.501890] Workqueue: events_unbound async_run_entry_fn
[  363.502394] Call trace:
[  363.502623]  __switch_to+0xf0/0x170
[  363.502956]  __schedule+0x340/0x940
[  363.503329]  schedule+0x58/0xf0
[  363.503631]  schedule_timeout+0x14c/0x180
[  363.504004]  __wait_for_common+0xd4/0x254
[  363.504377]  wait_for_completion+0x28/0x3c
[  363.504756]  __flush_work.isra.0+0x180/0x2dc
[  363.505154]  flush_work+0x18/0x2c
[  363.505465]  nvme_async_probe+0x24/0x44 [nvme]
[  363.505910]  async_run_entry_fn+0x40/0x1e0
[  363.506294]  process_one_work+0x1f4/0x460
[  363.506669]  worker_thread+0x188/0x4e0
[  363.507059]  kthread+0xe0/0xe4
[  363.507353]  ret_from_fork+0x10/0x20
[  363.507742] INFO: task (udev-worker):706 blocked for more than 241 seconds.
[  363.508370]       Not tainted 6.1.0-12-arm64 #1 Debian 6.1.52-1
[  363.508903] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  363.509602] task:(udev-worker)   state:D stack:0     pid:706   ppid:277    flags:0x0000080d
[  363.510359] Call trace:
[  363.510588]  __switch_to+0xf0/0x170
[  363.510916]  __schedule+0x340/0x940
[  363.511289]  schedule+0x58/0xf0
[  363.511590]  async_synchronize_cookie_domain+0xe8/0x150
[  363.512073]  async_synchronize_full+0x20/0x30
[  363.512478]  do_init_module+0x160/0x1f4
[  363.512834]  load_module+0x1cb8/0x2220
[  363.513182]  __do_sys_finit_module+0xac/0x130
[  363.513584]  __arm64_sys_finit_module+0x28/0x34
[  363.514002]  invoke_syscall+0x78/0x100
[  363.514355]  el0_svc_common.constprop.0+0xd4/0xf4
[  363.514791]  do_el0_svc+0x34/0xd0
[  363.515144]  el0_svc+0x34/0xd4
[  363.515442]  el0t_64_sync_handler+0xf4/0x120
[  363.515841]  el0t_64_sync+0x18c/0x190
[  414.724449] nvme nvme0: I/O 10 QID 0 timeout, completion polled
[  476.157964] nvme nvme0: I/O 15 QID 0 timeout, completion polled
[  484.334241] INFO: task kworker/u8:4:167 blocked for more than 362 seconds.
[  484.334908]       Not tainted 6.1.0-12-arm64 #1 Debian 6.1.52-1
[  484.335443] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  484.336141] task:kworker/u8:4    state:D stack:0     pid:167   ppid:2      flags:0x00000008
[  484.336903] Workqueue: events_unbound async_run_entry_fn
[  484.337409] Call trace:
[  484.337638]  __switch_to+0xf0/0x170
[  484.337968]  __schedule+0x340/0x940
[  484.338345]  schedule+0x58/0xf0
[  484.338647]  schedule_timeout+0x14c/0x180
[  484.339020]  __wait_for_common+0xd4/0x254
[  484.339394]  wait_for_completion+0x28/0x3c
[  484.339773]  __flush_work.isra.0+0x180/0x2dc
[  484.340170]  flush_work+0x18/0x2c
[  484.340481]  nvme_async_probe+0x24/0x44 [nvme]
[  484.340926]  async_run_entry_fn+0x40/0x1e0
[  484.341311]  process_one_work+0x1f4/0x460
[  484.341684]  worker_thread+0x188/0x4e0
[  484.342078]  kthread+0xe0/0xe4
[  484.342373]  ret_from_fork+0x10/0x20
[  484.342766] INFO: task (udev-worker):706 blocked for more than 362 seconds.
[  484.343397]       Not tainted 6.1.0-12-arm64 #1 Debian 6.1.52-1
[  484.343930] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  484.344629] task:(udev-worker)   state:D stack:0     pid:706   ppid:277    flags:0x0000080d
[  484.345387] Call trace:
[  484.345616]  __switch_to+0xf0/0x170
[  484.345944]  __schedule+0x340/0x940
[  484.346321]  schedule+0x58/0xf0
[  484.346624]  async_synchronize_cookie_domain+0xe8/0x150
[  484.347109]  async_synchronize_full+0x20/0x30
[  484.347514]  do_init_module+0x160/0x1f4
[  484.347870]  load_module+0x1cb8/0x2220
[  484.348217]  __do_sys_finit_module+0xac/0x130
[  484.348616]  __arm64_sys_finit_module+0x28/0x34
[  484.349033]  invoke_syscall+0x78/0x100
[  484.349386]  el0_svc_common.constprop.0+0xd4/0xf4
[  484.349820]  do_el0_svc+0x34/0xd0
[  484.350175]  el0_svc+0x34/0xd4
[  484.350473]  el0t_64_sync_handler+0xf4/0x120
[  484.350874]  el0t_64_sync+0x18c/0x190
[  537.599512] nvme nvme0: I/O 11 QID 0 timeout, completion polled

NVME device is WD Red SN700

Please include ”bootefi bootmgr” support into your u-boot build

You already provide most of the things needed to boot other distros, namely binaries for u-boot and dtbs. However, it would be very useful if booting in UEFI mode was supported. This way even unmodified installation media could be used (theoretically). In any case - it is might be preferred to use this standardised boot method then u-boot in many cases (e.g. as far as I can see, NixOS would be much easier to get running this way).

CONFIG_CMD_BOOTEFI=y
CONFIG_EFI_LOADER=y

Thank you for your work! Your work already makes bootstrapping other distros easier.

NVMe Support

HELLO,
Thank you for your port for Nanopi R5!

I encounter a problem with the management of the NVMe which does not seem to detect while it works perfectly with the FriendElec version of Debian Buster.
Is there anything to do?

Thanks in advance

Friendlyelec debian 11

lspci
0000:00:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd Device 3566 (rev 01)
0000:01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
0001:10:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd Device 3566 (rev 01)
0001:11:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
0002:20:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd Device 3566 (rev 01)
0002:21:00.0 Non-Volatile memory controller: Sandisk Corp WD Black SN750 / PC SN730 NVMe SSD

Debian 12 RC4

lspci
0000:00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3568 Remote Signal Processor (rev 01)
0000:01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
0001:00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3568 Remote Signal Processor (rev 01)
0001:01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
0002:00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3568 Remote Signal Processor (rev 01)

Separate partition for the kernel and initramfs

Hello,

First off I'd like to thank you for this project! All other ones I tried for building boot images and rootfs are overly complex or poorly worded/instructed.

After a couple times making successful images I ran into a scenario on the R5S with an NVME disk installed and used in overlayfs mode, so I don't burn out the emmc. When I do an apt upgrade or apt full upgrade the kernel and initramfs files are saved in the /boot folder as expected, except that since the rootfs is in overlay mode the U-boot can only load the kernel and initramfs that was burned on it. I'm suspecting that the SPL can't use overlayfs and doesn't know about the new files.

That said, I propose having the /boot folder in a separate partition with a fat32 filesystem. This is the method that FirendlyElec uses so u-boot and SPL can access the /boot early on to load the kernel. The reason I suggest this instead of booting directly from the NVME disk is so I can use the NVME for data only and have a "factory default" image on the emmc, while still maintaining kernel updates.

I was thinking of a similar structure:

Sector: 0     8192    32768     524288
| IDBLOADER | UBOOT | KERNELFS | ROOTFS |

I tried to disect the partitioning in make_debian.sh, but was unsure how adding the KERNELFS would work.

Thoughts?

U-Boot build error - cant find default configuration

Sorry if this is a beginner mistake but I get this error while trying to build u-boot with your script

root@debian:/home/debian/Desktop/nanopi-r5/uboot# sh make_uboot.sh 
branch: 2023.07
make: Entering directory '/home/debian/Desktop/nanopi-r5/uboot/u-boot'
  CLEAN   scripts/basic
  CLEAN   scripts/kconfig
make: Leaving directory '/home/debian/Desktop/nanopi-r5/uboot/u-boot'

configuring nanopi-r5c
make: Entering directory '/home/debian/Desktop/nanopi-r5/uboot/u-boot'
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  YACC    scripts/kconfig/zconf.tab.c
  LEX     scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
***
*** Can't find default configuration "arch/../configs/nanopi-r5c-rk3568_defconfig"!
***
make[1]: *** [scripts/kconfig/Makefile:96: nanopi-r5c-rk3568_defconfig] Error 1
make: *** [Makefile:576: nanopi-r5c-rk3568_defconfig] Error 2
make: Leaving directory '/home/debian/Desktop/nanopi-r5/uboot/u-boot'
root@debian:/home/debian/Desktop/nanopi-r5/uboot# 

I tried using my M2 Max Mac with Arm64 Debian 12 do do fast compiles. And offer my help in that regard if there's any need

Feedback: flashing over USB works

Hi friend,

I appreciate your work on this R5S Debian image! It works flawlessly so far, I was even able to flash it over USB:

> rkdeveloptool db MiniLoaderAll.bin
Downloading bootloader succeeded.

> rkdeveloptool wl 0x0 nanopi-r5_bookworm-rc3.img
Write LBA from file (100%)

> rkdeveloptool ppt
**********Partition Info(GPT)**********
NO  LBA       Name                
00  00008000  rootfs

> rkdeveloptool rd
Reset Device OK.

It boots fine just as with the other flashing methods in the Readme. This should also work with upgrade_tool I guess, it's supposed to be a precompiled version of rkdeveloptool afaiu.

Good job on boiling the device support down to the essentials, it makes it so much easier for me to try and port this neat little thing to mainline OpenWrt.

Ethernet ports do not work correctly on 2.5GB switch

This implementation of Debian for NanoPi R5C is much better than the stock images. However, when I test the ethernet behavior, I found it works well on Gigabit ethernet switches but not on 2.5G switches. On 2.5G switched network, it always negotiate to 100MB date rate, even though on 1GB switches it achieves 1Gb throughput. From lshw, it appears the NIC installed in the R5C are RTL8125, but the driver used is r8169. I don't know if this is the problem or not, though. Below is the lshw output:

NanoPi-R5C:~$ sudo lshw -C network
*-network
description: Ethernet interface
product: RTL8125 2.5GbE Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0001:01:00.0
logical name: lan0
version: 05
serial: a8:be:fc:be:a0:e8
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=6.1.0-10-arm64 firmware=rtl8125b-2_0.0.2 07/13/20 ip=192.168.2.110 latency=0 link=no multicast=yes port=twisted pair
resources: irq:41 ioport:100000(size=256) memory:f2200000-f220ffff memory:f2210000-f2213fff

Feedback: The bootloader is capable of booting NixOS 23.05 with mainline kernel 6.3.X+

I have been successfully running NixOS on my R5S board using the 1.0 release of the bootloader and the corresponding DTB in UEFI mode for a couple of weeks already (I have tested both GRUB and systemd-boot boot managers - both work just fine). I have /boot on an SD card used as EFI system partition (ESP), as having it on the eMMC did not work for some reason. The bootloader itself is installed on the eMMC, and the dtb file is also loaded from a FAT32 partition on eMMC (the partition is marked for boot, too). The OS and most files are on an NVMe drive (SK Hynix P31 Gold, which I recommend for this board due to high power efficiency. Do use thermal pads anyway, though).

See here for my adventures regarding that.

I should note that the kernel from the NixOS repo does not support PCI, HDMI, and LEDs on this chip with its default configuration, so the kernel needs to be recompiled with some kernel options changed. It is easy to do on NixOS, but it takes a lot of time (12-14 hours) on the board itself - so it is wise to "pin" the kernel packages version and update it from time to time for now. Still, it runs the mainline kernel which is a big win for these boards.

Thus, the main takeaway snippet (I think I should try to upstream some of these kernel configuration options to avoid kernel recompilations):

{ config, pkgs, lib, ... }:

{
  config = lib.mkIf pkgs.stdenv.isAarch64 {
    boot = {
      # partial Rockchip related changes from Debian 12 kernel version 6.1
      # Also, see here:
      # https://discourse.nixos.org/t/how-to-provide-missing-headers-to-a-kernel-build/11422/3
      kernelPatches = [
        {
          name = "rockchip-config.patch";
          patch = null;
          extraConfig = ''
            PCIE_ROCKCHIP_EP y
            PCIE_ROCKCHIP_DW_HOST y
            ROCKCHIP_VOP2 y
          '';
        }
        {
          name = "status-leds.patch";
          patch = null;
          # old:
          # LEDS_TRIGGER_NETDEV y
          extraConfig = ''
            LED_TRIGGER_PHY y
            USB_LED_TRIG y
            LEDS_BRIGHTNESS_HW_CHANGED y
            LEDS_TRIGGER_MTD y
          '';
        }
      ];

      initrd.availableKernelModules = [
        ## Rockhip
        ## Storage
        "sdhci_of_dwcmshc"
        "dw_mmc_rockchip"

        "analogix_dp"
        "io-domain"
        "rockchip_saradc"
        "rockchip_thermal"
        "rockchipdrm"
        "rockchip-rga"
        "pcie_rockchip_host"
        "phy-rockchip-pcie"
        "phy_rockchip_snps_pcie3"
        "phy_rockchip_naneng_combphy"
        "phy_rockchip_inno_usb2"
        "dwmac_rk"
        "dw_wdt"
        "dw_hdmi"
        "dw_hdmi_cec"
        "dw_hdmi_i2s_audio"
        "dw_mipi_dsi"
      ];
    };
    # Most Rockchip CPUs (especcially with hybrid cores) work best with "schedutil"
    powerManagement.cpuFreqGovernor = "schedutil";
  };
}

Bootstrapping the installation required building a custom UEFI install image for me using nixos-generators project (it is easier to do that when u-boot and the DTB file are already on the board's eMMC). You will need the snippet above to build a usable installation image, too.

Another takeaway is to run irqbalance --oneshot on startup to spread interrupts processing between cores, otherwise it is too easy to overwhelm the first core with interrupts, especially on high network interfaces activity (use irqtop for monitoring).

On NixOS this can be achieved using this snippet:

{ config, pkgs, lib, ... }:

{
  config = {
    systemd.services."irqbalance-oneshot" = {
      enable = true;
      description = "Distribute interrupts after boot using \"irqbalance --oneshot\"";
      documentation = [ "man:irqbalance" ];
      wantedBy = [ "sysinit.target" ];
      serviceConfig = {
        Type = "oneshot";
        RemainAfterExit = true;
        ExecStart = "${pkgs.irqbalance.out}/bin/irqbalance --foreground --oneshot";
      };
    };
  };
}

Additionally to the above, I have the following in my configuration (one may, or may not need that depending on the needs):

{ config, pkgs, lib, ... }:

## NanoPi R5S-board specific configuration

# This board can be used with NixOS thanks only to this project:
# https://github.com/inindev/nanopi-r5/
# A lot of information is taken from there

{
  config = lib.mkIf pkgs.stdenv.isAarch64 {
    boot.kernelParams = [
      "console=tty1"
      "console=ttyS2,1500000"
      "earlycon=uart8250,mmio32,0xfe660000"
    ];
    # Let's blacklist the Rockchips RTC module so that the
    # battery-powered HYM8563 (rtc_hym8563 kernel module) will be used
    # by default
    boot.blacklistedKernelModules = [ "rtc_rk808" ];
  };
}

I have been running the device as LXC/libvirt/Docker host for weeks now without any issues. Thank you @inindev for your hard work! You made it possible!

IPv6 is not working after installation

First of all, thanks for your work - it is much appreciated.

I've been trying to wrap my head around why on earth IPv6 is not working like it normally does on all Debian systems. It turns out the kernel cmdline is using ipv6.disable=1.

I didn't find any statement on why this is done, nor that it is done, or how to remove it.

add ESP to boot image?

If you could add a small ESP to the disk image, then it would be possible to use u-boot(efi) => grub/EFI kernel instead of depending on just the u-boot commands for specific kernel images (eg, bootz or booti). Something like this works nicely:

echo 'label: gpt' | sudo sfdisk ${DISK}
echo -e '16M,512M,U\n,+,\n' | sudo sfdisk ${DISK}

Also, thanks for publishing this!

Edit: 512 MB is apparently the minimum recommended ESP size.

NanoPi R5C `wan0` not detected

The rc4 image for the R5C does not detect wan0 on my NanoPi R5C. I suppose the reason is still due to the problem underlying issue #3.

lspci finds only one Ethernet controller at 0001:01:00.0. That is also the only controller that shows up in dmesg. No output about the other controller whatsoever, not in ip a, not in dmesg, not in lspci.

Let me know what I can do to help debug!

cgroup v1 support

Trying to get Home Assistant working on this Debian release I see it complains that cgroup v1 is required.
As far as I understand to switch from v2 back to v1 I'd usually put systemd.unified_cgroup_hierarchy=0 in grub file but this build uses different bootloader (I'm on emmc).
Can you advise how to get cgroup v1 working?

[Q] Install to eMMC

I've read the readme so far and I am wondering how to install to the integrated emmc instead of sd card.
Would this be an option during this step?

when the micro sd has finished imaging, eject and use it to boot the nanopi r5c or r5s to finish setup

Thanks for providing a plain debian and your support!

Boot OpenWRT From NVMe.

Hello, with this bootloader is possible to boot openwrt from nvme? what changes will be necessary any to openwrt image before writing to disk?

Thank you!

Hello @inindev,

I want just to share you how much grateful I am to your work on this repository. I tested a lot of things on the last days (DietPi, ARMbian, all internet and reddit forums) to find the best way to use my NanoPI R5S with a new NVMe. I tested like dozens of setup, from scratch install and images. I found an opened issue on DietPi talking about the fact this hardware isn't able to boot directly to NVMe and so it needs a bootloader to do the job. Your section booting from internal NVMe (r5s only) answers to it PERFECTLY and it the easiest task to do I have seen this week.

Your tutorial and your work are quick, crystal clear and useful!
Thank for your share, I love the open source initiative for this.

Again, thanks!

Failed messages in dmesg

In dmesg I see such a messages, can it be fixed?

# dmesg | egrep -i 'errors|critical|failed'
[    3.201967] arm-scmi firmware:scmi: Failed. SCMI protocol 22 not active.
[    3.230803] arm-scmi firmware:scmi: Failed. SCMI protocol 17 not active.
[    7.907999] pci 0002:00:00.0: BAR 0: failed to assign [mem size 0x40000000]
[    7.909295] pci 0002:00:00.0: BAR 1: failed to assign [mem size 0x40000000]

I join in thanking you for a great job!

kconfig options

Good job so far, your built image is working great but I am wondering if it's possible to add the ability to update kconfig options in your build scripts.

Thank you

Images have /etc/machine-id set.

Hi,

after long searching for why my two nanopi-r5s where generating the same mac addresses for the openvswitch setup, I figured out this was because of the /etc/machine-id being the same for both nanopi-r5s.

Would it be possible to regenerate the machine-id on first boot?

rm -f /etc/machine-id && dbus-uuidgen --ensure=/etc/machine-id

Thank you in advance!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.