next week there is a (virtual) meeting at ARM who invited some people involved in Linux on ARM CPUs. One of the topics there is to tell them Debian's needs and pain points.
My current list (based on own experience and asking for feedback in #debian-arm) currently has:
 - Fragmentation
  - Vendor kernels vs. mainline
    This got better in the past is my subjective impression, but it
    still hurts. Device tree made this a tad simpler, but it's not
    unusual to have vendor specific bindings.
  - early boot code
    U-Boot (or general: bootloader) is device specific and more often
    than not there is only a Vendor variant available.
    Also today there are more relevant components: ATF, UEFI/EDK2
  Vendors care at different intensities (and profit from external
  developers) Would Arm Base System Architecture (BSA) help? (This is
  only for AArch64 though, arm32 still relevant for us.)
 - relevant SoC/SBC vendors:
  - Allwinner
  - Broadcom / RaspberryPi Foundation
  - Marvell
  - NXP
  - Odroid
  - Rockchip
  - some more for sure (which?)
 - Graphics
  Similar problematic, vendor blobs vs. OSS
Is there anything on your mind that is missing above and that you'd like
to be shared with ARM?
Hello,
next week there is a (virtual) meeting at ARM who invited some people involved in Linux on ARM CPUs. One of the topics there is to tell them Debian's needs and pain points.
My current list (based on own experience and asking for feedback in #debian-arm) currently has:
 - Fragmentation
  - Vendor kernels vs. mainline
    This got better in the past is my subjective impression, but it     still hurts. Device tree made this a tad simpler, but it's not     unusual to have vendor specific bindings.
  - early boot code
    U-Boot (or general: bootloader) is device specific and more often     than not there is only a Vendor variant available.
    Also today there are more relevant components: ATF, UEFI/EDK2
  Vendors care at different intensities (and profit from external
  developers) Would Arm Base System Architecture (BSA) help? (This is
  only for AArch64 though, arm32 still relevant for us.)
 - relevant SoC/SBC vendors:
  - Allwinner
  - Broadcom / RaspberryPi Foundation
  - Marvell
  - NXP
  - Odroid
  - Rockchip
  - some more for sure (which?)
 - Graphics
  Similar problematic, vendor blobs vs. OSS
Is there anything on your mind that is missing above and that you'd
like to be shared with ARM? Feel free to reply here or discuss in #debian-arm. (I'm ukleinek there.)
Best regards
Uwe
W dniu 10.06.2021 o 16:43, Uwe Kleine-König pisze:
next week there is a (virtual) meeting at ARM who invited some
people involved in Linux on ARM CPUs. One of the topics there is to
tell them Debian's needs and pain points.
My current list (based on own experience and asking for feedback in #debian-arm) currently has:
 - Fragmentation
  - Vendor kernels vs. mainline
    This got better in the past is my subjective impression, but
it still hurts. Device tree made this a tad simpler, but it's not
unusual to have vendor specific bindings.
  - early boot code
    U-Boot (or general: bootloader) is device specific and more
often than not there is only a Vendor variant available.
    Also today there are more relevant components: ATF, UEFI/EDK2
  Vendors care at different intensities (and profit from external
  developers) Would Arm Base System Architecture (BSA) help? (This
is only for AArch64 though, arm32 still relevant for us.)
 - relevant SoC/SBC vendors:
  - Allwinner
  - Broadcom / RaspberryPi Foundation
  - Marvell
  - NXP
  - Odroid
  - Rockchip
  - some more for sure (which?)
 - Graphics
  Similar problematic, vendor blobs vs. OSS
Is there anything on your mind that is missing above and that you'd
like to be shared with ARM?
Sorry if it offends someone but I see Debian Arm team to be more
Debian Arm SBC team. Sure, it is most of available hardware as it
includes Windows-on-Arm laptops and Apple M1 systems too but Arm world
has also something outside of SBC.
My questions (probably get ignored):
1. When CBSA spec gets released? It is mentioned in BSA spec but
not public.
2. Are there plans to enforce BSA compliance for new designs?
3. How many years we need to wait for Arm systems to work out-of-
the-box? I mean unpack, connect input/video/power, boot generic
distro installer, install, reboot and use. So far there are
nearly no such ones outside of server space.
On 6/10/21 7:43 AM, Uwe Kleine-König wrote:
next week there is a (virtual) meeting at ARM who invited some people
involved in Linux on ARM CPUs. One of the topics there is to tell them
Debian's needs and pain points.where and how can I attend that meeting?
On Thursday 10 June 2021 12:44:23 Marcin Juszkiewicz wrote:
My questions (probably get ignored):
1. When CBSA spec gets released? It is mentioned in BSA spec but
not public.
New acronym, please define.
2. Are there plans to enforce BSA compliance for new designs?
3. How many years we need to wait for Arm systems to work out-of-
the-box? I mean unpack, connect input/video/power, boot generic
distro installer, install, reboot and use. So far there are
nearly no such ones outside of server space.
This is also true, and a bit of a sore spot with me. Why? Because the pi folks
Hello,
next week there is a (virtual) meeting at ARM who invited some people involved in Linux on ARM CPUs. One of the topics there is to tell them Debian's needs and pain points.
My current list (based on own experience and asking for feedback in #debian-arm) currently has:
- Fragmentation
- Vendor kernels vs. mainline
This got better in the past is my subjective impression, but it
still hurts. Device tree made this a tad simpler, but it's not
unusual to have vendor specific bindings.
- early boot code
U-Boot (or general: bootloader) is device specific and more often
than not there is only a Vendor variant available.
Also today there are more relevant components: ATF, UEFI/EDK2
Vendors care at different intensities (and profit from external
developers) Would Arm Base System Architecture (BSA) help? (This is
only for AArch64 though, arm32 still relevant for us.)
- relevant SoC/SBC vendors:
- Allwinner
- Broadcom / RaspberryPi Foundation
- Marvell
- NXP
- Odroid
- Rockchip
- some more for sure (which?)
- Graphics
Similar problematic, vendor blobs vs. OSS
Is there anything on your mind that is missing above and that you'd like to be shared with ARM? Feel free to reply here or discuss in #debian-arm. (I'm ukleinek there.)
Best regards
Uwe
W dniu 10.06.2021 o 20:36, Gene Heskett pisze:
On Thursday 10 June 2021 12:44:23 Marcin Juszkiewicz wrote:
My questions (probably get ignored):
1. When CBSA spec gets released? It is mentioned in BSA spec but
not public.
New acronym, please define.
I can not as CBSA is all you have in public docs.
It is "C* Base System Architecture" probably where "C*" can be any
word. If you have NDAs signed with Arm then reach there and ask.
2. Are there plans to enforce BSA compliance for new designs?
3. How many years we need to wait for Arm systems to work out-of-
the-box? I mean unpack, connect input/video/power, boot
generic distro installer, install, reboot and use. So far there are
nearly no such ones outside of server space.
This is also true, and a bit of a sore spot with me. Why? Because
the pi folks
To be honest: I do not care how bad Arm SBCs are. I just skip them and
do not plan to spend any money on buying those. Most are really far
from being usable as generic Arm system.
Just get _someone_ to make a good quality 64 bit server which doesn't cost the earth and works well with UEFI and relatively standard interfaces
and components.
AMD were doing this n years ago but the devices never got popular/cheap enough for use. Marvell have the espressobin and macchiatobin - just
get something that looks like a performant mini-ATX / itx board and
can run forever at low power but in a standard form factor.
3. How many years we need to wait for Arm systems to work out-of-
the-box? I mean unpack, connect input/video/power, boot generic
distro installer, install, reboot and use. So far there are
nearly no such ones outside of server space.
I see Debian Arm team to be more Debian Arm SBC team.
Just get _someone_ to make a good quality 64 bit server which doesn't cost the earth and works well with UEFI and relatively standard interfaces
and components.
get something that looks like a performant mini-ATX / itx board and
can run forever at low power but in a standard form factor.
Is there anything on your mind that is missing above and that you'd like
to be shared with ARM? Feel free to reply here or discuss in
#debian-arm. (I'm ukleinek there.)
- relevant SoC/SBC vendors:
- Allwinner
- Broadcom / RaspberryPi Foundation
- Marvell
- NXP
- Odroid
- Rockchip
- some more for sure (which?)
- Graphics
Similar problematic, vendor blobs vs. OSS
Is there anything on your mind that is missing above and that you'd like to be shared with ARM? Feel free to reply here or discuss in #debian-arm. (I'm ukleinek there.)
I'm guessing there's much requests wrt SBCs as that is for many
people their
first experience with ARM systems (besides phones). It is/was for me.
And they make for (potentially) great fits for systems that need to
be on 24/7,
like quassel-core or FreedomBox (a Debian Pure Blend), as they
consume little
power, which is great for the environment and your wallet.
I really think Debian should have a better answer to installing on
the Raspberry Pi, as this ist the only board that is widely
available, sold in *huge* numbers (40 million?), can boot aarch64,
has up to 8GB RAM (which makes it quite usable for many tasks), and
most of all a long support times (they guarantee production of the
RPi4 until January 2026, which is probably longer than most Intel
hardware sold today, and probably four times as long as comparable
SBC products.
How much different is the process of booting an RPi 4 with UEFi from
e.g. booting some run of the mill notebook with obscure Realtek
components that need binary blobs too?
As somebody who has used Raspbian now for years, quassel-core or
FreedomBox is rather offputting, because I very much prefer true
Debian that matches amd64 except for architecture. If I wanted to
have some distribution that is "Debian based" and not Debian
outright, I'd probably go for Raspberry Pi OS.
The official arm64 install documentation lists as of today as
supported arm64 boards:
Applied Micro (APM) Mustang/X-Gene T ARM Juno Development Platform
Has anybody of you seen these in the wild?
Why is the Raspberry Pi 4 with UEFI or the stock boot process not
listed here?
What can a mere Debian user like me do to improve this documentation
problem?
Pretty sure just everything folks have been asking for for years can
be summarized in four words: libre, upstream, standards, supported.
Is there anything on your mind that is missing above and that you'd like
to be shared with ARM? Feel free to reply here or discuss in
#debian-arm. (I'm ukleinek there.)
Ask Raspberry/Pi vendor then. Make them work on getting support for
their product into mainline, make use of available standards during
design of their next products.
Properly designed Arm board should boot generic ISO written into USB
stick (dd if=d-i.iso of=/dev/sda). Several SBC work that way already
(or can have their firmware flashed to be that way).
Distributions should not waste time on getting SBC systems working
but SBC vendors should make them 'just work' with distributions.
You go to store, buy x86-64 laptop/computer and expect it to just
work with Debian.
'of the mill notebook': connect cables, plug USB stick with generic installer, boot, install, use. Then use the same USB stick with
another notebook from different vendor.
RPi4: find out how it boots, prepare SD card with RPi4 specific
installer, boot, install, use. And then rewrite SD card for another
SBC.
I see a difference.
Let me be honest: if someone wants to use R/Pi SBC then R/Pi OS is
what they should use. To not waste time of other distribution
maintainers.
This way you get 'probably working' kernel with all out-of-tree
patches needed to get board working and functional + set of packages
with out-of-tree patches to get userspace running.
Debian, Fedora and other distros usually do not ship those out-of-
tree
patches because they are not even on a way to mainline projects.
Check doc, write new one, send to maintainer. Or even to this ML.
On Thu, Jun 10, 2021 at 4:43 PM Uwe Kleine-König<uwe@kleine-koenig.org> wrote:
Is there anything on your mind that is missing above and that you'd
like to be shared with ARM? Feel free to reply here or discuss in #debian-arm. (I'm ukleinek there.)
I'll be at the meeting as well, and one point I would want to bring up
is support for 32-bit binaries on 64-bit kernels. This has come up a
few times on #debian-arm, and the problem is a mismatch between which obsolete instructions are emulated depending on the kernel: 64-bit
kernels emulate all the instructions that were removed in v8 (setend,
cp15 barriers, swp), while 32-bit kernels emulate instructions that
were already needed in v7 (swp, mrc tlsreg, unaligned
ldm/stm/ldrd/strd). This means that some binaries that ran fine on an
ARMv7 processor may break when running on an ARMv8 processor with a
32-bit kernel, while other binaries may break on the same hardware on
a 64-bit kernel.
This situation is bad for Debian as there are mixed messages regarding
what users should actually run on ARMv8 hardware and what should
be tested. My hope is that we can find an agreement regarding which
of the emulation code we actually want on v8 processors and then make
sure that every binary that can run on a 32-bit kernel can also run on
a 64-bit kernel (but not necessarily the other way round). This could
mean adding features to arch/arm64/ that have previously been
rejected, or artificially crippling the emulation code in arch/arm/
when running on v8 to force user space applications to get fixed.
Side note: yes, 32-bit user space code is still important to run for
a lot of users, especially in low-memory configurations, but support
for 32-bit kernels is unavailable on most newer CPU cores and
somewhat lacking even on older cores (missing errata workarounds
and certain features of 64-bit kernels).
Arnd
I really think Debian should have a better answer to installing
on the Raspberry Pi
can boot aarch64
As somebody who has used Raspbian now for years, quassel-core
or FreedomBox is rather offputting, because I very much prefer
true Debian that matches amd64 except for architecture. If I
wanted to have some distribution that is "Debian based" and
not Debian outright, I'd probably go for Raspberry Pi OS.
The official arm64 install documentation lists as of today
as supported arm64 boards:
Applied Micro (APM) Mustang/X-Gene T
ARM Juno Development Platform
Has anybody of you seen these in the wild?
Why is the Raspberry Pi 4 with UEFI or the stock boot process
not listed here?
https://www.debian.org/releases/bullseye/arm64/install.en.pdf
(page 6)
What can a mere Debian user like me do to improve this documentation
problem?
- Fragmentation
- Vendor kernels vs. mainline
This got better in the past is my subjective impression, but it
still hurts. Device tree made this a tad simpler, but it's not
unusual to have vendor specific bindings.
I think the problem isn't on Debian's side, but on the side of the
Raspberry Pi Foundation (RPF).
quassel-core and FreedomBox are (a collection of) programs already
available in Debian, which you can install with apt[itude|-get].
The FreedomBox project does also provide downloadable images, but
that just/still a (pure/true) Debian system.
So I guess there's some miscommunication/misunderstanding here?
On donderdag 10 juni 2021 16:43:44 CEST Uwe Kleine-König wrote:
- Fragmentation
- Vendor kernels vs. mainline
This got better in the past is my subjective impression, but it
still hurts. Device tree made this a tad simpler, but it's not
unusual to have vendor specific bindings.
Mainline would be best, but if (initially) a vendor kernel 'needs' to be made,
please don't use some random kernel version, but base it off an Extended Long Term Support kernel. IIUC 5.10 is intended to be an ELTS kernel.
It also has the 'side' benefit that it (usually) aligns with a Debian Stable release, which means various tooling should also easily work. And it should also mean that it's 'easy' to get it working on other distros as well.
In my bubble most vendor kernel already do this. They align however not
to an ELTS kernel, but to the Android universe. That's at least the case
for NXP which is quite dominant in my bubble.
On vrijdag 11 juni 2021 15:20:34 CEST Uwe Kleine-König wrote:
In my bubble most vendor kernel already do this. They align however not
to an ELTS kernel, but to the Android universe. That's at least the case
for NXP which is quite dominant in my bubble.
Lucky you :)
I'm not very familiar with the Android universe and I see it separate from the
rest of the Linux universe. (my android phone (SGS7) runs 3.18 ...)
My router from 2017 has an ARM cpu, but uses kernel 3.4.103 ... _sigh_
Maybe/hopefully this is just anecdotal and dated and things are aligned/ converged much more now.
But generally speaking, if only 1 or a few kernels would be used by ARM vendors, then it's easier to combine efforts and help each other, rather then having everyone on their own island.
An ELTS kernel seems well suited for that.
There are some interesting Chromebooks (existing and announced), maybe
some SBCs as well, based on Mediatek SoCs[1].
Apple's M1 and future designs are also extremely interesting, e.g. a
Macbook Air fully supported by a mainline kernel would be *very*
interesting, despite the price[1].
- Graphics
Similar problematic, vendor blobs vs. OSS
Personal pain point: the PowerVR GX6250 in the Mediatek MT8173. But
since this is a meeting with ARM, having fully mainlined support for all their GPUs would already be a great start (unsure what the current
status is).
Mainlined support for the various on-chip hardware decoders would also
be great (i.e. ffmpeg and friends in addition to Linux).
Is there anything on your mind that is missing above and that you'd like to be shared with ARM? Feel free to reply here or discuss in #debian-arm. (I'm ukleinek there.)
[1] writing this on an Acer Chromebook R13 running an ancient kernel
from archlinuxarm.org that would benefit from mainline support.
[2] I'm not aware of a similar fanless laptop
IMHO the version to pick is always the current tip of the development
tree.
Assuming the vendors get their changes into mainline users are
free to use any later kernel.
That is more useful than restricting to an ELTS kernel.
With an ELTS kernel the users wail that it is too old
and/or the vendors have the pain to update their patch stacks to the
next ELTS version
...
[1] https://lwn.net/Articles/749530/
On Fri, Jun 11, 2021 at 7:25 AM Ralph Aichinger wrote:
Many criticisms of the RPi that were true 5 years ago no longer
hold.
Some of them are still true; the weird GPU-starts-CPU SoC boot
process,
blobs required for the boot process,
some Linux kernelpatches are not in mainline etc
FreedomBox is a Debian blend, so a FreedomBox install *is* a Debian
install, there are no custom packages or other hacks. At least that
is how it is claimed to be, I haven't tried it.
I assume because of the proprietary software needed to boot the
RPi4,a lthough there is a WIP libre replacement that isn't yet in
Debian, see other comments in the thread about that.
Many criticisms of the RPi that were true 5 years ago no longer hold.
or FreedomBox is rather offputting, because I very much prefer
true Debian that matches amd64 except for architecture.
Why is the Raspberry Pi 4 with UEFI or the stock boot process
not listed here?
"All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero
W,
2, 3) boot from their GPU"
So it seems this is no longer true, and exactly what I said.
If there are Blobs needed to bring up the RPi4 they are included
in above UEFi firmware (or the stuff used in other boot mechanisms).
I don't see how this is different from the "blobs" I load when I
boot my UEFI Asus mainboard.
some Linux kernel patches are not in mainline etc
What patches do you mean?
the RPi4b runs fine without anything but a stock debian kernel
With "WIP libre replacement" do you mean the tianocore/EDK2/UEFi port
here?
https://github.com/pftf/RPi4
On Fri, Jun 11, 2021 at 2:20 PM Diederik de Haas <didi.debian@cknow.org> wrote:
...
[1] https://lwn.net/Articles/749530/
That's an interesting project. Thanks for that link.
Insecure infrastructure (and other gadgets, like home routers) is such
a problem I hope the CIP project can get funding from places like the National Science Foundation or Homeland Security (in the US).
Maybe the GPL license needs an update that addresses the abandonware
problem. The update clause requires vendors on top of the base system
to provide updates for the life of the device. Something like, "GPL
plus the update clause".
The update clause will ensure vendors fix their bugs and send them
upstream. The update clause won't affect the kernel because it is
being updated.
Jeff
Will this be added to edk2-platforms?
https://github.com/tianocore/edk2-platforms/
On Sat, 2021-06-12 at 06:17 +0000, Paul Wise wrote:
On Fri, Jun 11, 2021 at 7:25 AM Ralph Aichinger wrote:
Many criticisms of the RPi that were true 5 years ago no longer
hold.
Some of them are still true; the weird GPU-starts-CPU SoC boot
process,
Is this still true for the Raspberry Pi4 with UEFI?
https://github.com/pftf/RPi4
Even Debian Wiki says
https://wiki.debian.org/RaspberryPi
"All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero W,
2, 3) boot from their GPU"
So it seems this is no longer true, and exactly what I said.
blobs required for the boot process,
If there are Blobs needed to bring up the RPi4 they are included
in above UEFi firmware (or the stuff used in other boot mechanisms).
I don't see how this is different from the "blobs" I load when I
boot my UEFi Asus mainboard.
some Linux kernelpatches are not in mainline etc
What patches do you mean? Patches that are in Debian kernels, but
not in Linus' upstream kernels? Or patches on top of what Debian
does? Because if you mean the latter, than I can assure you, that
the RPi4b runs fine without anything but a stock debian kernel,
both during installation (there the kernel from recent bullseye arm64Â netinst works just fine) as in actual use. The kernel I am currently
running is
ii linux-image-5.10.0-7-arm64 5.10.40-1 arm64 Linux
5.10 for 64-bit ARMv8 machines (signed)
directly from Debian archive.
And I stand by my statement: What was true 5 years ago (weird GPU boot, patched proprietary kernel, architecture that falls right between
armel/armhf in Debian) is no longer true for kernels after 5.10
and with RPi4. The RPi4 works with stock Debian kernels (and supposedly
stock upstream kernels), runs straight arm64 just like other devices
and boots debian netinstall installation directly as long as you copy
it over onto an UEFi partiton with the UEFi EDK2 files included.
FreedomBox is a Debian blend, so a FreedomBox install *is* a Debian install, there are no custom packages or other hacks. At least that
is how it is claimed to be, I haven't tried it.
I have not tried it either, but I am slightly worried about
small variations in the details. And I do not need the extra
software they install (yes, I could uninstall, of course).
My most recent Pi4 is used for taking backups with restic over
wireguard, so I more or less just need restic, wireguard, and
ssh (plus the usual commandline utilities). It would feel wrong
to install Freedombox, look what has to be uninstalled, look
for potential specific configurations etc.
I assume because of the proprietary software needed to boot the
RPi4,a lthough there is a WIP libre replacement that isn't yet in
Debian, see other comments in the thread about that.
With "WIP libre replacement" do you mean the tianocore/EDK2/UEFi port
here?
https://github.com/pftf/RPi4
Or something else?Â
/ralph
Some of them are hugely true: at the time when the first RPi was released, it was released as ARM v6 with hardware floating point. Almost all Linux distributions at that point had agreed on architectures <ARM v7 32 bit as having software floating point and ARM v7 specs to be hardware floating point.
Sounds small: but it's meant that Raspbian was always the odd one out, that RPi .debs had to be essentially rebuilt from scratch and you couldn't
just move to stock Debian / Ubuntu or whatever or run software from one
on the other.. Raspberry Pi OS still preserves this v6-ness and essential
32 bit nature - not just for backward compatibility but because the Soc ine very Pi Zero is still only ARM v6 and 32 bit.
This is also the reason why Raspberry Pi OS isn't particularly concerned with 64 bit and a 64 bit Raspberry Pi OS is in paermanent beta, though
you've been able to run 64 bit code on everything since some models of the Raspberry Pi 2.
There have also been points when the Raspberry Pi Foundation didn't
talk to the wider ARM Linux community (and where the wider community couldn't get information/offer advice/help) which hasn't helped the overall situation or some people's feelings about Raspberry Pi in gneral
Strange booting process: a consequence of the original Broadcom SoC.
It would be _so_ nice if RPi people would just adopt UEFI from here on in
and produce firmware that would default to that.
The details of Raspberry Pi-ness and requests there are subtly different
to requests to ARM themselves. The fact that the RPi is very much dominant at
the moment is also because it's very much available while most of the other ARM SBCs are on back order / not currently in production / waiting on chips. If that situation continues,then the RPi will become the de facto solution for most ARM stuff in the medium term.
As a matter of fact, starting with RPi3, the Raspberry Pi has been an official EDK2/UEFI platform for more than 2 years now.
... Debian could do itself a
favour by embracing UEFI support for platforms that have it and at the same time try to set a clear delimiter of responsibilities ("ARM manufacturers,
if you provide a working UEFI implementation for your platform to take care of the early boot code/custom kernel headaches, then we'll see what we can
do to make our distribution work on it").
On 2021-06-12 11:57 +0100, Pete Batard wrote:
As a matter of fact, starting with RPi3, the Raspberry Pi has been an official EDK2/UEFI platform for more than 2 years now.
... Debian could do itself a
favour by embracing UEFI support for platforms that have it and at the same time try to set a clear delimiter of responsibilities ("ARM manufacturers, if you provide a working UEFI implementation for your platform to take care of the early boot code/custom kernel headaches, then we'll see what we can do to make our distribution work on it").
We have embraced UEFI and if it's available the installer should use it.
It is my understanding that the current (testing) vanilla debian
installer does boot on a UEFI Pi4 (after we fixed #985956). Is that understanding wrong?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Some of them are hugely true: at the time when the first RPi was released, it was released as ARM v6 with hardware floating point. Almost all Linux distributions at that point had agreed on architectures <ARM v7 32 bit as having software floating point and ARM v7 specs to be hardware floating point.
On Sat, Jun 12, 2021 at 11:04:35PM +0100, Wookey wrote:
On 2021-06-12 11:57 +0100, Pete Batard wrote:
As a matter of fact, starting with RPi3, the Raspberry Pi has been an
official EDK2/UEFI platform for more than 2 years now.
... Debian could do itself a
favour by embracing UEFI support for platforms that have it and at the same >>> time try to set a clear delimiter of responsibilities ("ARM manufacturers, >>> if you provide a working UEFI implementation for your platform to take care >>> of the early boot code/custom kernel headaches, then we'll see what we can >>> do to make our distribution work on it").
We have embraced UEFI and if it's available the installer should use it.
The Raspberry Pi 4 UEFI firmware has been an official EDK2
implementation for some time...
Hmm, then I don't understand the point of the rpi4-uefi.dev project
then. I guess it only exists because people don't want to compile edk2-platforms themselves,
So, at the risk of being controversial, it doesn't seem to me like
everybody in the Debian world has been that willing to embrace UEFI.
And I could point to further evidence of this when I also brought the
idea on this list that, maybe, it was time for Debian to start
looking into moving away from using good old uboot or similar for distributing special installable images for platforms like the Pi
On Sat, Jun 12, 2021 at 11:34 AM Andrew M.A. Cater wrote:
Some of them are hugely true: at the time when the first RPi was released, it
was released as ARM v6 with hardware floating point. Almost all Linux distributions at that point had agreed on architectures <ARM v7 32 bit as having software floating point and ARM v7 specs to be hardware floating point.
This is no longer relevant, since the arm64 and armhf capable RPi
boards are way more popular than the old boards now.
--
bye,
pabs
https://wiki.debian.org/PaulWise
This is no longer relevant, since the arm64 and armhf capable RPi
boards are way more popular than the old boards now.
https://wiki.debian.org/PaulWise
Pi Zero is still ARM v6 :(
Granted we also should have logged a bug for that issue as soon as we picked >it up, so we have to share part of the blame on this one. But the delays in >processing #985956, even though we tried to bring attention over and over >again to the fact that this very negatively affected one of the rare UEFI >installation of Bullseye on ARM64, on what has to be the current most >widespread system for that arch, was a bit concerning. Especially, it is not >the first time we've seen what I would qualify as extended delays in trying >to get showstopping UEFI patches looked into. As a matter of fact, I >eventually gave up trying to get the necessary Pi4 network patches backported >into Debian 10 (#950578), because even though we did submit a working patch >from the get go, it took 3 months (!) to actually get someone on the Debian >side to look into it, only to then tell us to just go re-do that patch, which >is not what I would qualify as a viable mode of operation.
So, at the risk of being controversial, it doesn't seem to me like everybody >in the Debian world has been that willing to embrace UEFI. Or if they do, >then not everybody appears to have recognized the importance of being able to >provide Debian in UEFI mode on what has to account for the most popular ARM64 >platform. And I could point to further evidence of this when I also brought >the idea on this list that, maybe, it was time for Debian to start looking >into moving away from using good old uboot or similar for distributing >special installable images for platforms like the Pi not that we have a full >blown UEFI, as this very idea seemed to irk a few people (which, to be fair, >may not have been directly affiliated with Debian).
But regardless of this, my remark was aimed more at the topic at hand which >should be what feedback Debian may want to convey to the ARM community, and >especially the ARM platform manufacturers, and therefore goes beyond than >just the Raspberry Pi platform.
In short, I would reiterate that, in light of the headaches caused by all the >other approaches, and especially a requirement that still seems to boil down >to providing custom images (in part because of custom boot methods as well as >proprietary blobs, which I don't realistically see as going away) the >feedback Debian should provide to ARM vendors is that, if the latter want >better cooperation with Linux distros, then they should put the onus on >releasing a working UEFI firmware for their platform, especially as it's been >demonstrated that, even for an SBC as quirky and as ill-suited for it as the >Raspberry Pi (and that was part of the point of the whole exercise), it is >not that difficult to achieve.
Let me bring the idea on this list that, maybe, it is time for vendors
to start looking into moving away from using good old U-Boot on microsd
or similar to provide on-board SPI flash to store bootloader. So we
could stop distributing special installable images for platforms like
the Pi.
On Sun, Jun 13, 2021 at 9:45 AM Marcin Juszkiewicz wrote:
Let me bring the idea on this list that, maybe, it is time for vendors
to start looking into moving away from using good old U-Boot on microsd
or similar to provide on-board SPI flash to store bootloader. So we
could stop distributing special installable images for platforms like
the Pi.
Storing boot firmware on the board seems to encourage various
sub-optimal things. Fully proprietary bootloaders. GPL violating
bootloaders. Bootloaders containing blobs. Bootloaders that are locked
down and cannot be replaced at all, especially on mobile. Forks of
random snapshots of existing bootloaders.
Personally I would go the other way; there should be a standard boot
protocol between the SoC boot ROM and later layers of the boot process
and vendors should stop shipping any boot firmware beyond the SoC boot
ROM, leaving it to OS distributors to package mainline bootloaders
that support that protocol.
W dniu 14.06.2021 o 03:22, Paul Wise pisze:
On Sun, Jun 13, 2021 at 9:45 AM Marcin Juszkiewicz wrote:
Let me bring the idea on this list that, maybe, it is time for vendors
to start looking into moving away from using good old U-Boot on microsd
or similar to provide on-board SPI flash to store bootloader. So we
could stop distributing special installable images for platforms like
the Pi.
Storing boot firmware on the board seems to encourage various
sub-optimal things. Fully proprietary bootloaders. GPL violating bootloaders. Bootloaders containing blobs. Bootloaders that are locked
down and cannot be replaced at all, especially on mobile. Forks of
random snapshots of existing bootloaders.
Personally I would go the other way; there should be a standard boot protocol between the SoC boot ROM and later layers of the boot process
and vendors should stop shipping any boot firmware beyond the SoC boot
ROM, leaving it to OS distributors to package mainline bootloaders
that support that protocol.
Whatever allow SBC to have "unpack, connect, install, reboot, use".
Now on-boot-media bootloader can be whatever crap you can imagine.
And still requires maintaining all those /InstallDebianOn/RandomSBC wiki pages, tools to generate installer images per board, tools to generate bootable images per board etc.
On maandag 14 juni 2021 13:15:07 CEST Adrian Bunk wrote:
Any solution to the abandonware problem for consumer products has to be
political, you need a law mandating for how many years repairs and
security updates have to be available.
There is another type of solution that you can do right now:
vote with your wallet
Any solution to the abandonware problem for consumer products has to be political, you need a law mandating for how many years repairs and
security updates have to be available.
...
Maybe the GPL license needs an update that addresses the abandonware
problem. The update clause requires vendors on top of the base system
to provide updates for the life of the device. Something like, "GPL
plus the update clause".
...
Jeff
On 2021.06.14 11:14, Arnd Bergmann wrote:
As far as I can tell (please let me know if this has changed), the only
way to get UEFI boot on Raspberry Pi is to load an EDK2 from
a special partition on a bootable drive (µSD or USB).
Not really.
You can load everything from a standard FAT32 EFI System Partition (ESP), as least on the Raspberry Pi 4, which allows you to create media that is 100% UEFI compliant from the get go (no need for special partitions or anything) and also has the benefit of allowing you to install vanilla Debian using the same media for the target and the source (without even having to do any
extra gymnastics for reboot), which can be a hugely beneficial thing on SBCs where connectivity might be limited or where users may not have the luxury
of being able to afford 2 media.
As detailed at [1], here is the overview of the entire installation process:
Create a GPT ESP (EFI System Partition) onto an USB, extract the netinst.iso content there, add the latest Raspberry PI UEFI firmware
and proceed to a standard Debian networked installation. That's it!
And by the way, this method of installing Debian from a single media by leveraging the ESP is something that's also frequently used on x86 UEFI
based PCs, so there's really nothing "custom" about that method, apart from the fact that you need to sprinkle a couple extra files besides the
extracted ISO content.
Of course, it may require distro maintainers to shift from the idea that "people should only use DD when writing ISOHybrids". But then again, considering that the whole point of UEFI was to make booting possible from a simple media content extraction to a FAT32 partition (and even for ARM there are simple ways [2] to work around the 4 GB FAT32 limitation, if your worry is that you may have a >4 GB file on your ISO), this method should always have been something that image creators need to consider, along with some awareness that DD mode is not always the panacea that it's cracked up to be, as it can be very problematic for Windows users [3].
Regards,
/Pete
[1] https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839
[2] https://github.com/pbatard/uefi-ntfs
[3] https://github.com/pbatard/rufus/wiki/FAQ#Why_doesnt_Rufus_recommend_DD_mode_over_ISO_mode_for_ISOHybrid_images_Surely_DD_is_better
As far as I can tell (please let me know if this has changed), the only
way to get UEFI boot on Raspberry Pi is to load an EDK2 from
a special partition on a bootable drive (µSD or USB).
Create a GPT ESP (EFI System Partition) onto an USB, extract the
netinst.iso content there, add the latest Raspberry PI UEFI firmware
and proceed to a standard Debian networked installation. That's it!
As you still need device specific boot media,
it does not solve the problem that
BBR tries to address by asking for UEFI support in the boot
firmware.
Storing boot firmware on the board seems to encourage various
sub-optimal things. Fully proprietary bootloaders. GPL violating
bootloaders. Bootloaders containing blobs. Bootloaders that are locked
down and cannot be replaced at all, especially on mobile. Forks of
random snapshots of existing bootloaders.
Personally I would go the other way; there should be a standard boot
protocol between the SoC boot ROM and later layers of the boot process
and vendors should stop shipping any boot firmware beyond the SoC boot
ROM, leaving it to OS distributors to package mainline bootloaders
that support that protocol.
Whatever allow SBC to have "unpack, connect, install, reboot, use".
Now on-boot-media bootloader can be whatever crap you can imagine.
And still requires maintaining all those /InstallDebianOn/RandomSBC wiki
pages, tools to generate installer images per board, tools to generate
bootable images per board etc.
Agreed, it is impossible to have board-agnostic boot media
at the same
time as board-agnostic boot ROM unless you have some other place to
store board specific code and data, pretty much by definition. Whether
you store this in eMMC boot-partition, a spi-nor chip, or on-chip flash doesn't matter too much, but most boards already have at least on of
those.
The missing bit that I see is getting board vendors to actually enable
UEFI support in their boot firmware, and storing (all of) it in the boot partition rather than the eMMC data partition.
And by the way, this method of installing Debian from a single media byThis didn't work for me yesterday on two occasions.
leveraging the ESP is something that's also frequently used on x86 UEFI
based PCs, so there's really nothing "custom" about that method, apart from >> the fact that you need to sprinkle a couple extra files besides the
extracted ISO content.
What _did_ work was
creating the ESP partition and formatting it [using parted for the creation of the partition and fdisk to mark it as fat32. I put in an ESP partition of 512M, which appears to be too small to hold the contents of the Bullseye rc2.
I then copied over the firmware and UEFI zip.
I used dd to put the iso onto a USB drive and used that to boot from.
Result: one successful install. [Only to discover that my RPi4 is one of the very early ones and appears limited to 3GB even if I toggle the setting under UEFI.
Of course, it may require distro maintainers to shift from the idea that
"people should only use DD when writing ISOHybrids". But then again,
considering that the whole point of UEFI was to make booting possible from a >> simple media content extraction to a FAT32 partition (and even for ARM there >> are simple ways [2] to work around the 4 GB FAT32 limitation, if your worry >> is that you may have a >4 GB file on your ISO), this method should always
have been something that image creators need to consider, along with some
awareness that DD mode is not always the panacea that it's cracked up to be, >> as it can be very problematic for Windows users [3].
See above - not a problem for me. In fact, the Raspberry Pi Foundations imaging software appears to work fine to write an iso to an SD card or USB and that or Rufus would be a better thing to advise.
[1] https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839
This is actually the only solution you have.
My old iPhone 5s ... is still receiving security updates
On Fri, Jun 11, 2021 at 7:25 AM Ralph Aichinger wrote:
Many criticisms of the RPi that were true 5 years ago no longer hold.Some of them are still true; the weird GPU-starts-CPU SoC boot
process, blobs required for the boot process, some Linux kernel
patches are not in mainline etc
The details of Raspberry Pi-ness and requests there are subtly differentto requests to ARM themselves. The fact that the RPi is very much dominant at
the moment is also because it's very much available while most of the other ARM SBCs are on back order / not currently in production / waiting on chips. If that situation continues,then the RPi will become the de facto solution for most ARM stuff in the medium term.
Just my €0.02
Andy Cater
Let me bring the idea on this list that, maybe, it is
time*for vendors to start looking into *moving away from
using good old U-Boot on microsd or similar to provide
on-board SPI flash to store bootloader. So we could stop
distributing special installable images for platforms like
the Pi.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 48:24:06 |
| Calls: | 6,648 |
| Files: | 12,198 |
| Messages: | 5,329,987 |