Manjaro ARM Preview1 for Raspberry Pi 4!

Manjaro ARM Preview1 for Raspberry Pi 4!

The Manjaro ARM project is proud to announce the first test release for the Raspberry Pi 4!
So still a lot is missing.

This is an indication of how far upstream (Raspberry Pi) is with 64-bit support.

Download:
LXQT
Minimal

Features:

The Raspberry Pi 4 is the latest upgrade in the Raspberry Pi SBC series. This one has a Quadcore A72 CPU, up to 4 GB of LPDDR4 RAM, 2x USB 2.0, 2x USB 3.0 ports, double micro-HDMI ports, AC Wifi, Bluetooth 5.0 and Gigabit ethernet.

So this is basically the upgrade for Raspberry Pi everyone has been waiting for!

How to install:

Download the image/zip file from the download location. Verify that the download completed successfully.

After that, install Etcher (sudo pacman -S etcher if on Manjaro) and burn it to an SD card (8 GB or larger).

Put the SD card into Raspberry Pi 4's SD card slot on the main board and boot it up. The Raspberry Pi 4 should recognize the SD card as a bootable device and boot from it.

On the first boot, it will display an OEM installer. After you have made your choices it will reboot into your newly setup system.

Known Issues:
LXQT

  • No sound device
  • No GPU/VPU acceleration
  • OS can only see 1GB of RAM, even if the device has more.

Donate!

Please consider supporting Manjaro ARM via Patreon, Ko-Fi or to Manjaro's Paypal.

9 Likes

To enable Sound and VC4 GPU stuff add this you your /boot/config.txt.

dtparam=audio=on
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

And remove the blacklist file:
/etc/modprobe.d/blacklist-vchiq.conf

I will add them in the next kernel update.

Hi,
I've flashed the minimal preview to an SD card and headlessly booted up on a Raspberry Pi 4, its connecting to ethernet and I can port scan that its got a ssh port open but the normal default user/password isn't working (manjaro) - am i missing something for this new release?

Thanks

All releases since 19.04 don't have a default user, until the OEM setup has been run.

So you need to plugin a monitor and keyboard first, to finish the setup of Manjaro ARM.

Hi. Just started on my Manjaro journey. Burned the SD card image and started up the Pi 4. As you said, OEM starts, cue frantic trying-to-find-the-right-options :wink: The LXQT desktop looks gorgeous. This was on the Pi 4 with 4GB, which of course Manjaro can presently only access 1GB of, so it performed a bit like Raspbian on a Pi 3, but that's fine, I'm sure 4GB support will come eventually :slight_smile:
Good job so far!

Mike

1 Like

My attempt at enabling full 2/4GB RAM:
https://1drv.ms/u/s!AsAt419K-9C9gcJXL89TOTmV9gs83g?e=0NjsQM

Replace the DTB file in /boot/broadcom with one of these, and remove the 1GB RAM restriction from /boot/config.txt and /boot/cmdline.txt.

The issue appears to be address collisions between DMA and MMIO ranges. I altered the DMA ranges on the /scb bus as follows:

"Middle ground" version:

	dma-ranges = <0x0 0x00000000  0x0 0x00000000  0x3c000000>,
		     <0x0 0x40800000  0x0 0x40800000  0x3b800000>,
		     <0x0 0x80000000  0x0 0x80000000  0x7c000000>;

"Brave" version:

	dma-ranges = <0x0 0x00000000  0x0 0x00000000  0x3c000000>,
		     <0x0 0x40800000  0x0 0x40800000  0x3b800000>,
		     <0x0 0x7f800000  0x0 0x7f800000  0x7c800000>;

"Conservative" version:

	dma-ranges = <0x0 0x00000000  0x0 0x00000000  0x3c000000>;

This should stop DMA from trampling on MMIO address space.

This is not an issue on 32-bit, as the kernel includes a hack to restrict all DMA to the low 1GB of physical RAM when compiled for 32-bit LPAE. Rather than extending the hack to 64-bit kernels, I chose to fix this in DTB.

What are the differences between Middleground, Brave and Conservative versions?
Riscs?

And do you have a kernel/bootloader patch we can apply directly?
Prebuilt dtb's are fine for testing, but will get replaced with next kernel update. :slight_smile:

Conservative completely restricts DMA on all buses to the low 1GB address space, like the LPAE-specific hack.
Brave allows DMA to all addresses not part of known MMIO regions.
Middleground is like Brave, except I have excluded the whole 7C000000:80000000 physical address range from DMA (Brave has 7C000000:7F800000). It's not clear from the data I have if the 7F800000:80000000 range is used for MMIO, or if it's general-purpose RAM that can be used for DMA.

Here is the same thing as a Linux kernel patch (this is the Middleground version):

1 Like

Thanks. Will try it out.

Sorry. The DTB's do not boot on my rpi4. :frowning:

Do they regress and fail to boot even with the 1GB limit still in place?

No. With the 1 GB limit they continue.

PS: Patch does not apply, since it is for another kernel, where there have been other modifications.

error: patch failed: arch/arm/boot/dts/bcm2838.dtsi:317
error: arch/arm/boot/dts/bcm2838.dtsi: patch does not apply
==> ERROR: A failure occurred in prepare().

Can you check if the failure behavior (e.g. serial output) is the same with my DTBs as with the original?

Please test with the Conservative DTB first.

I don't have a serial console for the Pi, but the lights blink the same way with your DTB's and with the original DTB's.
So it looks like the dma-ranges change just does not affect it.

Uploaded new DTBs to the same folder, this time with the coherent DMA pool increased to 16M or 64M.
The issue with the previous DTBs seems to be that the kernel runs out of coherent DMA pool when trying to allocate bounce buffers. With RAM restricted to 1GB, this issue doesn't manifest because bounce buffers are only used when a device needs to DMA into physical addresses outside the low 1GB.

BTW, easiest way to get serial output is to connect to another Pi's serial port on the GPIO header.
Also, I found that the pi3-disable-bt dtoverlay is required to get serial output on the Pi 4.

Just tested both. Exact same symptoms as the previous dtbs.
They still work with the 1G ram limit though.

Maybe it's easier to just "hack" it like they did with 32-bit?

Unfortunately a similar hack is not possible in arm64, as it relies on the old boardfiles mechanism, which is arm32-exclusive.

Can you check /proc/cmdline with the 1G limit restored? I need to see if the kernel command line parameters from DTB are propagating through properly (the Pi firmware is known to mess with the kernel command line).

Sure.
Here's the /boot/cmdline.txt:

root=/dev/mmcblk0p2 rw rootwait console=ttyAMA0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 elevator=noop mem=1G

And here's the contents of /proc/cmdline with coherent-64MB dtb:

coherent_pool=64M 8250.nr_uarts=0 cma=64M bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:04:66:91 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  root=/dev/mmcblk0p2 rw rootwait console=ttyS0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyS0,115200 elevator=noop mem=1G

Success! I was able to get a 4GB Pi to boot in 64-bit mode with full RAM, using the coherent16m DTB, and the following extra arguments added to /proc/cmdline:

swiotlb=force cma=256M@16M