The officially official Devuan Forum!

You are not logged in.

#1 Re: ARM Builds » sshd via wlan0 only if ethernet cable is plugged - otherwise no sshd » Today 02:12:57

When a service starts listening on 0.0.0.0, it will listen on available ips,at that time,
If something come up after that, it will not listen on it.. and for the service to listen on then, a reload of the service is required..

This usually happens when you start a network service, and later plug-in a Ethernet cable,
In this case, you will need to reload the network service so that it can listen on the new ip address that you connected later..

Since probably you are listening on 0.0.0.0, this could be the case, in your case you are listening on 127.0.0.1 only( because wlan0 doesn't come up yet.. by some reason..).
You should configure wlan on /etc/network/interfaces

Also test it! smile
connect a serial adapter, login via serial( without any Ethernet cable connected.. only wireless! )
Ensure that ssh is listening on 0.0.0.0..
Take some time until wlan0 comes up for sure.., and then issue:

nc -nzv -w 1 wlan0.ip 22
nc -nzv -w 1 127.0.0.1 22

If you get sshd open on wlan0.ip,
This means that when sshd cames up, you already had wlan0 configured, and so, you don't have this problem I am speaking of..
And probably you have problems related with what fsmithred, ralph.ronnquist, told above.. smile

If only 127.0.0.1:22 is open, then sshd started before you had wlan0 fully up..

#2 Re: ARM Builds » armhf not possible on cubietruck » 2021-01-25 00:50:43

hello hoschi,

hoschi wrote:

Thanks for all the input !
I tried to mount the written flash card and alter boot.scr
The truck booted up und continously tried to boot from network.
But i changed converted the boot.cfg right on the mounted SD card.
This may have been not the right war, because it didn't work.
After some attempts i did quit this.

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 smile
So forget for now the 'boot.scr' wink

hoschi wrote:

Instead i opened the usb <-> uart adapter envelope and installed it this afternoon.

The information about using the right connectors came from here:
https://andre.blaatschaap.be/2013/01/cu … onnection/

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 smile

#3 Re: ARM Builds » VLC and HVEC/x265 on the Raspberry Pi 4 with arm64 » 2021-01-21 21:09:18

joril wrote:

I've tried following the path "32-bit Devuan + vlc from Raspbian", but still no luck sad h264 works but only in full screen, h265 doesn't work at all... It throws errors about "CMA buf pool alloc buf failed" so I've tried fidgeting with the "cma=" parameter on cmdline.txt, but to no avail.

hello joril,
yeah it shouldn't be easy indeed.. sad

While the kernel space indeed as seen tremendous advances,
The userspace is still lacking and it still depends on manual builds/hacks and such.. sad

What are the mount of MB you added to the Contiguous Memory Allocator( cma )?
it should need at least 256MB,
I would, as a precaution, add 'cma=384M', its a kernel parameter usually set in the bootargs..

At least some people around ARM is using 384MB( but I believe its for different userpace tools..by other words different hardware, but its a nice consensus value for any device.. ), anyway it deserves a shot.. smile

I don't hold my breath on it, because probably it won't work, but one needs at least to try..

#4 Re: ARM Builds » armhf not possible on cubietruck » 2021-01-07 18:40:45

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

You can try however to test the changes kuleszdl, proposed..
Have you tried the image here ? smile
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.. smile
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 ) sad
Because of this factors, we choose the serial install that works always wink

#5 Re: ARM Builds » armhf not possible on cubietruck » 2021-01-06 09:49:33

hoschi wrote:

Moin,

I've read somewhere that a USB hub in between could possibly make a difference,
but it didn't. sad

Hello,
In the README section, in the end, the method specified to install is via serial connection..
Using a usb-to-serial converter, exactly because it prevents that problem with displays wink

#6 Re: ARM Builds » Raspberry Camera raspistill/raspivid » 2021-01-05 17:01:46

alphalpha wrote:

i guess the ov5647 worked

that might be what i have here too, but im not 100 percent shure
all i can say it that it says 5MP Camera on the box and it does not look like an original

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

alphalpha wrote:
raspistill -o test.jpg
mmal: mmal_vc_shm_init: could not initialize vc shared memory service
mmal: mmal_vc_component_create: failed to initialise shm for 'vc.camera_info' (7:EIO)
mmal: mmal_component_create_core: could not create component 'vc.camera_info' (7)
mmal: Failed to create camera_info component

not shure what thas means

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 sad

#7 Re: ARM Builds » VLC and HVEC/x265 on the Raspberry Pi 4 with arm64 » 2021-01-02 23:04:12

joril wrote:
tuxd3v wrote:

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

I've tried compiling 3.0.3 too (had to add --disable-wayland and patch a line inside the x264 codec) but still no h265 acceleration sad
Maybe I could try building a 32bit image of Beowulf and use the vlc debs from Raspbian...?

You can build the binaries for 32 bits( like the instructions say ), if it fails,
C0rnelious has images for 64 bits

Devuan image builder - https://github.com/pyavitz/rpi-img-builder/tree/devuan
You can find sample images under release - https://github.com/pyavitz/rpi-img-builder/releases

As far as I know all the usual suspects work. HDMI, Audio, Bluetooth, Wifi, Eth... etc.

If you find any bugs or have a request than open an issue at the hub.

Now supports - BCM2711, 2710, 2708.

You can give them a try..

if its not possible, then see all dependencies that raspbian has for vlc, and get those files from there smile

#8 Re: ARM Builds » Raspberry Camera raspistill/raspivid » 2021-01-02 22:53:20

alphalpha wrote:

yes i used the right connector and had that gpu_mem=128 and also start_x=1 in /boot/config.txt
not sure what sensor i have, cant find any information on this

i was trying to get this working https://elinux.org/RPi-Cam-Web-Interface , it uses mjpeg

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

Just try first with the V1, to test wink
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.. sad

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

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 smile

#9 Re: ARM Builds » Raspberry Camera raspistill/raspivid » 2021-01-01 16:00:52

hello alphalpha,
You sure you connected the camera do CSI interface( closer to hdmi output )?

You need in the config.txt, gpu memory at least:

gpu_mem=128

Then restart..

You can see more about it in camera

Are you using libcamera?

What is the sensor you are using?
imx214    - will be built in next release
imx219    - will be built in next release
ov5647    - built in the kernel
imx477    - This one is not present in the kernel 5.10.x sad
OV7640  - built in the kernel
MT9V011- built in the kernel

#10 Re: ARM Builds » VLC and HVEC/x265 on the Raspberry Pi 4 with arm64 » 2020-12-30 22:47:45

joril wrote:
tuxd3v wrote:

That could be a problem, because VA API is the one responsible to get acceleration in VLC sad

Ouch X-) I disabled it because compilation was complaining about missing "EGL_LINUX_DRM_FOURCC_EXT" and other constants, and here https://www.raspberrypi.org/forums/view … 5#p1396812 someone said "You shouldn't need vaapi - that's an Intel API."
--disable-wayland didn't solve the issue

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

#11 Re: ARM Builds » VLC and HVEC/x265 on the Raspberry Pi 4 with arm64 » 2020-12-29 17:01:05

joril wrote:

I had to fiddle a bit with the "configure" invocation (remove -mfpu=neon-vfpv4 and -mfloat-abi=hard, add --disable-libva) to get it to compile... Sadly, still no HVEC acceleration sad

That could be a problem, because VA API is the one responsible to get acceleration in VLC sad

I don't know what extensions has the rpi4:
cat you check the cpuinfo

grep Features /proc/cpuinfo

maybe the compiler doesn't like this combination for arm64..
-mfpu=neon-vfpv4 - is armv7 related
-mfloat-abi=hard   - this one I think its arch agnostic,  i don't get why it gives error, maybe compiling for armv8, already implies hard-float.. but even so..

This options are very standard for armv8..
-march=armv8-a+simd+crc
-mtune=cortex-a53

One thing that maybe can create problems..
The compiled VLC, should use the same specs as the the libraries compiled in rpi userland..
or maybe the VLC code you downloaded require latest versions of some library that are not present in beowulf yet.. try getting a less recent version and see if it compiles without errors with va-api

#12 Re: ARM Builds » VLC and HVEC/x265 on the Raspberry Pi 4 with arm64 » 2020-12-29 00:29:01

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 sad

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 smile
tux

#13 Re: ARM Builds » [ ARM64 ] Build for nanoPI R2S » 2020-12-11 00:14:16

5) - Problems and testings to be done..

b) - Testing is needed, to check if interfaces maintain themselfs with same names, between reboots.
      Tests have being made, and the interfaces seems fixed with:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8152", KERNEL=="eth*", NAME="lan"
SUBSYSTEM=="net", KERNEL=="eth*", ATTR{ifindex}=="2", NAME="wan"

#14 Re: ARM Builds » [ ARM64 ] Build for nanoPI R2S » 2020-12-06 17:12:03

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..

#15 Re: Devuan Derivatives » Michaels Devuan Edition *Update* » 2020-12-05 20:25:45

alphalpha wrote:

i still have not figured out why the download is not working sometimes,
maybe i should upload somewhere else, but at the moment i am not sure where
i wish i had fast internet so i could just seed a torrent all the time

yeah,
I still haven't succeed to download the 12 image.. sad
I have being retrying, eventually I will succeed..

probably they limit the size possible to download to 100-120mb... the image has more than 2 GB big_smile

#16 Re: ARM Builds » [ ARM64 ] build, for Pine64 RockPro64 » 2020-12-05 20:18:05

hello  cafinux,
you can grab the image here smile

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" smile
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 smile

If you have any doubts, just ask wink

#17 Re: Devuan Derivatives » Michaels Devuan Edition *Update* » 2020-12-04 03:45:50

hello alphalpha,
I downloaded the iso, tested it, and its awesome!
I tested the 11 version..

the initial menu is very nice,
The way you created grouping and theming things up is fantastic man..

I which there was a live media installable and with some 600-700mb size..
Amazing work!

Now I am trying to download the 12 in browser, and I receive: "503 Service Unavailable"

EDIT: Wait.. a F5 tried again and its downloading smile

#18 Re: ARM Builds » Raspberry Pi ASCII install issue. (pkgmaster) » 2020-12-01 06:16:40

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 sad
if you have 'ntpdate' installed:

ntpdate server_ip

If you have 'ntp', then

ntpq -p

should do the trick smile

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

#19 Re: ARM Builds » Edev1 Devuan Builder » 2020-11-28 18:06:00

Hello all,
Adding support for 1 board more, to edev1.
nanoPI R2S - mini router

next board, will probably be nanoPi Fire3( a octacore cortex-A53 ).

#20 Re: Devuan Derivatives » Michaels Devuan Edition *Update* » 2020-11-23 23:48:56

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

#21 ARM Builds » [ ARM64 ] Build for nanoPI R2S » 2020-11-18 23:19:33

tuxd3v
Replies: 2

Hello All,
I made a build for the NanoPi R2S..

Its a headless server image..
eth0 - Wan( Gigabit )
eth1 - Lan( Gigabit )

NOTA!
Its strongly advised to buy the metal enclosure,
Due to the fact that RockChip rk3328, with 2 nic's in a so small closed board environment will heat a lot!!
Even in a open environment it reaches [ 55 - 57 ]°C on iddle.
The  fact that there are 2 network chips, and the usual PMIC, with rk3328 on a so small board, will make the cpu heat more than usual..


Features & Versions:

1) - Arm Trusted Firmware  - ATF v2.3
     U-boot boot-loader       - v2020.10, with support patch for nanoPI R2S
2) - Linux Kernel                - MainLine 5.8.16. with patch's to add support for nanoPI R2S
3) - UserSpace                  - Devuan Beowulf ( for arm64 )
4) - ChangeLog                  - create Beowulf image,created Kernel deb packages, with Wireguard vpn,iscsi, nfs,etc
                                             Apply patches to Uboot/Kernel device tree, plus USB3 support added for the
                                             usb-to-Ethernet 8153b Gigabit Nic( eth1 - LAN )
5) - Problems & to be done - This Image have been tested with a high performance blower, spreading fresh air to it during 1 day,
                                               at full throttle..
                                               To be Done,
                                               Port the Image to Kernel 5.9.x or 5.10.x( next LTS ), this work is in progress..


1) BootLoader( ATF + u-boot )

Disk Partitioning scheme:

# parted /dev/mmcblk0
(...)                                                         
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start    End       Size      Type     File system  Flags
 1      32768s   262143s   229376s   primary  ext2         boot
 2      262144s  3743744s  3481601s  primary  ext4         esp

a)   - Bootloader( Arm Trusted Firmware + U-Boot ),
        1st pseudo-partition( starting at sector 64, til sector 8063 ) 'idbloader.img'
        2nd pseudo-partition( starting at sector 16384, til sector 24575 ) 'uboot.itb'
        3rd pseudo-partition( starting at sector 24576, til sector 32767s ) 'none - empty'
  a1) - The Bootloader will search for a file called 'boot.scr', and after initialize the u-boot environment, will execute that script..
  a2) - In  'boot.scr', for this image, it will point to 'nanoPI R2S' Device Tree Binary File by default..
b)  - 1st partition( starting at sector 32768 ), is mounted as  '/boot', and contain 'boot.scr' referred in a1),a2).
c)  - 2nd partition( starting at sector 262144 ) is mounted as rootfs '/'

NOTA!
The Bootloader in a) usually takes ~16MiB( idbloader.img + uboot.itb + none )..
Each time a bootloader is built, all area [ sectors 64 - 32767 ], needs to be clean first( so that you can flash the new bootloader.. because could still be there any bits of the previous one.. which could lead to unpredictable consequences.. ).


The 'boot.cmd' script( format, Human Readable ):

~# cat /boot/boot.cmd 
setenv eth1addr "B2 54 C3 7B 35 A8"
setenv macaddr1 "B2 54 C3 7B 35 A8"
#setenv console tty1
setenv devtype mmc
setenv devnum 1
part uuid ${devtype} ${devnum}:2 rootfsuuid
setenv bootargs "earlyprintk earlycon=uart8250,mmio32,0xff130000 swiotlb=1 coherent_pool=1m consoleblank=0 net.ifnames=0 biosdevname=0 console=ttyS2,1500000n8 cma=64M usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u root=PARTUUID=${rootfsuuid} rw fsck.repair=yes rootwait elevator=noop"
if ext2load ${devtype} ${devnum}:1 ${kernel_addr_r} vmlinux; then
  if ext4load ${devtype} ${devnum}:2 ${fdt_addr_r} usr/lib/linux-image-5.8.16/rockchip/rk3328-nanopi-r2-rev00.dtb; then
    fdt addr ${fdt_addr_r}
    fdt resize 65536
    fdt set /ethernet@ff550000 local-mac-address "[${macaddr1}]"
    booti ${kernel_addr_r} - ${fdt_addr_r}
  fi;
fi;

2) - Linux Kernel

Packages:
Linux Kernel 5.8.16:

~# dpkg -l |grep -E "(linux-.*(headers|image|libc-dev))"
ii  linux-headers-5.8.16       5.8.16-20                          arm64        Linux kernel headers for 5.8.16 on arm64
ii  linux-image-5.8.16         5.8.16-20                          arm64        Linux kernel, version 5.8.16
ii  linux-libc-dev:arm64       5.8.16-20                          arm64        Linux support headers for userspace development

There are support for the most common things like nfs,iscsi,wireguard vpn,tun,tap, etc
The target will be to reach, at least Linux kernel 5.10, improve  the Device Tree Bindings, when possible..


3) - UserSpace -Users & Passwords:

a) root      - password 'toor'
b) devuan - password 'devuan'

NOTA!
SSH is enabled, so that you can login, but root login, is disabled, you should login as 'devuan', only then switch to 'root', if you want to.. for that,
After Login as 'devuan', issue:

sudo su -

And type your 'devuan' password, that's it..


4) - Changelog

a) kernel mainline 5.8.16,
b) Beowulf  Userspace,
c) Lima Kernel Graphics Driver( not needed..its a headless system.. but still present ),
d) Patches for Device tree, reworked to find better power supply values for regulators( lower values ) and DVFS reworked, to those regulator lower voltage levels,
    Also DRAM DVFS was reworked, but not much only in the upper frequencies..
    Patchs to usb-to-Ethernet reworked to fix eth1 Mac address.
    Reworked Device tree for the leds on the device( three leds, )
   

    ~# ls /sys/class/leds
    nanopi-r2s:green:lan  nanopi-r2s:green:wan  nanopi-r2s:red:sys
    

e) traditional kernel deb-packages( .deb )
f) Swap is on and its Zram based, mounted on boot, by default, enforced in '/etc/rc.local'..

~# cat /etc/rc.local |grep swap
swapon -a

5) - Problems and testings to be done..

a) In beowulf, its impossible, for now, to automount zramfs as swap, automatically.. its enforced, see 4f)
b) - Testing is needed, to check if interfaces maintain themselfs with same names, between reboots.
c) - If you attach a usb-Serial debugger, with the board powered up.it sometimes restart..
      So, when using a usb-to-serial converter conected, do it before powerup..
d) - When network interfaces come up the 'post-up' command brings the leds on, but when you disconnect, the 'pre-down' commands have no efect, and the leds
      are maintained on..
      This need to be investigated..

For this image, to reach more Supported Hardware and Users, your help is also needed smile
Testing this image, and posting your feedback.


Best Regards,
tux

#22 Re: ARM Builds » [ ARMEL ] Builds, for RPi's Boards » 2020-11-10 01:33:07

ShorTie wrote:

They are moving away from /opt/vc/lib and to a more normal of /usr

hello ShorTie, thanks,
When you install them, I believe they are still copied to /opt/vc/lib?
If they are moving away, to  /opt, its a good sign smile

#23 Re: ARM Builds » [Solved] Raspberry Pi 1 Probelms » 2020-11-09 23:13:33

alphalpha wrote:

Yes, it is working wink

hello alphalpha,you welcome!
Glad you succeed, kudos for you! smile

EDIT: I saw your image for x86,
And it seems nice!
Could we see that graphical environment, and great work from you in the SBC world? wink

thanks

#24 Re: ARM Builds » [Solved] Raspberry Pi 1 Probelms » 2020-11-09 01:50:57

alphalpha wrote:

not really, they are installed but unconfigured
libraspberrypi-dev was depended on libraspberrypi0 and that depended on raspberrypi-bootloader
and i didnt want to install that bootloader

but now i get more errors from make

make                                                                       23:18
g++ -L/opt/vc/lib -lm -lpthread -lbcm_host -o fm_transmitter main.o mailbox.o sample.o wave_reader.o transmitter.o
/usr/bin/ld: warning: libvchiq_arm.so, needed by /opt/vc/lib/libbcm_host.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libvcos.so, needed by /opt/vc/lib/libbcm_host.so, not found (try using -rpath or -rpath-link)

i tried to copy the /opt/vc/lib folder from https://github.com/raspberrypi/firmware … opt/vc/lib but that didn't do the trick

hello,
yeah it needed libraspberrypi-dev,libraspberrypi0..

alphalpha wrote:

and that depended on raspberrypi-bootloader

well.. that could be a problem.. sad

You need to make the Dynamic Linker aware of 'libbcm_host.so':

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

try to find all dependencies of 'libbcm_host.so':

ldd /opt/vc/lib/libbcm_host.so

see what is missing..

and then find what packages this files are in..

apt-get install apt-file
apt-file update

For what I saw above you have already 2 unresolved dependencies( 'libvchiq_arm.so', 'libvcos.so'  )..

apt-file search libvchiq_arm.so
apt-file search libvcos.so

See the packages were those file are.. and try to install them, if you find its safe..

alphalpha wrote:

now i compiled the fm_transmitter on raspbian and copied it over to devuan but i can't run it
the file is there and is executable but

./fm_transmitter

  returns 'no such file or directory: ./fm_transmitter'

that is another situation..

Once you get the binary compiled and running in raspbian..
You will need to copy him, and all the dependencies that are not in devuan...
I mean all those shared libraries '*.so' to devuan

and then update devuan dynamic linker so that he knows how to link your 'fm_transmitter' to those libraries( when you execute the binary )..

echo "/opt/vc/lib" >> /etc/ld.so.conf
echo "/other/path/to/so/dependency" >> /etc/ld.so.conf
ldconfig -vv

after that, you can test the binary dynamic resolution with:

ldd ./fm_transmitter

and see if all references to shared objects are all recognized..
if they are, the binary should execute

what says the command bellow? smile

file ./fm_transmitter

#25 Re: ARM Builds » [Solved] Raspberry Pi 1 Probelms » 2020-11-08 23:59:57

hello,
yeah it shouldn't be that, I believe that is for 1wire protocol( DS18B20 and such.. )..

The DHT22, and the DHT11 I believe both use the same protocol smile
so maybe you can use it with that driver( dht11 )..

Of-course you can always go via gpio are request information on the data pin, without any driver( probably what you have smile  )..
Some sort of BitBanging the protocol via software..

its a 1 Wire protocol, it just isn't the "1Wire protocol" we know from Dallas..its different..

Does you succeed getting the 2 packages from raspbian? smile

Board footer

Forum Software