Orange Pi R1 Plus (Orange Pi R1+) support?

[JonatasPrust]

On 5/11/2021 at 3:58 AM, Vasco said:

Thank you for bringing support to this board. I tried latest image (Buster and Focal) and couldn't boot.

 

It always ends up with:

 

Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  UUID=e5dd5e3a-06ae-43df-964d-5e3c5dc07a7f does not exist.  Dropping to a shell!
(initramfs)

 

Here is the full boot sequence (2 boots):

https://pastebin.com/CNssk1uG

 

Tried with 3 differentt Sandisk Ultra and also with Etcher (Linux and Windows) and Rufus.

 

Anything else I could try?

 

Thanks

 

Same problem with the image "Suitable for Testing - OrangePI R1 PLUS", then i used a image of "RockPI E", and have booted on UART0. But i dont have suficient knowledge on linux to help on development.

Is there any forecast to have a stable version for this card?

Thanks

 

[Vasco]

Well it's not of my concern anymore. I gave it away. Wouldn't want to burden devs with my problems with it.

[Igor]

7 hours ago, JonatasPrust said:

But i dont have suficient knowledge on linux to help on development.

We need many different profiles of people to run this project and just about any help, help on development. Since in other case developers have to fix web pages, developers have to run projects, developers have to seek for money, developers have to maintain servers, developers have to maintain forum, developers have to moderate forums, developers have to maintain infrastructure, developers have to maintain relations with partners, developers have to waste time on repeated support question, developers have to deal with "customers", ...

 

7 hours ago, JonatasPrust said:

Is there any forecast to have a stable version for this card?

This is amateur supported development so this information can't be provided. We don't know when things will become stable - that is the most expensive part. If we stop with development, we only gain - I would say you should do something about.

[atomic77]

I recently got my hands on an R1+ and was able to get it booted with a RockPi-E buster image, though I get the same error when I try to use any of the orangepi-r1plus images.

 

Since I have the hardware, I'd be open to making the needed changes to get this particular board to work in a PR to the armbian/build repo. Can anyone give me any pointers to what might need to change in the orangepi-r1plus image to get there?

[Igor]

13 hours ago, atomic77 said:

Can anyone give me any pointers to what might need to change in the orangepi-r1plus image to get there?

I think we have to get rid of our Nanopi R2S patch since I would assume mainline version is just fine and cleaned out. Then adjusting R1 related commits accordingly. Also one quick look into u-boot if upstream version is good enough to boot the board properly and remove patches there too.

And it should work.

 

https://armbian.atlassian.net/browse/AR-573

[atomic77]

I finally had some time this weekend to dig into this. It's my first exposure to the armbian kernel build process and device tree files, so please forgive any stupid questions! I made a first attempt at the changes on my github fork.

 

I was not able to get the kernel built if I completely removed the nanopi-r2s patch as there was some extra dependencies on rockchip-ddr.h. So I started by removing the rev00/rev20 DTS files that seemed to conflict with the mainline, and tried to find any references to the old files and change them.

 

What isn't clear to me is should I be also rewriting the u-boot patch files based on the upstream kernel version as well ? Are those copied completely from the source tree?

 

When I try to boot, I get an error - is there a way I can get more details on what has gone wrong?

 

Spoiler

Found U-Boot script /boot/boot.scr
3185 bytes read in 6 ms (517.6 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1
132 bytes read in 4 ms (32.2 KiB/s)
12006837 bytes read in 526 ms (21.8 MiB/s)
28779008 bytes read in 1252 ms (21.9 MiB/s)
Failed to load '/boot/dtb/rockchip/rk3328-orangepi-r1-plus.dtb'
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!

 

 

I hope I'm not too far off course with my changes, any help is appreciated!

[Igor]

1 hour ago, atomic77 said:

any help is appreciated!

I can only give you one hint at this stage. Kernel 5.14.y is coming (WIP, not finished yet) with improved support for Nanopi R2S. I would propose to start from there. It is too troublesome to back port to 5.10.y We can ship EDGE (5.14.y) variant only.

 

1 hour ago, atomic77 said:

What isn't clear to me is should I be also rewriting the

Of course. If not else, this for sure.

[atomic77]

I tried a build of 5.14 and made a couple of adjustments in u-boot-rockchip64-edge/add-board-orangepi-r1plus to include the rk3328-nanopi-r2s.dtb file instead of the rk3328-nanopi-r2-rev00.dtb, but the board doesn't come up and has the same issue reported originally:

 

Spoiler

U-Boot 2020.10-armbian (Sep 12 2021 - 16:36:11 +0000)

 

Model: Xunlong Orange Pi R1 Plus
DRAM:  1022 MiB
PMIC:  RK8050 (on=0x40, off=0x00)
MMC:   mmc@ff500000: 1
Loading Environment from MMC... MMC Device 0 not found
*** Warning - No MMC card found, using default environment

In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Model: Xunlong Orange Pi R1 Plus
Net:   eth0: ethernet@ff540000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
3185 bytes read in 5 ms (622.1 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1
177 bytes read in 4 ms (43 KiB/s)
11093764 bytes read in 485 ms (21.8 MiB/s)
29071872 bytes read in 1264 ms (21.9 MiB/s)
52137 bytes read in 9 ms (5.5 MiB/s)
2698 bytes read in 8 ms (329.1 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
Moving Image from 0x2080000 to 0x2200000, end=3e50000
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    11093700 Bytes = 10.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to 3d499000, end 3df2d6c4 ... OK
   Loading Device Tree to 000000003d423000, end 000000003d498fff ... OK

Starting kernel ...

Loading, please wait...
Starting version 241
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)

 

What I don't quite get is why nanopi r2s is the basis for the r1 plus image, though the device tree seems to be quite different from the rock pi e, which seems to work pretty well without any adjustments at all?

 

 

[bemapiu86]

i just install debian , ubuntu and armbian , but i cannot install remote desktop for any os . I try vnc,TigerVNC.....

 

Anyone know how to remote from win10 to orange pi r1 plus ?

Please show me.

 

Thank so much