Majority of the SBC boards doesn't even have a flash, and those who have, its blank..
So to flash it, you need first an operating system running on it, or very specialized hardware to flash uboot to it..

Majority of people still needs a sd card, as a way, to boot at least the installer, and this is already provided by Devuan.
Devuan has a generic Installer for armhf and also for arm64.

Devuan is using only 1 bootloader, since you cannot escape it( uboot )..

How do you see it as an improvement, loading above the bootloader, a second bootloader( GRUB )?
It doesn't change nothing, for the image point of view, and complicates the process,
In the end you gain nothing from it, only looses..

If EFI were able to provide the kernel with sufficient information, so that the kernel would be able to boot, without uboot,
Then would be a improvement, but since from the beginning you need uboot anyway, I fail to understand what you gain with EFI..

Remember that uboot is the one that objectively needs to be compiled for each board separately..

hello mcc,
For what I see Primary UART is the one to be used by linux
Enable the uart in RaspberryPI config.txt

enable_uart=1

it should appear( after raspberrypi boots up.. ) as /dev/ttyAMA0

Put a login tty on RaspberryPi  in /etc/initab

T0:23:respawn:/sbin/agetty -L ttyAMA0 115200 vt100

Now shutdown your Rpi, and remove Power Supply from it..

UART GPIO Pins:
6 - GND
8 - TX
10 - RX

How to Connect to serial adapter to RaspberryPI uart:

Is very important to connect the pins in a correct way..
You should only connect Ground, TX,RX..

How to connect:
The Board has:
1)GND
2)TX
3)RX

The usb-serial adapter has( at least):
1)GND
2)TX
3)RX

So you connect:
1) Insert usb adapter in your PC computer

2) connect the pins, from rpi with serial adapter
The ground from adapter with ground from the board
The TX from adapter with RX from the board
The RX from adapter with TX from the board

3) Use a serial adapter application like 'picocom', for example, or other and start it, and issue in the PC:
find the usb /dev/serial.device in the pc

ls -ltr /dev/*USB*

Now use the serial device you found in dmesg..

picocom /dev/serial.device -b 115200

4) Only then, you apply power to the SBC board

After this you should see the output in the serial console output in your pc, and later a login tty

hello hoschi,

I believe you should first try with the basic approach, the one in here .

Then if this doesn't work, try the solution that kuleszdl posted changing the boot.scr..
It is indeed a bit pesky, you need to understand the uboot boot process, and its a bit difficult for someone starting..

basically you have a text file called 'boot.cmd', and you need to generate a binary file from that one called 'boot.scr'.
every change that you make to 'boot.cmd' and you need to compile it in binary format 'boot.scr', it will substitute previous 'boot.scr' with the new one..

But I believe you should first go with the default option
So forget for now the 'boot.scr'

The serial connection,
Is very important to connect the pins in a correct way..

You should only connect Ground, TX,RX..

How to connect:
The Board has:
1)GND
2)TX
3)RX

The usb-serial adapter has( at least):
1)GND
2)TX
3)RX

So you conect:
1) Insert adapter in your computer

2)
The ground from adapter with ground from the board
The TX from adapter with RX from the board
The RX from adapter with TX from the board

3) Use a serial adapter application like picocom, for example, or other and start it

4) Only then, you apply power to the SBC board

After this you should see the output in the serial console output, and later a text based installer

hello hoschi,
its well known that at least CubieBoard1 works very well at install time

You can try however to test the changes kuleszdl, proposed..
Have you tried the image here ?
http://deb.devuan.org/devuan/dists/beow … rd-images/

After the zcat process..
You can mount the image with:

apt-get install u-boot-tools
mkdir /mnt/iso
mount -t vfat -o loop,offset=$((2048 * 512)) /path/to/Cubietruck.img /mnt/iso
cd /mnt/iso
# To see the boot.scr code..
strings boot.scr

create a boot.cmd file with the content you want..then generate the new boot.scr with:

mkimage -C none -A arm -T script -d boot.cmd boot.scr
sync
cd /
umount /mnt/iso

then try the changed boot script within  the changed Cubietruck.img..
burn Cubietruck.img to sdcard, and test if you can access, otherwise you will need the adapter..

The problem of install via normal procedure, is that you need display working, and keyboard, and ethernet..
ethernet is the easy part, display is the most difficult one( and sometimes keyboard too )
Because of this factors, we choose the serial install that works always

yeah, if it says 5Mpix, should be a OmniVision ov5647 sensor..

that is the current problem..
if you have loaded the kernel module, and have 128mb for gpu_mem, it should work..

C0rnelious has a optimization:

echo 'SUBSYSTEM=="vchiq",GROUP="video",MODE="0660"' > /etc/udev/rules.d/10-vchiq-permissions.rules
echo 'SUBSYSTEM=="vcio",GROUP="video",MODE="0660"' >> /etc/udev/rules.d/10-vchiq-permissions.rules
echo 'SUBSYSTEM=="vc-mem",GROUP="video",MODE="0660"' >> /etc/udev/rules.d/10-vchiq-permissions.rules

then reboot, and load the module ov5647 again, and test with root user..

the userland code also has test functionalities..
for example:

vcgencmd measure_volts
vcgencmd measure_temp
vcgencmd pm_get_status
mmal_vc_diag stats
mmal_vc_diag camerainfo -- this one is very relevant..
mmal_vc_diag mmal-stats
vchiq_test -p 1
vchiq_test -f 1
vchiq_test -b 10
etc

You can find those commands, and others in '/opt/vc/bin', check if the camera cable if attached in the correct way..
also you can find in '/opt/vc/src/hello_pi', a full set of examples and testing apps.. to build them all you just need to issue:

apt-get install libfreetype6-dev
chmod +x /opt/vc/src/hello_pi/rebuild.sh
cd /opt/vc/src/hello_pi
./rebuild.sh

from those , I was only able to run:
/opt/vc/src/hello_pi/hello_world/hello_world.bin

but I am also waiting for the camera

hello alphalpha,
you need to load the kernel module for your camera to work..

Just try first with the V1, to test
It can be that you have yet another sensor.. its important to know, what sensor you have so that we can load the respective kernel module..
imx -Sony sensors
ov  - OmniVision Sensors

Do this, to load 3 different sensors, you will see errors on kernel modules it doesn't have, but no problem..it will load what it have..

modprobe ov5647;modprobe imx219;modprobe imx477

Raspberry Pi delivered 3 different cameras.
v1 - with 5Mpix CMOS ov5647 sensor
v2 - with 8Mpix CMOS imx219 sensor
v3 - with 12.3Mpix CMOS imx477( there are not yet support for this high Quality camera in mainline kernel..)

I am about to release a version with the kernel module imx219( V2 camera.. )

to use raspistill, you just need to do a basic test:

raspistill -o test.jpg

I have also ordered a camera, its a v1 version, and its s clone with  ov5647 sensor, but its in the mail, I am still waiting for it..

can you share your dmesg, ( maybe we could sort that out from there..) ?

EDIT:
I forgot to tell you that you also need the raspberrypi userland:

cd /root
apt-get install g++ cmake
git clone https://github.com/raspberrypi/userland.git
cd userland
./buildme --native
cd /root
rm -rf userland

the code will land in '/opt/vc',
You need to update your path and also the Dynamic linker..

# Update PATH
echo "export PATH="/opt/vc/bin":${PATH}" /root/.bashrc
# Update Dynamic Linker paths
echo "/opt/vc/lib" >> /etc/ld.so.conf
ldconfig -vv

then logout of root, and login again..
done

You seem to be right, vaapi maybe its not used for raspberrypi.
They refer instead mmal

I also found a thread in videolan forums that say that rpi doesn't use vaapi..

For what I saw v3.0.3 was the version they were speaking of in the forum.. and complaining because debian updated to v3.0.6

hello joril,

I don't own a rpi4, but the generic build of VLC for arm64 will not bring hardware acceleration with it for rpi, or any other board, it depends always in libraries that are related with that board/SoC.. in the arm world each vendor implements things in a different way, so they are not compatible

Kodi, and Raspbian( and maybe others), offers prebuild libraries and also hardware acceleration( but because they had built it specifically for that hardware.. ).
I don't know the level of acceleration support that we can get with VLC, or others, but I believe at least x264 is possible to some extent, maybe some stuff is yet done in the CPU, but it should play reasonably well..

I believe the solution could be to build VLC yourself, with raspberrypi userland libraries..

1) Start by building the userland libraries for RPI:

git clone https://github.com/raspberrypi/userland.git
cd userland
/buildme --native

The libraries/headers should land in:  '/opt/vc'

2) Update the dynamic linker..

echo "/opt/vc/lib" >> /etc/ld.so.conf
ldconfig -vv

3) Then build VLC or FFmpeg with support for RPi( will take advantage of the RaspberryPi userspace Libraries built above.. ):

a) Build VLC..
VLC has lots of dependencies,
So I just searched for RPI Build, and this tutorial is from 2017, its better to get the last VLC source code, to build..

On those cflags/cxxflags , you can compile for '-mcpu=cortex-a72'( rpi4 ), or if compiling for a generic arm64 '-mcpu=cortex-a53', the binary will work on rpi3 and rpi4 in this last case..

b) You can also build ffmpeg, for players that use it..
I found this tutorial .

One possible improvement would be to package it and put it in the repos, the userspace libraries for RPi, and the VLC package..
hope it helps
tux

Tests done with version 0.2 of the Devuan Image( iperf3 )
This includes the new driver for the lan nic 8153b( rtl8152 v2.14.0 - 2020.09 ):
This tests were conducted with the default Window Congestion algo 'reno', the 'cubic' algo in long periods of time, provokes resets of the Lan interface( so it was not tested bellow )..

with 'ondemand' governor:

---=== LAN ===---
Under 100% cpu load( cpu 100% occupied ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on lan( usb rlt8153b ) - [ 839Mbit/s, 839Mbit/s ]
Under 0% cpu load( cpu idle ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on lan( usb rlt8153b ) - [ 845Mbit/s, 845Mbit/s ]

---=== WAN ===---
Under 100% cpu load( cpu 100% occupied ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on wan( usb rlt8211e ) - [ 690Mbit/s, 690Mbit/s ]
Under 0% cpu load( cpu idle ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on wan( usb rlt8211e ) - [ 862Mbit/s, 862Mbit/s ]

Peaks of around ~920Mbit/s were observed sometimes..

with 'performance' governor:

---=== LAN ===---
Under 100% cpu load( cpu 100% occupied ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on lan( usb rlt8153b ) - [ 846Mbit/s, 846Mbit/s ]
Under 0% cpu load( cpu idle ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on lan( usb rlt8153b ) - [ 841Mbit/s, 841Mbit/s ]

---=== WAN ===---
Under 100% cpu load( cpu 100% occupied ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on wan( rlt8211e ) - [ 687Mbit/s, 687Mbit/s ]
Under 0% cpu load( cpu idle ), during 1000 seconds
tcp -> nano-pi r2s [ in, out ] on wan( rlt8211e ) - [ 920Mbit/s, 920Mbit/s ]

Peaks of around ~922Mbit/s were observed sometimes..

NOTA!
This values may vary a bit, depending on the load you have in the nanoPi R2S, and also on the temperature..

The tests were done in both extremes( no load -idle, or 100% load -all 4 cores saturated ), using ondemand/performance governor..
There are still a problem to solve in interface lan, which uses a usb-to-ethernet rlt8153b, and depends on USB 3.0 rk3328 driver..

The r8153b driver was updated with the last official driver( v2.14.0 ), and made a lot of improvements.. but still from time to time it resets the interface, we mitigated the problem by resetting to the same macaddress..

hello  cafinux,
you can grab the image here

EDIT: there are several partitions because it is using a shceme of GPT partitions and so to make a small image was impossible, since the backup partition table is mirrored at the end of the sdcard, obligating you to do a large image..

So we make several images that you can dd to the correct places to form the final image..in that way we make a "small image"
The next image for that board, will have a traditional msdos partition scheme ignoring the 3 bootloader partitions and so will be all info in same image

If you have any doubts, just ask

hello Dave,
yes the sources.list should point to:

http://deb.devuan.org/merged

Is also good to update the ntp, sometimes it won't work without it
if you have 'ntpdate' installed:

ntpdate server_ip

If you have 'ntp', then

ntpq -p

should do the trick

well, you are right, the image should be updated to beowulf( and with that, the sources.list ).

Hello alphalpha,
I have tried several times do download the iso image, unsuccessfully.
The download terminated after some 50-100mb downloaded..