Pi4 64-bit raspbian kernel for testing - Focus on Pi4

[fanoush]

But what about Pi 2, wouldn't [pi2] match both BCM2836 and BCM2837 models?

maybe set arm_64bit=1 would just silently fail on 32bit cpu and load 32bit kernel? And if not it could be changed to work like this? Would it solve the issue?

[dom]

maybe set arm_64bit=1 would just silently fail on 32bit cpu and load 32bit kernel? And if not it could be changed to work like this? Would it solve the issue?

I don't think it would help with related settings (like initrd) that vary with 32/64 bit.
But it's not a bad idea (I'll need to check what the current behaviour is with arm_64bit=1 on 32-bit arms).

Filters for [2835]/[2836]/[2837]/[2838] or something like [64bit-capable] are possible, but the config.txt filtering
is already quite complex to describe so we'll need to convince ourselves there is a real need.

[incognitum]

maybe set arm_64bit=1 would just silently fail on 32bit cpu and load 32bit kernel?

Problem is that my kernels have non-standard names, not kernel7.img and kernel8.img
(Need some extra kernel options. And I want to prevent that an end-user could accidently brick their system by running for example rpi-update, which would replace the kernels by stock versions if they had standard names).

[PhilE]

Problem is that my kernels have non-standard names, not kernel7.img and kernel8.img
And I want to prevent that an end-user could accidently brick their system by running for example rpi-update, which would replace the kernels by stock versions if they had standard names).

The upcoming "os_prefix" will let you put your own kernels in a subdirectory (or with a custom name prefix), out of reach of rpi-update.

[MikeDB]

Loaded this up on a new memory card and it seems to do what I want.

BUT ... why is the mouse so sluggish, even on the fastest setting ? On the normal kernal it's fine. Any suggestions what to change to fix it ?

Thanks

[MikeDB]

Is a 64 bit gcc package not available (for compilation on the pi4 - I'm aware of cross-compile options ...) yet, or did I miss it?

Best regards,

Wilfried

Wilfried - Did you come up with a solution to this ? It seems odd to me to have to have an x64 machine to compile anything to run on a Pi.

[Kendek]

Wilfried - Did you come up with a solution to this ? It seems odd to me to have to have an x64 machine to compile anything to run on a Pi.

But there is a solution, just chrooting into an arm64 root (for example, unpack the Ubuntu base tar.gz). Not as comfortable as cross-compile, but easy enough.

[MikeDB]

Wilfried - Did you come up with a solution to this ? It seems odd to me to have to have an x64 machine to compile anything to run on a Pi.

But there is a solution, just chrooting into an arm64 root (for example, unpack the Ubuntu base tar.gz). Not as comfortable as cross-compile, but easy enough.

Sorry I'm not a Linux expert. Are you saying run 64 bit Ubuntu from inside Raspian, then run the 64 bit GCC there, then exit Ubuntu and run the 64 bit code from the special Run command on the menu ?

Seems rather convoluted (and probably needing a larger memory Pi4). I was hoping for something more along the lines of special command lines in Geany.

[Kendek]

Sorry I'm not a Linux expert. Are you saying run 64 bit Ubuntu from inside Raspian, then run the 64 bit GCC there, then exit Ubuntu and run the 64 bit code from the special Run command on the menu ?

Seems rather convoluted (and probably needing a larger memory Pi4). I was hoping for something more along the lines of special command lines in Geany.

The chroot directory is a fully passive environment. But basically yeah, you can run the 64-bit GCC from here and then you can run the compiled program directly on Raspbian. Nothing special, I use this method on Synology routers too, with 256-512MB RAM.

[PhilE]

To explain a little, chroot lets you run a process (an application, script or shell) with any directory as its root. This acts as simple sandbox, but also allows applications that require different system files (libraries, etc.) to be run without needing to add or overwrite system files on the host computer.

[Kendek]

Seems rather convoluted (and probably needing a larger memory Pi4). I was hoping for something more along the lines of special command lines in Geany.

Basic steps for a simple 64-bit compilation:

Prepare the Ubuntu chroot environment:

Code: Select all

mkdir ubuntu
cd ubuntu
wget http://cdimage.ubuntu.com/ubuntu-base/daily/current/eoan-base-arm64.tar.gz
tar -xzf *.tar.gz
cat /etc/resolv.conf >etc/resolv.conf
chroot .
apt update
apt install locales-all build-essential

Then compile your program:

Code: Select all

export CFLAGS="-march=armv8-a+crc -mtune=cortex-a72"
export CXXFLAGS=$CFLAGS
export MAKEFLAGS="-j4"

make

[MikeDB]

To explain a little, chroot lets you run a process (an application, script or shell) with any directory as its root. This acts as simple sandbox, but also allows applications that require different system files (libraries, etc.) to be run without needing to add or overwrite system files on the host computer.

Thanks Phil. So should I just download and run the ARM 64bit GCC package from their website and run it under chroot ? I assume if this works, I can also run Geany in the same chroot or is that not possible ?

(Sorry been a Windows person since before it was released to the general public so new to Linux and what often seems to me its rather long winded ways)

[PhilE]

@MikeDB - I haven't tried running the 64-bit compiler myself, I was just providing some background information. @Kendek's instructions look to be clear, thorough and plausible, so I just you give them a go.

Cross-compilation on the pi (armv7-> armv8) is possibly another option - crosstool-ng makes configuring and installing a cross-compiler fairly painless (in my limited experience).

[MikeDB]

@MikeDB - I haven't tried running the 64-bit compiler myself, I was just providing some background information. @Kendek's instructions look to be clear, thorough and plausible, so I just you give them a go.

Cross-compilation on the pi (armv7-> armv8) is possibly another option - crosstool-ng makes configuring and installing a cross-compiler fairly painless (in my limited experience).

I'm editing DSP code (which is why I like the idea of going to 64 bit - instant ~30% speed up) so I often compile a hundred of times an hour or more as I optimise the algorithms so cross-compiling from another machine becomes a no-go. I wasn't aware of an armv8 compiler that ran on armv7 but will take another look for one.

Thanks for your help
Mike

[fanoush]

There is https://packages.debian.org/buster/gcc- ... -linux-gnu however on the bottom it shows that it is availablle only for some limited set of architectures including i386 and ppc64el (!), it does not include armhf.

[MikeDB]

There is https://packages.debian.org/buster/gcc- ... -linux-gnu however on the bottom it shows that it is availablle only for some limited set of architectures including i386 and ppc64el (!), it does not include armhf.

Yes. I would have expected to be able to find something suitable on
https://developer.arm.com/tools-and-sof ... /downloads
but it always assumes an X86 doing the actual compiling.

Even the $2500/year Arm Development Studio only runs on X86 (Windows or Linux) which seems madness to me. Developing code for an ARM based server must be a nightmare. And I thought at one time ARM were hoping Apple would migrate Macs to ARM architecture but without hosted compilers I don't see how that's possible.

Obviously none of this is the Raspberry Pi Foundation's fault, but I would have thought someone would have developed something far more straightforward by now. I think few would consider developing Windows programs without Visual Studio over the past 20 years or so.

I'll try Kendek's approach tomorrow.

[Gavinmc42]

On Gentoo64 I have the reverse problem, compiling for 32bit Pi's on Aarch64.
Using Buildroot was the first thing that worked for me.

Native Arm compiling?
Run 32bit compilers on 32bit OS, run 64bit on 64bit OS, that works.

[MikeDB]

On Gentoo64 I have the reverse problem, compiling for 32bit Pi's on Aarch64.
Using Buildroot was the first thing that worked for me.

Native Arm compiling?
Run 32bit compilers on 32bit OS, run 64bit on 64bit OS, that works.

Gentoo64 was actually my first port of call for going to 64 bits, but it didn't seem to like my Samsung 4k monitor, flashing the screen on and off every few seconds. Spent a day trying to fix that before going to the Raspian with 64 bit kernal which seems to work ok, but has these other problems.

[sakaki]

On Gentoo64 I have the reverse problem, compiling for 32bit Pi's on Aarch64.
Using Buildroot was the first thing that worked for me.

Native Arm compiling?
Run 32bit compilers on 32bit OS, run 64bit on 64bit OS, that works.

Gentoo64 was actually my first port of call for going to 64 bits, but it didn't seem to like my Samsung 4k monitor, flashing the screen on and off every few seconds. Spent a day trying to fix that before going to the Raspian with 64 bit kernal which seems to work ok, but has these other problems.

If your monitor currently works in Raspbian, then it is likely to be a combination of the kernel + RPi boot firmware versions causing the flashing issues you experienced. Both have been going through a rapid evolution since the RPi4 was launched.

You can bring both up-to-date on Gentoo as follows:

Code: Select all

demouser@pi64 ~ $ sudo emaint sync --repo genpi64
demouser@pi64 ~ $ sudo emerge -v1u bcm2711-kernel-bis-bin

(Updating the kernel binary package - in this case, to 4.19.76.20191008 - will also automatically pull in the boot firmware that was current at that time).

If you do this and ensure your /boot/config.txt contains the same HDMI-related settings on Gentoo as on your working Raspbian system, then it should just work under Gentoo also.

hth, sakaki

[MikeDB]

If your monitor currently works in Raspbian, then it is likely to be a combination of the kernel + RPi boot firmware versions causing the flashing issues you experienced. Both have been going through a rapid evolution since the RPi4 was launched.

You can bring both up-to-date on Gentoo as follows:

Code: Select all

demouser@pi64 ~ $ sudo emaint sync --repo genpi64
demouser@pi64 ~ $ sudo emerge -v1u bcm2711-kernel-bis-bin

(Updating the kernel binary package - in this case, to 4.19.76.20191008 - will also automatically pull in the boot firmware that was current at that time).

If you do this and ensure your /boot/config.txt contains the same HDMI-related settings on Gentoo as on your working Raspbian system, then it should just work under Gentoo also.

hth, sakaki

Ok thanks - I'll give it another go, although I thought it would be up to date as it was a fresh download of everything to a new memory card.

[sakaki]

Ok thanks - I'll give it another go, although I thought it would be up to date as it was a fresh download of everything to a new memory card.

The current (v1.5.1) image was released on 2nd September 2019, and ships with a 4.19.67.20190827 kernel.

The kernel and boot firmware have been updated several times since then. So if you write this image, boot it, and then perform the update as described in my post above, you should be good to go.

If your particular monitor is flashing right from the first usage under v1.5.1 Gentoo however, you might need to temporarily connect it to another monitor / TV, so you can see the screen / perform the kernel update. Alternatively in this case, you can set a 'safe' mode temporarily, by editing config.txt in the first partition (which can be done on any PC) and uncommenting the following hdmi_group and hdmi_mode lines, so they read:

Code: Select all

# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=1
hdmi_mode=1

Or alternatively, uncomment the hdmi_safe setting in that file, as follows:

Code: Select all

# uncomment if you get no picture on HDMI for a default "safe" mode
hdmi_safe=1

Either approach should give you a very clunky-looking VGA display, but should also work on just about any external monitor, and you'll at least be able to get in, start a console, and update the kernel and boot firmware as described. Once that's done, you can reboot and then run the bundled GUI tool (Applications -> Settings -> RPi Config Tool) to choose an appropriate resolution.

(For avoidance of doubt for anyone else reading this, most monitors appear to work fine under the shipped v1.5.1 kernel and boot firmware, it is just a few where an update like this is required.)

best, sakaki

[gubertoli]

Was any special kernel configuration used to build this 64-bit kernel?

https://github.com/raspberrypi/linux/bl ... _defconfig

After successfully moving to aarch64 through rpi-update and changing config.txt, how to correctly rebuild the kernel ? (I have to build to include new modules support)

I followed official RPi kernel building documentation for local build, just changing to KERNEL=kernel8 but it broke the Raspbian.

Please, any advice ?

[incognitum]

I followed official RPi kernel building documentation for local build, just changing to KERNEL=kernel8 but it broke the Raspbian.

You will need a real 64-bit operating system (e.g. OpenSuse), and not Raspbian, if you want to do a native build.

[Kendek]

After successfully moving to aarch64 through rpi-update and changing config.txt, how to correctly rebuild the kernel ? (I have to build to include new modules support)

Compile 64-bit kernel on Raspbian:

Prepare for compilation:

Code: Select all

sudo -i
mkdir ubuntu64
cd ubuntu64
wget http://cdimage.ubuntu.com/ubuntu-base/releases/eoan/release/ubuntu-base-19.10-base-arm64.tar.gz
tar -xzf *.tar.gz
cat /etc/resolv.conf >etc/resolv.conf

mount -B /dev dev
mount -B /proc proc
mount -B /sys sys
mount -t tmpfs tmp tmp
mount -B /boot boot
mkdir lib/modules
mount -B /lib/modules lib/modules

chroot .
apt update
apt install locales-all wget unzip build-essential bc bison flex libssl-dev kmod
wget https://github.com/raspberrypi/linux/archive/rpi-4.19.y.zip
unzip *.zip
cd linux-rpi-4.19.y

Compile and install the kernel:

Code: Select all

export KCFLAGS="-march=armv8-a+crc -mtune=cortex-a72"
export MAKEFLAGS="-j4"

make bcm2711_defconfig
make Image modules dtbs

INSTALL_MOD_STRIP=1 make modules_install
cp arch/arm64/boot/dts/broadcom/*.dtb /boot
cp arch/arm64/boot/dts/overlays/*.dtb* /boot/overlays
cp arch/arm64/boot/Image /boot/kernel8.img

[hawk_ing]

hi,
how would it be possible to execute aarch64 binaries after switching to 64bit kernel whithout installing a complete guest OS?

Code: Select all

pi@rpi:~ $ /tmp/test.aarch64
-bash: /tmp/test.aarch64: No such file or directory

Code: Select all

pi@rpi:~ $ uname -a
Linux rpi 4.19.75-v8+ #1270 SMP PREEMPT Tue Sep 24 18:59:17 BST 2019 aarch64 GNU/Linux

Code: Select all

pi@rpi:~ $ file $(which ls)
/bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=67a394390830ea3ab4e83b5811c66fea9784ee69, stripped

Code: Select all

pi@rpi:~ $ sudo dpkg --add-architecture aarch64
pkg-config-dpkghook: Warning: Architecture aarch64 not defined in architecture tables, ignored

BR,
hawk