Configure RPI3 ARM 19.06 image headless?

I don't have a monitor to be able to configure the image.

Can someone please walk me through configuring eth0 and/or configuring wifi and getting ssh running able to login?

I'd imagine I can mount the data partition in Linux and make the necessary changes to the files and then when it boots up I should be able to ssh in and get things further configured.

Thanks

The images start an OEM setup. Ethernet should be up from first boot, so it should be getting an IP.

I haven't actually tested if you can do the OEM setup from SSH (since that's not really Manjaro ARM's use case), but if it gets an IP, you should be able to SSH to it with ssh root@{IP}.
Root is configured to have auto login on first boot, so it might work.
Else you have to use the Manjaro ARM installer, to create your SD card.

eth0 did dhcp. ssh is not configured to allow root login without a password.

With the SD card mounted, I set a root password, and edited sshd_config and added 'PermitRootLogin yes'. Unmounted it, and booted it up on the Pi3.

After logging in as root I was presented with the OEM configurator and rebooted - it removed 'PermitRootLogin yes'. I then logged in as my user account.

I configured wireless 802.11ac with wpa_supplicant - works fine.

Only issue I see so far is the load average is stuck at 4.0 - 100% CPU . So the performance is negatively affected. I upgraded the system with pacman -Syu it grabbed a new kernel I think and rebooted. Same issue.

I tested openssl speed it is about 1/3rd of raspbian - I suppose because whatever issue is with the kernel.

Linux manjaro 5.2.0-1-MANJARO-ARM #1 SMP Tue Jul 9 07:33:03 UTC 2019 aarch64 GNU/Linux

It would be nice to be able to place a config.txt or some such file in FAT partition with the key=values that the OEM setup script is looking for and having an systemd unit file that looks for it and uses that. Like how raspbian looks for a file called /boot/ssh and /boot/wpa_supplicant to configure enabling ssh and wireless.

Please tell me what the CPU is used for here:
Like an output of top/htop or something. Because that does not happen on my end.

But glad you found a way around the OEM thing.
I will look into the ssh root access on first boot. Might be an oversight on my part, since the OEM setup is set to actually turn it off again.

In another post they said the cpu scheduler was set to max - then it was fixed to ondemand. Not sure if this is related. I wouldn't think that would hamper openssl performance though.

I see the load is going down quickly. So it's probably still the kernel load that gets shown there.
Because the CPU is not getting hammered in your screenshot, which is 4 minutes after boot.

Yeah, we changed the default cpu governor to OnDemand from Performance, because performance will keep your CPU at the higest clock rate, even when it's not needed. OnDemand will turn it up or down, depending on what's needed.

No, the load is going up quickly. I just booted it up to grab that SS for you. I left it running for 15 minutes before and it stables out the 1,5,15 minute load numbers to 4.0.

[root@manjaro ~]# uptime
 12:08:26 up 29 min,  1 user,  load average: 4.13, 4.11, 3.54
[root@manjaro ~]# openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 3236171 aes-128-cbc's in 2.87s
Doing aes-128-cbc for 3s on 64 size blocks: 1089193 aes-128-cbc's in 2.88s
Doing aes-128-cbc for 3s on 256 size blocks: 300023 aes-128-cbc's in 2.88s
Doing aes-128-cbc for 3s on 1024 size blocks: 76883 aes-128-cbc's in 2.88s
Doing aes-128-cbc for 3s on 8192 size blocks: 9694 aes-128-cbc's in 2.88s
Doing aes-128-cbc for 3s on 16384 size blocks: 4847 aes-128-cbc's in 2.88s
OpenSSL 1.1.1c  28 May 2019
built on: Sat Jun  1 16:37:43 2019 UTC
options:bn(64,64) rc4(char) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -Wa,--noexecstack -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -Wa,--noexecstack -D_FORTIFY_SOURCE=2 -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc      18041.37k    24204.29k    26668.71k    27336.18k    27574.04k    27574.04k

27574.04k on this Manjaro kernel for AES. I was monitoring the power usage of the Pi while running the test, it may not be scaling up the cpu frequency. The power draw stayed at 2.672 watts.

While running raspian buster I get 56836.10k on the same openssl cypher test and the power draw increases to 4.2 watts over idle 2.83 watts.

The load problem is a know upstream Kernel Bug since Kernel 5.0. It might be fixed with Kernel 5.3.

https://archlinuxarm.org/forum/viewtopic.php?f=65&t=13485
https://github.com/raspberrypi/linux/issues/2881

https://patchwork.kernel.org/cover/10937233/

1 Like

Ah good info! Thanks.

So is it possible to switch back to 4.19 ?

Not really. And as mentioned in the first link provided by @xabbu it's a cosmetic issue. The load isn't really that high, as seen by your CPU usage.

Manjaro ARM runs mainline.
You will be able to install 5.3-rc1 when it gets released.

I'm not sure it is only cosmetic. The last post linked from @xabbu from the developer of the patch said the first two patches should be implemented ASAP while only the last of the 3 were cosmetic.
I think it is affecting the scheduler having the kernel think the load is that high.

Running benchmarks on the 5.2 Manjaro kernel with all 4 cores 100% I can never get it to pull more than idle power draw of 2.77 watts and the temperature never raises above 55degC. Benchmarking is slower

In Raspbian with 4 cores at 100% it will pull 5.3 watts and reach over 65degC.

The initial regression should be fixed now upstream in 5.1 and 5.2.

Everything else should be discussed in a separate issue.

Cool! Hopefully we can get a new Manjaro kernel soon!

The RPI3 images from Manjaro run upstream mainline kernel.
Not the one from Raspberry Pi Foundation.
So if it's really fixed upstream, it will come in as a regular update at some point.

1 Like

Yes it is in upstream 5.2.1

https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.2.1

Will build that later today. :slight_smile:

2 Likes

I tried the 5.2.1 build - it does return the cpu load to normal.

But there is a still a problem with the CPU frequency governor. 100% max 4 cores only pulling 2.8 watts.

Half the throughput on OpenSSL vs a 4.19 Raspbian kernel.

I also tried the ArchArm 5.2.1 kernel from here: http://mirror.archlinuxarm.org/aarch64/core/linux-aarch64-5.2.1-1-aarch64.pkg.tar.xz

It has the CPU Governor set to performance, but it does the same thing. Must be some other bug.

Agreed. That must be a separate thing.

But glad the 100% cpu thing is gone. :slight_smile:

I also noticed this but I'm not sure how comparable two different architectures are. Since Raspbian is 32 Bit and armv7l. Manajro Arm is 64 Bit and aarch64 (armv8)

Arch Arm also supports the armv7 architectures for Raspberry Pi. The Kernel source for this architecture (linux-raspberrypi) is from the Raspberry Pi Foundation.

I ran openssl speed -evp aes-128-cbc on the same board (Raspberry Pi 3 Model B) with an Archlinux arm image for aarch64 and armv7l.

64 Bit aarch64 -> 27830.88k
32 Bit armv7l  -> 52614.49k

raw output https://gist.github.com/xabbu/d7e39b1fea6f6456d417af39807c4f87

I'm not sure what the conclusion could be, but the architecture makes a difference.