Jump to content

NanoPi R5S Armbian Image

Peter Scargill

By Peter Scargill
in Rockchip

 Share

Recommended Posts

maxmatteo

maxmatteo

Posted
Posted

ubuntu focal from vendor:

 

base system: 

root@FriendlyELEC:~# ./inxi -F
System:
  Host: FriendlyELEC Kernel: 5.10.66 arch: aarch64 bits: 64 Console: pty pts/0
    Distro: Ubuntu 20.04.1 LTS (Focal Fossa)
Machine:
  Type: ARM System: FriendlyElec NanoPi R5S details: N/A serial: fbaa4320f846b9b1
Battery:
  ID-1: test_battery charge: 100% condition: N/A
CPU:
  Info: quad core model: N/A variant: cortex-a55 bits: 64 type: MCP
  Speed (MHz): avg: 408 min/max: 408/1992 cores: 1: 408 2: 408 3: 408 4: 408
Graphics:
  Device-1: display-subsystem driver: rockchip_drm v: N/A
  Device-2: mali-bifrost driver: mali v: N/A
  Device-3: rk3568-dw-hdmi driver: dwhdmi_rockchip v: N/A
  Display: server: X.org v: 1.20.8 driver: N/A note:  X driver n/a tty: 255x54
  Message: Unable to show GL data. Required tool glxinfo missing.
Audio:
  Device-1: rk3568-dw-hdmi driver: dwhdmi_rockchip
  Device-2: simple-audio-card driver: asoc_simple_card
  Device-3: simple-audio-card driver: N/A
  Device-4: simple-audio-card driver: asoc_simple_card
  Sound Server-1: ALSA v: k5.10.66 running: yes
Network:
  Device-1: Realtek RTL8125 2.5GbE driver: r8125
  IF: eth1 state: down mac: 52:21:96:d1:s2:59
  Device-2: Realtek RTL8125 2.5GbE driver: r8125
  IF: eth1 state: down mac: 52:21:96:f5:c1:59
  Device-3: rk3568-gmac driver: rk_gmac_dwmac
  IF: eth0 state: up speed: 1000 Mbps duplex: full mac: 4e:27:96:d1:c1:59
  Device-4: Realtek 802.11ac NIC type: USB driver: N/A
  IF-ID-1: eth2 state: down mac: d6:66:ff:20:da:50
Drives:
  Local Storage: total: 938.79 GiB used: 0 KiB (0.0%)
  ID-1: /dev/mmcblk2 model: 8GTF4R size: 7.28 GiB
  ID-2: /dev/nvme0n1 vendor: Crucial model: CT1000P2SSD8 size: 931.51 GiB
Partition:
  Message: No partition data found.
Swap:
  Alert: No swap data was found.
Sensors:
  Missing: Required tool sensors not installed. Check --recommends
Info:
  Processes: 135 Uptime: 36m Memory: 1.91 GiB used: 386.6 MiB (19.7%) Init: systemd Shell: Bash
  inxi: 3.3.19

partition: 

root@FriendlyELEC:~# parted /dev/mmcblk2  print
Model: MMC 8GTF4R (sd/mmc)
Disk /dev/mmcblk2: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name      Flags
 1      8389kB  12.6MB  4194kB               uboot
 2      12.6MB  16.8MB  4194kB               misc
 3      16.8MB  21.0MB  4194kB               dtbo
 4      21.0MB  37.7MB  16.8MB               resource
 5      37.7MB  79.7MB  41.9MB               kernel
 6      79.7MB  113MB   33.6MB               boot
 7      113MB   147MB   33.6MB               recovery
 8      147MB   2487MB  2340MB  ext4         rootfs
 9      2487MB  7818MB  5331MB  ext4         userdata

 

dmesg:

  Reveal hidden contents

 

0
nicklasfrahm

nicklasfrahm

Posted
Posted (edited)

I have an R5S, how would I create a new board configuration? I noticed that there is currently no bootconfig in the upstream u-boot repository. Would that be an issue?

 

I read through some of the developer documentation, but I can't find a section that explains how to go about adding support for a new board.

I have some familiarity with compilers and the likes, but I have never built a kernel or OS images by myself. I would however love to contribute.

Edited by nicklasfrahm
1
Werner

Werner

Posted
Posted
  On 7/16/2022 at 7:29 AM, nicklasfrahm said:

I read through some of the developer documentation, but I can't find a section that explains how to go about adding support for a new board.

Expand  

Yeah that is one of the sections that are still missing and nobody took the challenge yet to make a write-up. However you can dig through old PRs that added support for a board to get an idea where things got added or adjusted.

Examples:

https://github.com/armbian/build/pull/3628

https://github.com/armbian/build/pull/3770

1
tekrantz

tekrantz

Posted
Posted (edited)

Just wondering if I could rip the uboot from one of the nanopi r5s BSP images and overwrite that section of the quartz64 armbian images if it might boot?

 

If it is worth a chance, what would the dd command be to rip the uboot off of the BSP image?  what offset and length?

 

oh and I would have to grab the BSP device tree as well

Edited by tekrantz
0
Werner

Werner

Posted
Posted
  On 9/11/2022 at 6:24 PM, tekrantz said:

could rip the uboot from one of the nanopi r5s BSP images

Expand  

If you follow that way you could rip kernel package as well. That way the first working images for OPi Zero 2 were made. However Armbian does not want or like to do that since then you could basically directly use vendor provided images.https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one

 

At the bottom line it all depends on the development for the SoC or family which in this case is rk35xx. If that grows adding support for different boards that are built around that SoC is easy in comparison but that also depends on having a person that knows how to do that and want to donate their precious time doing so. Both aren't easy to find ;).

 

1
c0rnelius

c0rnelius

Posted
Posted

I think I can help here as I'm already working on this off and on. The problem I have is I don't own the hardware, so I'm not going to be submitting any thing to Armbian. But so far "as I'm told by the tester" I have the board booting and everything working except the m.2 and eth leds. Those two bits are a WIP and I'm currently waiting for the tester to get back from holiday so he can see if its working now.

 

As for submitting the work to Armbian. I'd be happy to point whom ever to what I've done so far and help where I can.

1
c0rnelius

c0rnelius

Posted
Posted

Vendor u-boot needs to be purged from the eMMC: https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R5S#The_Boot_order_between_eMMC_and_SD_card

I drop test imgs and kernels here: https://github.com/pyavitz/binary/releases/tag/images

 

What was last reported;

5.19.3-2022-08-22 boots but no m.2, nor proper eth led functions.

5.19.6 I was told it booted, but then upon powering down the device it wouldn't come back. No other info given.

Only change between 5.19.3 and 5.19.6 was a defconfig adjustment.

 

Not tested;

5.19.8-2022-09-10 pin-ctrl added in hopes it brings up the m.2 and a custom led patch for the eth ports.

 

Can open an issue there or find me on IRC / Discord.

1
9bx154

9bx154

Posted
Posted
  On 9/13/2022 at 12:16 PM, Cornelius said:

...custom led patch for the eth ports.

Expand  

Maybe it will help with leds if add such a file, for example /etc/udev/rules.d/nanopi-r5s-led.rules: 

SUBSYSTEM=="leds", KERNEL=="green:wan", ACTION=="add", ATTR{trigger}="netdev", ATTR{device_name}="eth2", ATTR{link}="1" ATTR{rx}="1" ATTR{tx}="1"
SUBSYSTEM=="leds", KERNEL=="green:lan1", ACTION=="add", ATTR{trigger}="netdev", ATTR{device_name}="eth0", ATTR{link}="1" ATTR{rx}="1" ATTR{tx}="1"
SUBSYSTEM=="leds", KERNEL=="green:lan2", ACTION=="add", ATTR{trigger}="netdev", ATTR{device_name}="eth1", ATTR{link}="1" ATTR{rx}="1" ATTR{tx}="1"

 

0
9bx154

9bx154

Posted
Posted

Found that BBR congestion control (TCP_CONG_BBR) is not enabled in kernel (Linux r5s 5.19.11 #3 SMP Mon Sep 26 11:14:54 EDT 2022 aarch64 GNU/Linux), it is possible to enable this feature.

  

root@r5s:~# sysctl net.core.default_qdisc=fq
sysctl: setting key "net.core.default_qdisc": No such file or directory

root@r5s:~# sysctl net.ipv4.tcp_congestion_control=bbr
sysctl: setting key "net.ipv4.tcp_congestion_control": No such file or directory

 

0
Dysmas

Dysmas

Posted
Posted (edited)

@Cornelius I used your last image and loaded it to emmc. It starts fine, but I don't know the login and password to use.

To load to emmc, I had to uncompress the xz file. I recompressed with gz (but this step is not necessary). Then I copied the file to a microSD card which contains their eflasher. Then install was fine.

Edited by Dysmas
add name
0
9bx154

9bx154

Posted
Posted (edited)

Cornelius, thanks!

#4 succeeded only 50%, needs to be tweaked in the kernel NET_SCH_FQ_CODEL and NET_SCH_FQ options... 

root@r5s:~# uname -a
Linux r5s 5.19.11 #4 SMP Mon Sep 26 17:57:58 EDT 2022 aarch64 GNU/Linux
root@r5s:~# sysctl net.core.default_qdisc=fq
sysctl: setting key "net.core.default_qdisc": No such file or directory
root@r5s:~# sysctl net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_congestion_control = bbr

 

Found problem with creating a bonding interface: 

root@r5s:~# modprobe bonding
modprobe: FATAL: Module bonding not found in directory /lib/modules/5.19.11

 

Edited by 9bx154
0
Dysmas

Dysmas

Posted
Posted (edited)

Thanks for the login. Everything is working fine until now, thank you.

 

I found only a problem : the order of eth0, eth1, eth2 is strange. In the Linux (Ubuntu 20) given by Friendly Elec, the order is :

eth0 = WAN  (right)

eth1 = LAN1  (middle)

eth2 = LAN2  (left)

 

In the Armbian tested we have :

eth0 = LAN1 (middle)

eth1 = LAN2 (left)

eth2 = WAN (right)

 

this creates some confusion, because the order of ports from right to left (R5S box is designed like that) is eth2, eth0, eth1. 

 

The choice of the constructor was better.

Edited by Dysmas
0
Dysmas

Dysmas

Posted
Posted (edited)

OK thanks.

I hope I put the issues in the right place, because I was not sure of the meaning of :

defconfig ->  rockchip64-rk356x_defconfig

Just for information of the reader, two other issues are for keyboard configuration, and start on microSD card.

Edited by Dysmas
0
Dysmas

Dysmas

Posted
Posted

I have another problem which is not a bug, so probably its place is here.

Friendly Elec offers a very useful eflasher utility, with a one click backup. This utility requires that the system starts on the SD card, and the emmc is available. Unfortunately, due to the slightly strange way boot order is handled on this machine, this seems no longer possible.

https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R5S#The_Boot_order_between_eMMC_and_SD_card

As far as I understand, when Armbian is loaded on the eMMC, we are in the situation where the eMMC has an Image with Mainline U-boot. And in this case, whatever is present on the SD card, boot is always done on the eMMC.

Method 1 does not give any result, because the file created is trashed on reboot.

Method 2 (MaskROM) masks the eMMC, which makes impossible the backup of the eMMC, or the loading of a new image, with this utility.

 

If I understand well the table, the only way to overcome this problem would be to make the image recognized as a FriendlyElec image. I have no idea if it is possible and how.

 

 

 

 

0
balbes150

balbes150

Posted
Posted
  On 9/27/2022 at 1:53 PM, Dysmas said:

Friendly Elec offers a very useful eflasher utility, with a one click backup.

Expand  

I am interested to look at this utility (is it a copy of our DDBR utility, which they give out for their development). As part of Armbian, the DDBR utility has been used for a long time, which performs the creation of a full backup (and recovery) of the entire eMMC "as is".

0
Dysmas

Dysmas

Posted
Posted

It is quite similar to what you say.

The images for the R5S are present here:

https://drive.google.com/drive/folders/1l6wnh_eXG-udXZC1C7G0-e4V6PEVdY_L

In the subdirectory 02_SD-to-emmc images, the images contain the eflasher. You have also the code separatly somewhere, I do not remember where.

On a card which has this utility, it is possible to make a backup "as is" of the full emmc. It is also possible to put different images, raw or gz, and they can be loaded to the emmc.
Small defect of this utility : it does not compress the backup.
You will not be able to use it on a different machine without modifying it, I think, because it is designed for the R5S.

0
Dysmas

Dysmas

Posted
Posted

Progress : I found the reason for which method 1 was not working.  The wiki says :

dd if=/dev/zero of=/dev/mmcblk2 bs=8M count=1

because in FriendlyElec images, the eMMC is mmcblk2.

But in Armbian there is no mmcblk2, and the eMMC is mmcblk1.

I corrected the command :

dd if=/dev/zero of=/dev/mmcblk1 bs=8M count=1

 

And then the Nanopi booted on the SD card, with the eMMC available.
And so I could load an image on the eMMC.

 

This makes things more complex, but at least it works.

0

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

ร—   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

ร—   Your link has been automatically embedded.   Display as a link instead

ร—   Your previous content has been restored.   Clear editor

ร—   You cannot paste images directly. Upload or insert images from URL.

ร—
 Share
Go to topic listing
ร—
ร—
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept