The state of Arm64 on Raspberry Pi (and its Documentation

[Ralph Aichinger]

Hello!

With a little bit of envy I discovered that Ubuntu not only runs
in a vanilla flavour on the Raspberry Pi, but that there is
a very straightforward download page and stuff seems reasonably
documented. In both 32 and 64 bit.

https://ubuntu.com/download/raspberry-pi

In comparison to this Debian's Arm64 wiki page lists tons of
obsolete Arm64 hardware that is no longer available, but does
not document the one Arm64 system that is the easiest to buy
in shops very well, in my opinion.

https://wiki.debian.org/Arm64Port

Now I do understand that the binary blobs needed to use the
Raspberry Pi are a no-no for some, but from a pragmatic
standpoint the Pi is the Arm64 system sold in the highest
numbers, except for cell phones, probably.

It is not that I want to complain, writing docs is a lot of
work, an has to be done by people probably burdened with other
work too (after all they have to understand what they describe).

Is there some "official" Debian documentation on how to
install aarch64 Debian on the Pi 3 or 4 in an "official" (i.e.
diverging as little as possible from Debian standards) way?

Does installing Debian on top of UEFI firmware work yet
in practice

https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4

or should I start from somewhere else? I do not need graphics,
a purely headless setup is fine by me.

Is there some way for a somewhat experienced sysadmin to
help in documenting this stuff, trying out things, filing bugs, etc?

I hope the tone of this message does not come across as demanding,
pushy or unfriendly, I really do appreciate all your work in
the arm port, I have been using arm devices as my servers at
home for years now, and I am very grateful that these devices
can run with a sane Debian based OS. But I think using
vanilla Debian on the Pi should be a lot easier than it is
now.

Thanks in advance,
Ralph Aichinger

[Wookey]

Post by Ralph Aichinger
In comparison to this Debian's Arm64 wiki page lists tons of
obsolete Arm64 hardware that is no longer available, but does
not document the one Arm64 system that is the easiest to buy
in shops very well, in my opinion.
https://wiki.debian.org/Arm64Port

It's a wiki - feel free to update it.

Post by Ralph Aichinger
Is there some "official" Debian documentation on how to
install aarch64 Debian on the Pi 3 or 4 in an "official" (i.e.
diverging as little as possible from Debian standards) way?

Yes: The Pi1,2,and 3 docs are linked from here:
https://wiki.debian.org/InstallingDebianOn
https://wiki.debian.org/RaspberryPi3 being the first arm64 hardware.

I gather there is a Pi4, so if someone could do that it would be helpful.

No doubt it could all do with some updating as I expect support has improved.

Post by Ralph Aichinger
Does installing Debian on top of UEFI firmware work yet
in practice

Yes it works pretty well.

Post by Ralph Aichinger
https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4
or should I start from somewhere else? I do not need graphics,
a purely headless setup is fine by me.
Is there some way for a somewhat experienced sysadmin to
help in documenting this stuff, trying out things, filing bugs, etc?

Yep - get an account on the wiki and start editing.

Or file bugs if things are actually broken, but working in say,
Rasbian or ubuntu and we could fix it (i.e. it's not due to non-free
blobs)

Wookey

[Pete Batard]

Hi Ralph,

Post by Ralph Aichinger
Is there some "official" Debian documentation on how to
install aarch64 Debian on the Pi 3 or 4 in an "official" (i.e.
diverging as little as possible from Debian standards) way?

Not from Debian (AFAIK) but, for the Pi 3, you will find some posts on
the Raspberry Pi forums:
https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=249449&sid=beb9a5a5fc456deef7c00f1ffc0be1df
as well as a corresponding blog post at
https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html.

I am the author of both these posts.

For the Pi 4, the situation is a bit more tricky (see below).

Post by Ralph Aichinger
Does installing Debian on top of UEFI firmware work yet
in practice

It does. Pi 3 in full UEFI mode should not be much of an issue if you
follow the guides I pointed to.

Pi 4 is a bit more problematic because the most *CRUCIAL* factor is that
we are missing a working network driver in Debian, which makes netinst a
very dicey issue.

I have tried to bring attention to it a few times (the thing is, Debian
10.3.0 *could* have had a working network driver for the Raspberry Pi 4,
so that folks could perform netinst from vanilla ISOs), but, unless I am
very mistaken and the next Debian *installer* uses a 5.6 kernel, I don't
think the Debian maintainers have quite yet grasped that the genet ACPI
driver *must* be retrofitted into the Debian 4.x kernel if they want Pi
4 installation support.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950578

Post by Ralph Aichinger
https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4
or should I start from somewhere else?

The more appropriate place to start is: https://github.com/pftf/RPi4
which provides regularly updated *EXPERIMENTAL* UEFI firmware images for
the Pi 4.

Using such an image, you can pretty much get Debian installed on a USB
flash drive, as you would do on a regular x86 UEFI based PC, along with
networking if you manage to update your kernel to very latest. But,
again, the main issue right now is that, unless the installer's image
kernel is patched, you will sadly not be able to perform a netinst, so
you have to jump through a few annoying hoops to get networking.

The one things that need to be pointed out are:
- You will be limited to 3 GB of RAM on 4 GB models (requires a kernel
patch such as the one from https://github.com/pftf/RPi4/issues/20 to be
upstreamed)
- You will not get SD card support in Linux, because there again, an
ACPI driver is missing (https://github.com/pftf/RPi4/issues/26).

Post by Ralph Aichinger
I do not need graphics, a purely headless setup is fine by me.

Graphics should work. Video acceleration is another story, but X run
without much trouble.

Post by Ralph Aichinger
Is there some way for a somewhat experienced sysadmin to
help in documenting this stuff, trying out things, filing bugs, etc?

If you want to help, maybe report that the bug I pointed out above
affects you too, since, if you can live without SD support, it's pretty
much the one thing that stands in the way of being able to use the
vanilla netinst ISOs on the Pi 4.

Post by Ralph Aichinger
I hope the tone of this message does not come across as demanding,
pushy or unfriendly, I really do appreciate all your work in
the arm port, I have been using arm devices as my servers at
home for years now, and I am very grateful that these devices
can run with a sane Debian based OS. But I think using
vanilla Debian on the Pi should be a lot easier than it is
now.

Amen!

We're doing what we can to make that happen on the UEFI side, and I
believe we are already there in terms of providing a usable means of
installing and running vanilla Debian on the Pi 4, at least from USB.

The only thing that's missing, really, is for Debian folks to integrate
the retrofitted Genet network driver, which we submitted 2 months ago,
in the vanilla aarch64 installation images...

Regards,

/Pete

[Gene Heskett]

This post might be inappropriate. Click to display it.

[Pete Batard]

Hi Gene,

Post by Gene Heskett

Post by Pete Batard
The only thing that's missing, really, is for Debian folks to
integrate the retrofitted Genet network driver, which we submitted 2
months ago, in the vanilla aarch64 installation images...

Tweaks my curiosity. That driver doesn't exist in the raspi armhf build
from raspbian, yet the networking is flawless. I run a host file based
net config, and it Just works.

That's because it uses Device Tree, and the DT based version of the
Genet driver has been in the kernel for a while, so it should be mostly
okay.

But we have to use ACPI in UEFI for various reasons. The Pi 4 has a few
quirks, especially when it comes to DMA and USB, that paradoxically make
an ACPI implementation easier to sort out compared to DT. This doesn't
mean we won't support DT, just that ACPI is more suitable for now. So we
need ACPI bindings in Genet, whereas the existing Genet driver is
intended as a DT mode driver.

As a matter of fact, much of what the proposed patch does is add ACPI
support to the existing driver.

Also please bear in mind that the Pi Foundation adds a lot of quirks to
their 32-bit kernels, some of which have yet to find their way in
mainline aarch64. Raspbian is a very custom as a kernel.

Regards,

/Pete

[deloptes]

Post by Pete Batard
That's because it uses Device Tree, and the DT based version of the
Genet driver has been in the kernel for a while, so it should be mostly
okay.
But we have to use ACPI in UEFI for various reasons. The Pi 4 has a few
quirks, especially when it comes to DMA and USB, that paradoxically make
an ACPI implementation easier to sort out compared to DT. This doesn't
mean we won't support DT, just that ACPI is more suitable for now. So we
need ACPI bindings in Genet, whereas the existing Genet driver is
intended as a DT mode driver.
As a matter of fact, much of what the proposed patch does is add ACPI
support to the existing driver.
Also please bear in mind that the Pi Foundation adds a lot of quirks to
their 32-bit kernels, some of which have yet to find their way in
mainline aarch64. Raspbian is a very custom as a kernel.

Very interesting notes. I was planning to try debian kernel or custom kernel
build on debian. What I tried recently is do raspbian network boot
(diskless) and yesterday did debootstrap from within raspbian of a debian
buster armhf. The supplied kernel did not work (of course), so I was going
to look into that, but I am wondering now, after reading this, if I should
take arm64 instead of armhf.

For now I use the raspbian kernel in debian, but as you say it is 32 and I
am not into the details, so thank you for the hints.

Does it mean one should prefer arm64 and take a newer 5.x kernel?

regards

[Ralph Aichinger]

Post by deloptes
For now I use the raspbian kernel in debian, but as you say it is 32 and I
am not into the details, so thank you for the hints.

I am probably not telling news, but there is a 64bit kernel in
Raspbian. You just have to boot the kernel8.img, it is aarch64.

***@pi:~# uname -a
Linux pi.h5.or.at 4.19.108-v8+ #1298 SMP PREEMPT Fri Mar 6 18:15:51 GMT 2020
+aarch64 GNU/Linux

There is not 64bit userland, though.

/ralph

[Florian La Roche]

Hello deloptes,

Post by deloptes

Post by Pete Batard
Also please bear in mind that the Pi Foundation adds a lot of quirks to
their 32-bit kernels, some of which have yet to find their way in
mainline aarch64. Raspbian is a very custom as a kernel.

Very interesting notes. I was planning to try debian kernel or custom kernel
build on debian. What I tried recently is do raspbian network boot
(diskless) and yesterday did debootstrap from within raspbian of a debian
buster armhf. The supplied kernel did not work (of course), so I was going
to look into that, but I am wondering now, after reading this, if I should
take arm64 instead of armhf.
For now I use the raspbian kernel in debian, but as you say it is 32 and I
am not into the details, so thank you for the hints.
Does it mean one should prefer arm64 and take a newer 5.x kernel?

I am using a 5.6.2 arm64 kernel without any GUI on a raspi3, works for me.

You can use the current Debian kernel and add also current
raspberry-pi-patches to
recompile the kernel. A script doing this is available here (also
works as native compile
as well as a cross-compile):
https://github.com/laroche/arm-devel-infrastructure/blob/master/vmdb2-debian/kernel5.sh

Compiled binary kernels (for armhf and arm64) can also be downloaded
for kernel 5.4.20, 5.4.28, 5.5.15, 5.6.2 from:
https://github.com/laroche/arm-devel-infrastructure/releases
I often try to also compile newer upstream releases, even if the
Debian kernel sources
are not yet rebased (mostly just disabling patches completely if I
don't need them).

Instead of using the Debian installer, I can also recommend to use
"vmdb2" to create a
ready-to-use image. That can also be generated on any normal
amd64/x86_64-PC and does
not require a running arm64/armhf setup:
https://github.com/laroche/arm-devel-infrastructure/blob/master/vmdb2-debian/debian-rpi3-arm64.yaml

best regards,

Florian La Roche

[Alan Corey]

Can't be a real program, it doesn't have a man page. I just installed
it (on a Pi under Raspbian) because I'm looking for a way to put
Buster or Bullseye on my Pinebook Pro SSD. Which is going to need
drivers and firmware. The best thing I've seen is
https://github.com/daniel-thompson/pinebook-pro-debian-installer but
it uses GPT. It's a script for running debootstrap and it gets the
drivers and firmware from somewhere. I just need to figure out how to
not have it use GPT.

Anyway I don't see anything in this vmdb2 about drivers and firmware.
vmdb2 --help gets me:
Usage: vmdb2 [options]

Options:
--version show program's version number and exit
-h, --help show this help message and exit
--generate-manpage=TEMPLATE
fill in manual page TEMPLATE
--output=FILE write output to FILE, instead of standard output
--image=FILE create image file FILE
-v, --verbose verbose output
--no-verbose opposite of --verbose
--size=SIZE size of output image
--rootfs-tarball=FILE
store rootfs cache tar archives in FILE

Configuration files and settings:
--dump-setting-names
write out all names of settings and quit
--dump-config write out the entire current configuration
--no-default-configs
clear list of configuration files to read
--config=FILE add FILE to config files
--list-config-files
list all possible config files
--help-all show all options

Logging:
--log=FILE write log entries to FILE (default is to not write log
files at all); use "syslog" to log to system log,
"stderr" to log to the standard error output, or
"none" to disable logging
--log-level=LEVEL log at LEVEL, one of debug, info, warning, error,
critical, fatal (default: debug)
--log-max=SIZE rotate logs larger than SIZE, zero for never (default:
0)
--log-keep=N keep last N logs (10)
--log-mode=MODE set permissions of new log files to MODE (octal;
default 0600)

Peformance:
--dump-memory-profile=METHOD
make memory profiling dumps using METHOD, which is one
of: none, or simple (no meliae support
anymore)(default: simple)
--memory-dump-interval=SECONDS
make memory profiling dumps at least SECONDS apart

Post by Florian La Roche
Hello deloptes,

Post by deloptes

Post by Pete Batard
Also please bear in mind that the Pi Foundation adds a lot of quirks to
their 32-bit kernels, some of which have yet to find their way in
mainline aarch64. Raspbian is a very custom as a kernel.

Very interesting notes. I was planning to try debian kernel or custom kernel
build on debian. What I tried recently is do raspbian network boot
(diskless) and yesterday did debootstrap from within raspbian of a debian
buster armhf. The supplied kernel did not work (of course), so I was going
to look into that, but I am wondering now, after reading this, if I should
take arm64 instead of armhf.
For now I use the raspbian kernel in debian, but as you say it is 32 and I
am not into the details, so thank you for the hints.
Does it mean one should prefer arm64 and take a newer 5.x kernel?

I am using a 5.6.2 arm64 kernel without any GUI on a raspi3, works for me.
You can use the current Debian kernel and add also current
raspberry-pi-patches to
recompile the kernel. A script doing this is available here (also
works as native compile
https://github.com/laroche/arm-devel-infrastructure/blob/master/vmdb2-debian/kernel5.sh
Compiled binary kernels (for armhf and arm64) can also be downloaded
https://github.com/laroche/arm-devel-infrastructure/releases
I often try to also compile newer upstream releases, even if the
Debian kernel sources
are not yet rebased (mostly just disabling patches completely if I
don't need them).
Instead of using the Debian installer, I can also recommend to use
"vmdb2" to create a
ready-to-use image. That can also be generated on any normal
amd64/x86_64-PC and does
https://github.com/laroche/arm-devel-infrastructure/blob/master/vmdb2-debian/debian-rpi3-arm64.yaml
best regards,
Florian La Roche

[deloptes]

This post might be inappropriate. Click to display it.

[Arnd Bergmann]

Post by Pete Batard
Hi Gene,

Post by Gene Heskett

Post by Pete Batard
The only thing that's missing, really, is for Debian folks to
integrate the retrofitted Genet network driver, which we submitted 2
months ago, in the vanilla aarch64 installation images...

Tweaks my curiosity. That driver doesn't exist in the raspi armhf build
from raspbian, yet the networking is flawless. I run a host file based
net config, and it Just works.

That's because it uses Device Tree, and the DT based version of the
Genet driver has been in the kernel for a while, so it should be mostly
okay.
But we have to use ACPI in UEFI for various reasons. The Pi 4 has a few
quirks, especially when it comes to DMA and USB, that paradoxically make
an ACPI implementation easier to sort out compared to DT. This doesn't
mean we won't support DT, just that ACPI is more suitable for now. So we
need ACPI bindings in Genet, whereas the existing Genet driver is
intended as a DT mode driver.

There is no need to use ACPI when using the UEFI boot path, that can
just as well work with a normal DT. There is also no need to use UEFI for
booting a 64 bit kernel, most bootloaders only use the native ARM64
boot protocol, although u-boot can do either one these days.

Do you have a pointer to what the issues with USB and DMA are?

Arnd

[Pete Batard]

Hi Arnd,

Post by Arnd Bergmann
There is no need to use ACPI when using the UEFI boot path, that can
just as well work with a normal DT.

But there's also no reason to declare that DT should be the only way to
boot a platform.

Post by Arnd Bergmann
There is also no need to use UEFI for
booting a 64 bit kernel

Correct. However, it can provide a more familiar user experience and
tends to be better supported. For instance, I'm not sure you can get a
full graphical GRUB menu from the other solutions (but I haven't really
investigated).

In case this is your impression, it's not because I am contributing to
the UEFI that I am advocating UEFI as the "one true way" to boot a platform.

My experience however is that it may make it easier for end-users to run
and keep a distro updated, especially when modern Linux distros support
ESPs and EFI GRUB as a means to customize boot options, such as the
ability to select kernels or provide kernel options through a GUI, as is
the case on an x86 PC.

But again, we're not pitting one boot method against one another. We're
only providing some options and it's up to the users to choose which
method they think suits them best.

OP specifically pointed to the UEFI firmware, and since I'm somewhat
familiar with it, I tried to provide some info on that.

Post by Arnd Bergmann
Do you have a pointer to what the issues with USB and DMA are?

Devices that sit behind the GPU/Videocore can only access 1 GB, and
require a translation, and (from what we gather) there happens to be a
silicon bug that forces devices that don't sit behind GPU (USB, Genet)
to limit DMA to 3 GB. There is also non-cache coherency for XHCI over
PCIe and some weird ECAM, if I recall correctly.

Some of these are also mentioned on lkml such as in:
https://lkml.org/lkml/2019/9/6/352

Regards,

/Pete

[Arnd Bergmann]

Post by Pete Batard
Hi Arnd,

Post by Arnd Bergmann
There is no need to use ACPI when using the UEFI boot path, that can
just as well work with a normal DT.

But there's also no reason to declare that DT should be the only way to
boot a platform.

It took us long enough to get all the ARMv7 platforms to agree on
one way to pass platform information, I certainly don't want to see
one platform that runs both 32-bit and 64-bit kernels to use two
different methods depending which kernel you run.

We do have support for ACPI on server platforms, but that doesn't
make it a good idea for embedded SoCs.

Post by Pete Batard

Post by Arnd Bergmann
Do you have a pointer to what the issues with USB and DMA are?

Devices that sit behind the GPU/Videocore can only access 1 GB, and
require a translation, and (from what we gather) there happens to be a
silicon bug that forces devices that don't sit behind GPU (USB, Genet)
to limit DMA to 3 GB. There is also non-cache coherency for XHCI over
PCIe and some weird ECAM, if I recall correctly.

That sounds exactly like all the issues that we have ways to express
in DT already, but that ACPI specifically assumes work as expected.

For the DMA range settings, there is a 'dma-ranges' property to
express how addresses become visible on the parent bus. The
"dma-coherent" property can be used to list coherency per
dma master, and the pci-host driver supports arbitrary config space
access when using DT.

Post by Pete Batard
https://lkml.org/lkml/2019/9/6/352

Ok.

Arnd

[Ralph Aichinger]

Hi Pete!

Not from Debian (AFAIK) but, for the Pi 3, you will find some posts on the
Raspberry Pi forums: https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=249449&sid=beb9a5a5fc456deef7c00f1ffc0be1df
as well as a corresponding blog post at
https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html.
I am the author of both these posts.

Would it be OK for you, if I "mine" these postings for putting them
somewhere on the wiki?

It does. Pi 3 in full UEFI mode should not be much of an issue if you follow
the guides I pointed to.

OK

Pi 4 is a bit more problematic because the most *CRUCIAL* factor is that we
are missing a working network driver in Debian, which makes netinst a very
dicey issue.

Does this also hold for USB connected adapters (as a measure to install
while kernel problems are ironed out)? Or will a USB3 connected adapter
that works in Raspbian work with UEFI too?

I have tried to bring attention to it a few times (the thing is, Debian
10.3.0 *could* have had a working network driver for the Raspberry Pi 4, so
that folks could perform netinst from vanilla ISOs), but, unless I am very
mistaken and the next Debian *installer* uses a 5.6 kernel, I don't think
the Debian maintainers have quite yet grasped that the genet ACPI driver
*must* be retrofitted into the Debian 4.x kernel if they want Pi 4
installation support.

I assume Ubuntu does include these patches? Or do they go the other
way of device-tree and whatever is used there to boot instead of GRUB
and UEFI, especially for arm64?

The more appropriate place to start is: https://github.com/pftf/RPi4 which
provides regularly updated *EXPERIMENTAL* UEFI firmware images for the Pi 4.

Thanks! To me the Pi 4 is so much more attractive, as 4GB make a lot of sense
for a 64bit system.

- You will be limited to 3 GB of RAM on 4 GB models (requires a kernel patch
such as the one from https://github.com/pftf/RPi4/issues/20 to be
upstreamed)

OK, still better than 1GB ;)

- You will not get SD card support in Linux, because there again, an ACPI
driver is missing (https://github.com/pftf/RPi4/issues/26).

For a full vanilla Debian install, I probably would use an external
SSD or HD anyway, so not much of a problem to me.

If you want to help, maybe report that the bug I pointed out above affects
you too, since, if you can live without SD support, it's pretty much the one
thing that stands in the way of being able to use the vanilla netinst ISOs
on the Pi 4.

OK

We're doing what we can to make that happen on the UEFI side, and I believe
we are already there in terms of providing a usable means of installing and
running vanilla Debian on the Pi 4, at least from USB.

I got an extra Pi 4 today, and will certainly try it.

Thanks for your reply,
/ralph

[Pete Batard]

Post by Ralph Aichinger

Not from Debian (AFAIK) but, for the Pi 3, you will find some posts on the
Raspberry Pi forums: https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=249449&sid=beb9a5a5fc456deef7c00f1ffc0be1df
as well as a corresponding blog post at
https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html.
I am the author of both these posts.

Would it be OK for you, if I "mine" these postings for putting them
somewhere on the wiki?

If you could do that that would be great! Feel free to use whatever data
you want from these.

Post by Ralph Aichinger

Pi 4 is a bit more problematic because the most *CRUCIAL* factor is that we
are missing a working network driver in Debian, which makes netinst a very
dicey issue.

Does this also hold for USB connected adapters (as a measure to install
while kernel problems are ironed out)?

It "should" work with USB network adapters that are natively supported.
But I haven't tested. Feel free to report how it goes.

Post by Ralph Aichinger
Or will a USB3 connected adapter
that works in Raspbian work with UEFI too?

I don't expect that the Raspberry Pi Foundation touched the drivers for
hardware they didn't produce, so if an external adapter works in
Raspbian, it'll probably work in Debian.

Post by Ralph Aichinger

I have tried to bring attention to it a few times (the thing is, Debian
10.3.0 *could* have had a working network driver for the Raspberry Pi 4, so
that folks could perform netinst from vanilla ISOs), but, unless I am very
mistaken and the next Debian *installer* uses a 5.6 kernel, I don't think
the Debian maintainers have quite yet grasped that the genet ACPI driver
*must* be retrofitted into the Debian 4.x kernel if they want Pi 4
installation support.

I assume Ubuntu does include these patches? Or do they go the other
way of device-tree and whatever is used there to boot instead of GRUB
and UEFI, especially for arm64?

I haven't tested Ubuntu, but since the Pi 4 UEFI firmware default to
ACPI (by disabling DT - there's an option in the firmware UI to
re-enable it), then if you can get networking through genet, then they
must have applied the recent ACPI changes to their driver, because it's
only very recently that those were integrated in mainline.

But I would say that if it works, they're probably working around the
tianocore UEFI firmware altogether and using a different boot method,
because we've only gotten it in a somewhat working state towards the end
of January this year.

Post by Ralph Aichinger

- You will not get SD card support in Linux, because there again, an ACPI
driver is missing (https://github.com/pftf/RPi4/issues/26).

For a full vanilla Debian install, I probably would use an external
SSD or HD anyway, so not much of a problem to me.

Yup. I've been running Debian 10.3 on a Pi 4 with recompiled 5.5 and
4.19 kernels (for networking), against a fast USB 3.0 drive, and it
makes quite a difference to have file system I/O that is blazingly fast
at last! Where possible, you definitely want to use USB over SD.

Post by Ralph Aichinger
I got an extra Pi 4 today, and will certainly try it.

Great. If you have any questions or feel the guides are missing some
elements, don't hesitate to let me know.

Regards,

/Pete

[Paul Wise]

Post by Ralph Aichinger
...
Does installing Debian on top of UEFI firmware work yet
in practice
https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4

Please note that Debian does not have edk2-platforms packaged yet, so
you will need to either build it yourself or use builds done by
someone else to install/update the boot firmware. In case you want to
help package it, check out these links:

https://mentors.debian.net/intro-maintainers
https://lists.debian.org/debian-efi/
https://salsa.debian.org/efi-team/

[Lucas Nussbaum]

Post by Ralph Aichinger
Hello!
With a little bit of envy I discovered that Ubuntu not only runs
in a vanilla flavour on the Raspberry Pi, but that there is
a very straightforward download page and stuff seems reasonably
documented. In both 32 and 64 bit.
https://ubuntu.com/download/raspberry-pi

Note that this uses a custom kernel, not the upstream (vanilla) kernel.


For the RPI 4, I've been working on this, and documenting my progress on
https://wiki.debian.org/RaspberryPi4

What works:

1) it's possible to run Debian 10 on the RPI4 with two packages from
unstable: raspi-firmware, and the kernel (5.5). Once they will be
backported, it will sound even better. I don't know if there are plans
to backport support to 4.19 (I doubt it).

2) images can be generated similarly to what is done for other RPI
versions, see
https://salsa.debian.org/raspi-team/image-specs/-/compare/master...rpi4
(it's just a WIP branch at this point)

A good pointer for the status of the linux kernel is
https://github.com/lategoodbye/rpi-zero/issues/43

There's a #debian-raspberrypi channel on IRC (OFTC), too.

Lucas

[basti]

Hello,
i have try to boot rpi4 with real debian kernel.

I have try:
- build kernel from source -> boot with dtb from ubuntu, but do not find
an sdcard
- use uefi -> install via debian installer, does not boot after install
is finished, can't find a boot media

can please someone share a minimal image to boot aarch64 on rpi4?

Best regards

[deloptes]

Post by basti
can please someone share a minimal image to boot aarch64 on rpi4?

Why using the term aarch64 and what is wrong with kernel8.img? I was told it
is the arm64 one and I think I tried it

[Tixy]

Post by deloptes

Post by basti
can please someone share a minimal image to boot aarch64 on rpi4?

Why using the term aarch64 and what is wrong with kernel8.img? I was
told it is the arm64 one and I think I tried it

AArch64 is the abbreviation used by ARM for their 64-bit ISA, and is
also used used by projects like GCC.

[deloptes]

Post by Tixy
AArch64 is the abbreviation used by ARM for their 64-bit ISA, and is
also used used by projects like GCC.

I read this, but it said that the naming was merged to arm64 which initiated
from Apple. I am confused, cause the article said you can use both in GCC
for same thing

[Tixy]

Post by deloptes

Post by Tixy
AArch64 is the abbreviation used by ARM for their 64-bit ISA, and is
also used used by projects like GCC.

I read this, but it said that the naming was merged to arm64 which initiated
from Apple. I am confused, cause the article said you can use both in GCC
for same thing

Yeh they're probably interchangeable. AArch64/32 are Arm's 'official'
ISA names and Linux kernel engineers mostly thought they sucked [1].
Don't know what this has to do with Apple, unless it's an LLVM arch
naming thing?

[deloptes]

Post by Tixy
Don't know what this has to do with Apple, unless it's an LLVM arch
naming thing?

Yes LLVM.

I was planning to build our favorite desktop on arm64 for fun, but being
preoccupied now, could move forward, so this topic is intrigueing me as to
what architecture to start and build under debian.

Interesting it says here arm64
https://www.debian.org/releases/oldstable/i386/ch02s01.html.en

but here aarch64
https://www.debian.org/releases/stable/

But
https://www.debian.org/releases/oldstable/arm64/index.html.en

and another but
aarch64 links to https://www.debian.org/ports/arm/

where you can go to
https://wiki.debian.org/Arm64Port

Crazy! No wonder I got confused.

So what can the community rule out here. Is it aarch64 and arm64 the same or
not?

thanks

regards

[deloptes]

Post by deloptes
So what can the community rule out here. Is it aarch64 and arm64 the same
or not?

I think this is the answer
https://wiki.debian.org/Arm64Port#Nomenclature_and_defines



If your package does architecture-specific things explicitly then you will
need to understand what names to use in tests.

The gnu name for the architecture (as given to configure) is
aarch64-linux-gnu.

The debian name for the architecture is arm64

GCC defines __aarch64__ for the architecture.

Be careful of things which check for arm* in debian architecture tests, as
it is usually wrong to do the same thing for arm64 as for 32-bit arm
(arm/armel/armhf). In general, if you are not sure, you should do the same
thing as on amd64 as that matches quite closely (64 bit, little endian,
32-bit ints and floats, 64-bit pointers, longs and doubles).

Check the link below for 'upstream package porting' to see if your package
has had porting attention from Linaro.

There is also a big-endian version of the architecture/ABI:
aarch64_be-linux-gnu but we're not supporting that in Debian (so there is
no corresponding Debian architecture name) and hopefully will never have
to. Nevertheless you might want to check for this by way of completeness in
upstream code.

[Lennart Sorensen]

Post by deloptes
I think this is the answer
https://wiki.debian.org/Arm64Port#Nomenclature_and_defines
If your package does architecture-specific things explicitly then you will
need to understand what names to use in tests.
The gnu name for the architecture (as given to configure) is
aarch64-linux-gnu.
The debian name for the architecture is arm64
GCC defines __aarch64__ for the architecture.
Be careful of things which check for arm* in debian architecture tests, as
it is usually wrong to do the same thing for arm64 as for 32-bit arm
(arm/armel/armhf). In general, if you are not sure, you should do the same
thing as on amd64 as that matches quite closely (64 bit, little endian,
32-bit ints and floats, 64-bit pointers, longs and doubles).
Check the link below for 'upstream package porting' to see if your package
has had porting attention from Linaro.
aarch64_be-linux-gnu but we're not supporting that in Debian (so there is
no corresponding Debian architecture name) and hopefully will never have
to. Nevertheless you might want to check for this by way of completeness in
upstream code.

Well a lot of people looking for 64bit arm support would look for arm64,
while aarch64 is technically the name, it sure doesn't scream "arm"
at a user.

Besides there is i386 which intel retroactively called IA32, and then to
confuse everyone decided IA64 was itanium, not the 64bit version of x86.
Lots of people tried to install ia64 debian on 64 bit x86 machines
over the years. Debian calls it amd64 while gcc calls it x86_64 and
intel calls it em64t or maybe now they changed it to "intel 64", not
sure actually.

[Nate Bargmann]

Post by Lennart Sorensen
Besides there is i386 which intel retroactively called IA32, and then to
confuse everyone decided IA64 was itanium, not the 64bit version of x86.
Lots of people tried to install ia64 debian on 64 bit x86 machines
over the years. Debian calls it amd64 while gcc calls it x86_64 and
intel calls it em64t or maybe now they changed it to "intel 64", not
sure actually.

It does seem strange to install the 'amd64' distro on my Intel Core
boxes. As I was aware of the history behind the name it made sense.
x86_64 is a bit more difficult to type but seems less ambiguous. Oh
well.

- Nate

[Lennart Sorensen]

Post by Nate Bargmann
It does seem strange to install the 'amd64' distro on my Intel Core
boxes. As I was aware of the history behind the name it made sense.
x86_64 is a bit more difficult to type but seems less ambiguous. Oh
well.

Too bad it has an underscore which isn't permitted in architecture names
in debian since it is the field separator in the package filename. :)

[Wookey]

Post by Lennart Sorensen

Post by Nate Bargmann
It does seem strange to install the 'amd64' distro on my Intel Core
boxes. As I was aware of the history behind the name it made sense.
x86_64 is a bit more difficult to type but seems less ambiguous. Oh
well.

Too bad it has an underscore which isn't permitted in architecture names
in debian since it is the field separator in the package filename. :)

We can deal with that. gcc and pkgconfig already have to when building
cross-tools which have triplets in the name:
pkg-config-x86-64-linux-gnu
gcc-x86-64-linux-gnu
binutils-x86-64-linux-gnu

A simple substitution suffices. It does add another little bit of
tiresome complication to the already horrible complicated rules files
for gcc.

Wookey

[Wookey]

Post by deloptes
So what can the community rule out here. Is it aarch64 and arm64 the same or
not?

yes, arm64 and aarch64 are different names for the same architecture.

Linux (kernel) and debian/ubuntu (and Apple in IOS/LLVM) called it
arm64. ARM corp called it aarch64. The glibc ABI triplet is
aarch64-linux-gnu. These are all the same ABI/architecture.

Apologies for the confusion. I was rather hoping more projects would
use the obvious (and IMHO more user-friendly) arm64 name, rather than
following the corporate steer, and in the early days it was hard
to tell how this would go. But most have plumped for aarch64, so users
are exposed to both names.


Wookey

[peter green]

Post by Wookey
Apologies for the confusion. I was rather hoping more projects would
use the obvious (and IMHO more user-friendly) arm64 name, rather than
following the corporate steer, and in the early days it was hard
to tell how this would go. But most have plumped for aarch64, so users
are exposed to both names.

I think Debian made the right decision in using "arm64", IMO
the clarity for end-users (who aren't likely to have a clue what
"aarch" is but will probablly have heard of arm) outweighs
the inconsistency between Debian and projects that decided
to do what arm corporate wanted.

Interestingly andriod seems to use arm64 for the "abi"* and
aarch64 for the "instruction set"

* I am not an andriod expert, but an andiod "abi" seems to be
roughly equivilent to a Debian architecture.

[Wookey]

Post by peter green
Interestingly andriod seems to use arm64 for the "abi"* and
aarch64 for the "instruction set"

I was hoping to avoid getting into all this because it's detail almost
no-one needs to care about, but there are indeed separate names for
the instruction set and the ABI and and the execution state and the
microarchitecture and the elf layout, and if I try to type it in here
without swotting up properly I'll get it wrong :-)

Wikipedia is pretty good for a summary:
https://en.wikipedia.org/wiki/ARM_Cortex-A32#32-bit_architecture
Or for full detail:
http://infocenter.arm.com/help/index.jsp?noscript=1

Post by peter green
* I am not an andriod expert, but an andiod "abi" seems to be
roughly equivilent to a Debian architecture.

A debian architecture is essentially defined as an ABI (but also
includes a baseline ISA than can shift over time). So yes that makes
sense.

Wookey

[Lucas Nussbaum]

Post by basti
Hello,
i have try to boot rpi4 with real debian kernel.
- build kernel from source -> boot with dtb from ubuntu, but do not find
an sdcard
- use uefi -> install via debian installer, does not boot after install
is finished, can't find a boot media
can please someone share a minimal image to boot aarch64 on rpi4?

Hi basti,

You can use (and maybe adjust) the raspi_4.yaml file at
https://salsa.debian.org/raspi-team/image-specs/-/compare/master...rpi4

Just replace all references to 127.0.0.1:3142 with your local mirror.

I'll try to upload a working image somewhere ASAP (probably over the
week-end).

Lucas

[basti]

Hello Lucas,

thanks for the link. Build a image with kernel 5.5 boot the rpi4, but
USB is not working. lsusb show nothink. ( I know there is the Problem
with the pcie)

Build Image with Kernel 5.6 does nothing. No monitor output, no output
on serial.

When I try to upgrade the image with kernel 5.5 to 5.6 and reboot there
is the same described above. (Kernel 5.6. is upgraded from your repo.)

Post by Lucas Nussbaum

Post by basti
Hello,
i have try to boot rpi4 with real debian kernel.
- build kernel from source -> boot with dtb from ubuntu, but do not find
an sdcard
- use uefi -> install via debian installer, does not boot after install
is finished, can't find a boot media
can please someone share a minimal image to boot aarch64 on rpi4?

Hi basti,
You can use (and maybe adjust) the raspi_4.yaml file at
https://salsa.debian.org/raspi-team/image-specs/-/compare/master...rpi4
Just replace all references to 127.0.0.1:3142 with your local mirror.
I'll try to upload a working image somewhere ASAP (probably over the
week-end).
Lucas

[Lucas Nussbaum]

Hi,

For 5.5:
That's possible. I did not check USB yet.
And see the latest messages on
https://github.com/lategoodbye/rpi-zero/issues/43 ...

For 5.6:
strange. I think it worked.

It would really be great to get a 5.6 kernel in experimental, from the
kernel team.

I'll try to refresh the status of my RPI4 work soon.

Lucas

Post by basti
Hello Lucas,
thanks for the link. Build a image with kernel 5.5 boot the rpi4, but
USB is not working. lsusb show nothink. ( I know there is the Problem
with the pcie)
Build Image with Kernel 5.6 does nothing. No monitor output, no output
on serial.
When I try to upgrade the image with kernel 5.5 to 5.6 and reboot there
is the same described above. (Kernel 5.6. is upgraded from your repo.)

Post by Lucas Nussbaum

Post by basti
Hello,
i have try to boot rpi4 with real debian kernel.
- build kernel from source -> boot with dtb from ubuntu, but do not find
an sdcard
- use uefi -> install via debian installer, does not boot after install
is finished, can't find a boot media
can please someone share a minimal image to boot aarch64 on rpi4?

Hi basti,
You can use (and maybe adjust) the raspi_4.yaml file at
https://salsa.debian.org/raspi-team/image-specs/-/compare/master...rpi4
Just replace all references to 127.0.0.1:3142 with your local mirror.
I'll try to upload a working image somewhere ASAP (probably over the
week-end).
Lucas

[Gunnar Wolf]

Post by Ralph Aichinger
Hello!
With a little bit of envy I discovered that Ubuntu not only runs
in a vanilla flavour on the Raspberry Pi, but that there is
a very straightforward download page and stuff seems reasonably
documented. In both 32 and 64 bit.
https://ubuntu.com/download/raspberry-pi
In comparison to this Debian's Arm64 wiki page lists tons of
obsolete Arm64 hardware that is no longer available, but does
not document the one Arm64 system that is the easiest to buy
in shops very well, in my opinion.
https://wiki.debian.org/Arm64Port
Now I do understand that the binary blobs needed to use the
Raspberry Pi are a no-no for some, but from a pragmatic
standpoint the Pi is the Arm64 system sold in the highest
numbers, except for cell phones, probably.
(...)

Hi,

A couple of days ago, I announced the pure-Debian (+ raspi-firmware
from non-free), preinstalled, daily-built Buster images I have
available here:

https://raspi.debian.net/

We are still not offering images for the RPi4, but am following Lucas'
work, and hope to add them soon.

Greetings,