Devuan on Raspberry Pi 4 - now also aarch64

therion23 · 2019-07-05 06:36:57

Update 20200205: If you have a Pi 3 (or a Pi 2 revision 1.2), go to post 12 for aarch64, or read below for armhf.

If you have a Pi 2 1.0 or 1.1, the easiest way of making a bootable SD card for the Pi 4 is like this:

- Grab a Devuan image for Pi 2 (sorry, 32 bit only when doing this on a Pi 2). For some reason i could never boot the Ascii image on my Pi 2, but Jessie worked fine.
- Boot it on your Pi 2 and set up networking.
- From http://archive.raspberrypi.org/debian/p … -firmware/ get raspberrypi-bootloader and raspberrypi-kernel - make sure they have matching version numbers and not older than 20190620.
- From http://archive.raspberrypi.org/debian/p … e-nonfree/ get the latest firmware-brcm80211.
- install all three with dpkg.
- Double check your /boot/cmdline.txt - especially the root= setting.
- Reboot.

If it boots right, you should be running 4.19.50-v7l+. Shutdown, put the card into your Pi 4 and boot it up.

Now, if the screen blanks during boot on your Pi 4, it is most likely during switching framebuffers. In this case, wait a bit till you can log in via ssh, and as root, do:

echo blacklist vc4 > /etc/modprobe.d/blacklist-vc4.conf

And reboot. Solved the issue for me (HDMI - haven't tried the analogue output).

If you want the hardware specific bits (which usually live in /opt/vc), from the first URL above, get libraspberrypi0, libraspberrypi-bin and libraspberrypi-dev - all three the same version as the kernel and bootloader you got above! Install via dpkg and edit /etc/ld.so.conf.d/00-vmcs.conf to read this one line:

/opt/vc/lib

Run ldconfig or reboot.

Finally, update your system - but you know all about that already, right? :)

Caveat emptor - the above worked for me. Twice. Enjoy Devuan on your Pi 4!

Last edited by therion23 (2020-02-05 16:47:21)

tuxd3v · 2019-11-23 20:38:27

Hello therion23,
I tried with a Rpi1, compile a kernel, uboot, and try to boot the device..

I am stuck there..

On 'config.txt'
kernel=my-u-boot.bin

then created the boor.cmd, and scr script file, and I can boot the kernel..
The problem is that it hangs waiting for '/dev/mmbblk0p2'

So,
rpi1 execute:
1) - 'bootcode.bin', then bootcode.bin, reads 'config.txt', were it knows about my pseudo kernel( u-boot ) 'kernel=my-u-boot.bin'.
2) - It passes to VC4 to load 'start.elf'
3) - 'start.elf'( I believe ?! ) load my u-boot..
3) - my u-boot is loaded, which instructs to load the Real Kernel..

The problem... Kernel Hangs, waiting for '/dev/mmcblk0p2'

Here are the logs taken from ttyAMA0:

port is        : /dev/ttyUSB0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,

Terminal ready
)
## Executing script at 02400000
## Error: Can't overwrite "ethaddr"
## Error inserting "ethaddr" variable, errno=1
switch to partitions #0, OK
mmc0 is current device
12655 bytes read in 9 ms (1.3 MiB/s)
4898976 bytes read in 221 ms (21.1 MiB/s)
Kernel image @ 0x008000 [ 0x000000 - 0x4ac0a0 ]
## Flattened Device Tree blob at 02600000
   Booting using the fdt blob at 0x2600000
   Using Device Tree in place at 02600000, end 0260616e

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.3.11 (tuxd3v@desktop0) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #10 Fri Nov 22 18:58:43 WET 2019
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi Model B
[    0.000000] Memory policy: Data cache writeback
[    0.000000] cma: Reserved 8 MiB at 0x0e800000
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 60900
[    0.000000] Kernel command line: earlyprintk=serial,ttyAMA0,115200 console=ttyAMA0,115200n8 console=tty1 root=/dev/mmcblk0p2 rw rootwait rootfstype=ext4 elevator=noop fsck.repair=no smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 selinux=0 noinitrd
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 224072K/245760K available (6889K kernel code, 665K rwdata, 2188K rodata, 468K init, 781K bss, 13496K reserved, 8192K cma-reserved)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] ftrace: allocating 24939 entries in 49 pages
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] random: get_random_bytes called from start_kernel+0x2e8/0x518 with crng_init=0
[    0.000024] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[    0.000084] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[    0.000181] bcm2835: system timer (irq = 27)
[    0.000717] Console: colour dummy device 80x30
[    0.001220] printk: console [tty1] enabled
[    0.001315] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
[    0.050370] pid_max: default: 32768 minimum: 301
[    0.050974] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.051049] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.052850] CPU: Testing write buffer coherency: ok
[    0.054651] Setting up static identity map for 0x8200 - 0x8238
[    0.055914] devtmpfs: initialized
[    0.063740] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
[    0.064288] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.064380] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.065901] pinctrl core: initialized pinctrl subsystem
[    0.067862] NET: Registered protocol family 16
[    0.071960] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.076890] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
[    0.076971] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.077173] Serial: AMBA PL011 UART driver
[    0.119919] SCSI subsystem initialized
[    0.120275] usbcore: registered new interface driver usbfs
[    0.120432] usbcore: registered new interface driver hub
[    0.121020] usbcore: registered new device driver usb
[    0.123563] clocksource: Switched to clocksource timer
[    1.544513] VFS: Disk quotas dquot_6.6.0
[    1.544721] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.545158] FS-Cache: Loaded
[    1.545574] CacheFiles: Loaded
[    1.546008] simple-framebuffer f6fb000.framebuffer: framebuffer at 0xf6fb000, 0x300000 bytes, mapped to 0x(ptrval)
[    1.546090] simple-framebuffer f6fb000.framebuffer: format=a8r8g8b8, mode=1024x768x32, linelength=4096
[    1.572117] Console: switching to colour frame buffer device 128x48
[    1.595073] simple-framebuffer f6fb000.framebuffer: fb0: simplefb registered!
[    1.616069] thermal_sys: Registered thermal governor 'step_wise'
[    1.616929] NET: Registered protocol family 2
[    1.618970] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[    1.619515] TCP established hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    1.619977] TCP bind hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    1.620393] TCP: Hash tables configured (established 2048 bind 2048)
[    1.620926] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    1.621324] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    1.622195] NET: Registered protocol family 1
[    1.624019] RPC: Registered named UNIX socket transport module.
[    1.624377] RPC: Registered udp transport module.
[    1.624644] RPC: Registered tcp transport module.
[    1.635374] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.647450] hw perfevents: no irqs for PMU, sampling events not supported
[    1.658382] hw perfevents: enabled with armv6_1176 PMU driver, 3 counters available
[    1.672981] Initialise system trusted keyrings
[    1.684376] workingset: timestamp_bits=14 max_order=16 bucket_order=2
[    1.713463] FS-Cache: Netfs 'nfs' registered for caching
[    1.726013] NFS: Registering the id_resolver key type
[    1.736825] Key type id_resolver registered
[    1.747181] Key type id_legacy registered
[    1.757432] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    1.770306] Key type asymmetric registered
[    1.780643] Asymmetric key parser 'x509' registered
[    1.790870] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    1.801620] io scheduler mq-deadline registered
[    1.811990] io scheduler kyber registered
[    1.836484] bcm2835-rng 20104000.rng: hwrng registered
[    1.870326] brd: module loaded
[    1.896340] loop: module loaded
[    1.907862] Loading iSCSI transport class v2.0-870.
[    1.919594] usbcore: registered new interface driver smsc95xx
[    1.930373] usbcore: registered new interface driver usb-storage
[    1.941229] mousedev: PS/2 mouse device common for all mice
[    1.953892] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[    1.965277] sdhci: Secure Digital Host Controller Interface driver
[    1.975797] sdhci: Copyright(c) Pierre Ossman
[    1.986095] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.997306] ledtrig-cpu: registered to indicate activity on CPUs
[    2.008264] hidraw: raw HID events driver (C) Jiri Kosina
[    2.018757] usbcore: registered new interface driver usbhid
[    2.028797] usbhid: USB HID core driver
[    2.039867] bcm2835-mbox 2000b880.mailbox: mailbox enabled
[    2.050636] Initializing XFRM netlink socket
[    2.060524] NET: Registered protocol family 17
[    2.070349] Key type dns_resolver registered
[    2.081652] registered taskstats version 1
[    2.091048] Loading compiled-in X.509 certificates
[    2.109931] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
[    3.009889] random: fast init done
[    3.912321] printk: console [ttyAMA0] enabled
[    3.927686] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-09-30 14:41
[    3.948148] vchiq: vchiq_init_state: slot_zero = (ptrval)
[    3.971479] Waiting for root device /dev/mmcblk0p2...
[  212.003677] random: crng init done

Can you see the amount of time it took to initialize rng?
Maybe I need to configure it.. don't know, but I already tried, without success..maybe I am doing something wrong..

The objective...
Get Rid of Every Blob RaspberryPi trows at it..
Till now I am unsuccessful on that

Have you any advice?

Thanks in Advance,
Best Regards,
tux

therion23 · 2019-11-24 08:51:12

Hello!

I know terribly little about u-boot, however, i see no messages about mmc-bcm2835 and sdhost-bcm2835 (comparing with a Pi Zero here), so it really looks like a missing card reader driver to me.

Now, that delay i do know a little about, but no sureshot fix for it. It is something introduced with kernels 4.16 onwards (i believe), and related to how it gathers random data.

- Try installing haveged and reboot. It fixed things for some people (supposedly works without a hardware RNG).
- Try removing haveged, installing rng-tools and reboot. Fixed things for other people (supposedly requires a hardware RNG).
- Try removing rng-tools, plugging an 802.11 USB adapter and reboot. This fixed it for me on a Pi 2.

Let me know your results.

tuxd3v · 2019-11-24 17:09:25

therion23 wrote:

Hello!
I know terribly little about u-boot, however, i see no messages about mmc-bcm2835 and sdhost-bcm2835 (comparing with a Pi Zero here), so it really looks like a missing card reader driver to me.

Hello,
My kernel '.config' is yet very crude.. and I trusted it too much( to bad for me..I paid the price )

You were straight to the point
My rpi1B v1.0 is up and running
its consuming now 17MB of Ram..

So bootcode.bin->start.elf->u-boot-> real kernel..

I still have some annoyances, the iface 'eth0' gets renamed to something very absurd..
and maybe I don't have yet all modules that I need enabled.. :S

For example the CPU Activity led, is only blinking, not reflecting the load, or processing my PI have..
I will recompile also a u-boot with support for HardFloat operations..

I still need to do a lot of checkings on it..

Now, that delay i do know a little about, but no sureshot fix for it. It is something introduced with kernels 4.16 onwards (i believe), and related to how it gathers random data.
- Try installing haveged and reboot. It fixed things for some people (supposedly works without a hardware RNG).
- Try removing haveged, installing rng-tools and reboot. Fixed things for other people (supposedly requires a hardware RNG).
- Try removing rng-tools, plugging an 802.11 USB adapter and reboot. This fixed it for me on a Pi 2.

The driver in Kernel 5.3.11, seems to be working now, about 14 seconds, a lot less from the 211 before.. but more checking is needed..

About rng-tools:
You can use in '/etc/default/rng-tools' a device like '/dev/urandom' it is the only way I could boot a 'Orange PI one Plus', because the TRNG hardware isn't yet supported( will be in kernel 5.4 I believe )..
You can try this solution has a last resort..

I will update, with my findings about what I could optimise
Thanks a lot to put me in the right track!!

Last edited by tuxd3v (2019-11-24 17:12:37)

therion23 · 2019-11-24 17:37:19

This both explains and (hopefully) solves your eth0 issue: StackExchange link

This explains how to control the LEDs: Jeff Geerling's blog. Your options for triggers are:

gpio - controlled through GPIO (off by default)
heartbeat - heartbeat-like pulse
timer - pulse every second
input - under-voltage detection
mmc0 - memory I/O
cpu0 - CPU activity

Good luck!

tuxd3v · 2019-12-08 18:49:52

therion23 wrote:

This both explains and (hopefully) solves your eth0 issue: StackExchange link
This explains how to control the LEDs: Jeff Geerling's blog. Your options for triggers are:
gpio - controlled through GPIO (off by default)
heartbeat - heartbeat-like pulse
timer - pulse every second
input - under-voltage detection
mmc0 - memory I/O
cpu0 - CPU activity
Good luck!

Thanks!
I will try that, specially the the ACK les to 'cpu0'

ubik · 2019-12-29 19:02:02

I didn't have an older Pi to modify the Devuan image so I used qemu and chroot on a x86 PC with instructions from https://wiki.debian.org/RaspberryPi/qemu-user-static. Mounting the Devuan image and /dev, /proc, /sys & /dev/pts and chrooting in lets you run apt as if you were running on the Pi itself :-)

To get around the problem of the vc4 module and to get the second monitor output to work you need Mesa 19.1.0 or later, that means an upgrade to beowulf and fixing a few dependancies.

I downloaded libgl1-mesa-dri_19.2.0~rc1-1~bpo10+1~rpt3_armhf.deb
libglapi-mesa_19.2.0~rc1-1~bpo10+1~rpt3_armhf.deb and
libglx-mesa0_19.2.0~rc1-1~bpo10+1~rpt3_armhf.deb from http://archive.raspberrypi.org/debian/pool/main/m/mesa/

And to get those working I needed to install binfmt-support, libpfm4 and some other bits that aren't available in the Devuan archives yet:
libllvm8_8.0.1-3~bpo10+1_armhf.deb
llvm-8_8.0.1-3~bpo10+1_armhf.deb
llvm-8-runtime_8.0.1-3~bpo10+1_armhf.deb from
http://ftp.nl.debian.org/debian/pool/ma … olchain-8/

Finally in /boot/config.txt I commented out dtoverlay=vc4-kms-v3d and added:

dtoverlay=vc4-fkms-v3d 
max_framebuffers=2

So far beowulf seems to be running well and I have Xfce running across two 1600x1200 monitors :-)

The only other problem I had was that the HDMI 1 output on the Pi 4 doesn't seem to be as strong as HDMI 0 and really didn't like the long cable I had.

Thanks to therion23

pAul · 2020-01-05 22:22:22

I followed therion23's description, raspi 4 boots up, looks nice, thanks!
However, I cannot set up WLAN AP. I even played with newer kernels and newest firmware.

Current configs:

# uname -a
Linux devuan 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux

# dmesg | grep brcmfmac
[    2.614772] brcmfmac: F1 signature read @0x18000000=0x15264345
[    2.622859] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    2.623389] usbcore: registered new interface driver brcmfmac
[    2.859070] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    2.873290] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[    3.018180] brcmfmac mmc1:0001:1 wlan1: renamed from wlan0
[   11.974904] brcmfmac: power management disabled
[   12.039577] brcmfmac: power management disabled

# iw list | grep AP
         * AP
         * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{P2P-device } <= 1,

starting hostapd:

# hostapd -dd /etc/hostapd/hostapd.conf
...
nl80211: Teardown AP(wlan1) - device_ap_sme=1 use_monitor=0
nl80211 driver initialization failed.
hostapd_interface_deinit_free(0xc70cd8)
hostapd_interface_deinit_free: num_bss=1 conf->num_bss=1
hostapd_interface_deinit(0xc70cd8)
wlan1: interface state UNINITIALIZED->DISABLED
hostapd_bss_deinit: deinit bss wlan1
wlan1: AP-DISABLED
hostapd_cleanup(hapd=0xc719a0 (wlan1))
hostapd_free_hapd_data: Interface wlan1 wasn't started
....

# iwconfig 
eth0      no wireless extensions.
lo        no wireless extensions.
br0       no wireless extensions.

wlan1     IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=31 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

as well as

# cat /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet manual

auto wlan1
allow-hotplug wlan1
iface wlan1 inet manual
wireless-power off

auto br0
iface br0 inet dhcp
bridge_ports eth0 wlan1
bridge_fd 0
bridge_stp off

and

# cat /etc/hostapd/hostapd.conf 
bridge=br0

interface=wlan1
driver=nl80211

ssid=XSXDX
channel=7
hw_mode=g
preamble=1
ieee80211n=1
ieee80211d=1
country_code=DE
wmm_enabled=1

auth_algs=3
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_passphrase=XPXPX

Did I miss something or is it due to the 32bit version?

pAul · 2020-01-11 17:49:05

pAul wrote:

I followed therion23's description, raspi 4 boots up, looks nice, thanks!
However, I cannot set up WLAN AP. I even played with newer kernels and newest firmware.

an upgrade of hostapd to version 2.6 did the job:
https://github.com/raspberrypi/firmware/issues/1117

tuxd3v · 2020-01-27 19:51:58

Hello therion23,
Can you join us on trying to get a arm64 version of Devuan, running in RaspberryPi Here ?

It would be nice to get more people involved

Last edited by tuxd3v (2020-01-27 19:52:32)

therion23 · 2020-02-05 07:15:16

Hey, i wonder why i didn't get topic reply emails anymore. In fact, i came for a look because this morning i started "upgrading" Devuan to 64 bit

Step 1 - getting the above method up to speed with kernel packages from raspberrypi.org so people will have a "tedious but simple" way of getting Devuan running aarch64 on a Pi 4.
Step 2 - documenting it here.
Step 3 - coming over to help you

1+2 should be done this time tomorrow. Count me in for 3 after that, so we can get a "complex but accurate" version too!

therion23 · 2020-02-05 16:37:51

Devuan aarch64 on Pi 4 (if you have a Pi 3) - the dirty and lowdown way:

- Grab a Devuan Ascii image for Pi 3.
- Boot it on your Pi 3 and set up networking.
- From http://archive.raspberrypi.org/debian/p … -firmware/ get raspberrypi-bootloader and raspberrypi-kernel - make sure they have matching version numbers and not older than 20200114 (kernel 4.19.93).
- From http://archive.raspberrypi.org/debian/p … e-nonfree/ get the latest firmware-brcm80211 (might actually be in the Devuan apt as well - forgot to check).
- install all three using dpkg with the --force-architecture parameter.
- Double check your /boot/cmdline.txt - especially the root= setting.
- Edit your /boot/config.txt - delete (or comment out) "kernel=kernel8.img", add "arm_64bit=1" on a separate line and finally replace "dtoverlay=vc4-kms-v3d" with "dtoverlay=vc4-fkms-v3d".
- Reboot.

If it boots at all, it will boot in 64 bit on any Pi 4 and Pi 3, and even the final Pi 2 revision 1.2 (which i do not own, but people tell me it is just an underclocked 2837).

Finally, update your system!

Caveat emptor - the above worked for me (i did, however, update to ceres before installing the three packages and rebooting). Enjoy Devuan aarch64 on your Pi 4!

PS: If you want the hardware specific bits (which usually live in /opt/vc), you have to wait. AFAIK, libraspberrypi(0,-bin,-dev) only exist in armhf versions so far, and i definitely cannot help there.

Last edited by therion23 (2020-02-05 18:29:09)

therion23 · 2020-02-06 09:06:59

ubik wrote:

To get around the problem of the vc4 module and to get the second monitor output to work you need Mesa 19.1.0 or later, that means an upgrade to beowulf and fixing a few dependancies.

By now, mesa 19.3.3 and llvm 9 are both in the Devuan repositories (at least on ceres) - awesome you got it working dual headed, i cannot try that since my adapters are too thick to fit side by side, but i have to try your "max_framebuffers" trick one day i get more slim HDMI adapters

And yes you are right, the HDMI output closest to the USB C power port is stronger - if you get no video during boot after switching from vc4-kms-v3d to vc4-fkms-v3d then try the other HDMI port, and depending on your monitor, you might need a power cycle to send it a "wake up" signal.

pAul wrote:

Did I miss something or is it due to the 32bit version?

Sorry, i forgot to write i upgraded to ceres before starting everything - my bad!

Glad you both (and possibly others) made it work - thanks should go out to freenode #devuan-arm who went "we honestly have no idea - try it!".

pAul · 2020-05-18 08:36:08

therion23 wrote:

If you have a Pi 2 1.0 or 1.1, the easiest way of making a bootable SD card for the Pi 4 is like this:
- Grab a Devuan image for Pi 2 (sorry, 32 bit only when doing this on a Pi 2). For some reason i could never boot the Ascii image on my Pi 2, but Jessie worked fine.
- Boot it on your Pi 2 and set up networking.
- From http://archive.raspberrypi.org/debian/p … -firmware/ get raspberrypi-bootloader and raspberrypi-kernel - make sure they have matching version numbers and not older than 20190620.
- From http://archive.raspberrypi.org/debian/p … e-nonfree/ get the latest firmware-brcm80211.
- install all three with dpkg.
If it boots right, you should be running 4.19.50-v7l+. Shutdown, put the card into your Pi 4 and boot it up.

does this procedure only work with the version with 1GB of memory? I have no success with the 2GB version, or should I also upgrade to boewulf or even ceres? I'll try out and report.

Last edited by pAul (2020-05-18 08:36:32)

therion23 · 2020-05-18 13:25:48

pAul wrote:

does this procedure only work with the version with 1GB of memory? I have no success with the 2GB version, or should I also upgrade to boewulf or even ceres? I'll try out and report.

Mine is a 4GB model, but i doubt it makes any difference. Tell me where it breaks for you and i'll try to think of a solution.

pAul · 2020-05-18 14:45:51

therion23 wrote:

Mine is a 4GB model, but i doubt it makes any difference. Tell me where it breaks for you and i'll try to think of a solution.

It boots up wright on the Pi2, but on the Pi4 (2GB) it does not receive an IP-address

# uname -a
Linux devuan 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux

# cat /boot/cmdline.txt 
dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0

On the Pi4 with 1GB everything works fine even with ascii (and newest hostapd). But the same card does not receive an IP on the version with 2GB of memory.

therion23 · 2020-05-18 16:46:25

Okay, that sounds extremely strange. Do you have a wlan0 interface at all? Also, maybe it's worth updating the EEPROM as in:

https://www.raspberrypi.org/documentati … teeprom.md

If you are running a 32 bit Devuan you should be able to just pull a couple of packages for Raspbian, install, run and remove again. The updater will not work on a 64 bit system.

Note that i have no idea exactly what those update fix, apart from lowering the temperature and fixing some USB3 stuff.

pAul · 2020-05-19 08:35:18

Thanks for your reply. I'm really confused about what's going on. I'm able to boot raspbian and also made an EEPROM update using stable/pieeprom-2020-04-16.bin as explained.

The ouput of $ vcgencmd bootloader_config changed from

BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
FREEZE_VERSION=0

to

[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
TFTP_IP=
TFTP_PREFIX=0
BOOT_ORDER=0x1
SD_BOOT_MAX_RETRIES=3
NET_BOOT_MAX_RETRIES=5
[none]
FREEZE_VERSION=0

However, I'm not able to see devuan receiving an ip address. Also tried the SD card with devuan from Raspi4 - 1GB without success in my Pi4 - 2 GB.

pAul · 2020-05-19 08:42:56

therion23 wrote:

Do you have a wlan0 interface at all?

wlan0 is present

output from raspbian:

$ iwconfig
lo        no wireless extensions.

wlan0     IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          
eth0      no wireless extensions.

therion23 · 2020-05-19 09:13:24

Does "ifconfig -a" show you a hardware address on a line starting with "ether"? Do you get output from "iwlist scan"? If yes to both, it's not a firmware or hardware issue. If not, grep your dmesg for "brcmfmac"

Since your wlan0 isn't even associated, it might be worth running wpa_supplicant manually in the foreground with logging to stdout, and see what happens when it tries to associate (you can probably use wpa_cli as well, never used it myself so cannot be of much help there).

Is your wireless access point locked on MAC addresses? Because the behaviour is the exact same as if you forgot to add the MAC of the 2GB Pi.

Does Raspbian or anything else get an IP address on your 2GB Pi?

pAul · 2020-05-19 10:07:11

WLAN I will set up later. Firstly, the Pi is connected via LAN. I thought, I can grab the working SD Card form the 1 GB version with devuan, plug in into the 2 GB Pi and get started.

Maybe that's the point. The 1 GB Pi has a wlan1 interface, and my Pi2 a wlan2. However, since I use both as WLAN AP, I bridged those interfaces with eth0 to the bridge interface br0 which is the only one to ask the DHCP server. The only explanation I have, is that the bridge does not succeed on the 2 GB having a wlan0 interface, and thus does not ask for an IP address.

I should better start with a blank SD card.

Btw: clean Raspbian or yan's image from https://dev1galaxy.org/viewtopic.php?id=3209&p=3 worked well

Last edited by pAul (2020-05-19 10:09:09)

therion23 · 2020-05-19 10:37:02

It would definitely be worth disabling all the bridging and see if you can get an IP address for a plain interface. That should tell you the next step.

pAul · 2020-05-23 09:01:20

forgot to answer, everything works fine with your above instruction, therion23
(clean install is sometimes better ;-) )

the only thing I don't understand is what you mean with

- Double check your /boot/cmdline.txt - especially the root= setting.

cf. with my output post #16

Anyway, everything works great, thanks for the instruction

therion23 · 2020-05-23 10:00:10

Sometimes root= points to an UUID instead of a partition, and when it does, you cannot just copy over cmdline.txt from another installation. Setting it, as you did and is default, to /dev/mmcblk0p2 is fine for nearly all Pi setups - UUID's are really only useful (in this context) if you have two or more bootable USB devices, and not sure in what order they get enumerated.

Glad you got it working!

The officially official Devuan Forum!

#1 2019-07-05 06:36:57

Devuan on Raspberry Pi 4 - now also aarch64

#2 2019-11-23 20:38:27

Re: Devuan on Raspberry Pi 4 - now also aarch64

#3 2019-11-24 08:51:12

Re: Devuan on Raspberry Pi 4 - now also aarch64

#4 2019-11-24 17:09:25

Re: Devuan on Raspberry Pi 4 - now also aarch64

#5 2019-11-24 17:37:19

Re: Devuan on Raspberry Pi 4 - now also aarch64

#6 2019-12-08 18:49:52

Re: Devuan on Raspberry Pi 4 - now also aarch64

#7 2019-12-29 19:02:02

Re: Devuan on Raspberry Pi 4 - now also aarch64

#8 2020-01-05 22:22:22

Re: Devuan on Raspberry Pi 4 - now also aarch64

#9 2020-01-11 17:49:05

Re: Devuan on Raspberry Pi 4 - now also aarch64

#10 2020-01-27 19:51:58

Re: Devuan on Raspberry Pi 4 - now also aarch64

#11 2020-02-05 07:15:16

Re: Devuan on Raspberry Pi 4 - now also aarch64

#12 2020-02-05 16:37:51

Re: Devuan on Raspberry Pi 4 - now also aarch64

#13 2020-02-06 09:06:59

Re: Devuan on Raspberry Pi 4 - now also aarch64

#14 2020-05-18 08:36:08

Re: Devuan on Raspberry Pi 4 - now also aarch64

#15 2020-05-18 13:25:48

Re: Devuan on Raspberry Pi 4 - now also aarch64

#16 2020-05-18 14:45:51

Re: Devuan on Raspberry Pi 4 - now also aarch64

#17 2020-05-18 16:46:25

Re: Devuan on Raspberry Pi 4 - now also aarch64

#18 2020-05-19 08:35:18

Re: Devuan on Raspberry Pi 4 - now also aarch64

#19 2020-05-19 08:42:56

Re: Devuan on Raspberry Pi 4 - now also aarch64

#20 2020-05-19 09:13:24

Re: Devuan on Raspberry Pi 4 - now also aarch64

#21 2020-05-19 10:07:11

Re: Devuan on Raspberry Pi 4 - now also aarch64

#22 2020-05-19 10:37:02

Re: Devuan on Raspberry Pi 4 - now also aarch64

#23 2020-05-23 09:01:20

Re: Devuan on Raspberry Pi 4 - now also aarch64

#24 2020-05-23 10:00:10

Re: Devuan on Raspberry Pi 4 - now also aarch64

Board footer