Debian Bullseye on Raspberry Pi 4 4GB?

[Rick Thomas]

Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from a CD/DVD or USB Flash stick or uSDcard?

If so, where would I look for instructions for doing so?

ADVthANanksCE!
Rick

[Matthias Klein]

Hello Rick,

> Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from a
> CD/DVD or USB Flash stick or uSDcard?

I don't think so.

But you can generate your own image with the vmdb2 tool and this repo:
https://salsa.debian.org/raspi-team/image-specs

Or use prebuild images: https://wiki.debian.org/RaspberryPiImages

Best regards,
Matthias

[deloptes]

Rick Thomas wrote:

> Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from a
> CD/DVD or USB Flash stick or uSDcard?
>
> If so, where would I look for instructions for doing so?

is the aarch64 bullseye kernel working on the RPI?
The buster does not work, so I copied the raspberrypi kernel and it works
fine.
As there is no bios to boot from specific device it is just a matter of
copying all you need to the uSDcard and adjusting the files.

[Pete Batard]

On 2021.02.18 23:02, Rick Thomas wrote:
> Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from a CD/DVD or USB Flash stick or uSDcard?

Absolutely!

This can be done using the *vanilla* ARM64 bullseyes ISOs, in a manner
that, once you have prepared your USB media (which too is
straightforward -- see below), is identical to the one one would follow
to install Debian on a UEFI x86 PC, with Debian-installer taking care of
everything.

The small "secret" to this is that the Raspberry Pi 4 actually has an
official UEFI firmware [1] that is SBBR compliant [2]. Because once you
have an SBBR compliant UEFI firmware (and the ACPI kernel drivers for
your platform, which recent kernels have), any modern Linux distribution
that is UEFI aware can pretty much be installed on any ARM64 platform
through UEFI, and of course Debian is no exception to that.

SBBR is designed to make ARM64 platforms as easily to install an OS on
as any regular x86 UEFI based PC. And you can see that in effect with
the whole procedure to install vanilla Debian bullseye on a Pi 4, which
stands in:

1. Create a GPT ESP on a USB media that is large enough to accommodate
the content from the *vanilla* mini or netinst ISO

2. Extract all the ISO content there, along with an SBBR compliant UEFI
firmware and any additional support files your platform needs to boot.

3. Power up the platform and go through a standard Debian install using
the console or graphical Debian installer, which will happily set
everything for you, as expected (including networking, default
partitioning, GRUB installation in either console or graphical mode and
so on).

> If so, where would I look for instructions for doing so?

This is documented on the Raspberry Pi forums at:
https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839

Please bear in mind however that, since Bullseye is a moving target (and
it also seems that validating SBBR installations on a platform like the
Raspberry Pi 4 is not yet part of the testing process for Debian),
regressions or breakage may be introduced from one ISO released to the
next. But outside of these (usually short lived) regressions, the
procedure does work, and you should be able to install vanilla bullseye
on your Pi 4 as easily as if you were installing on an x86 PC.

Regards,

/Pete

[1] https://github.com/pftf/RPi4
[2]
https://community.arm.com/iot/b/internet-of-things/posts/arm-server-standards-part-2-sbbr-specification-released

[Diederik de Haas]

On vrijdag 19 februari 2021 00:02:27 CET Rick Thomas wrote:
> Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from a
> CD/DVD or USB Flash stick or uSDcard?
>
> If so, where would I look for instructions for doing so?

https://raspi.debian.net/tested-images/ contains a Bullseye image that is
tested on a RPi4 4GB.

[Pete Batard]

Technically, this is not as much installing Debian, which is what OP
asked about, but more taking an image that was installed/setup by
somebody else, and flat-copying that to your media.

The end result is that you may not have as much flexibility with user
setup, partitioning and so on, as you would have with using the formal
Debian installer.

And of course, the problem with preinstalled images like these is that
distro maintainers need to multiply them for every platform they want to
support, which quickly become unmanageable and leaves any user of any
platform that hasn't deemed worth supporting stranded...

The established goal of SBBR, which is a bona fide ARM standard that was
designed precisely to address this major pain point, is to stop this
madness and let the platform developers (rather than the distro
maintainers) take care sorting out platform support by:

1. Making sure that the platform has a well established means of
booting, through a formal UEFI firmware, which, despite its misgivings,
is arguably the most user-friendly way to do so, as it mimics the known
PC user experience.

2. Working with mainline kernel to add whatever ACPI drivers are needed
to support their platform, which too is arguably better than requiring
everyone to use your "custom" version of the kernel.

I can only be hopeful that, since this should aid reduce their workload,
and especially avoid the multiplication of custom images for this or
that platform, both distro maintainers and contributors will come to
realize that a phase shift is happening and that now is the time to
start moving away from the old "If you want to run our distro on ARM,
then you'll first need to flat-copy this custom image" paradigm...

Regards,

/Pete

[Diederik de Haas]

On vrijdag 19 februari 2021 15:48:41 CET Pete Batard wrote:
> On 2021.02.19 13:37, Diederik de Haas wrote:
> > On vrijdag 19 februari 2021 00:02:27 CET Rick Thomas wrote:
> >> Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from
> >> a CD/DVD or USB Flash stick or uSDcard?
> >>
> >> If so, where would I look for instructions for doing so?
> >
> > https://raspi.debian.net/tested-images/ contains a Bullseye image that is
> > tested on a RPi4 4GB.
>
> Technically, this is not as much installing Debian, which is what OP
> asked about,

I don't presume to know exactly what OP wants, so I gave him another option.
Maybe he's just looking for != RaspberryPiOS and != Buster. I don't know.
If a pre-built Bullseye image is not what he wants, there are other suggestion
to choose from. Excellent.

The images on raspi.debian.net are built from the repo Matthias Klein
referenced: https://salsa.debian.org/raspi-team/image-specs

> And of course, the problem with preinstalled images like these is that
> distro maintainers need to multiply them for every platform they want to
> support, which quickly become unmanageable and leaves any user of any
> platform that hasn't deemed worth supporting stranded...

OP asked about RPi4, not any other platform.

I find it interesting that you felt the need to critique my suggestion.
I could do the same with yours, but why would I?

Relax.

[Arnd Bergmann]

On Fri, Feb 19, 2021 at 3:48 PM Pete Batard <pe...@akeo.ie> wrote:
> On 2021.02.19 13:37, Diederik de Haas wrote:
>
> The established goal of SBBR, which is a bona fide ARM standard that was
> designed precisely to address this major pain point, is to stop this
> madness and let the platform developers (rather than the distro
> maintainers) take care sorting out platform support by:
>
> 1. Making sure that the platform has a well established means of
> booting, through a formal UEFI firmware, which, despite its misgivings,
> is arguably the most user-friendly way to do so, as it mimics the known
> PC user experience.

It's easy to mix up these things, but the that does this is the 'BBR', which
comes in two flavors: 'SBBR' for large-scale servers and 'EBBR' for
the typical development board like the Raspberry Pi.

SBBR is usually not what you want here, having a simple boot-loader
like u-boot that implements enough of UEFI to be called EBBR is.
Ideally the bootloader in the Raspberry Pi would implement EBBR
directly, but at the moment, it does not.

The main purpose of the Tianocore port to the Raspberry Pi (as I
understand it) is to give developers a chance to hack on Tianocore
without having to buy or risk breaking an expensive server.

Having Tianocore onto an SD card to get booted instead of a kernel
is not really all that different to having a Debian netinstall kernel/initrd
on the SD card.

> 2. Working with mainline kernel to add whatever ACPI drivers are needed
> to support their platform, which too is arguably better than requiring
> everyone to use your "custom" version of the kernel.

The only thing that is needed for platform support is to have
the actual device drivers upstream, ACPI has nothing to do with
it. The reason that servers tend to just work is that they follow SBSA,
which defines a minimum set of hardware that just works, but that
doesn't help you on non-server hardware.

We certainly don't want to add ACPI support for all those non-server
platforms to the kernel, in addition to the support that we already
have.

Arnd

[Gunnar Wolf]

Hi Pete,

Pete Batard dijo [Fri, Feb 19, 2021 at 02:48:41PM +0000]:

> > > If so, where would I look for instructions for doing so?
> >
> > https://raspi.debian.net/tested-images/ contains a Bullseye image that is
> > tested on a RPi4 4GB.
>
> Technically, this is not as much installing Debian, which is what OP asked
> about, but more taking an image that was installed/setup by somebody else,
> and flat-copying that to your media.
>
> The end result is that you may not have as much flexibility with user setup,
> partitioning and so on, as you would have with using the formal Debian
> installer.

I completely agree here - That's why I¹ have stubbornly refused adding
packages to the base install; the image is shipped with a base system,
adding only the smallest possible handful of packages I could find to
get a working system (ssh, parted, dosfstools, iw, wpasupplicant,
raspi-firmware and firmware-brcm80211). The anti-pattern is the
overloaded Raspbian (specially its first iterations, before they
started shipping the non-GUI version).

¹ I speak in first person as it is me who builds said images. Diedrik,
who answered to your mail, is also a team member and has helped
quite a bit with QA and insight.

> And of course, the problem with preinstalled images like these is that
> distro maintainers need to multiply them for every platform they want to
> support, which quickly become unmanageable and leaves any user of any
> platform that hasn't deemed worth supporting stranded...

Right again -- The motivation for Michael Stapelberg first, then for
me to take on his work, is simply the amount of Raspberry systems out
there for which there was no easy way to get Debian running, despite
it being completely capable of doing so.

[Pete Batard]

On 2021.02.19 15:35, Diederik de Haas wrote:
> I find it interesting that you felt the need to critique my suggestion.

I'm afraid you are misreading my point.

I'm trying to bring attention to the fact that maybe it is time to start
considering moving away from providing custom images to install Linux on
ARM servers, nothing more nothing less. I'm merely trying to bring
attention to an alternative that looks like the it's going to become the
main contender as time moves on (which of course, you are entitled to
disagree with, as it's obviously not possible for anyone to predict what
the future entails).

And I'm also starting from what OP explicitly stated ("install (...)
from a CD/DVD or USB Flash stick or uSDcard?") which, in the absolute,
would tend to hint that they want to go through a full installation
process rather than apply a flat image. But there again, I agree that,
without OP clarifying, this is open to interpretation.

As the provider of a custom image, I can understand why you would read
this like a critique, but I can assure you that it's as much a
"critique" as one would make of people developing a boot process aimed
purely at BIOS systems at the time where UEFI was still in the process
of being introduced, which of course did make a lot of sense and which
nobody would point the finger at, for choosing to invest resources in an
established process rather than one that is being introduced and not yet
widespread.

So please don't misconstrue an attempt to bring aweress to a new method
of installing systems to a critique of the old ones.

Regards,

/Pete

[Matthias Klein]

Am Fri, 19 Feb 2021 14:48:41 +0000
schrieb Pete Batard <pe...@akeo.ie>:

> I can only be hopeful that, since this should aid reduce their
> workload, and especially avoid the multiplication of custom images
> for this or that platform, both distro maintainers and contributors
> will come to realize that a phase shift is happening and that now is
> the time to start moving away from the old "If you want to run our
> distro on ARM, then you'll first need to flat-copy this custom image"
> paradigm...

In my opinion, it should not be a matter of either (installers) or
(ready-made images). Both have their justification in my opinion.

The installer is of course more "mainline" to the way a classic
distribution is installed on a PC. Certainly useful for the "home
server user".

But in the embedded area where it is more about devices with a defined
functionality / behavior, I find tools like vmdb2 to create
reproducible images that do not require manual installation very
important.

As a starting point for the development of such devices I find the repo
from Gunnar, Diederik and Co. very useful and important.

Best regards,
Matthias

[Pete Batard]

On 2021.02.19 16:01, Arnd Bergmann wrote:
> The main purpose of the Tianocore port to the Raspberry Pi (as I
> understand it) is to give developers a chance to hack on Tianocore
> without having to buy or risk breaking an expensive server.

No.

It can be used as such, yes. But that is certainly not the reason I and
some other developers got involved in this project.

Granted, we did use this opportunity to try to make it a showcase of
SBBR, but this was done *precisely* with the idea to demonstrate to
platform vendors that, if the Pi was able to get there, it shouldn't be
that complicated for them to add SBBR compliance in their platform too.

So, I would turn that around to state that the main purpose of the
Tianocore port to the Raspberry Pi was to prove that, as opposed to what
many are assuming, SBBR compliance is actually not that difficult to
implement and is probably something vendors should consider to add for
their platform.

> Having Tianocore onto an SD card to get booted instead of a kernel
> is not really all that different to having a Debian netinstall kernel/initrd
> on the SD card.

Except, and this is the main point, it provides a familiar environment
to the user, who can reap the benefits of some much needed
uniformization between platforms.

Why, when it is absolutely possible to achieve it, as was demonstrated
on a cheap platform like the Pi (that actually comes with horrible
quirks to be able to accomplish so, especially in terms of xHCI
support), should end users have to juggle with heteroclitic means of
configuring their system for OS installation? Why shouldn't they be able
to take a single ARM64 installation source for their favourite Linux
distro, and expect that to work on their ARM64 platform, just like it
does on their x86 PC?

This goal can be achieved. And, precisely for those who seem to doubt
that it can be achieved, we are using one of the cheapest and most
widespread platform to demonstrate it (because it makes sense to use
that as a example).

>> 2. Working with mainline kernel to add whatever ACPI drivers are needed
>> to support their platform, which too is arguably better than requiring
>> everyone to use your "custom" version of the kernel.
>
> The only thing that is needed for platform support is to have
> the actual device drivers upstream, ACPI has nothing to do with
> it.

Except that the SBBR specs clearly points to ACPI being the preferred
method of describing the platform hardware, so that the same SBBR
platform can be used for Linux, Windows or whatever other OS a user may
choose, it does make sense to want to prefer ACPI over the Linux-centric
Device Tree.

Now, that does not mean that you can't support both (and in fact the
Raspberry Pi UEFI firmware does). But in terms of following the specs,
you want to prefer ACPI over something else.

> The reason that servers tend to just work is that they follow SBSA,
> which defines a minimum set of hardware that just works, but that
> doesn't help you on non-server hardware.

I don't believe the Raspberry Pi was ever developer with SBSA in mind.
And yet it has an SBBR compliant UEFI firmware.

> We certainly don't want to add ACPI support for all those non-server
> platforms to the kernel, in addition to the support that we already
> have.

Can you explain why?

What's the downside there?

Isn't the whole point of a kernel to support the hardware that a large
enough number of users want to see supported, regardless of how it is
being discovered? Or is there a secret clause that I'm not aware of, and
that states "(*) as long as that hardware is not being discovered
through ACPI"?

Regards,

/Pete

[Diederik de Haas]

On vrijdag 19 februari 2021 18:03:34 CET Pete Batard wrote:
> I agree that, without OP clarifying, this is open to interpretation.

That was my point, which resulted in: let's give OP as many options as
possible so he can choose for himself.

> As the provider of a custom image, I can understand why you would read
> this like a critique

My point was don't assume so much (and shoot down options bc of that).

My goal is to get Debian Bullseye in the best possible shape in general and
RPi related things in particular. Because of that I made some (minor)
contributions. You're highly inflating my involvement/contribution to those
images. And they're made/provided by Gunnar Wolf, not me.
There is a RPi related project which you could call 'mine', but as of right
now it neither supports RPi4 nor (pure) Debian thus also not Debian Bullseye,
so I didn't bring that up as that clearly didn't fulfill OP's requirements.

I think 'your' project is interesting and if it's exactly what OP was looking
for: great. I also think your enthusiasm for 'your' project is great, that's
usually how most progress in FLOSS is achieved :-)
But different people have different wants/needs and (possibly related) different
skill sets, resulting in different solution being right for person A than for
person B.
So don't shoot down other solutions if you aren't or can't be certain they're
incorrect.

Cheers

[Pete Batard]

On 2021.02.19 22:10, Diederik de Haas wrote:
> So don't shoot down other solutions if you aren't or can't be certain they're
> incorrect.

Again, I am not trying to shoot down other solutions.

You are misreading way too much into what I stated, and this is starting
to get a bit annoying.

All I said is that, technically, your proposal might not qualify with
what OP appeared to be after, and elaborated on why that might be the case.

Then I brought back the discussion to how some of the drawbacks of the
current pre-buit image distribution requirements might be alleviated
through a different method. And yes, I am trying to push for that new
method to become as established a "standard" as the pre-built image one,
precisely because I do anticipate the usual pushback that comes with
trying to implement something different, in order to try to solve some
of the pain points of a long established ecosystem.

If you think that qualifies as "shooting down", so be it, but then I
have no choice but to retort that you appear to be continuing to place
intent in my statement, that was never present.

Unless

Regards,

/Pete

[Rick Thomas]

On Thu, Feb 18, 2021, at 3:02 PM, Rick Thomas wrote:
> Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB)
> from a CD/DVD or USB Flash stick or uSDcard?
>
> If so, where would I look for instructions for doing so?

A couple of folks have asked for clarification from the OP. Well, as the OP here, I offer the following clarification of my goals for this project.

I recently bought a Raspberry Pi4 (4GB) to experiment with. It's currently running Ubuntu 20.04.2 LTS, because at the time I was installing it, that was the closest distro I could find to a vanilla Debian. It works pretty well and I'd be willing to stay with it for the long term if nothing better shows up. But, since I bought it to experiment with, I wondered if there was an experimental pure Debian installer I could test and report on my experiences. Sort of as a way of contributing back to the community that has been so helpful to me.

Meanwhile, in another part of the woods, I've been using a sheevaplug for 12 years or so to serve DNS, DHCP, NTP and other network services to my home network. It's running Debian Buster at the moment. I'm looking forward to upgrading it to Bullseye in the near future. Which is fine, but I've heard tell that sheevaplug support is planned to be dropped in the release after Bullseye.

Which got me to thinking, maybe I could use the Raspberry Pi to replace the Sheevaplug when support is finally dropped.

So the goal in my OP is to find a bare-bones Debian-like (real Debian, if possible) distro that I could install and administer to provide network services the way I'd been doing with the Sheevaplug.

The upshot is that my first attempt will be with one of the "ready-made" installation images, and see how much post-installation customization it allows. Then I'll try the more conventional Debian Installer and see how that works.

I will, of course, share my experiences with the list.

Thanks for listening...
Rick

[Rick Thomas]

If I can get the Pi4 working with either of the Debian alternatives, I will probably buy a Pi zero W as the actual replacement for the Sheeva, and keep the Pi4 for experimentation.

Enjoy!
Rick

[Ryutaroh Matsumoto]

From: deloptes <delo...@gmail.com>

> is the aarch64 bullseye kernel working on the RPI?
> The buster does not work, so I copied the raspberrypi kernel and it works
> fine.

Since I couldn't find an answer on the list, I write what I know.
I use RPi4B 8GB. Plain upstream kernel became fully functioning from
kernel version 5.8. Kernel version 5.9 was fine. 4K display output is
also possible by hdmi_enable_4kp60=1 "config.txt".
Gnome desktop environment works fine with 4K display.
We can install Linux kernel 5.10 from buster-backports, which is
the way to create images on raspi.debian.net for buster.

Linux kernel 5.10 have several regressions:
1. Unless reset_raspberrypi.ko is loaded by initramfs, USB boot becomes impossible.
2. 5GHz WiFi is blocked by the newly introduced vc4.ko.
3. According to Diederik on the linux-rpi-kernel list, the audio functionality is also
affected by vc4.ko.
4. My btrfs root filesystem becomes completely unmountable once every week...

2 and 3 can be worked around by module_blacklist=vc4 in the kernel comand line.
Because of 4, I am using self-compiled upstreadm kernel 5.9.16...
Another intel laptop also becomes very unstable with kernel 5.10,
and I am staying away from 5.10.

Best regards, Ryutaroh Matsumoto

[Luke Kenneth Casson Leighton]

On Friday, February 19, 2021, Pete Batard <pe...@akeo.ie> wrote:

> Why, when it is absolutely possible to achieve it, as was demonstrated on a cheap platform like the Pi (that actually comes with horrible quirks to be able to accomplish so, especially in terms of xHCI support), should end users have to juggle with heteroclitic means of configuring their system for OS installation?

because the product, designed by Broadcom, is not in the slightest bit targetted at end-users, and Broadcom do not give a flying f*** about such a tiny market of only 1 million a year in sales.  their profit margins are too small to bother with us.

Broadcom's Minimum Order Quantity for these processors, which are designed for mass-volume IPTV, Set Top Box and other multimedia computing appliances, is 5 million units and above.

Normally Broadcom would provide the full software stack for the customer placing 5, 10, 50, 100 million orders for a complete solution.  That customer *does not care* about the software boot process or some xHCI incompatibility.

Have people forgotten already that the only reason the original PI exists is because Eben Upton was an employee who, having access to normally NDA'd documentation, worked on the PCB in his spare time?  This was the only exception to Broadcom's normal MOQ rules, they could not exactly tell him to stop when he told them it was for educational purposes, could they?

please understand: the manufacturers of these SoCs consider you, all Free Software idiots (including me) to be an absolute nuisance.

i showed the manufacturers of my laptop the linux kernel boot process at Computex, they told me it looked like i was spying on their product!

we are "lapping at the heels" of these massive Corporations.  we are nothing to them.

when we can place orders for a million processors, *then* they will listen to what you and I want, Pete.

sorry if any of the reality check above shocks you.  personally i got absolutely sick of the ongoing callous pathological exploitation of our collective expertise, many years ago, and started a new SoC initiative.  it's entirely Libre.  [and offtopic for the debian-arm list, so please if you would like to discuss that, contact me direct or on freenode #libre-soc].

l.



--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

[deloptes]

Ryutaroh Matsumoto wrote:

> 2 and 3 can be worked around by module_blacklist=vc4 in the kernel comand
> line. Because of 4, I am using self-compiled upstreadm kernel 5.9.16...
> Another intel laptop also becomes very unstable with kernel 5.10,
> and I am staying away from 5.10.
>
> Best regards, Ryutaroh Matsumoto

Thank you - very interesting to read your experience. The RPi4 is not so
high on my priorities. I tried long time ago compiling kernel etc., but it
demanded a lot of time testing, debuggin, so I stick to the raspberry pi
kernel for one. It is good to know that debian has also (somehow) working
kernel.

[Ian Campbell]

I'm sure someone who follows rpi closer than I will correct if not, but
isn't the whole Pi Zero range based the older ARMv6 (i.e. not armhf)
processor which requires the Raspbian rebuild because it is not
compatible with the armhf baseline used by Debian (and most other
distros I think)?

If so then any experiments/learnings on a Pi4 (a full ARMv7 CPU
supported by the arm64 Debian arch) with full Debian aren't likely to
be very transferable.

Ian.

[Matthias Klein]

Am 20. Februar 2021 11:49:27 schrieb Ian Campbell <i...@debian.org>:

>
> I'm sure someone who follows rpi closer than I will correct if not, but
> isn't the whole Pi Zero range based the older ARMv6 (i.e. not armhf)
> processor which requires the Raspbian rebuild because it is not
> compatible with the armhf baseline used by Debian (and most other
> distros I think)?

Yes, the Pi Zero does not support armhf.

The prebuild images use the armel baseline:
https://salsa.debian.org/raspi-team/image-specs/-/blob/master/Makefile#L70

Best regards,
Matthias

[Alan Corey]

Yet if you stick with Raspbian everything "just works".  There is only one distribution that works on everything they sold.  If you look at the source of raspi-config you can see how the software identifies the hardware versions 

And ARMv7 becomes ARMv8 under the right conditons and can run 64 bit Debian (not on the Zero).  There was a Manjaro I think 64 bit that I was running on a Pi 3b a couple years ago.

[Arnd Bergmann]

On Sat, Feb 20, 2021 at 11:10 AM Ian Campbell <i...@debian.org> wrote:
>
> On Fri, 2021-02-19 at 18:42 -0800, Rick Thomas wrote:
> > If I can get the Pi4 working with either of the Debian alternatives,
> > I will probably buy a Pi zero W as the actual replacement for the
> > Sheeva, and keep the Pi4 for experimentation.
>
> I'm sure someone who follows rpi closer than I will correct if not, but
> isn't the whole Pi Zero range based the older ARMv6 (i.e. not armhf)
> processor which requires the Raspbian rebuild because it is not
> compatible with the armhf baseline used by Debian (and most other
> distros I think)?

Correct. The Debian armel port works on ARMv6, but is much slower
than Raspbian for anything that uses the floating point unit.

> If so then any experiments/learnings on a Pi4 (a full ARMv7 CPU
> supported by the arm64 Debian arch) with full Debian aren't likely to
> be very transferable.

The bootloader is still the same on both, and that is the main
difference to any other machine. Aside from that, it's just a Debian,
whether armel or arm64. You should in fact be able to install
an armel rootfs and have both armel and arm64 kernels to
allow booting it across the entire range.

Arnd

[Pete Batard]

Hi Luke,

On 2021.02.20 04:16, Luke Kenneth Casson Leighton wrote:
>
>
> On Friday, February 19, 2021, Pete Batard <pe...@akeo.ie

> <mailto:pe...@akeo.ie>> wrote:
>
> > Why, when it is absolutely possible to achieve it, as was
> demonstrated on a cheap platform like the Pi (that actually comes with
> horrible quirks to be able to accomplish so, especially in terms of xHCI
> support), should end users have to juggle with heteroclitic means of
> configuring their system for OS installation?
>
> because the product, designed by Broadcom, is not in the slightest bit
> targetted at end-users, and Broadcom do not give a flying f*** about
> such a tiny market of only 1 million a year in sales.  their profit
> margins are too small to bother with us.

I appreciate that you feel the desire to express your candid opinion.

But I am afraid you are shoehorning the topic in order to be able to do
so as this was never a discussion about specific SoC manufacturers.

This section was a discussion about how we used *whatever* ARM64 SoC
platform we saw as fitting (on account of it being cheap and widespread,
and nothing else) to demonstrate that SBBR is not just for vendors who
design server platforms and have a significant amount of resources.

> Broadcom's Minimum Order Quantity for these processors, which are
> designed for mass-volume IPTV, Set Top Box and other multimedia
> computing appliances, is 5 million units and above.

Irrelevant.

> Normally Broadcom would provide the full software stack for the customer
> placing 5, 10, 50, 100 million orders for a complete solution.  That
> customer *does not care* about the software boot process or some xHCI
> incompatibility.
>
> Have people forgotten already that the only reason the original PI
> exists is because Eben Upton was an employee who, having access to
> normally NDA'd documentation, worked on the PCB in his spare time?  This
> was the only exception to Broadcom's normal MOQ rules, they could not
> exactly tell him to stop when he told them it was for educational
> purposes, could they?

Still irrelevant.

> please understand: the manufacturers of these SoCs consider you, all
> Free Software idiots (including me) to be an absolute nuisance.

Yes. We know.

But, and here's the kicker that you appear to ignore in order to go on
this tangent, we have demonstrated that one can *still* provide an SBBR
UEFI implementation for platforms where vendors are less than cooperative.

And this is kind of the point: If we could achieve it for a platform
where we got little cooperation (for the record, even if it's in their
interest, I wouldn't say that the Raspberry Pi Foundation are exactly
onboard with the SBBR effort, which may have to do with it having been
developed externally), then it means it should also be achievable for
others.

The point is: It is possible to get SBBR even from relatively
uncooperative vendors.

And the fact that Broadcom are, per your description, one of the less
friendly manufacturers when it comes to Open Source software helps bring
the point home.

But please understand, we could also have picked the manufacturer that's
friendliest for FLOSS, and it wouldn't have made much of a difference.

With the goal of demonstrating that you can pick this or that ARM64 SoC
based platform out there, and produce an SBBR-compliant UEFI firmware
for it, the choice or what platform was picked becomes largely
irrelevant and out of scope for this topic (except for the fact that it
coincided with the platform OP plans to use).

> i showed the manufacturers of my laptop the linux kernel boot process at
> Computex, they told me it looked like i was spying on their product!
>
> we are "lapping at the heels" of these massive Corporations.  we are
> nothing to them.

I don't know who that "we" is, but if your idea is that the people who
are interested in showcasing SBBR went with a Broadcom-based platform,
with some desire to help their business, you are missing the mark.

Again, we, as developers of this specific SBBR showcase, couldn't have
cared less about the SoC manufacturer (as long as we could obtain a
minimum level of information to allow for development, as, obviously,
"we" can't do miracles for a fully closed platform) and could have
picked the Librest SoC implementation just as well, if it made a good
showcase.

But then, and that is part of the point, had we done just that, we
probably would have faced some pushback of "Well, your SBBR
implementation only works because the SoC manufacturer was open and
cooperative. But that's never going to work in the real world of
Broadcom, Qualcomm and Whoever-com..."

In a sense, using the SoC from a corporation that looks down on Open
Source efforts is a boon, because it demonstrates that, as much as we
would like the SBBR effort to come from cooperative platform and SoC
designers themselves (and the established goal of producing an SBBR
compliant for the Pi 4 is precisely to show that this is easier to
accomplish than platform manufacturers may think), the community can
also bypass them if that's what's needed, in the same manner as the
community got together to ensure that Linux can be installed on
platforms where the manufacturers only cared about non Free/Libre OSes.

> when we can place orders for a million processors, *then* they will
> listen to what you and I want, Pete.

No.

When we showcase what's achievable, and demonstrate that the cost of
achieving it might be a lot less than a company's estimate, as well (and
that is the most crucial point) that it can be greatly beneficial for
the end users of the platform (because this is something that, as
cynical as one can be on that topic, *might* ultimately translate to
profit), then they *may* listen to what *some* people want, which is to
make the means of installing and running OSes on ARM64 a lot more
user-friendly than it is now.

> sorry if any of the reality check above shocks you.

You are assuming a lot here. And I'm afraid that you are assuming very
very wrong.

> personally i got
> absolutely sick of the ongoing callous pathological exploitation of our
> collective expertise, many years ago,

I believe this is what you should have started with, because it then
makes your desire to go on this largely irrelevant tangent a lot clearer.

> and started a new SoC initiative.
>  it's entirely Libre.  [and offtopic for the debian-arm list, so please
> if you would like to discuss that, contact me direct or on freenode
> #libre-soc].

And that is great.

I can only wish you all success with it, and also that you will be
considering developing or helping people who want to develop an SBBR
compliant firmware, as (to come back to the actual topic since, once
again, *this* is the only goal we are interested in here) it should make
life easier for end users who are trying to install Libre operating
systems onto it.

Regards,

/Pete

[Rick Thomas]

Hmmm... The "tested images" page [1] lists images for both Buster and Bullseye that reportedly boot on the RPi 0W. I don't know what they had to do to make it work. They're cheap enough that I may just buy one and try it, for fun.
Rick

[1] https://raspi.debian.net/tested-images/

[Rick Thomas]

Please continue this discussion under a different Subject. It has nothing to do with my original question.

Thanks!
Rick

[LinAdmin]

I am not convinced that all images listed on [1] do work as
advertized.

[Diederik de Haas]

On zaterdag 20 februari 2021 13:46:00 CET Rick Thomas wrote:
> Hmmm... The "tested images" page [1] lists images for both Buster and
> Bullseye that reportedly boot on the RPi 0W. I don't know what they had to
> do to make it work. They're cheap enough that I may just buy one and try
> it, for fun.

What Ian said is entirely correct.
The images for the Pi 0/0w/1 are build from raspi_1_bullseye.yaml (for
Bullseye ofc) and use armel
The images for RPi 2 use armhf
The images for RPi 3 and 4 use arm64

On zaterdag 20 februari 2021 12:27:34 CET Matthias Klein wrote:
> The prebuild images use the armel baseline:
> https://salsa.debian.org/raspi-team/image-specs/-/blob/master/Makefile#L70

And Matthias pointed to the solution that was taken for the 'tested images'.
(Responding as your question came after Matthias posted his response)

HTH

[Rick Thomas]

Thanks, yes that does help a lot.

I'm always amazed by the helpfulness and depth of knowledge shown by the folks on the Debian lists!
Rick

> Attachments:
> * signature.asc

[Rick Thomas]

I downloaded the pre-installed SD card image from

https://raspi.debian.net/tested-images/

I used the "2021.02.10 10 (Buster) 4" image. I

Here's what I did:

Downloaded the img.xz file and the sha256 file, and used the sha file to check the integrity of the img file.

Uncompressed the img.xz and used dd to copy it to a 32GB micro-SD card. I noticed that it left a lot of unused space on the card. (I'll come back to that in a later report)

Powered off the RPi4; disconnected all the USB components (except keyboard and mouse) that were attached to it; replaced the old SD card with the one I had just created; and re-applied power. It booted and gave me a console login prompt.

Logged in as "root" (As shipped, the root account has no password); changed the root password to something slightly less insecure. Created a user account and verified that I could use the user account to ssh to the RPi from another computer. Thus verifying that the system had drivers for the RJ45 ethernet port.

Ran "apt update && apt upgrade" which worked fine.

Noticed that the system as shipped is very "bare bones", so I was glad that apt worked and I could install several utilities I would need later.

Since one of my goals is to run this as an NTP server, I was somewhat surprised to note that "hwclock" didn't work (Missing driver, maybe?) :
root@pi:~# hwclock --verbose --show
hwclock from util-linux 2.33.1
System Time: 1613889592.600667
Trying to open: /dev/rtc0
Trying to open: /dev/rtc
Trying to open: /dev/misc/rtc
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

root@pi:~# ls -l /dev/rtc*
ls: cannot access '/dev/rtc*': No such file or directory

What package should I file a bug report against for this problem?

That's it for now. Next I'll try the "2021.02.10 11 (Bullseye) 4" image.

Enjoy!
Rick

[Reco]

Hi.

On Sat, Feb 20, 2021 at 10:53:18PM -0800, Rick Thomas wrote:
> root@pi:~# ls -l /dev/rtc*
> ls: cannot access '/dev/rtc*': No such file or directory
>
> What package should I file a bug report against for this problem?

There's nothing to report. No model of Raspberry PI has RTC, so this is
expected.

Reco

[Rick Thomas]

Hmmm... A little googling turns up a GPS hat from Adafruit which fits the Pi4B. It can double as both a battery backed hardware clock and an NMEA-PPS source for ntp, which would be very cool. Cost is about $40 which is well within the budget for this project.

Thanks for the encouragement!
Rick

[Reco]

Hi.

Way too expensive. A battery-backed DS1307 chip will cost you $4-5 on
Amazon *and* will do the same as far as RTC is concerned.

Of course, if you absolutely need GNSS that's different. Separate GNSS
UART connected chip cost me $20 - a certain Neoway G7.

And yes, you can attach both to your RPi.

Reco

[Alan Corey]

Price sounds high, look around a little.  This is a GPS clock module?  The bare module is in the $5 range I think, I have a few.  Mine came from dx.com

[Alan Corey]

I guess a question is why you want an RTC. If you have a decent
internet connection just run NTP on something and it will set the
computer's clock. If you have a cell phone install the Termux app and
then NTP under that, that can be your local NTP clock.

I looked into it a little years ago when I had only a part time dial
up connection. There is a time signal on GPS satellites with about 1
microsecond accuracy, it's how a GPS works, by triangulation. But
then I got my first cell phone which got me both internet and an
accurate time. And now I tether one to a Pi with a USB cable and it's
a wifi AP for the whole house.

--
-------------
Education is contagious.

[Reco]

Hi.

On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> I guess a question is why you want an RTC. If you have a decent
> internet connection just run NTP on something and it will set the
> computer's clock.

IPSec, Tor, sec=krb5* NFS mounts.

At least these four things are badly screwed if Debian OS lacks access
to RTC. Systemd manages to launch those before NTP-based time
synchronization kicks in, which leads to funny things to say the least.


And last, but not least, having working RTC leads to meaningful
timestamps in log files that describe "early boot" (i.e. before NTP time
sync kicks in), and that's valuable to me by itself.

Reco

[Jeffrey Walton]

On Sun, Feb 21, 2021 at 8:58 AM Reco <recov...@enotuniq.net> wrote:
>
> Hi.
>
> On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> > I guess a question is why you want an RTC. If you have a decent
> > internet connection just run NTP on something and it will set the
> > computer's clock.
>
> IPSec, Tor, sec=krb5* NFS mounts.

And anything related to X.509.

In the old days of cell phones, back when you needed a SIM card to get
time from the network, you had to jump through hoops to use a
non-provisioned device for development.

I think things have gotten better since then. I don't recall seeing
clock problems on unprovisioned devices in a while.

> At least these four things are badly screwed if Debian OS lacks access
> to RTC. Systemd manages to launch those before NTP-based time
> synchronization kicks in, which leads to funny things to say the least.

This may be a Systemd bug.

> And last, but not least, having working RTC leads to meaningful
> timestamps in log files that describe "early boot" (i.e. before NTP time
> sync kicks in), and that's valuable to me by itself.

Jeff

[Andrei POPESCU]

On Du, 21 feb 21, 09:20:07, Jeffrey Walton wrote:
> On Sun, Feb 21, 2021 at 8:58 AM Reco <recov...@enotuniq.net> wrote:
> > On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> > > I guess a question is why you want an RTC. If you have a decent
> > > internet connection just run NTP on something and it will set the
> > > computer's clock.
> >
> > IPSec, Tor, sec=krb5* NFS mounts.
>
> And anything related to X.509.
>
> In the old days of cell phones, back when you needed a SIM card to get
> time from the network, you had to jump through hoops to use a
> non-provisioned device for development.
>
> I think things have gotten better since then. I don't recall seeing
> clock problems on unprovisioned devices in a while.
>
> > At least these four things are badly screwed if Debian OS lacks access
> > to RTC. Systemd manages to launch those before NTP-based time
> > synchronization kicks in, which leads to funny things to say the least.
>
> This may be a Systemd bug.

I'd say it's up to each daemon to declare its dependencies in the
service file.

The problems are likely also much less visible for systems that are
always on as systemd-timesyncd will quite quickly advance the clock on
reboots based on a time stamp saved during shutdown.

Kind regard,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Reco]

Hi.

On Sun, Feb 21, 2021 at 06:10:08PM +0200, Andrei POPESCU wrote:
> On Du, 21 feb 21, 09:20:07, Jeffrey Walton wrote:
> > On Sun, Feb 21, 2021 at 8:58 AM Reco <recov...@enotuniq.net> wrote:
> > > On Sun, Feb 21, 2021 at 08:42:45AM -0500, Alan Corey wrote:
> > > > I guess a question is why you want an RTC. If you have a decent
> > > > internet connection just run NTP on something and it will set the
> > > > computer's clock.
> > >
> > > IPSec, Tor, sec=krb5* NFS mounts.
> >
> > And anything related to X.509.
> >
> > In the old days of cell phones, back when you needed a SIM card to get
> > time from the network, you had to jump through hoops to use a
> > non-provisioned device for development.
> >
> > I think things have gotten better since then. I don't recall seeing
> > clock problems on unprovisioned devices in a while.
> >
> > > At least these four things are badly screwed if Debian OS lacks access
> > > to RTC. Systemd manages to launch those before NTP-based time
> > > synchronization kicks in, which leads to funny things to say the least.
> >
> > This may be a Systemd bug.
>
> I'd say it's up to each daemon to declare its dependencies in the
> service file.

The problem here is "started NTPd != time sync". Lack of internet
connectivity, slow to start 1st stratum time source (GNSS cold start can
take several minutes), misconfiugured resolver - it all will lead to the
problem described above.

And it's perfectly understandable why systemd does not have
"time-synced.target" state. To have it it needs to magically deduce
correct time somehow :)

So no, it's not a bug per se, but an unimplementable restriction, and it
cannot be solved by introducing everyone's dependency on ntpd. Besides,
if your platform provides RTC (and most do) - it's a problem that should
not arise at the first place.

> The problems are likely also much less visible for systems that are
> always on as systemd-timesyncd will quite quickly advance the clock on
> reboots based on a time stamp saved during shutdown.

And again - started systemd-timesyncd != synced time. The only
difference with proper ntpd is that systemd-timestynced uses only one
source of correct time - another NTP server.

Reco

[Alan Corey]

I think it's unreasonable to expect that kind of time accuracy from the first microsecond of bootup.  Relative accuracy maybe, by counting cycles of a crystal oscillator and storing events in some buffer.  Then once you have a good time reference write them all out to permanent storage by doing the arithmetic to assign real times to those events.

[Reco]

On Sun, Feb 21, 2021 at 12:19:31PM -0500, Alan Corey wrote:
> I think it's unreasonable to expect that kind of time accuracy from the
> first microsecond of bootup. Relative accuracy maybe, by counting cycles
> of a crystal oscillator and storing events in some buffer. Then once you
> have a good time reference write them all out to permanent storage by doing
> the arithmetic to assign real times to those events.

The kernel itself does exactly this.
But what does it tell the kernel about the "right" time in the rest of
the world (i.e. - any other host)? Exactly nothing.

End result - you can measure whatever happens during the boot just fine,
but you start 1st Jan 1970 0:00 each boot.

You see, the problem is not the timekeeping, it's the setting
more-or-less the same time on different systems.

Reco

[Alan Corey]

That's why when you get a real time you adjust the times on your logged events.  There's the time you got the time fix, everything else is N microseconds before that back to when you started recording. So you record back to <time fix time> minus <recording duration>.

[Reco]

On Sun, Feb 21, 2021 at 02:36:52PM -0500, Alan Corey wrote:
> That's why when you get a real time you adjust the times on your logged
> events. There's the time you got the time fix, everything else is N
> microseconds before that back to when you started recording. So you record
> back to <time fix time> minus <recording duration>.

Yup. But by the time you get this "real time" you have other processes
(rpc.gssd, for instance) which already have managed to communicate with
someone (KDC), and are in the wrong state (krb5 time difference).

RTC solves this, "fake RTC" (i.e. storing a timestamp on reboot) solves
it to some extent, but nothing else does.

Reco

[Gene Heskett]

And I try to make it easy on the level2 servers (most distro
naintained "pool.ntp.org" site that supply the net since I have 5 or 6
machines running mostly 24/7, I've configured my router to rebroadcast
on my local, not accessable home network. So that makes this router a
level 17 server and all the rest of my boxes get time well wihin 5
milliseconds of ntp. But to the level2 servers in the typical pool, I am
just one client.

Since its a free service but they still have to pay for the bandwidth,
and electricity to run them, it makes sense to cut the bytes used if you
can.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Rick Thomas]

My goal is to replace my aging sheevaplug with something more modern. The sheevaplug exists for the purpose of providing network services (in particular, for the purposes of this discussion, NTP) to the 20 or so computers on my home LAN. To do that, it needs to have a reliable source of accurate time (to a few tens of milliseconds) as soon after boot as possible.

The machine I'd like to use is a Raspberry Pi4B or a Pi0W. But without an RTC it won't do the job.

Hence, I'm looking for an RTC module that can be easily added to a Pi4B or Pi0W with minimal (ideally none) soldering, and with Debian kernel support. If the module also does GPS, so much the better! But that's not strictly necessary. It would be very nice if it fits inside the existing case for the Pi4B.

Do any of the devices that folks have mentioned here fit that bill?

Thanks!
Rick

[ore...@disroot.org]

February 21, 2021 7:12 AM, "Rick Thomas" <rick....@pobox.com> wrote:

> Since one of my goals is to run this as an NTP server, I was somewhat surprised to note that
> "hwclock" didn't work (Missing driver, maybe?) :
> root@pi:~# hwclock --verbose --show
> hwclock from util-linux 2.33.1
> System Time: 1613889592.600667
> Trying to open: /dev/rtc0
> Trying to open: /dev/rtc
> Trying to open: /dev/misc/rtc
> No usable clock interface found.
> hwclock: Cannot access the Hardware Clock via any known method.

FYI, for next purchase, maybe. Pine A64+ board had a couple options for RTC battery attachments and for battery backup. On Bullseye/sid, that command is working. Thanks for helping me feel I didn't waste a few dollars on that option. :)

# hwclock --verbose --show
hwclock from util-linux 2.36.1
System Time: 1613958480.577164
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1612997502 seconds after 1969
Last calibration done at 1612997502 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2021/02/22 01:48:03
Hw clock time : 2021/02/22 01:48:03 = 1613958483 seconds since 1969
Time since last adjustment is 960981 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2021-02-21 20:48:01.547366-05:00

[ore...@disroot.org]

February 19, 2021 4:45 PM, "Gunnar Wolf" <gw...@debian.org> wrote:
> Pete Batard dijo [Fri, Feb 19, 2021 at 02:48:41PM +0000]:
>
>>
>> The end result is that you may not have as much flexibility with user setup,
>> partitioning and so on, as you would have with using the formal Debian
>> installer.
>
> I completely agree here - That's why I¹ have stubbornly refused adding
> packages to the base install; the image is shipped with a base system,
> adding only the smallest possible handful of packages I could find to
> get a working system (ssh, parted, dosfstools, iw, wpasupplicant,
> raspi-firmware and firmware-brcm80211). The anti-pattern is the
> overloaded Raspbian (specially its first iterations, before they
> started shipping the non-GUI version).
>
> ¹ I speak in first person as it is me who builds said images. Diedrik,
> who answered to your mail, is also a team member and has helped
> quite a bit with QA and insight.
>
>> And of course, the problem with preinstalled images like these is that
>> distro maintainers need to multiply them for every platform they want to
>> support, which quickly become unmanageable and leaves any user of any
>> platform that hasn't deemed worth supporting stranded...
>
> Right again -- The motivation for Michael Stapelberg first, then for
> me to take on his work, is simply the amount of Raspberry systems out
> there for which there was no easy way to get Debian running, despite
> it being completely capable of doing so.

An advantages of minimal images versus normal install process is less user time and tedium. If you have several Pi's to setup similarly, with favorite sets of a few additional packages, headless, it is faster to dd a minimal image, then do a few manual steps and run a script for your customizations. Versus the longer step-by-step process of normal installs. Thank you Gunnar, and Michael!

[Reco]

Hi.

On Sun, Feb 21, 2021 at 01:58:08PM -0800, Rick Thomas wrote:
> Hence, I'm looking for an RTC module that can be easily added to a
> Pi4B or Pi0W with minimal (ideally none) soldering, and with Debian
> kernel support. If the module also does GPS, so much the better! But
> that's not strictly necessary. It would be very nice if it fits
> inside the existing case for the Pi4B.
>
> Do any of the devices that folks have mentioned here fit that bill?

DS1307 has in-tree kernel module that works. A minor problem is that
Debian does not build it - #958904.

And if soldering is not your cup of tea - look for so-called Breakout
Board Kit, like that one - [1].

[1] https://www.amazon.com/DS1307-Real-Clock-Breakout-Board/dp/B00NAY199E

Reco

[Leigh Brown]

Hi Rick,

Take a look at the following. No soldering required, and they fit in the
case nicely (for Pi4 at least).

Adafruit PiRTC - PCF8523 Real Time Clock for Raspberry Pi
(https://www.adafruit.com/product/3386)

Adafruit PiRTC - Precise DS3231 Real Time Clock for Raspberry Pi
(https://www.adafruit.com/product/4282)

Regards,

Leigh.

[Gunnar Wolf]

Rick Thomas dijo [Sat, Feb 20, 2021 at 04:46:00AM -0800]:

> Hmmm... The "tested images" page [1] lists images for both Buster
> and Bullseye that reportedly boot on the RPi 0W. I don't know what
> they had to do to make it work. They're cheap enough that I may
> just buy one and try it, for fun.

They basically "just worked" from the beginning -- using the
linux-image-rpi kernel build and the armel architecture. Yes, they are
slow... but they work quite well if you don't want more than what they
can provide!

[Gunnar Wolf]

LinAdmin dijo [Sat, Feb 20, 2021 at 07:30:35PM +0100]:

> I am not convinced that all images listed on [1] do work as
> advertized.

> (...)
> > [1] https://raspi.debian.net/tested-images/


Right. I'm only one person responsible for the builds, and quite
time-starved myself. I did test on real hardware all of the provided
images, and verified basic functionality for everything I'm claiming
there... But help is most welcome to improve!

(and, yes, the great raspi-team has helped quite a bit, but all in
all, the final step of image building and creation is down to my ten
fingers and pair of eyes)

[Rick Thomas]

I'm here to help test. I don't have the developer skills (anymore -- last time I did that kind of stuff was 30 years or more ago. The world has seen a lot of changes since then!)

Please feel free to email me off list if there's anything I can do to help.

Rick

[Rick Thomas]

On Mon, Feb 22, 2021, at 2:45 AM, Leigh Brown wrote:
> Hi Rick,
...

> Take a look at the following. No soldering required, and they fit in the
> case nicely (for Pi4 at least).
>
> Adafruit PiRTC - PCF8523 Real Time Clock for Raspberry Pi
> (https://www.adafruit.com/product/3386)
>
> Adafruit PiRTC - Precise DS3231 Real Time Clock for Raspberry Pi
> (https://www.adafruit.com/product/4282)

I've ordered one of the high precision modules from adafruit. It looks like it will fit inside the case and hence be protected from accidental damage or exposure to the elements.

I'll report back when I've got it installed.

Thanks for the pointers!
Rick

[Rick Thomas]

I installed the most recent Bullseye image [1] on my Pi4B (4GB) a few days ago. It's happily running on the table next to me right now.

Here's what I found:

It loads and boots just as expected. Apt and tasksel work and I was able to install all the utilities I need to make it useful on my network.

However, I noticed a couple of things that I should have expected, but nevertheless caused me some confusion at first:
1) The default timezone is set to UTC. I had to manually set it to account for the fact that I live on the US West Coast.
2) When I tried to use aptitude, it complained about not having "locale" info. I would have expected default locale to be set to something like "C" that would avoid the error messages, even if some/most users would want to re-set it to their own preferences, later on.

It would be nice if there was a README describing these quirks (and any others I've missed), and how to deal with them after the first boot. Even better would be if there was a script that automatically ran on the first boot that asked a bunch of questions and made the appropriate customizations automatically. I'd be willing to write such a script if someone else would first write the README so I knew exactly what the script needed to do.

Great work! Looking forward to the next iteration.

Enjoy!
Rick


[1] "2021.02.10 11 (Bullseye) 4" https://raspi.debian.net/tested-images/

[Alan Corey]

There are scripts for those, keyboard and language too.  Also WiFi country, I forget what else.  Locales is in there.

Take a look at a recent raspi-config.  I think Odroid, maybe the Pine64 bunch has a generic-ized version of that.  Armbian probably does too.  Raspi-config is just a Bash script that uses Whiptail for its menus.  Parts of it are useful on other things.  It's on Github somewhere.

[Rick Thomas]

On Thu, Feb 25, 2021, at 10:10 PM, Alan Corey wrote:

There are scripts for those, keyboard and language too.  Also WiFi country, I forget what else.  Locales is in there.

Take a look at a recent raspi-config.  I think Odroid, maybe the Pine64 bunch has a generic-ized version of that.  Armbian probably does too.  Raspi-config is just a Bash script that uses Whiptail for its menus.  Parts of it are useful on other things.  It's on Github somewhere.

On Thu, Feb 25, 2021, 11:09 PM Rick Thomas <rick....@pobox.com> wrote:

 

Thanks! Alan...

So, here's what I found...

Immediately after the first boot of the SD card, as root, do the following:

#Get the raspi-config utility:

    wget https://archive.raspberrypi.org/debian/pool/main/r/raspi-config/raspi-config_20200601_all.deb -P /tmp

#Install packages it needs:

    apt-get install libnewt0.52 whiptail parted triggerhappy lua5.1 alsa-utils -y

    sudo apt-get install -fy

#Install the utility itself:

    dpkg -i /tmp/raspi-config_20200601_all.deb

#And run it

    raspi-config

It will give you a bunch of customizations you might want to do.  I can personally vouch that you'll need to at least do options (1) change the root password and set up a non-root user,  (2) Configure the network, and (4) set localizations (timezone, keyboard, locale, and a few others).

The 20200601 version happens to be the latest as of this writing.  But just to be sure, you can use the tool itself (option 8) to check for and install any updated version.

Easy!

Rick

[Andrew M.A. Cater]

And whoosh - you've created a FrankenDebian and dependencies on a Raspberry
Pi OS that you don't run.. Raspi-config is a collection of
shell scripts. Gunnar's Raspberry Pi images are deliberately small.

If you want to reconfigure locale -

apt-get install locales ; dpkg-reconfigure locales

(this last as root / root equivalent using sudo)

Timezone: dpkg-reconfigure tzdata

There are good Debian commands that will work on every Debian system you
come across :-)

All the very best, as ever,

Andy C.

[Alan Corey]

Right, I wasn't exactly recommending running raspi-config on a non-raspian system but looking at how it does things and doing them manually.  One of the things I dislike about Debian (I haven't looked at others) is that there's an ever-increasing hodgepodge of specialized little scripts.  If you've been using it awhile you're probably not in the habit of re-reading documentation to see if somebody changed how you're officially supposed to do something.

But raspi-config is a place to look up things like how to boot to a command line, or how to configure locales or change your keyboard layout.  And it's maintained, unlike some ancient documentation that should be banished but is still out there.

[Rick Thomas]

Thanks Andy and Alan, for the clarification.

This is an experimental system, so I felt there was no long-term harm (it being a short-term installation, anyway) in installing rapsi-config from the raspian archives just to see what it looked like and explore what it could do.  Having verified that it really doesn't do anything I can't do just as easily manually (all the things Andy listed and a few more) I will probably take the manual approach in the future.

Enjoy!

Rick

[Alan Corey]

What's interesting about raspi-config is that it works to some degree
on all the little ARM machines. If it can't find what it's trying to
change it aborts. No guarantees but I've never seen it break
anything. I never overclock anything.

[Ryutaroh Matsumoto]

Hi John,

> Does anyone have wifi running on an RPi400 with Debian 64 Buster or
> Bullseye?

I'm using RPi4B 8GB model, which seems similar to RPi400.
Without "module_blacklist=vc4" in the kernel command line
(i.e. "cmdline.txt"), WiFi on my RPi4B does not work.

Best regards, Ryutaroh

[LinAdmin]

Bullseye 64 Bit does more or less work. There arise problems when you install a desktop with media players which deliver audio and should give output to the headphone plug and HDMI.

I also had to find out that all 64 Bit versions of all distributions are much less powerful than the 32 Bit solution of the same software. The benchmark by T. Kaiser shows that some performances of 64 Bit are only about half of the values compared to the 32 Bit installation :-(

Unfortunately the Bullseye 32 Bit kernel seems not to boot, because the support of USB looks broken:

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

I just wonder why this bug has not got any answers?

My personal judgement: The Pi 4 with 8GB RAM has fantastic performance for a small desktop system at very low cost. For this reason I grudgingly accept  the closed source blobs required...

Happy computing!

LinAdmin

[Andrei POPESCU]

On Du, 28 feb 21, 06:49:49, Alan Corey wrote:
> Right, I wasn't exactly recommending running raspi-config on a non-raspian
> system but looking at how it does things and doing them manually. One of
> the things I dislike about Debian (I haven't looked at others) is that
> there's an ever-increasing hodgepodge of specialized little scripts. If
> you've been using it awhile you're probably not in the habit of re-reading
> documentation to see if somebody changed how you're officially supposed to
> do something.

What scripts would that be?

The 'dpkg-reconfigure' command is the standard method to (re)configure
packages that are using debconf.

As far as I know the Debian Installer does the equivalent of
'dpkg-reconfigure --priority=<priority> <package>' (when run manually
'priority' defaults to 'low').

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Arnd Bergmann]

On Mon, Mar 1, 2021 at 9:40 AM LinAdmin <lina...@quickline.ch> wrote:
>
> Bullseye 64 Bit does more or less work. There arise problems when you install a desktop with media players which deliver audio and should give output to the headphone plug and HDMI.
>
> I also had to find out that all 64 Bit versions of all distributions are much less powerful than the 32 Bit solution of the same software. The benchmark by T. Kaiser shows that some performances of 64 Bit are only about half of the values compared to the 32 Bit installation :-(
>
> Unfortunately the Bullseye 32 Bit kernel seems not to boot, because the support of USB looks broken:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981586
> I just wonder why this bug has not got any answers?

Presumably nobody has tried debugging it ;-)

There is really no good reason to run a 32-bit /kernel/ on the Pi 4,
especially the version
with 8GB RAM. While the bug should get fixed in principle to make the
default kernel
work and allow installing a 32-bit distro, the best setup for this
machine (especially
the versions with less than 4GB) is to use an armhf user space with a
64-bit kernel.

You can get that today by installing a multiarch system starting with
an armhf install
(if you get its kernel to boot) and then running 'dpkg
--add-architecture arm64' to
allow installing the arm64 version of the kernel image. It would be
nice to actually
package the arm64 kernel image for armhf to make it easier to run this
way without
having to set up a multiarch system. This is how mipsel kernels work as well, so
there is definitely precedence.

Arnd

[Alan Corey]

Or just run raspbian on a Pi 3B, I've got 4 of them. omxplayer and
other things that utilize the GPU make it quite livable.

[Leigh Brown]

Hi Alan,

On 2021-03-01 12:35, Alan Corey wrote:
> Or just run raspbian on a Pi 3B, I've got 4 of them. omxplayer and
> other things that utilize the GPU make it quite livable.

In my opinion, that is not the best advice if you are looking to
purchase something new.

When compared to the Pi 3B, the PI 4B has:
* at least double the RAM
* DDR4 versus DDR2
* Cortex-A72 versus Cortex-A53
* Better thermals to reduce the chances of thermal throttling
* Full Gigabit performance versus 300Mb
* 25% fast Videocore (500MHz versus 400MHz)

Benchmarks really show the differences[1].

Cheers,

Leigh.
--
[1]
https://www.phoronix.com/scan.php?page=article&item=raspberry-pi4-benchmarks

[ore...@disroot.org]

I got wifi working on RPi4B 4GB, and RPi Zero W with Buster, with only the following. Using a couple months older version of:

https://wiki.debian.org/WiFi/HowToUse

It was Command line section, now is Using_ifupdown section:

To get interface name (wlan0):
# ip a

To bring up interface:
# ip link set wlan0 up

To scan for networks (not necessary at home):
# iwlist scan

Edit /etc/network/interfaces.d/wlan0
Uncomment lines and change to my wifi SSID and password.

To connect (have some patience):
# ifup wlan0

To verify IP address:
# ip a

It's probably better, more secure, to use WPA-PSK so the password is encrypted, but the above was simpler and worked.

[Ryutaroh Matsumoto]

> Bullseye 64 Bit does more or less work. There arise problems
> when you install a desktop with media players which deliver
> audio and should give output to the headphone plug and HDMI.

Diederik reported probably the same problem to the linux-rpi-kernel
list as
http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-February/008002.html
For that problem, black listing vc4.ko at cmdline.txt prevents the problem
http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-February/008007.html

> Unfortunately the Bullseye 32 Bit kernel seems not to boot,
> because the support of USB looks broken:

Debian kernel team does not support booting 32-bit kernel
on 64-bit ARM, as told by Ben
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971059#12

Best regards, Ryutaroh

[Diederik de Haas]

On dinsdag 2 maart 2021 00:04:01 CET ore...@disroot.org wrote:
> Edit /etc/network/interfaces.d/wlan0
> Uncomment lines and change to my wifi SSID and password.

> ...

> It's probably better, more secure, to use WPA-PSK so the password is
> encrypted, but the above was simpler and worked.

You can use wpa_passphrase to 'encrypt' your wifi password.

[LinAdmin]

On 01.03.21 10:54, Arnd Bergmann wrote:
> On Mon, Mar 1, 2021 at 9:40 AM LinAdmin <lina...@quickline.ch> wrote:
>> Bullseye 64 Bit does more or less work. There arise problems when you install a desktop with media players which deliver audio and should give output to the headphone plug and HDMI.
>>
>> I also had to find out that all 64 Bit versions of all distributions are much less powerful than the 32 Bit solution of the same software. The benchmark by T. Kaiser shows that some performances of 64 Bit are only about half of the values compared to the 32 Bit installation :-(
>>
>> Unfortunately the Bullseye 32 Bit kernel seems not to boot, because the support of USB looks broken:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981586
>> I just wonder why this bug has not got any answers?
> Presumably nobody has tried debugging it ;-)

I have have tried debugging it and found out that USB
support is not enabled. USB-Keyboard is dead and therefore
no uas either.

Lacking knowledge of kernel configuration I could not yet
find that specific switch :-)

> There is really no good reason to run a 32-bit /kernel/ on the Pi 4,
> especially the version
> with 8GB RAM. While the bug should get fixed in principle to make the
> default kernel
> work and allow installing a 32-bit distro, the best setup for this
> machine (especially
> the versions with less than 4GB) is to use an armhf user space with a
> 64-bit kernel.

Benchmarking shows that the Pi4 with 32 bit kernel has about
double performance compared to 64 bit kernel!!!

Regards

LinAdmin

[LinAdmin]

That approach may be reasonable for many arm architectures
which do not show considerably lower performance on 64 bit
compared to 32 bit.

For the Pi4 this is an undeniably good reason not to use 64
bit because contrary to common believes the 32 bit kernel
has no problems with 8 GB of RAM.

Regards

LinAdmin

>
> Best regards, Ryutaroh
>

[Arnd Bergmann]

highmem is a huge problem by itself, and we plan to remove
it in the future for 32-bit kernels across all architectures. We should
probably add a boot-time warning in the mainline kernel as well
for any such configuration.

There is a small overhead in memory consumption for running
a 64 bit kernel, but for configurations with more at least 512MB
of RAM, you tend to be better off running a 64-bit kernel in order
to make use of all the features, optimizations and errata workarounds
that are missing in 32-bit kernels.

Arnd

[Arnd Bergmann]

On Tue, Mar 2, 2021 at 7:51 PM LinAdmin <lina...@quickline.ch> wrote:

> > There is really no good reason to run a 32-bit /kernel/ on the Pi 4,
> > especially the version
> > with 8GB RAM. While the bug should get fixed in principle to make the
> > default kernel
> > work and allow installing a 32-bit distro, the best setup for this
> > machine (especially
> > the versions with less than 4GB) is to use an armhf user space with a
> > 64-bit kernel.
>
> Benchmarking shows that the Pi4 with 32 bit kernel has about
> double performance compared to 64 bit kernel!!!

Can be more specific about what benchmarks and who ran them?
This seems highly unlikely.

Arnd

[Jeffrey Walton]

Maybe https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956418?

Jeff

[Ryutaroh Matsumoto]

> That approach may be reasonable for many arm architectures
> which do not show considerably lower performance on 64 bit
> compared to 32 bit.
>
> For the Pi4 this is an undeniably good reason not to use 64
> bit because contrary to common believes the 32 bit kernel
> has no problems with 8 GB of RAM.

How about running 32-bit binaries/executables on 64 bit-kernel,
which can be done on RPi with no problem.

My reason for advocating 32-bit binaries on 64-bit ARM CPUs
(not limited to RPi4) is considerably smaller memory footprint.

Best regards, Ryutaroh

[LinAdmin]

The common believe that on the same hardware 64-bit must be better or equal to 32-bit is clearly wrong for the "crazy" BCM2711 chip used in Pi4.

The detailed benchmarks for Raspian Buster are at 32 Bit Kernel 4.19 and 64 Bit Kernel 5.4. showing for calculation AES 16KB  50% less throughput for 64-bit.

On my system I get similar results e.g. for AES-128 (16KB):

    Salsa Buster arm64     5.9.0   42'000

    Ubuntu LTS armv7l      5.4      92'000

When playing a FullHD video coded H265, the average CPU load is 80% on 64-bit and less than 30% on 32-bit!

Similar situations when encoding to H265 using ffmpeg .

LinAdmin

[Arnd Bergmann]

Cortex-a72 does not have those instructions, and they are only
available on 64-bit code (user and kernel space), so this would make
64-bit kernels run faster on some other SoC, but it won't affect
the performance of 32-bit user space, or anything on Raspberry Pi 4.

Arnd

[Arnd Bergmann]

On Wed, Mar 3, 2021 at 9:44 AM LinAdmin <lina...@quickline.ch> wrote:
>
> The common believe that on the same hardware 64-bit must be better or equal to 32-bit is clearly wrong for the "crazy" BCM2711 chip used in Pi4.
> The detailed benchmarks for Raspian Buster are at 32 Bit Kernel 4.19 and 64 Bit Kernel 5.4. showing for calculation AES 16KB 50% less throughput for 64-bit.

This is a user space microbenchmark, it has nothing to do with what the
kernel does underneath it.

Looking at the output, I see it's not even running the same version of
the program:

Test on 32-bit kernel:
OpenSSL 1.1.1c, built on 28 May 2019
type 16 bytes 64 bytes 256 bytes 1024 bytes
8192 bytes 16384 bytes
aes-128-cbc 62184.51k 76615.98k 83103.15k 84435.97k
85237.76k 85169.49k
aes-128-cbc 62511.68k 76704.43k 83097.09k 84763.99k
85150.38k 85229.57k
aes-192-cbc 50203.94k 64933.31k 71396.52k 73090.39k
73602.39k 73706.15k
aes-192-cbc 56285.24k 67498.65k 71976.02k 73356.29k
73525.93k 73258.33k
aes-256-cbc 51010.29k 60062.42k 63579.31k 64656.73k
64927.06k 64831.49k
aes-256-cbc 50869.32k 60057.64k 63678.55k 64560.47k
64935.25k 64891.56k

Test on 64-bit kernel:
OpenSSL 1.1.1d, built on 10 Sep 2019
type 16 bytes 64 bytes 256 bytes 1024 bytes
8192 bytes 16384 bytes
aes-128-cbc 38070.54k 40669.85k 41716.22k 42029.40k
42131.46k 42177.88k
aes-128-cbc 38065.38k 40746.26k 41775.96k 42064.21k
42229.76k 42292.57k
aes-192-cbc 32294.31k 34105.22k 35048.28k 35303.42k
35351.21k 35351.21k
aes-192-cbc 32254.74k 34136.98k 35043.33k 35301.38k
35367.59k 35367.59k
aes-256-cbc 27986.06k 29351.96k 29962.33k 30127.79k
30173.87k 30179.33k
aes-256-cbc 27986.74k 29372.25k 29969.24k 30119.25k
30160.21k 30157.48k

> On my system I get similar results e.g. for AES-128 (16KB):
> Salsa Buster arm64 5.9.0 42'000
> Ubuntu LTS armv7l 5.4 92'000

Do you mean you are running the openssl benchmarks from two
different distros here? Could it be that you are running a 64-bit openssl
binary on the Buster arm64 kernel?

If you want to compare the kernel performance, you have to ensure that
you are running the exact same user space on both. For the openssl
test, it should be sufficient to boot the Buster installation and enter
a chroot.

As you can see in the two listings you sent, the 32-bit version reports
the 'neon' feature, while the 64-bit version reports 'asimd', which is
what 64-bit user space expects, so either those tests are running
64-bit user space, or the 32-bit user space is running on the wrong
'personality' of the kernel.

It's possible that the feature detection in openssl fails when you run
in the wrong personality, as the /proc/cpuinfo output will contain
incompatible information. When you use 'sudo linux32 chroot /mnt/ubuntu-armv7'
to enter the chroot, that chroot should be in the correct personality.

> When playing a FullHD video coded H265, the average CPU load is 80% on 64-bit and
> less than 30% on 32-bit! > Similar situations when encoding to H265 using ffmpeg .

This could be the same problem with incorrect feature detection from
running the wrong personality, or it could be related to missing kernel
drivers for H265 acceleration in the 64-bit kernel. Do you know if this
uses a software codec or an accelerated version in the GPU?

Arnd

[Gene Heskett]

On Wednesday 03 March 2021 03:44:13 LinAdmin wrote:

> The common believe that on the same hardware 64-bit must be
> better or equal to 32-bit is clearly wrong for the "crazy"
> BCM2711 chip used in Pi4.
> The detailed benchmarks for Raspian Buster are at 32 Bit

> Kernel 4.19 <http://ix.io/1MFf> and 64 Bit Kernel 5.4.
> <http://ix.io/2paq> showing for calculation AES 16KB  50%

> less throughput for 64-bit.
>
> On my system I get similar results e.g. for AES-128 (16KB):
>     Salsa Buster arm64     5.9.0   42'000
>     Ubuntu LTS armv7l      5.4      92'000
> When playing a FullHD video coded H265, the average CPU load
> is 80% on 64-bit and less than 30% on 32-bit!
> Similar situations when encoding to H265 using ffmpeg .
>
> LinAdmin
>
> On 02.03.21 21:30, Arnd Bergmann wrote:
> > On Tue, Mar 2, 2021 at 7:51 PM LinAdmin <lina...@quickline.ch>
wrote:
> >>> There is really no good reason to run a 32-bit /kernel/ on the Pi
> >>> 4, especially the version
> >>> with 8GB RAM. While the bug should get fixed in principle to make
> >>> the default kernel
> >>> work and allow installing a 32-bit distro, the best setup for this
> >>> machine (especially
> >>> the versions with less than 4GB) is to use an armhf user space
> >>> with a 64-bit kernel.
> >>
> >> Benchmarking shows that the Pi4 with 32 bit kernel has about
> >> double performance compared to 64 bit kernel!!!
> >
> > Can be more specific about what benchmarks and who ran them?
> > This seems highly unlikely.
> >
> > Arnd

To add further fuel to this fire, this is precisely why, when running cnc
machinery with a pi3 or pi4, an armhf kernel is the only one that comes
anywhere near meeting the performance it takes to do a decent job of
running dangerous machinery. The irq response time of the 64 bit
kernels has been found to be seriously lacking. I built a
4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7l
kernel last on an rpi4 over a year ago, which can respond to a fault
interrupt in as little as 12 microseconds. Several have now tried the
arm64 version and all got far worse latency results. As bad as 200
microseconds. You simply cannot run a stepper motor, using software step
generators at even 10% of that motors speed potential with that kind of
timing wibbles in the steps sent. They will stall, stop, losing step
counts. Even if the code stops and the motor then restarts, you've lost
the home reference and wrecked the part being made. That kernel was also
built for a pi3b and worked well for around 2 years, but the pi3b was
about to its limits.

The other limit to using it, is the odd layout of the /boot directory
enforced by the firmware that boots it, not well documented, so I had to
invent my own way to install that kernel. But suffice to say, its dead
stable. I even put a small ups on it, runs for months. So stable that I
am also running an armhf version of a buildbot for linuxcnc on it.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Alan Corey]

I remember when 16 bit computers ran faster than 32. The data is half
the size. But eventually the advantages of the wider bus win out.
Like memory was measured in K, some chips wouldn't handle more than
640k of RAM without weird schemes. My first computer had 64k.

[Gene Heskett]

On Wednesday 03 March 2021 06:02:31 Alan Corey wrote:

> I remember when 16 bit computers ran faster than 32. The data is half
> the size. But eventually the advantages of the wider bus win out.
> Like memory was measured in K, some chips wouldn't handle more than
> 640k of RAM without weird schemes. My first computer had 64k.
>

My first computer had 256 bytes, Alan. An RCA Cosmac Super Elf, with an
1802 brain. I added another 4k of static ram, $400 for the kit I built
that plugged into an s100 bus I also had to build, then programmed it to
do a rather labor intensive and picture quality reducing job of
preparing a u-matic tape with a commercial on it, to work with an
automatic station break sequencer they had at KRCR, and getting rid of
the pix blurring extra copy step. To me it was a learning experience in
1979. In 1995 I took my then new wife of 6 years back to the left coast
to meet one of my last surviving aunts and to see some of the country
I'd lived in which took me within long distance range of calling that
station. Much to my surprise, it was so handy that 16 years later they
were still using it many times a day. As a retired Chief Engineer of
another medium market tv station, equipment in a tv station control room
has an average lifetime of 2 to 5 years. To have something I designed
and built still in daily use 16 years later was quite a surprise.

[Gunnar Wolf]

Ryutaroh Matsumoto dijo [Mon, Mar 01, 2021 at 11:57:47AM +0900]:

FWIW, I just popped today's daily image for Buster from
raspi.debian.net in my 8GB RPi4, and:

/----buster ↓ ---------------------------------------------------------
| Debian GNU/Linux 10 rpi4-20210226 ttyS1
|
| rpi4-20210226 login: root
| Linux rpi4-20210226 5.9.0-0.bpo.5-arm64 #1 SMP Debian 5.9.15-1~bpo10+1
| (2020-12-31) aarch64
|
| The programs included with the Debian GNU/Linux system are free
| software;
| the exact distribution terms for each program are described in the
| individual files in /usr/share/doc/*/copyright.
|
| Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
| permitted by applicable law.
| root@rpi4-20210226:~# ip l
| 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
| link/ether dc:a6:32:ae:8d:58 brd ff:ff:ff:ff:ff:ff
| 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
| link/ether dc:a6:32:ae:8d:59 brd ff:ff:ff:ff:ff:ff
\----------------------------------------------------------------------

For some reason I canot set up to debug right now, the serial console
gets garbled up (wrong baud rate or so?) when booting with Bullseye,
but connecting a HDMI monitor, it also works -- screenshot attached
:-)

Oh -- And I have just realized no image builds have happened in the
last week (since I did some movements to my build server). I'll try to
fix it and get the builds started again today (but I'm quite busy,
so.... lets hope it's an easy fix!)

[Ryutaroh Matsumoto]

> | 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> | link/ether dc:a6:32:ae:8d:59 brd ff:ff:ff:ff:ff:ff
> \----------------------------------------------------------------------

Just FYI, with kernel version 5.9 and 5.10, I have been unable to
get WiFi on RPi4B 8GB working with 2.4GHz.
5GHz works fine without vc4.ko and fails with vc4.ko.
2.4GHz WiFi is usable with Raspbian kernel 64-bit 5.10,
so I am assuming my hardware is OK.
Since I do not use 2.4GHz WiFi because it gets interfered by my
microwave oven, I have not spent much time on investigating the cause...

Best regards, Ryutaroh

[Alan Corey]

Interference from bluetooth?

[Ryutaroh Matsumoto]

> Interference from bluetooth?

Could be. I have been suspecting this possibility.
But as my main frequency is 5GHz, I have not investigating it...
The Raspbian OS is known to have suffered from the interference
between bluetooth and 2.4GHz WiFi as
https://github.com/RPi-Distro/firmware-nonfree/issues/8

Best regards, Ryutaroh

[Gunnar Wolf]

Ryutaroh Matsumoto dijo [Thu, Mar 04, 2021 at 08:10:15AM +0900]:

I use 2.4GHz networking, as I have several devices which cannot use
5GHz. And I cannot confirm what you mention. Screenshot provided with
the same image I used yesterday. If you don't want to open an attached
image (I often avoid to): Kernel 5.10.0-3-arm64, specified my wlan
details in /etc/network/interfaces.d/wlan0, and got a working network.

Greetings,

[Fan Naibed]

I also mostly use 2.4GHz, because range seems farther through walls.

For me on Pi4, 5.9 kernel, Buster

# iwlist scan

does show some 5 GHz transmitters around me, but does not show MY access point, and I was unable to connect to it with 5 GHz, although my phones can. 2.4 works OK for me with simple wlan0 settings, as Gunnar. The interwebs say setting a country code may help RPi's WiFi, but examples I found were only for wpa_supplicant.conf, which seems "missing" on my Rpi so far.

Does the below "daemon failed to start" mean I need to do something to setup and start wpa supplicant?

# ifup wlan0
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wlan0/whatever
Sending on LPF/wlan0/whatever
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1
ifup: failed to bring up wlan0

[Ryutaroh Matsumoto]

From: Arnd Bergmann <ar...@arndb.de>
Subject: Re: More progress to report
Date: Tue, 2 Mar 2021 21:41:46 +0100

> highmem is a huge problem by itself, and we plan to remove
> it in the future for 32-bit kernels across all architectures. We should
> probably add a boot-time warning in the mainline kernel as well
> for any such configuration.

I found an episode of the above.
As #986326, LTP (linux test project) consistently causes kernel panic
on linux-image-armmp-lpae, while it dosn't on linux-image-armmp,
both on Sid (5.10.26 kernels), 3 GB memory, 1GB swap partition,
and 2 CPU cores on QEMU 5.2.

Best regards, Ryutaroh