Debian on Pine64 H64B?

[oregano...@disroot.org]

At $45 with 3GB RAM, optional eMMC (35 for 64 GB), WiFi, etc., it seems interesting, but why is there almost zero coverage on Debian sites?

The Debian testing installer seemed to work, but initial boot didn't, or gave a blank HDMI display. At this point I don't recall spending any time trying to ssh onto it remotely, or examine the sdcard afterwards. What is the best way to get useful info and report it?

("Offtopic" but FYI) Dietpi worked fine.

These instructions took a long time, but resulted in a (more or less) working Debian system (on SD card). https://github.com/as365n4/Debian_on_Pine64_H64B Could someone point me to a better/cheaper/faster recipe?

Why isn't this SBC listed here https://wiki.debian.org/CheapServerBoxHardware or here https://wiki.debian.org/FreedomBox/Hardware ?

Thanks for any answers or suggestions!

[LinAdmin]

The unnamed decision makers of Debian some unknown time ago
decided that Pi and Pine stuff won't be supported by Debian.

I switched to Ubuntu LTS which made me (and many others) happy.

[Reco]

Hi.

On Sat, Sep 04, 2021 at 09:51:30AM +0200, LinAdmin wrote:
> The unnamed decision makers of Debian some unknown time ago
> decided that Pi and Pine stuff won't be supported by Debian.

Except that Raspberry Pis are supported by Debian.
There are even pre-built images at https://raspi.debian.net

> I switched to Ubuntu LTS which made me (and many others) happy.

Whatever floats your boat.

Reco

[Gene Heskett]

There are enough diffs that that path was not one I'd take. My target
install these days is debian, because LinuxCNC runs on a nearly default
debian install, and has since wheezy.
raspbian follows debian well, but throws anybody not running their kernel
under the buss and grinds them up leaving. Zero support for a realtime
kernel which LinuxCNC demands if its to run real hardware. So I was
forced to build my own. Questions involving it are ignored on their
forum. On the pi3, with its glacial swap, its a nearly 24 hour job.

So I was also forced to invent my own installer, which has now been
running happily since the pi3b shipped. But the pi3b, while doing the
job of running 1500 lbs of a cnc converted Sheldon Lathe, did so with
its tongue hanging out. When the pi4b shipped, the pi3b was replaced,
initially with a raspbian image, mofified by doing my own install of a
realtime kernel. That part is remarkably easy, just put the u-sd in a
card adapter, and unpack my 4.19 tarball to it. plug it back into the
pi4 and its done. And the pi4b does that job without breathing hard.
With startech usb3 adapters to a couple SSD's, I am even running my own
buildbot on it to keep LinuxCNC within a few hours of the github master.
By skipping the pi's earlier years, debian did not do its users any great
favors. The ultimate insult was when I asked a debian-arm related
question here on this list, and I was invited to use the main list,
where arm is a vulgar word.

So I found my own solutions. So, debian-arm, please make up your mind, do
you support the pi's or do you NOT support the pi's?

When I did try a net install of buster, but had no network after the
reboot, I went back to a raspbian seed image and haven't looked back, it
Just Works.

> Whatever floats your boat.

That attitude is Indicating to me that debian-arm still has zero interest
in arm. A sad truth IMO.

> Reco


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>

[Vagrant Cascadian]

On 2021-09-04, LinAdmin wrote:
> The unnamed decision makers of Debian some unknown time ago
> decided that Pi and Pine stuff won't be supported by Debian.

I personally have added support in Debian for:

Raspberry Pi 1
Raspberry Pi 2b
Raspberry Pi 3b+
Pine64+
Pinebook
Pinebook Pro
RockPro64
Rock64

And other platforms... others have added support for other Raspberry PI
and Pine64 platforms, as well as numerous other platforms...

I used the Pinebook as my primary computer for over a year, using
absolutely zero software from outside of Debian...


Debian isn't a consumer product, it is a community project. It is
largely a volunteer effort, suppored by the community, so... if you want
something supported, please help to add the support.

It pretty much comes down to submitting patches, bug reports, merge
requests, etc. to enabled the appropriate kernel options, bootloader
support, and debian-installer support.

Debian doesn't generally support patches that wouldn't be acceptible in
upstream projects, or support non-free binary blobs out of the box, so
maybe the support isn't as good on a per-platform basis as some other
targeted distros willing to use vendor forks or patches for various
components.


The support isn't always perfect; maybe all features don't always work;
I don't and can't personally test all combinations of features on all
platforms, nor have the time to enable all features on all combinations
of platforms. Thankfully, there are others in the community who test and
improve what they can.

Debian could always use more people helping with testing and perhaps
more importantly, upstreaming of support to make sure it works for their
use-cases...

I know not everybody can dive in and fix all kinds of issues, but there
is a pretty broad spectrum of ways to help out... sometimes things are
even supported but undocumented. Documenting workarounds and filing bug
reports appropriately is one angle that could potentially help.

> I switched to Ubuntu LTS which made me (and many others) happy.

Curious what exactly is different with Ubuntu that makes it work for
you...


live well,
vagrant

[Steve McIntyre]

On Sat, Sep 04, 2021 at 09:43:07AM -0400, Gene Heskett wrote:
>On Saturday 04 September 2021 04:48:48 Reco wrote:
>
>> Whatever floats your boat.
>
>That attitude is Indicating to me that debian-arm still has zero interest
>in arm. A sad truth IMO.

Thanks Gene, that's *really* going to help motivate the various folks
who are working on support for Arm platforms, most of them doing that
work on their own time as volunteers.

--
Steve McIntyre, Cambridge, UK. st...@einval.com
"This dress doesn't reverse." -- Alden Spiess

[Andrew M.A. Cater]

On Sat, Sep 04, 2021 at 08:31:11AM -0700, Vagrant Cascadian wrote:
> On 2021-09-04, LinAdmin wrote:
> > The unnamed decision makers of Debian some unknown time ago
> > decided that Pi and Pine stuff won't be supported by Debian.
>
> I personally have added support in Debian for:
>
> Raspberry Pi 1
> Raspberry Pi 2b
> Raspberry Pi 3b+
> Pine64+
> Pinebook
> Pinebook Pro
> RockPro64
> Rock64
>
> And other platforms... others have added support for other Raspberry PI
> and Pine64 platforms, as well as numerous other platforms...
>
> I used the Pinebook as my primary computer for over a year, using
> absolutely zero software from outside of Debian...

I was going to point out that Vagrant was probably the person very likely
to be able to contribute most. I note from
https://wiki.debian.org/InstallingDebianOn/Allwinner that the H64 from Pine
is supported in Bullseye.

Sometimes it comes down to the fact that we haven't got the hardware -
most of the people who run ARM have at some point bought dead end
ARM projects that never actually went anywhere in an attempt to get them
supported.

Sometimes it comes down to problems beyond Debian's control: most often
a vendor kernel with no source / with other issues / tied in to hardware
in obscure ways, a U-Boot similarly ... Often, if you contact the vendor
they have no real understanding of why a Debian person would be asking.

>
>
> Debian isn't a consumer product, it is a community project. It is
> largely a volunteer effort, suppored by the community, so... if you want
> something supported, please help to add the support.
>
> It pretty much comes down to submitting patches, bug reports, merge
> requests, etc. to enabled the appropriate kernel options, bootloader
> support, and debian-installer support.
>
> Debian doesn't generally support patches that wouldn't be acceptible in
> upstream projects, or support non-free binary blobs out of the box, so
> maybe the support isn't as good on a per-platform basis as some other
> targeted distros willing to use vendor forks or patches for various
> components.
>
>

Armbian / DietPi / Raspberry Pi OS have different viewpoints, include
different amounts of vendor code / have different attitudes to firmware.
Things "based on" Debian do things differently and sometimes it's hard
to see what they've done. As a consumer: if there's difficulty getting
Debian to work on the board you bought, help us by going back to the
manufacturer/vendor and politely pointing this out as a problem for you.

Help the maintainers of the ARM64 and armhf installers by using them -
and using reportbug to tell people what went wrong where.

> The support isn't always perfect; maybe all features don't always work;
> I don't and can't personally test all combinations of features on all
> platforms, nor have the time to enable all features on all combinations
> of platforms. Thankfully, there are others in the community who test and
> improve what they can.
>
> Debian could always use more people helping with testing and perhaps
> more importantly, upstreaming of support to make sure it works for their
> use-cases...
>
> I know not everybody can dive in and fix all kinds of issues, but there
> is a pretty broad spectrum of ways to help out... sometimes things are
> even supported but undocumented. Documenting workarounds and filing bug
> reports appropriately is one angle that could potentially help.
>
>
> > I switched to Ubuntu LTS which made me (and many others) happy.
>
> Curious what exactly is different with Ubuntu that makes it work for
> you...
>

Real Ubuntu LTS from Canonical or, to take the H64 from Pine example, the
Armbian based on Ubuntu Focal? https://www.armbian.com/pine64/ [or
any other third party rebuild similarly].

If you're on the Raspberry Pi4 - yes, you have Ubuntu LTS - but you also
have Debian https://raspi.debian.net.

Strictly, discussion of other distributions is off topic here unless you've
documented issues of where XYZ distribution works and Debian doesn't on
the same hardware. I await these direct comparisons from you with interest.

All the very best, as ever,

Andy Cater
>
> live well,
> vagrant

[Andrew M.A. Cater]

On Fri, Sep 03, 2021 at 08:30:52PM +0000, oregano...@disroot.org wrote:
> At $45 with 3GB RAM, optional eMMC (35 for 64 GB), WiFi, etc., it seems
interesting, but why is there almost zero coverage on Debian sites?
>

Maybe we haven't got the hardware: maybe we haven't seen it to test? [See
also later replies in this thread].

> The Debian testing installer seemed to work, but initial boot didn't, or
> gave a blank HDMI display. At this point I don't recall spending any time
> trying to ssh onto it remotely, or examine the sdcard afterwards.
> What is the best way to get useful info and report it?
>

SSH in might have been useful. The most useful thing would be to report a bug
against the "installation-reports" package using reportbug, if feasible.

> ("Offtopic" but FYI) Dietpi worked fine.
>
> These instructions took a long time, but resulted in a (more or less)
> working Debian system (on SD card).
> https://github.com/as365n4/Debian_on_Pine64_H64B
> Could someone point me to a better/cheaper/faster recipe?
>

Derivatives definitely do things differently and may be more prepared to
use vendor kernels / U-boot or whatever. Because of this, we may not be
able to advise directly.

> Why isn't this SBC listed here

> https://wiki.debian.org/CheapServerBoxHardware

> or here

> https://wiki.debian.org/FreedomBox/Hardware ?
>

Maybe because the wiki is not always up to date / because the FreedomBox
folk haven't seen one to try?

> Thanks for any answers or suggestions!

[Gene Heskett]

On Saturday 04 September 2021 11:31:11 Vagrant Cascadian wrote:

> On 2021-09-04, LinAdmin wrote:
> > The unnamed decision makers of Debian some unknown time ago
> > decided that Pi and Pine stuff won't be supported by Debian.
>
> I personally have added support in Debian for:
>
> Raspberry Pi 1
> Raspberry Pi 2b
> Raspberry Pi 3b+
> Pine64+
> Pinebook
> Pinebook Pro
> RockPro64
> Rock64

I wish I had known that 2 years ago, I bought a couple rock64's but all I
could find was armbian, whose kernel had milliseconds of IRQ latency
times. Totally unsuitable for running real hardware that may need
guidance in a 5 microsecond time frame.

> And other platforms... others have added support for other Raspberry
> PI and Pine64 platforms, as well as numerous other platforms...
>
> I used the Pinebook as my primary computer for over a year, using
> absolutely zero software from outside of Debian...
>

My how to questions were asked in order that the answers might get more
publicity. Unforch instead of answers which would have facilitated that
progress, but I was told instead to take it to the main list,
repeatedly.

And no one on the main list is even aware there are arm cpus fully
capable of doing these jobs. And with 2 exceptions, no one has had any
interest in how I did it. And only one was able to follow my directions
to a running system.

> Debian isn't a consumer product, it is a community project.

I am well awsre of that.

> It is
> largely a volunteer effort, suppored by the community, so... if you
> want something supported, please help to add the support.

I have made the offer, and I wrote it up where anyone with a browser can
read the blow by blow. According to the logs, I guess this was not the
list to tell, that readme has been looked at 3 times now in about 2
years.

Yes, I block the bots who must think I have I have a 50 gigabyte pipe,
but its ADSL at 10 megaBITs down. So I understandably block the bots so
that normal folks can get a byte out edgewise. However there are bots
that think robots.txt does not apply to them, so they get blocked with
a /8. If you are a customer of such a company to deserve the /8, my
sympathies, but you are still blocked. Change your ISP. It really is
that simple, refuse to support those that ignore the rules.

> It pretty much comes down to submitting patches, bug reports, merge
> requests, etc. to enabled the appropriate kernel options, bootloader
> support, and debian-installer support.
>

Such howto questions have been ignored and/or rejected in the past. That
was the response at the time. If you now have a new broom, I'd be glad
to help, but what I've done and which still works well, is also out of
date. Meaning I should probably try and build a 5.something kernel.
But its running well on a

4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7la

kernel for me. Absolute IRQ latency, worst case while running FF to
browse the web, 50 microseconds, 4 to 12 doing other things, the rp4b
multitasks well.

> Debian doesn't generally support patches that wouldn't be acceptible
> in upstream projects,

I have yet to find anything this kernel above cannot do.

> or support non-free binary blobs out of the box,
> so maybe the support isn't as good on a per-platform basis as some
> other targeted distros willing to use vendor forks or patches for
> various components.
>
>
> The support isn't always perfect; maybe all features don't always
> work; I don't and can't personally test all combinations of features
> on all platforms, nor have the time to enable all features on all
> combinations of platforms. Thankfully, there are others in the
> community who test and improve what they can.
>
> Debian could always use more people helping with testing and perhaps
> more importantly, upstreaming of support to make sure it works for
> their use-cases...
>
> I know not everybody can dive in and fix all kinds of issues, but
> there is a pretty broad spectrum of ways to help out... sometimes
> things are even supported but undocumented. Documenting workarounds
> and filing bug reports appropriately is one angle that could
> potentially help.
>
> > I switched to Ubuntu LTS which made me (and many others) happy.
>
> Curious what exactly is different with Ubuntu that makes it work for
> you...
>
>
> live well,
> vagrant

[Gene Heskett]

First, they have to be interested in your failure reports. Until now,
such has not been the case. No interest...

[Gunnar Wolf]

Gene Heskett dijo [Sat, Sep 04, 2021 at 09:43:07AM -0400]:
> (...)

> So I found my own solutions. So, debian-arm, please make up your mind, do
> you support the pi's or do you NOT support the pi's?

Debian has a very clear line set: We do _NOT_ ship non-free software,
no exceptions. Given the Raspberries need a non-free firmware blob for
the GPU to hand over execution to the ARM CPU at bootup... Yes, that
clearly means no official Debian images exist for Raspberry Pi
hardware. So, yes, we made up our mind, and the situation has been the
same since the original RPi was released in 2013.

Some people, me included (but by far, it's not only me) have prepared
prebuilt Debian images¹ that allow booting a standard Debian system
with *only* the raspi-firmware non-free package installed.

¹ https://raspi.debian.net
² https://tracker.debian.net/raspi-firmware

> When I did try a net install of buster, but had no network after the
> reboot, I went back to a raspbian seed image and haven't looked back, it
> Just Works.

Try running one of our tested images³. I strongly suggest you to use
the Bullseye images, as they are newer and more recently tested, and
are our primary target nowadays.

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

> > Whatever floats your boat.
>
> That attitude is Indicating to me that debian-arm still has zero interest
> in arm. A sad truth IMO.

We have zero interest to get engaged with divisive, aggressive users
that feel entitled to a full support tier when downloading free
software built by a bunch of volunteers. Do you want us to spend more
time fixing the many quirks in the RPi? Consider hiring a couple of us
to do so. No, not me -- I have my time fully booked and am happily
employed. But if you are interested, I can point you to many people
who might be interested.

[Gene Heskett]

1. That was an early buster net-install image, and my questions at the
time were bounced. Firmly.

2. I now have about 4 years invested in equiping raspbian 8, 9, & 10 with
a realtime kernel, and with a $40 ups, it runs until _I_ reboot it. My
target was to run a cnc converted machine I converted, with a pi, first
a 3b, now a 4b. And I have succeeded beyond my dreams from years ago. I
now know how to install a realtime kernel on a pi and once I understood
it, its as simple as putting the u-sd in a card reader and unpacking a
29 megabyte tarball to it. So my problems are solved.

I'm not upset with you for following debians lead in rejecting the pi,
but I am upset that the most popular arm product on the planet is
specifically disabled as far as debian is concerned. Thats not your
decision. But its also never been disclosed anyplace I have read, that
even a phone call to the foundation asking for permission has ever been
made.

IMO, debians rejection of pi support out of hand, without sharing the
results info with the users, is leaving an important fact out of the
story. One that in view of its market share, really needs to be shared
with us.

FWIW, I did use your kernel kit, until you stopped supporting it. And I
thank you for that.

I also have a couple rock64's, but I don't believe they use a compatble
gpio module. I talk to the interface card, a Mesa 7i90HD at 40 megabits,
and receive its answers at 25 megabits over an SPI interface. Can a
rock64 do that?

Take care, and stay well, Gunnar.

[Paul Wise]

If anyone wants to help to make Debian work on the RPi without the
proprietary boot firmware from Broadcom/RPi folks, the solution is to
package a VC4 GPU compiler for Debian and then improve and package the
rpi-open-firmware project.

https://github.com/librerpi/rpi-open-firmware/
https://github.com/itszor/vc4-toolchain/issues/7

--
bye,
pabs

https://wiki.debian.org/PaulWise

[Andrei POPESCU]

On Sb, 04 sep 21, 08:31:11, Vagrant Cascadian wrote:
> On 2021-09-04, LinAdmin wrote:
> > The unnamed decision makers of Debian some unknown time ago
> > decided that Pi and Pine stuff won't be supported by Debian.
>
> I personally have added support in Debian for:
>
> Raspberry Pi 1
> Raspberry Pi 2b
> Raspberry Pi 3b+
> Pine64+
> Pinebook
> Pinebook Pro
> RockPro64
> Rock64

Thank you!

Kind regards,
Andrei -- happy Debian user of a PINE A64+ and (still) considering the
Pinebook Pro for my next laptop
--
http://wiki.debian.org/FAQsFromDebianUser

[Pete Batard]

Hi Gunnar,

On 2021.09.06 18:59, Gunnar Wolf wrote:
> Gene Heskett dijo [Sat, Sep 04, 2021 at 09:43:07AM -0400]:
>> (...)
>> So I found my own solutions. So, debian-arm, please make up your mind, do
>> you support the pi's or do you NOT support the pi's?
>
> Debian has a very clear line set: We do _NOT_ ship non-free software,
> no exceptions. Given the Raspberries need a non-free firmware blob for
> the GPU to hand over execution to the ARM CPU at bootup... Yes, that
> clearly means no official Debian images exist for Raspberry Pi
> hardware.

I'd say that's not really true, since it's very much possible to install
Bullseye on the Pi 4 using *vanilla* unmodified ARM64 Debian ISOs [1].
And the same has been true for Buster on the Pi 3 for some time too [2].

So there are official Debian images for the Raspberry Pi hardware in
the form of the vanilla ISOs that are already being published, and that
let users sort the install issue by letting them bring the proprietary
blobs along with an SBBR compliant UEFI firmware, to make the whole
process work (and the same will apply to any ARM platform that is made
SBBR compliant, as this is the whole point of introducing a boot standard).

Granted, that wasn't possible for the Pi 1 and Pi 2 platforms, so your
original point stands, but the situation has been evolving and, as much
as I appreciate the work you did, I think it is time to seriously look
at whether Debian wants to continue promoting the use of *custom-built*
images for the installation of the system on modern Raspberry Pis'
(which, in my view is a dead end) or whether we should start advocating
for a more universal approach that no longer relies on volunteers like
yourself investing a lot of time to produce said pre-built images, with
all the drawbacks that that entails.

Now, I'm not going to pretend that everything is peachy with this new
UEFI/SBBR mode of installing vanilla images, because it's still fairly
new, and there are still quite a few rough edges to sort out (for
instance, the Debian installer appears to have a multiple problem with
the provision of firmware blobs, one of which being that is chokes on
ones that contain spaces, which means that it'll request
"brcm/brcmfmac43455-sdio.Raspberry" instead of
"brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model
B.txt", and also it doesn't seem to be able to look up a blob on USB
drives unless the media is re-plugged for each blob) as well as missing
drivers. But I'm continuing to be concerned that Pi users coming to this
list are still being painted the picture that there is no salvation
outside of the use of pre-built images, when there much certainly exist
an alternative.

>>> Whatever floats your boat.

Exactly. I think it should be better for us to provide users with a
choice when there exist multiple ones when it comes to installing Debian
on the Pi, and not give the impression that pre-built images is the only
way.

Please bear in mind that some people have probably worked as hard as you
did on making sure that there exists an alternative to pre-built, so, as
much as I understand that you want to promote your work, I'd also
appreciate if you started to paint a more accurate picture when it comes
to not being able to use official images for the installation of Debian
on modern Raspberry Pi's, especially after some people, including Debian
maintainers who worked on fixing bugs related to UEFI/SBBR boot,
invested time and effort making sure that this statement was no longer true.

Regard,

/Pete

[1] https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839
[2]
https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html

[Reco]

Hi.

On Tue, Sep 07, 2021 at 10:29:40AM +0100, Pete Batard wrote:
> Hi Gunnar,
>
> On 2021.09.06 18:59, Gunnar Wolf wrote:
> > Gene Heskett dijo [Sat, Sep 04, 2021 at 09:43:07AM -0400]:
> > > (...)
> > > So I found my own solutions. So, debian-arm, please make up your mind, do
> > > you support the pi's or do you NOT support the pi's?
> >
> > Debian has a very clear line set: We do _NOT_ ship non-free software,
> > no exceptions. Given the Raspberries need a non-free firmware blob for
> > the GPU to hand over execution to the ARM CPU at bootup... Yes, that
> > clearly means no official Debian images exist for Raspberry Pi
> > hardware.
>
> I'd say that's not really true, since it's very much possible to
> install Bullseye on the Pi 4 using *vanilla* unmodified ARM64 Debian
> ISOs [1]. And the same has been true for Buster on the Pi 3 for some
> time too [2].

A small nitpick. While it's indeed possible to boot rebuilt UEFI on
Raspberry Pi3 (which is free software, since it's patched TianoCore),
and boot unmodified Debian ARM64 via said UEFI - the booting of UEFI
itself still requires Broadcom blobs, which are non-free software.

Reco

[Pete Batard]

Hi Reco,

Yes, but that is *outside* of the scope of Debian, just like booting
Debian on UEFI x86 based PCs also requires the use of intel or AMD
non-free blobs (for RAM bringup, ME and all the other stuff that CPU
manufacturers have decided they no longer want to open) that are
integrated into the UEFI firmware and that you don't see or have to
provide yourself, but that are very much present still.

If the idea is that the Pi platform is less free than the x86 platform
because you need to provide non-free blobs for boot, you may want to
take a closer look at how modern x86 PCs behave in that matter, because
they are just as non-free as the Pi, albeit in a manner that makes it
less visible to the user.

But again, it doesn't matter because the provision of non-free blobs is
then moved outside of what Debian needs to concern itself with (it's now
part of TF-A/UEFI bringup, which is the place where these blobs should
logically reside), which allows the use of blob-free Debian images.

While UEFI is Open Source, it far from being Free Software (which of
course it was never designed to be, in order to accommodate system
providers who do did to add proprietary blobs from the get go), and the
provision of non-free blobs there becomes a non-issue (outside of
user-acceptance that their system relies on using non-free software, but
considering that any modern x86 user is pretty forced to accept that
these days, I don't see how the Pi situation should suddenly become
special in that regard).

Regards,

/Pete

[Reco]

Yet there's a difference. Intel ME or AMD PSP do not require firmware to
be written on a boot media, thus making the boot media redistributable
and (other blobs excluded) - DFSG-compliant.
In the case of the Raspberry Pi 3 (unsure about RPi 4) it's required to
have non-free Broadcom blobs in the first partition of SD card.
The resulting media for Raspberry Pi 3 is non-DFSG compliant, because
each and every file on a media that's used to boot is within the scope
of Debian. Or it cannot be provided by Debian officially.

I'm not writing that to imply that x86 or RPi is somehow more or less
"free" compared to each other. Compared to other ARM boards I've dealt
with, both x86 and RPis are equally non-free ;)

And of course, the porting of UEFI on RPi 3 (have not tried this on RPi
4) is an important achievement by itself, because while UEFI is an
overcomplicated and overengineered beast, it's still the best effort of
standartization of ARM booting we have these days.

> If the idea is that the Pi platform is less free than the x86 platform
> because you need to provide non-free blobs for boot, you may want to
> take a closer look at how modern x86 PCs behave in that matter,
> because they are just as non-free as the Pi, albeit in a manner that
> makes it less visible to the user.

I did not meant that. But I can compare Raspberry Pi to, say, kirkwood
subarch (QNAP TS series), where all you need to boot is a free software
without exceptions, starting with the bootloader.
Or, I can compare it to Odroid N2/N2+, where all non-free blobs are
contained to SPI, and the proper free OS is booted via simple kexec.

> But again, it doesn't matter because the provision of non-free blobs
> is then moved outside of what Debian needs to concern itself with
> (it's now part of TF-A/UEFI bringup, which is the place where these
> blobs should logically reside), which allows the use of blob-free
> Debian images.

But still, if [1] haven't stalled - all this discussion we're having
today would be pointless.

Reco

[1] https://github.com/christinaa/rpi-open-firmware

[Pete Batard]

On 2021.09.07 13:31, Reco wrote:
> Yet there's a difference. Intel ME or AMD PSP do not require firmware to
> be written on a boot media, thus making the boot media redistributable
> and (other blobs excluded) - DFSG-compliant.

I disagree.

The reason why the firmware needs to be written on boot media is because
the system was designed *NOT* to have its boot firmware on SPI flash.

So that's a pure design issue.

For instance, if the PI 4 SPI was large enough to accommodate the 3 MB
we need, we would happily run UEFI (and the proprietary blobs) from
there, instead of boot media.

But the system was designed to be as cheap as possible, and therefore,
to spare the cost of flash, with the result of requiring uses to provide
firmware from the boot media.

If you want to be pedantic about what constitute free vs non-free
according to whether the manufacturer of the system took provisions for
firmware blobs to reside on SPI flash or on a different media, be my
guest. But, in my view, there is no difference there, as it's just a
matter of someone deciding from where the firmware files should be booted.

Heck, if you want to go that way, what do you make of a Pi system where
the firmware blobs reside on a small SD card, that acts as an SPI flash
equivalent, and the system is installed on a different media (e.g USB,
which is what would typically be used, especially on the Pi 4, as it is
*much* faster that SD anyway)? Does that not qualify as a DSFG
compliant? Because that's already completely possible for the Raspberry
Pi if you want to go that route.

> In the case of the Raspberry Pi 3 (unsure about RPi 4) it's required to
> have non-free Broadcom blobs in the first partition of SD card.

And nobody forces you to use the SD card where the non-free blobs reside
to also be your Debian boot media, so you can consider it the same as
you would consider as SPI flash on a PC, i.e. orthogonal to Debian and
its installation process.

> The resulting media for Raspberry Pi 3 is non-DFSG compliant

Again, I'd like to hear where you draw the line for a system where the
user set up an SD card with the firmware and is installing Debian on USB.

> because
> each and every file on a media that's used to boot is within the scope
> of Debian.

Not sure how you reach that conclusion, with which I completely disagree.

> Or it cannot be provided by Debian officially.

Where is the part where Debian has to provide non-free blobs here?

There's two parts to this:
1. The Pi boot process, just like *any other modern boot process*
requires the use of non free blobs *before* the execution of the Debian
bootloaders and kernel.
2. The design of the Raspberry Pi *currently* requires that these
non-free blobs are provided on the boot media instead of some SPI flash,
as commonly found on other systems.

Considering that, even if we want to go that way, there is nothing in
the above that mandates that Debian and non-free blobs should reside on
the same media, if that's what you have an objection with, and one
again, since it's very much possible to split the pre Debian boot
process and Debian boot into completely separate media if you want to be
that much of a purist, I see nothing that prevents Debian from providing
an official installation media... which they actually already do in the
form of the vanilla ISO anyway.

> I did not meant that. But I can compare Raspberry Pi to, say, kirkwood
> subarch (QNAP TS series), where all you need to boot is a free software
> without exceptions, starting with the bootloader.

Yes, there we can be pedant as to what system is more free than some
other because users (rather than manufacturers, through an SPI flash)
have to be the ones dealing with non-free blobs.

I'm all for free software (heck, if I have the choice, you're not going
to see me touch non-free even with a 10 feet pole), but when the
constraints of where the non-free blobs have to reside is imposed by the
design of the system, and, from a bird's eye view, it doesn't
technically matter whether these blobs are provided from SPI flash or
from the user on their boot media, since they exist regardless, I fully
disagree with the idea that because the user have to dispense the
non-free blobs manually on one system, whereas this is done
automatically on another, the Debian situation with the Pi when booting
in UEFI mode is any different than the situation with x86 PC when
booting in UEFI mode, especially as, again, if you want to be a purist,
you can dedicate an SD card to the UEFI firmware, just as you would have
a dedicated flash UEFI on PC, and never ever have to touch proprietary
blobs in your Debian installation media.

Or to put it more succinctly, don't mistaken convenience, through a
logical *request* that users manually place mandatory non-free blobs on
the same media as the one they will use for Debian installation, so as
they don't have to add a separate media to the mix, for absolute
requirement.

> But still, if [1] haven't stalled - all this discussion we're having
> today would be pointless.

It's already pointless when modern x86 does make use of non free blobs
just like the Pi does, and that we're simply disputing whether them
residing in SPI rather than on a boot media (which, one last time, can
be kept entirely separate from the Debian boot media if you want)
somehow makes the Debian installation process on Pi suddenly more
"non-free" than on PC.

If you run anything on a modern PC, you already have to accept non-free
during your free OS installation. So the situation on Pi is no
different, even if it's up to the user rather than the manufacturer to
provide the non-free blobs and if, *for convenience*, you may want to
have them on the same boot media as the one you will install Debian with.

Now, that does not mean that I wouldn't mind seeing [1] happen to get a
completely free system, especially in the price range of the Pi. But I
really don't see how the location where non-free blobs that are required
for Debian boot ultimately reside has an impact on whether such and such
boot media can be recommended for Debian installation. Debian are NOT
being requested to produce the media with the non-free blobs here, or
even to make these blobs available to Pi users in a non-free repository.
I simply happens that, because of the design of the system, and because
the Pi does not yet accommodate a flash large enough to hold a UEFI
firmware, and unless they want to juggle two separate media, users are
requested to add the free Debian software on top of the non-free
firmware blobs required for system boot.

Regards,

/Pete

> [1] https://github.com/christinaa/rpi-open-firmware

[Reco]

On Tue, Sep 07, 2021 at 03:02:20PM +0100, Pete Batard wrote:
> On 2021.09.07 13:31, Reco wrote:
> > Yet there's a difference. Intel ME or AMD PSP do not require firmware to
> > be written on a boot media, thus making the boot media redistributable
> > and (other blobs excluded) - DFSG-compliant.
>
> I disagree.
>
> The reason why the firmware needs to be written on boot media is
> because the system was designed *NOT* to have its boot firmware on SPI
> flash.
>
> So that's a pure design issue.

It's illogical, but still - as long as the device has non-modifiable
firmware it's considered good, proper and "free".
If said firmware can be modified (as in - reflashed in EEPROM), or worse
- the device requires firmware to be uploaded on it at every poweron -
one has to distinguish between free and non-free firwmare.

I did not make those rules, RMS made them before my time.

> For instance, if the PI 4 SPI was large enough to accommodate the 3 MB
> we need, we would happily run UEFI (and the proprietary blobs) from
> there, instead of boot media.

I agree, but sadly it does not change anything in the grand scheme of
things. SPI flash can be modified by user, modification requires
non-free blobs.

> But the system was designed to be as cheap as possible, and therefore,
> to spare the cost of flash, with the result of requiring uses to
> provide firmware from the boot media.

I have to disagree here. If there's one thing that RPi design shows us,
it's how to make a profit on a bad-selling SOC initially intended for
media players.
I mean, the primary CPU is initalized by GPU.
The "main" OS is actually a second-class citizen running in a confined
environment, making RPIs unsuitable for any serious kind of realtime.
The lack of proper RTC (I know there's separate addons for that).
Network and I/O added as an afterthought, attached via USB (RPi 4 not
included).
Overheating problems.

If you're looking for a cheap as possible SBC, I suggest you to look at
NanoPIs.

> If you want to be pedantic about what constitute free vs non-free
> according to whether the manufacturer of the system took provisions
> for firmware blobs to reside on SPI flash or on a different media, be
> my guest. But, in my view, there is no difference there, as it's just
> a matter of someone deciding from where the firmware files should be
> booted.

Again, I did not make those rules.

> Heck, if you want to go that way, what do you make of a Pi system
> where the firmware blobs reside on a small SD card, that acts as an
> SPI flash equivalent, and the system is installed on a different media
> (e.g USB, which is what would typically be used, especially on the Pi
> 4, as it is *much* faster that SD anyway)? Does that not qualify as a
> DSFG compliant? Because that's already completely possible for the
> Raspberry Pi if you want to go that route.

As long as the booting process does not require the OS to deal with
non-free blobs directly, i.e. - not having those at filesystem or first
megabytes of media does not have any impact on the boot process - yep,
that makes OS image one step closer to DFSG.
But this hypothetical addon looks user-modifiable to me, so ... see
above.

> > In the case of the Raspberry Pi 3 (unsure about RPi 4) it's required to
> > have non-free Broadcom blobs in the first partition of SD card.
>
> And nobody forces you to use the SD card where the non-free blobs
> reside to also be your Debian boot media, so you can consider it the
> same as you would consider as SPI flash on a PC, i.e. orthogonal to
> Debian and its installation process.

I'm merely a Debian user, not DM or DD. I do not speak for Debian
Project, and my apologies if my writing convinced you differently.
I agree that using a separate media would be a viable workaround in this
case, but I'm sure there are others who will say their word in the case
I'm wrong.

Reco

[Pete Batard]

On 2021.09.07 15:55, Reco wrote:
> It's illogical, but still - as long as the device has non-modifiable
> firmware it's considered good, proper and "free".
> If said firmware can be modified (as in - reflashed in EEPROM), or worse
> - the device requires firmware to be uploaded on it at every poweron -
> one has to distinguish between free and non-free firwmare.

Okay, then we're on the same page that there's no fundamental difference
between modern x86 PC and Raspberry Pi, as PCs have reflashable EEPROM.

My point of contention here is that there's no reason to treat RPi and
x86 PCs differently, because, since both these platforms use proprietary
blobs for boot (at least for any PC produced in the next 10 years), they
both must be considered non-free.

And my point is that, since we are dealing with non free systems, it
makes little difference whether the non-free blobs reside in an EEPROM
or on boot media.

>> But the system was designed to be as cheap as possible, and therefore,
>> to spare the cost of flash, with the result of requiring uses to
>> provide firmware from the boot media.
>
> I have to disagree here.

Not sure what you're disagreeing with. It's pretty obvious that one
thing the Raspberry Pi Foundation has been doing to cut cost was to use
a boot method that does not require the adding of a flash chip to the
board (which is further evidenced by newer revisions of the Pi 4 having
done away with the flash that was previously used for the xHCI firmware
when they figured out a way to load it from the boot media as well).

The goal of the Pi Foundation has always been to provide the cheapest
platform they could, and eliminating the need of an Flash EEPROM for
platform bringup is one effective way to do that.

Again, that does not mean that I approve or am happy with that decision,
but I don't think there's much to disagree about what the intention of
the Pi Foundation has been, and why they happily went with an SoC that
allowed users to provide all the firmware blobs needed for early boot on
their own boot media.

> If there's one thing that RPi design shows us,
> it's how to make a profit on a bad-selling SOC initially intended for
> media players.
> I mean, the primary CPU is initalized by GPU.
> The "main" OS is actually a second-class citizen running in a confined
> environment, making RPIs unsuitable for any serious kind of realtime.
> The lack of proper RTC (I know there's separate addons for that).
> Network and I/O added as an afterthought, attached via USB (RPi 4 not
> included).
> Overheating problems.

I don't disagree with that. I've had to deal with the Broadcom quirks
and bugs (including a major screwup with DMA access above 3 GB for the
SoC used on the Pi 4), and I too would much rather have preferred the Pi
Foundation to go with something where corners had clearly not been cut.
But I don't think it's really relevant to this discussion, outside of
justifying why we don't happen to be dealing with non-free blobs that
are semi-hidden in an EEPROM, as we do for other systems.

> If you're looking for a cheap as possible SBC, I suggest you to look at
> NanoPIs.

I'm not looking for anything. I'm a happy user of NanoPC-T4 (running
armbian), which I think does a much better job than a Pi 4. But I'm also
realist in that the Pi 4 has enough momentum to make it a very
attractive platform for many, regardless of its obvious flaws, and
therefore, that we need to make sure that users are in a position to
install OSes like Debian without penalizing them more for using non-free
blobs than x86 PC users are being penalized for having non-free blobs in
their platform's firmware.

> As long as the booting process does not require the OS to deal with
> non-free blobs directly, i.e. - not having those at filesystem or first
> megabytes of media does not have any impact on the boot process - yep,

I kind of feel like you are making rules here.

The only part I can agree with is the "as long as the booting process
does not require the OS to deal with non-free blobs directly", which,
IMO, the UEFI installation processes for Debian that I linked to do
qualify for. These processes are specifically designed so that Debian
does not even have to know whether these non-free blobs exist, since
they are only being used for TF-A/UEFI bringup. And as a matter of fact,
we could actually delete them from the media altogether, from within
UEFI, before UEFI hand-off, and it'd create no issue whatsoever (outside
of inconveniencing users by forcing them to copy these files again for
the next boot). Of course they would still be present in memory, but
since your concern appears to be with what resides on the media...

So, as I said, these blobs are orthogonal to the Debian boot process and
should be considered as if they were internal to UEFI, in the same
manner as Intel ME or RAM set-up blobs of Intel UEFI PC platforms are
considered to be internal to x86 UEFI firmware.

> But this hypothetical addon looks user-modifiable to me, so ... see
> above.

I'd say flash EEPROM on PC is user modifiable too on PC, so...

> I agree that using a separate media would be a viable workaround in this
> case

Okay. In that case you may want to consider, again, that the only reason
the process we describe does not ask users to create 2 media is purely
for convenience, and therefore that it's a bit pointless to declare that
the one media method is bad whereas the two media method is okay,
especially as I have to maintain that what happens with the one-media
method and non-free blobs is no different that what happens with x86 PC
installation of Debian, when the UEFI firmware (which is user-modifiable
since, for instance, and provided someone did the groundwork, you can
replace it with coreboot -- which does include non-free blobs required
by modern platforms) also contains non-free blobs.

In other words, if that's your concern, nobody is claiming that the
Raspberry Pi platform even remotely qualifies as a free platform. But it
needs to be considered that, in that respect, and even as the
proprietary blobs are being provided on user media rather than hidden in
an EEPROM, it is no different than the equally non-free modern x86 PCs.

As such I don't believe that trying to make a big fuss over the fact
that the procedure we advise to use for single media installation of
vanilla Debian does end up with non-free blobs on the same media, is
warranted. Just like what's the case for x86 PC, Debian OS will never
have to concern itself with these blobs, let alone care about their
existence.

Regards,

/Pete

[lkcl]

On September 7, 2021 4:16:27 PM UTC, Pete Batard <pe...@akeo.ie> wrote:

>And my point is that, since we are dealing with non free systems, it
>makes little difference whether the non-free blobs reside in an EEPROM
>or on boot media.

it makes ALL the difference in the world.

not only is it deeply unethical to support non-free firmware, in the instance where such firmware contained spying backdoors that resulted in a user system being compromised, DEBIAN DEVELOPERS COULD BE HELD LEGALLY LIABLE.

if however the Pi Foundation wishes to distribute such unethical firmware to individuals, then they have engaged in a Contract of Sale with those individuals and THEY are legally liable for any damage or harm caused, under various Sale of Goods Acts or equivalent in the respective country.

likewise with a PC *that you bought* you did *NOT* buy that PC from a Debian Developer, you bought it from a PC distributor and your Contract of Sale is with THEM.

if you want a Debian Developer to enter into a Contract to provide you with a preinstalled nonfree firmware blob you should pay them adequate amounts of money so that they can take out the requisite Liability and Indemnity Insurance.

if you are not prepared to do that please do not complain because your life is made more "inconvenient".

>The goal of the Pi Foundation has always been to provide the cheapest
>platform they could, and eliminating the need of an Flash EEPROM for
>platform bringup is one effective way to do that.

indeed. thus, that places the product firmly in EXACTLY the same category as a non-free WIFI product that requires non-free firmware.

by forcing YOU to download that nonfree firmware, YOU take responsibility for that action.

WHEN the Pi Foundation realise the seriousness of their laziness and provide an on-board EEPROM or SPI NOR Flash IC just like every x86 PC has done since the late 1980s THEN it will be possible for debian to support their products because Debian Developers will not find themselves in the situation of being legally liable for distribution of potentially dangerous firmware.

>Again, that does not mean that I approve or am happy with that
>decision,
>but I don't think there's much to disagree about what the intention of
>the Pi Foundation has been, and why they happily went with an SoC that
>allowed users to provide all the firmware blobs needed for early boot
>on
>their own boot media.

yes.

this has been pissing people off for some considerable time.

Broadcom licensed the ARC Core firmware before ARC was bought by Synopsis and their License Agreement clearly prevents and prohibits them from providing the source code to third parties (you, me, Pi Foundation). the sale of ARC to Synopsis makes that even more challenging.

it also places them needlessly under NDA and also likely prevents and prohibits them from engaging in reverse-engineering, or be seen supporting ANY efforts which violate their Contract with Synopsis.

given that Broadcom's ACTUAL market for these SoCs is 100+ MILLION unit Set Top Boxes and TVs, the Pi Foundation Market is utterly trivial by comparison and, commercially, Broadcom really don't give a flying f*** about it. they care about their relationship with ARC (Synopsis) and do not want to do ANYTHING that could jeapordise their multi-billion-dollar sales.

people forget: the *only reason* that the Pi exists at all is because Eben Upton was an employee doing the design in his spare time, with inside access to NDA'd documents.

when his Managers discovered what he was doing and that it was for "Education" they couldn't exactly tell him to stop.

the Pi Processors due to being manufactured in such absolutely insane quantities are at least FOUR times lower cost than equivalents from Freescale, FIVE OR MORE times cheaper than Texas Instruments equivalents, and even beat the s*** out of Allwinner pricing, which is quite an achievement.

it makes *using* it very attractive, but unfortunately, that low "price" burdens everyone else with a "cost" - a real and actual financial burden - that Broadcom is in no way compensating anyone for (and would jeapordise their business if they did)

the situation is one where Broadcom is effectively spongeing off of Free Software developers, YET AGAIN burdening the entire Free Software Community with the cost of cleaning up their mess caused by sheer pathological Corporate laziness and profiteering, and i'm getting pretty fed up with it.

i am ESPECIALLY getting fed up of people not fully and properly understanding the realities of the situation and complaining that they can't get nonfree firmware preinstalled with products, for their own convenience.

please therefore have a little more understanding and appreciation for what Debian Developers are doing, and why they are doing it, and the difficult (spongeing) circumstances and obligations they are under.

l.

[Pete Batard]

On 2021.09.07 18:36, lkcl wrote:
>
>
> On September 7, 2021 4:16:27 PM UTC, Pete Batard <pe...@akeo.ie> wrote:
>
>> And my point is that, since we are dealing with non free systems, it
>> makes little difference whether the non-free blobs reside in an EEPROM
>> or on boot media.
>
> it makes ALL the difference in the world.
>
> not only is it deeply unethical to support non-free firmware, in the instance where such firmware contained spying backdoors that resulted in a user system being compromised, DEBIAN DEVELOPERS COULD BE HELD LEGALLY LIABLE.

No. Not when Debian are *NOT* the ones providing said non-free blobs.

Somehow I get the feeling that some people here are misconstruing the Pi
3 and Pi 4 installation process as: "Debian is in charge of providing
the non free blobs along with the Debian installation files".

This is not the case

The process is as follows:

1. The user downloads the UEFI Firmware and non-free blobs (that are use
SOLELY for UEFI bringup) FROM A THIRD PARTY that has no direct
association with Debian. And let me be 100% clear on that, NOONE here
is or has been even remotely asking that Debian should provide these
files. NOONE.

2. Separately, the user downloads the vanilla installation ISO from Debian.

3. User extracts all of this content on a single installation media (or
separate media if they are of the idea that having both contents reside
on the one media somehow taints it) .

So you're going to have to explain to me how Debian developers, who had
no involvement in the above process, and aren't providing any of the
firmware blobs, are supposed to be held liable. If anything, it's the
user choosing to place content from two independent project that are
governed by two separate licenses, that is liable for the end result of
what their own action of mixing the content entails (though, in the boot
process we're talking about, I also don't see a liability in having
binaries governed by different licenses when the handoff process between
executables governed by these licenses is the same as the handoff
process between non GPL UEFI and GPL Debian)

In other words, your assertion is exactly like saying that, if someone
happens to download malware from a third party on a Debian OS, then

"DEBIAN DEVELOPERS COULD BE HELD LEGALLY LIABLE".

That makes absolutely zero sense.

I do understand that you have strong objection to the Pi Foundation
blobs, but that's not a reason for magically extrapolating liability of
a process that does *NOT* involve Debian providing said blobs. Please
bear in mind that we are talking about a process that is very *NOT*
talking about a process that involves pre-built images, as the whole
goal is to work with vanilla Debian ISOs, and guide the user into what
preliminary, non-Debian related steps (since these steps can just as
well apply to Windows or FreeBSD) they can take to achieve that.

As I tried to explain earlier, these blobs are associated with the UEFI
firmware, not with Debian, in the same manner as x86 proprietary blobs
are associated with the UEFI firmware and not Debian. And I am certainly
not seeing anyone throwing a hissy fit at x86 UEFI requiring said
proprietary blobs, or pretending that, because Debian boot relies on
them, as part of the pre-Debian UEFI boot, Debian devs can be held
legally liable. Therefore, it makes no sense to pretend that it should
be any different for the Raspberry Pi, when the principle (UEFI early
boot relies on proprietary blobs, that are consumed by UEFI and become
completely irrelevant, apart from the fact that some of them may reside
in memory, to the rest of the boot process after UEFI handoff) is the same.

And yes, it is also possible to use this blobs to boot a Linux kernel
directly, but that is *NOT* at all what we are discussing here.

> if however the Pi Foundation wishes to distribute such unethical firmware to individuals, then they have engaged in a Contract of Sale with those individuals and THEY are legally liable for any damage or harm caused, under various Sale of Goods Acts or equivalent in the respective country.

It is your right to refuse to use a system that relies on proprietary
blobs. I therefore am going to assume that you are not using any modern
x86 PC, because, even if you use CoreBoot, you will find that they are
unavoidable.

> likewise with a PC *that you bought* you did *NOT* buy that PC from a Debian Developer, you bought it from a PC distributor and your Contract of Sale is with THEM.

Yup, and in the case of the Raspberry Pi process we are describing here,
the firmware blobs and UEFI firmware that you used were not provided by
a Debian developer, but obtained from a third party (mostly EDK2 +
Raspberry Pi Foundation) and whatever you want to pretend is a contract
of sale is also with THEM, not Debian.

That these blobs and UEFI firmware are being provided on SD or USB media
rather than an EEPROM does not change this picture.

> if you want a Debian Developer to enter into a Contract to provide you with a preinstalled nonfree firmware blob

That is NOT AT ALL what I want.

Worst, that is not even remotely implied in any of the guides I linked to.

Thus, it looks to me like you are "debating" a completely mistaken idea
of what the RPi installation process entails, and who is supposed to
provide what.

NOBODY is asking Debian to provide preinstalled nonfree firmware blobs
for Pi boot, just like nobody is asking Debian to provide nonfree EEPROM
x86 UEFI firmware that they can flash on their specific system. That's
what I went great length to try to describe as orthogonal to the Debian
boot process earlier, because it genuinely is.

The whole point (at least for the guides I linked to) is to keep these
entirely outside of the scope of what Debian has to provide.

That firmware blobs and UEFI firmware (provided by a non Debian related
third party) and Debian installation content (extracted from
*UNMODIFIED* vanilla Debian ARM64 ISO) happen to end up on the same
media, if you *choose* to use a single media, is the result of a user
operation that Debian has had no involvement with. So, again, I'm hard
pressed how you can find a liability for Debian there.

> you should pay them adequate amounts of money so that they can take out the requisite Liability and Indemnity Insurance.
>
> if you are not prepared to do that please do not complain because your life is made more "inconvenient".

There again, you are asserting that somebody is somehow complaining that
Debian should provide nonfree blobs for convenience.

I'm sorry but, CLEARLY, you have not read or understood the points I've
been trying to make earlier, or looked at the installation guides I
linked to.

>> The goal of the Pi Foundation has always been to provide the cheapest
>> platform they could, and eliminating the need of an Flash EEPROM for
>> platform bringup is one effective way to do that.
>
> indeed. thus, that places the product firmly in EXACTLY the same category as a non-free WIFI product that requires non-free firmware.
>
> by forcing YOU to download that nonfree firmware, YOU take responsibility for that action.

Yup. Nobody is suggesting that Debian is supposed to provide the Pi
nonfree blobs. And that is exactly the way it should be.

> WHEN the Pi Foundation realise the seriousness of their laziness and provide an on-board EEPROM or SPI NOR Flash IC just like every x86 PC has done since the late 1980s THEN it will be possible for debian to support their products because Debian Developers will not find themselves in the situation of being legally liable for distribution of potentially dangerous firmware.

Irrelevant, since, again, you are asserting that someone here has been
suggesting that Debian should distribute firmware, which is *NOT* the case.

> i am ESPECIALLY getting fed up of people not fully and properly understanding the realities of the situation

Amen! Especially people who seem to be following an ill-placed
misconception that somebody here is even remotely asking that Debian
should provide nonfree firmware, when that provision is being entirely
assumed by a non Debian third party, just as it is for x86 PC.

> please therefore have a little more understanding and appreciation for what Debian Developers are doing, and why they are doing it, and the difficult (spongeing) circumstances and obligations they are under.

I have appreciation for them. That's why I made sure to write guides
that describe a Raspberry Pi installation process that does NOT require
Debian to provide anything but the vanilla installation ISOs.

Regards,

/Pete

[Paul Wise]

On Tue, Sep 7, 2021 at 10:00 AM Pete Batard wrote:

> Yes, but that is *outside* of the scope of Debian, just like booting
> Debian on UEFI x86 based PCs also requires the use of intel or AMD
> non-free blobs (for RAM bringup, ME and all the other stuff that CPU
> manufacturers have decided they no longer want to open) that are
> integrated into the UEFI firmware and that you don't see or have to
> provide yourself, but that are very much present still.

I definitely disagree here, boot firmware needs libre licensing,
source code, reproducible builds etc too. Debian should be able to
provide all the software installed on a system, including the boot
firmware, RAM bringup etc. We even have TianoCore in Debian, but we
are missing edk2-platforms and coreboot. The only reason we can't
provide boot firmware on x86 and have to resort to vendor provided
firmware and fwupd is that it is all proprietary forks of TianoCore.
On other platforms like POWER and some ARM devices, the firmware is
libre so we could provide it and in some cases we do already.

[Pete Batard]

On 2021.09.09 04:43, Paul Wise wrote:
> On Tue, Sep 7, 2021 at 10:00 AM Pete Batard wrote:
>
>> Yes, but that is *outside* of the scope of Debian, just like booting
>> Debian on UEFI x86 based PCs also requires the use of intel or AMD
>> non-free blobs (for RAM bringup, ME and all the other stuff that CPU
>> manufacturers have decided they no longer want to open) that are
>> integrated into the UEFI firmware and that you don't see or have to
>> provide yourself, but that are very much present still.
>
> I definitely disagree here, boot firmware needs libre licensing,
> source code, reproducible builds etc too.

Okay, maybe I didn't express myself properly here, because we're
basically on the same page. I am not saying that where possible, Debian
should not care about providing what you suggest. I'm only saying that,
*WHEN* that is not possible, as is the case on x86 PC and on Pi, Debian
should be flexible enough to understand that taking a hard stance so as
to penalize users, and declaring "Thou shall not boot this platform with
Debian", even as it's most certainly possible to leave the issue of
proprietary blobs outside of what Debian needs to concern itself with
(by, for instance, placing the onus on users to sort the use of
proprietary blobs where needed, and not on Debian), is not in anybody's
interest.

> Debian should be able to
> provide all the software installed on a system, including the boot
> firmware, RAM bringup etc.

100% agree on the should.

The issue is that, by the time the "should" becomes reality (if it
becomes reality), and if you take the stance that no system should boot
Debian until that is the case, you have alienated the modern x86 PC user
base, the Raspberry Pi user base, as well as a bunch of other user
bases, that also would really like to see a completely free system
running Debian, but can't because the complexity of boot and lack of
volunteers to work on providing alternative libre blobs for their system
means they have no choice but to compromise. And considering that I'm
certainly not seeing Debian taking a hard stance against x86 PC boot,
that requires nonfree blobs, I can't help myself asking why the Pi
platform should be treated any differently.

> We even have TianoCore in Debian, but we
> are missing edk2-platforms and coreboot. The only reason we can't
> provide boot firmware on x86 and have to resort to vendor provided
> firmware and fwupd is that it is all proprietary forks of TianoCore.

My understanding is that RAM bringup is not a proprietary fork of
TianoCore. It is used by people producing UEFI firmware from Tiano, but
it's not something you can pick the source of, as opposed to what is the
case for Tiano....

Thus, unless I'm mistaken then, I think it's a bit disingenuous to
pretend that the situation with non free blobs on x86 is any better than
the one on the Raspberry Pi. And this is my whole point.

> On other platforms like POWER and some ARM devices, the firmware is
> libre so we could provide it and in some cases we do already.

And, as mentioned before, there has been some work to provide
replacements for the nonfree blobs on the Raspberry Pi with [1].

So, there again, if that effort was completed we "could" provide libre
firmware. And I'm all for Debian developers investing their time into
that effort to see it completed, if it genuinely bothers them that the
Pi platform, just like the x86 PC platform, has currently to rely on
nonfree blobs.

But I have to stress out that debating in "could" or "should", as we are
doing, does very little to bring a working solution to the end users who
are stuck with platforms that cannot (yet) be liberated, which currently
means:
- Accepting the use of nonfree blobs for RAM bringup and other stuff on
x86 PC (that are provided, outside of the scope of Debian, by a UEFI
firmware residing on an EEPROM, and that Debian does not need to provide)
- Accepting the use of nonfree blobs for pre-UEFI boot on Raspberry Pi
(that are provided, outside of the scope of Debian, by a UEFI firmware
residing on an SD or USB partition, and that Debian does not need to
provide).

Again, my issue is that I see it very disingenuous to have folks here
make it look like the situation for Debian on x86 PC is somehow
different than the situation for Debian on Raspberry Pi (when booted in
UEFI mode), because, when you do look at it objectively, it really isn't.

It's the same thing for both platform, where early boot (currently)
requires the use of proprietary nonfree blobs and where, as long as
nobody has provided a free equivalent for those, it makes little sense
to try to penalize the large amount of existing platform users for the
sake of "purity", especially when nobody is asking that Debian should
provide or even make it easy to obtain these nonfree blobs.

On the other hand, even as I get the feeling that some people have been
eager to present it that way, I am certainly NOT saying that the
situation with using nonfree blobs for platform bringup is something we
should blindingly accept. I too would much rather see a boot process
that is libre from end to end, on any platform. But not at the sake of
alienating a significantly large group platform users if that can't be
achieved in a reasonable timeframe. And that is why, as much as it
actually bothers me that indeed Debian cannot currently be the purveyor
of a completely libre solution from CPU reset, for either x86 PC and
Raspberry Pi, I have no choice but to advocate the current compromise,
as I believe that the ability for users to install Debian, so that they
are then in a better position to work on liberating the remaining
elements that are nonfree on their system, is better than the
alternative, especially when this is a stance that Debian clearly
already applies when it comes to x86 PC...

[Vagrant Cascadian]

On 2021-09-09, Pete Batard wrote:
> Okay, maybe I didn't express myself properly here, because we're
> basically on the same page. I am not saying that where possible, Debian
> should not care about providing what you suggest. I'm only saying that,
> *WHEN* that is not possible, as is the case on x86 PC and on Pi, Debian
> should be flexible enough to understand that taking a hard stance so as
> to penalize users, and declaring "Thou shall not boot this platform with
> Debian"

I think I missed that decree... I daresay, this argument has been
running around in circles, based on some false assertions...

For the majority of the lifespan of arm64 in Debian, the *only* boot
method supported by debian-installer was UEFI. A "Bring your own
firmware" sort of policy. Only very recently support for a handful of
platforms to boot using u-boot was added...

And while *technically* non-free isn't a part of Debian, the firmware
required to boot raspberry pi platforms has been in non-free for some
years now. The great compromise in the Debian social contract allows for
exactly this sort of scenario:

https://www.debian.org/social_contract

5. Works that do not meet our free software standards

We acknowledge that some of our users require the use of works that do
not conform to the Debian Free Software Guidelines. We have created
"contrib" and "non-free" areas in our archive for these works.

So, the whole idea that supporting booting Debian on the raspberry pi is
not allowed seems absurd to me.

Yes, there are non-free parts required to boot it. Debian cannot ship
those parts in Debian main. Some people choose to spend their time
making those parts easier for others to install, some choose to keep
their distanceand not get entangled in it. We have room for both
approaches.

I'm really greateful people went through the work to get UEFI support
for the Raspberry Pi working; it gives yet another option for people who
want to try that platform on Debian using the standard Debian arm64
installation media. It's a widely used platform and if some people want
to install Debian on it, great!

I am also really happy Debian can support platforms (e.g. pinebook) that
can boot with boot firmware entirely only using software from Debian
"main", without needing "non-free" or "contrib".


In Debian, those who do the work generally define what is and isn't
supported in Debian, with guiding documents like the social contract and
debian policy setting some boundaries and standards.

So, pick something you want to improve, and work on it, and share it
with the rest of us! :)


live well,
vagrant

[lkcl]

On September 9, 2021 4:17:08 PM UTC, Vagrant Cascadian <vag...@debian.org> wrote:

>I think I missed that decree... I daresay, this argument has been
>running around in circles, based on some false assertions...

and a sense of "entitlement". yes, you, Pete Batard: you carry a strong "entitlement" vibe. an expectation that debian "should" do something or be something, and complaining about how debian isn't as suits *you*.

you know how that can be ascertained? each time soneone says "if you feel that way here's how you can contribute" you *don't reply* with a "thank you i'll get right on that".

as vagrant points out, and so did paul, debian is about *volunteering* and being empowered and empowering others by getting down and dirty and actually *doing something*.

if you had said, "debian doesn't work as i demand it to be when compared to the expectations in my own head THEREFORE i TOOK RESPONSIBILITY for that and here's a patch whom do i send it to?" *now* you got people's attention in a positive way, even though the start of the sentence, if you actually genuinely wrote it like that, would make you look like a bit of a tit, yet, hilariously, you'd fit right it.

at the moment as things stand you've managed to piss off at least one long-term debian contributor, are getting strong repeated group-reinforced diplomatic hints from several other long-term developers, and have had even me raise eyebrows several times at the rather alarming misassertions you've made.

debian *isn't* a "one thing" (it's thousands of completely independent sovereign volunteers). it's certainly not a company. you don't get to make demands of "debian", it's like pissing up-wind: it's just going to come right back at you, in your own face.

please, take the hint, ok? *we know* it's a pissy situation with non-free firmware. *listen* to the reactions and feedback you're getting, and either start helping or for goodness sake at least stop damn well complaining and making thousands of people on this list feel miserable and underappreciated for the work that they do. unpaid.

l.

[Pete Batard]

Boy are people misinterpreting my intent here, as well as making me say
things (such as "Debian isn't as suits me") that I didn't say.

Vagrant has properly conveyed what I wanted to state, and that should
have been the end of it. But you still have to come around, to
misinterpret the message as well as continue to propagate the falsehood
that I am complaining about the current state of Debian for the Pi, or
demanding that Debian does anything in that respect, despite the fact
that, as much as it may go against the nice portrait of me you have
constructed, I have long taken matters in my own hands (along with the
help of other contributors) to ensure that:

1. There was an SBBR compliant UEFI firmware that people could use to
install Debian from the unmodified vanilla ISOs. e.g:
- https://github.com/tianocore/edk2/commits?author=pbatard
- https://github.com/tianocore/edk2-platforms/commits?author=pbatard

2. Fixes were applied to Debian to ensure that it could be installed
with said firmware. e.g.
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967918
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985956
And just for the record, these aren't "Hey, this doesn't work, you
guys fix this" bugs but "Here's a patch to fix this issue" bugs, for
which I directly contributed a patch...

3. Guides were written to provide step by step details on how a user
could go on installing Debian on Pi 3 or Pi 4, against which I have also
been providing support. e.g.
- https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839
-
https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html

So I'm afraid that your assertion that I am somehow not taking
responsibility, or not volunteering my time to improve Debian as well as
other Open Source projects, or that I am entitled, or making demands,
is falling completely flat on its face.

Like many others in this thread, your are picking bits and pieces of
what you *believe* people are stating, instead of reading what they are
actually saying. And that is the precise reason we are still going at
it, when Vagrant's post should have been a more than appropriate coda.

If you read my posts carefully, you find that the only slight request
that I have made is that Debian (i.e. people on this list whom I expect
to know better) should stop advertising pre-built images as the one
solution to install Debian on the Pi 3 or Pi 4, when there exists an
alternative for which a lot of people (including Debian maintainers,
EDK2 people, myself, and many others) have invested quite a lot of
effort in, and that have now reached a sufficient enough level maturity.

I have not been asking anything else than that. Instead, I have been
trying to counter, just like Vagrant did, the ridiculous idea that the
non free Pi firmware blobs were some kins of issue that precluded these
new methods of installing Debian, as well as other more worrying
misconceptions, including the false assertion, which you are positing
here again, that myself or other people are somehow demanding stuff from
Debian.

So please don't misconstrue response to falsehoods, such as the ones you
have produced below, with complaining or demanding. I believe that I
have been doing enough more than enough work to be in a position to try
to dispel said falsehoods when I see them, regardless of whether people
are able to correctly interpret what I am trying to say (like Vagrant
did) or not (like you did).

Regards,

/Pete

[lkcl]

On September 9, 2021 9:46:34 PM UTC, Pete Batard <pe...@akeo.ie> wrote:

Pete: thank you for pointing out that you've actively contributed, do keep emphasising that, it will help undo some of the damage.

i do get that you feel you're not making "demands": i have had people regularly misconstrue what i say for over 20 years. thus, i am actually quite "entuned" now to the subtleties

>If you read my posts carefully, you find that the only slight request
>that I have made is that Debian (i.e. people on this list whom I expect
>
>to know better) should

the two key phrases which tell us the mis-step that you keep making are "whom i expect to know better" and "should".

it *really isn't* ok to make what can only be described as "implication-loaded statements" about individual contributors that are in effect Sovereign entities.

"should" implies that you are directly criticising them for *not* doing something... for which, like any Sovereign State, you have absolutely no right whatsoever to expect them to do, and have zero control, leverage or contractual or financial or feudal right over them.

"expect to know better" is again along the same lines: much as i hate to have to spell this out to you, it's terribly insulting. it comes with the loaded implication that "everything they did - unpaid, remember - before you came along, is shit. because *you* said so".

now, that may actually be true, but if it is, and you hsve evidence to bsck it up, then as a newcomer you have to be *really* careful about how you go about presenting that.

what may surprise you is that it *actually doesn't matter* whether what you suggest as an alternative to the "shit" is good or not: it's the very fact that you *expected* them to do it [without offering any financial compensation or other reward or incentive, which would result in a contractual or moral obligation where both parties satisfactorily get what they want]

when you have accepted that, you'll do ok.

phrases that you *should* find ok to use is:

* "IN MY VIEW, dotdotdot"
* "in MY opinion"
* "the way *I* see it is..."
* "MY feeling is..."
* "*I* would like to see... {some envisaged but entirely conditional action}"

you notice how all of those involve the PERSONAL (singular) pronoun? the sentences they prefix should in NO WAY make ANY IMPLICATION or impose ANY OBLIGATION on ANYONE [other than you, yourself]

the phrases put a "safe ringfence" around what you say, where other people cannot cross the line and criticise *you* for saying what you did, because it's YOUR personal and Sovereign Opinion.

to make ANY criticism no matter how indirect, or to make ANY implication of expectation of effort by ANYONE other than YOURself is and always will be COMPLETELY inappropriate on any Software Libre Community Project.

once you have understood and accepted this, you'll do ok.

> [...]

>new methods of installing Debian, as well as other more worrying
>misconceptions, including the false assertion, which you are positing
>here again, that myself or other people are somehow demanding stuff
>from
>Debian.

unfortunately, you are: you just don't yet appreciate or understand how.

this lack of empathy and understanding of perspective is actually surprisingly common amongst people working for significant periods of time with computers [example: for me, that's since 1977], and particularly common for younger people who have not grown up with software libre and mailing lists [example: i'm 51, and been using internet-enabled computers since 1988].

it is your responsibility to work out why you're irritating people, and to learn the ground rules of interacting with Sovereign Individuals (aka Software Libre Contributors aka debian developers aka volunteers).

it's great that you're an active developer: the next step, if it appeals and interests you, would be to ask questions of people, "is what i've done useful to anyone, if so how can it be packaged or otherwise made available"

that tells people you're listening, and that's the best thing you can do right now.

l.

[Paul Wise]

On Thu, Sep 9, 2021 at 9:46 PM Pete Batard wrote:

> If you read my posts carefully, you find that the only slight request
> that I have made is that Debian (i.e. people on this list whom I expect
> to know better) should stop advertising pre-built images as the one
> solution to install Debian on the Pi 3 or Pi 4, when there exists an
> alternative for which a lot of people (including Debian maintainers,
> EDK2 people, myself, and many others) have invested quite a lot of
> effort in, and that have now reached a sufficient enough level maturity.

If you would like Debian to advertise the UEFI option, please feel
free to register an account on the Debian wiki and add it in the
appropriate places. Due to the past actions of the RPi foundation and
consequent culture of the larger RPi community, the userbase expects
pre-built images to be available, so I don't think those will be going
away any time soon, indeed I think we will see demand for more images
for other SBCs too, even though it goes against how Debian has done
things in the past; suggesting use of the installer etc.

https://wiki.debian.org/UEFI
https://wiki.debian.org/InstallingDebianOn
https://wiki.debian.org/?action=fullsearch&value=Raspberry

PS: if you or anyone else would like to package edk2-platforms,
coreboot or other libre boot/other firmware for Debian, that would be
very welcome.

https://wiki.debian.org/Firmware/Open

[Pete Batard]

On 2021.09.09 23:28, lkcl wrote:
> Pete: thank you for pointing out that you've actively contributed, do keep emphasising that, it will help undo some of the damage.

Talk about implication loaded statement here.

So you are taking as fact that everybody is agreeing with your *opinion*
that I am causing damage?

Let me be as bold as you then and state that there's probably an equal
number of people who think that the greater damage was done when you
decided that you couldn't let Vagrant's naturally concluding statement
sit, and went on a personal attack against my person, by misreading
Vagrant's take as a justification that this was somehow okay.

So you may want to contemplate that, instead of assuming that everyone
is on the same page as yours.

> i do get that you feel you're not making "demands": i have had people regularly misconstrue what i say for over 20 years. thus, i am actually quite "entuned" now to the subtleties

I get it, you are somehow more "entuned" to pass judgement than somebody
else on this list. And of course, in that portrait, I am the black
sheep, because I dared express general disappointment at the actions of
some people on this list, whom I truly expected to know better, so that
we could, for once, avoid this whole charade where I or somebody else
has to barge in to try to correct incomplete or incorrect statements,
and then have to contend with the irritation of some of the people who
tried to champion these statements... or worst, a never-ending lecture
from people who misread what one has been trying to accomplish for the
betterment of the list as some kind of attack on their fiefdom.

>> If you read my posts carefully, you find that the only slight request
>> that I have made is that Debian (i.e. people on this list whom I expect
>>
>> to know better) should
>
> the two key phrases which tell us the mis-step that you keep making are "whom i expect to know better" and "should".

So I am not entitled to expect people to know better, after people have
been repeatedly posting on this list that there exist other methods of
installing Debian, besides pre-built ISO, and yet we were still seeing
pre-built being advertised as the only known way?

I do fully expect some people on this list to know better. Just like I
also fully expected some people on this list to know better than go into
a complete misconstruction about how placing the nonfree Pi firmware
blobs on the same media as a Debian installation media could somehow be
problematic.

And I also expected people other than me to intervene when they saw that
incomplete statements, incorrect statements and other inaccuracies were
being posted here (which some did).

But then again, seeing how doing so runs the risk of devolving into a
personal attack, and how quick tempered some of the people appear to be
here, I'm starting to understand why a few list members may think twice
before trying to chime in.

> it *really isn't* ok to make what can only be described as "implication-loaded statements" about individual contributors that are in effect Sovereign entities.

I am disappointed in some people in this mailing list. Am I not entitled
to that? I fully expected that the people who would bother to post on
this list would try to paint a more realistic picture of what was being
discussed. And I certainly did not expect to have to still be here
trying to explain how your biased personal attacks are unbecoming from
what is supposed to be a technical mailing list.

> "should" implies that you are directly criticising them for *not* doing something...

If you want to call that criticizing, then I am criticizing some people
on list for not seemingly not remembering items that have been discussed
here before, when it was relevant to bring them up, as well as people
not intervening to point out said relevant items. I have been doing so,
because, unfortunately, this is not the first time I'm seeing it
happening. And as an "entuned" dialectician, I would certainly expect
you to understand that not all criticism is negative, because, in my
view, these statements are actually fairly neutral (i.e. you take them
in your stride while trying to keep them in mind, and move on).

It's like picking up a bug you introduced in code. While expressing
disappointment at finding it, you might tell yourself that you should
have done better, as well as lay the expectation that you'll remember it
enough so that you don't do the same mistake again. Or, if it's not the
first time this kind of bug is being reported in a project, then
somebody else might also state that they expected the project to do
better and express the idea that developers of the project should know
better than continuing to introduce these kind of bugs.

> for which, like any Sovereign State, you have absolutely no right whatsoever to expect them to do,

So a teacher has no right to expect a student to do better? Or to try to
remember things that are very relevant to their curriculum? Or to
correct them when they state something that can be demonstrated as
factually incorrect?

I'm kinda curious here: Have you ever tried to bring the "Students are
their own Sovereign State" defence when you were at school? If so, how
did it go?

When someone is trying to teach a group, that has been failing to
address the above behaviours, can't they tell them that they are
disappointed in them and that they should collectively do better?

> "expect to know better" is again along the same lines: much as i hate to have to spell this out to you, it's terribly insulting.

Insult is not the intent, but if some people do feel it that way, then
maybe it'll be helpful. Because I could really use not having to remind
people on this list about the same thing over and over.

> it comes with the loaded implication that "everything they did - unpaid, remember - before you came along, is shit. because *you* said so".

That escalated quickly. "I would expect better" equates to "everything
you did before me is shit"?

Do you actually pause to consider what you are writing? Or are you
simply just going with projection of how you believe people are supposed
to behave, in order to fit the false narrative you have constructed
about somebody's intent of expression?

> now, that may actually be true, but if it is, and you hsve evidence to bsck it up, then as a newcomer you have to be *really* careful about how you go about presenting that.

I am not that much of a newcomer to this list. And that's part of the
reason I feel entitled to be able to express global disappointment with
the list as a whole as a non-outsider. Plus, if the idea is that
newcomers should somehow expect to be offered less respect even when
formulating true statements, I have to worry about the kind of technical
list this is supposed to be.

Shouldn't what we care about here be facts first and foremost?

> what may surprise you is that it *actually doesn't matter* whether what you suggest as an alternative to the "shit" is good or not: it's the very fact that you *expected* them to do it [without offering any financial compensation or other reward or incentive, which would result in a contractual or moral obligation where both parties satisfactorily get what they want]

At this stage, I'm gonna pass on this as well as the rest of your
nonsensical advice and assessment of what the core of the issue is.

Treat that as lack of empathy if you wish, but, whether you understand
it or not, and as one of its member of it, I have been trying to make
this list better.

And even if I perceive that you genuinely believe that you are trying to
accomplish the same, by "teaching" me some etiquette (while of course
not passing a chance to use as much as this pointless exchange to try to
boost your public mentor image somehow), I do hope that you will come to
realize, on your own, that public prolonged personal attacks on a
technical mailing list isn't the right way to go about it, even if you
truly believe that you have the high ground and that everybody else on
the list is somehow agreeing with you.

Regards,

/Pete

[Pete Batard]

Hi Paul,

On 2021.09.10 00:10, Paul Wise wrote:
> On Thu, Sep 9, 2021 at 9:46 PM Pete Batard wrote:
>
>> If you read my posts carefully, you find that the only slight request
>> that I have made is that Debian (i.e. people on this list whom I expect
>> to know better) should stop advertising pre-built images as the one
>> solution to install Debian on the Pi 3 or Pi 4, when there exists an
>> alternative for which a lot of people (including Debian maintainers,
>> EDK2 people, myself, and many others) have invested quite a lot of
>> effort in, and that have now reached a sufficient enough level maturity.
>
> If you would like Debian to advertise the UEFI option, please feel
> free to register an account on the Debian wiki and add it in the
> appropriate places. Due to the past actions of the RPi foundation and
> consequent culture of the larger RPi community, the userbase expects
> pre-built images to be available, so I don't think those will be going
> away any time soon,

I agree with that, and I am not suggesting they go away.

I just want to make sure that we (Debian) propose all the options to
users who might be wanting to install it on Raspberry Pi.

> indeed I think we will see demand for more images
> for other SBCs too, even though it goes against how Debian has done
> things in the past; suggesting use of the installer etc.
>
> https://wiki.debian.org/UEFI
> https://wiki.debian.org/InstallingDebianOn
> https://wiki.debian.org/?action=fullsearch&value=Raspberry

Yeah, I've been trying to find time to update info here.

My main issue, really, is time and priorities. And I also wouldn't mind
sorting out WiFi installation (which is currently not working), as I
expect that people will be looking for a guide that offers proper WiFi
support during install.

> PS: if you or anyone else would like to package edk2-platforms,
> coreboot or other libre boot/other firmware for Debian, that would be
> very welcome.
>
> https://wiki.debian.org/Firmware/Open

Thanks. The UEFI firmware is still a bit of a moving target, and not
something that can considered free. But I'll be trying to edit the Wiki
where applicable.

Regards,

/Pete

[lkcl]

On September 10, 2021 1:54:36 AM UTC, Pete Batard <pe...@akeo.ie> wrote:

>I get it, you are somehow more "entuned" to pass judgement than
>somebody
>else on this list. And of course, in that portrait, I am the black
>sheep,

this is evasion through a technique known in CRNHQ.org terminology as "victimhood". it's a cyclic spiral.

at this point, given that this individual has begun to interpret constructive criticism as "personal attack", and begun to engage in personal attack as a way to undermine and thus evade responsibility, further engagement with them is futile and counterproductive.

i deeply apologise to everyone on this list for taking up your time, i will not be speaking with them again.

l.

[LinAdmin]

I have some doubts that debian.net has the same ownership
than official debian.org?

On 04.09.21 10:48, Reco wrote:
> Hi.

>
> On Sat, Sep 04, 2021 at 09:51:30AM +0200, LinAdmin wrote:
>> The unnamed decision makers of Debian some unknown time ago
>> decided that Pi and Pine stuff won't be supported by Debian.

> Except that Raspberry Pis are supported by Debian.
> There are even pre-built images at https://raspi.debian.net

>
>> I switched to Ubuntu LTS which made me (and many others) happy.

> Whatever floats your boat.
>
> Reco
>

[LinAdmin]

The unnamed decision makers of Debian some unknown time ago
decided that Pi and Pine stuff won't be supported by Debian.

On 03.09.21 22:30, oregano...@disroot.org wrote:

At $45 with 3GB RAM, optional eMMC (35 for 64 GB), WiFi, etc., it seems interesting, but why is there almost zero coverage on Debian sites?

The Debian testing installer seemed to work, but initial boot didn't, or gave a blank HDMI display. At this point I don't recall spending any time trying to ssh onto it remotely, or examine the sdcard afterwards. What is the best way to get useful info and report it?

("Offtopic" but FYI) Dietpi worked fine.

These instructions took a long time, but resulted in a (more or less) working Debian system (on SD card). https://github.com/as365n4/Debian_on_Pine64_H64B Could someone point me to a better/cheaper/faster recipe?

Why isn't this SBC listed here https://wiki.debian.org/CheapServerBoxHardware or here https://wiki.debian.org/FreedomBox/Hardware ?

Thanks for any answers or suggestions!

[Reco]

Hi.

On Fri, Sep 10, 2021 at 09:50:24AM +0200, LinAdmin wrote:
> I have some doubts that debian.net has the same ownership
> than official debian.org?

RPi images from raspi.debian.net are GPG-signed by Gunnar Wolf's key
(who is Debian Developer), that's good enough for me.

Reco

[Gene Heskett]

But will they run my lathe? If they cannot do it safely, with IRQ latency
response well under 50 microseconds they are of sub-zero interest to me.

[Gunnar Wolf]

LinAdmin dijo [Fri, Sep 10, 2021 at 09:51:51AM +0200]:

> The unnamed decision makers of Debian some unknown time ago

> decided that Pi and *Pine* stuff won't be supported by Debian.

Hey, we do have names!

I am one of them. I am willing (and have done so extensively) to put
time into making Debian easy to use in the Raspberry family, but I am
convinced raspi-firmware cannot be part of Debian itself.

That's why I ensured that all of the footers in
https://raspi.debian.net/ mention that «This site is not an official
Debian project. While the maintainer (Gunnar Wolf) is a Debian
Developer, content herein provided should be considered unofficial».

Greetings,

[Gunnar Wolf]

Gene Heskett dijo [Fri, Sep 10, 2021 at 08:07:56AM -0400]:

> > On Fri, Sep 10, 2021 at 09:50:24AM +0200, LinAdmin wrote:
> > > I have some doubts that debian.net has the same ownership
> > > than official debian.org?
> >
> > RPi images from raspi.debian.net are GPG-signed by Gunnar Wolf's key
> > (who is Debian Developer), that's good enough for me.
> >
> > Reco
>
> But will they run my lathe? If they cannot do it safely, with IRQ latency
> response well under 50 microseconds they are of sub-zero interest to me.

They are not designed to suit you. I guess you want to build your own
kernels with the RT_PREEMPT enabled, and that's not something you will
get with any of the mainstream Linux distributions. Also, the
Raspberry is not the right platform for using RT (I'd suggest you look
at the Beaglebone, as its hardware with separate microcontrollers is
better suited at real-time tasks - it has less computing power, but is
better suited for RT tasks -- you will find
https://beagleboard.org/static/presentations/MakerFaireNY20140920_UsingBeagleBoneRealTimeMicrocontrollers.pdf
interesting).

Our images' goal is to provide something as close as possible to a
base, just-installed Debian image, following the RPi culture of having
installed images. You can build from there.

Of course, if you want to do a shipping in the hundreds, thousands or
further numbers of units, you won't want to use the images we generate
-- but you might find the vmdb2 scripts we have as a worthy starting
point for you to customize and build your own images. FWIW, I have a
script set for the ~10 Raspberries we use at work for driving displays
with our activities; I only use our "raw" images for testing them.

[Reco]

Hi.

On Fri, Sep 10, 2021 at 08:07:56AM -0400, Gene Heskett wrote:
> On Friday 10 September 2021 06:59:17 Reco wrote:
>
> > On Fri, Sep 10, 2021 at 09:50:24AM +0200, LinAdmin wrote:
> > > I have some doubts that debian.net has the same ownership
> > > than official debian.org?
> >
> > RPi images from raspi.debian.net are GPG-signed by Gunnar Wolf's key
> > (who is Debian Developer), that's good enough for me.
>

> But will they run my lathe? If they cannot do it safely, with IRQ latency
> response well under 50 microseconds they are of sub-zero interest to me.

Images provided by raspi.debian.net are shipped with ordinary, non-RT
kernel. Feel free to install RT-enabled kernel from the usual sources.

Reco

[Gene Heskett]

I knew that Reco, but the howto install after building it is the best
kept secret on this ball of rock and water, so I invented my own
installer. The revelant files total under 30 megs as a tarball.

So why do we not have a .deb builder for kernels.? Such secrecy, since it
doesn't involve the blacklisted firmware, and which my install doesn't
touch, certainly seems politically non-productive to me.

[Reco]

On Fri, Sep 10, 2021 at 12:04:56PM -0400, Gene Heskett wrote:
> So why do we not have a .deb builder for kernels.?

wiki.debian.org is your friend, consider learning how to search it.
In this particular case, you probably want [1].

Reco

[1] https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage

[Lennart Sorensen]

On Fri, Sep 10, 2021 at 12:04:56PM -0400, Gene Heskett wrote:

> I knew that Reco, but the howto install after building it is the best
> kept secret on this ball of rock and water, so I invented my own
> installer. The revelant files total under 30 megs as a tarball.
>
> So why do we not have a .deb builder for kernels.? Such secrecy, since it
> doesn't involve the blacklisted firmware, and which my install doesn't
> touch, certainly seems politically non-productive to me.

Did make-kpkg stop existing? It's been a while since I had a reason to
build my own kernel on any of my debian systems. I must admit searching
for it, it does appear to no longer exist. Hmm.

Some searching on google seems to indicate that these days one is
expected to use make deb-pkg in the kernel tree instead. I must admit
I have never tried that.

--
Len Sorensen

[Gene Heskett]

On Friday 10 September 2021 10:35:09 Gunnar Wolf wrote:

> Gene Heskett dijo [Fri, Sep 10, 2021 at 08:07:56AM -0400]:
> > > On Fri, Sep 10, 2021 at 09:50:24AM +0200, LinAdmin wrote:
> > > > I have some doubts that debian.net has the same ownership
> > > > than official debian.org?
> > >
> > > RPi images from raspi.debian.net are GPG-signed by Gunnar Wolf's
> > > key (who is Debian Developer), that's good enough for me.
> > >
> > > Reco
> >
> > But will they run my lathe? If they cannot do it safely, with IRQ
> > latency response well under 50 microseconds they are of sub-zero
> > interest to me.
>
> They are not designed to suit you. I guess you want to build your own
> kernels with the RT_PREEMPT enabled,

yes

> and that's not something you will
> get with any of the mainstream Linux distributions.

Then you need to update your testing of currant wintel versions. I would
estimate that IRQ latency today, thanks to the impetus of the Linus rant
a decade back about its poor performance is having an effect on stock
kernels, compared to a decade ago when latencys often ran north of a
millisecnd, the cureent shipping kernels with buster are now doing under
100 microseconds as the output of the linux-rt list get adopted into
shipping kernels. That is its target, to become the default kernel.

> Also, the
> Raspberry is not the right platform for using RT (I'd suggest you look
> at the Beaglebone, as its hardware with separate microcontrollers is
> better suited at real-time tasks - it has less computing power, but is
> better suited for RT tasks -- you will find
> https://beagleboard.org/static/presentations/MakerFaireNY20140920_Usin
>gBeagleBoneRealTimeMicrocontrollers.pdf interesting).

Depends on your point of view I think.

The beaglebone is for little bitty machines with barely enough hardware
to qualify as a cnc driver, a raspi4b can run circles around it while
browsing the web with firefox, I have done it on that pi4b.

Based on what I have learned, I could run any of the other 3 of my now
wintel powered machines on an rpi4 with a mesa 7i90 & friends interface.
But the rpi4, its 5 amp psu, and the full interface with a box to hold
it all would cost almost $400 per machine to convert. If I was starting
from scratch on a new machine the diff in the power bill would pay the
cost diff per machine in 2 years with the diff in power used. The wintel
stuff is hungry, 200+ watts/machine, the pi uses 10 watts to do the same
job, 21 watts leaving the monitor live too.

> Our images' goal is to provide something as close as possible to a
> base, just-installed Debian image, following the RPi culture of having
> installed images. You can build from there.

And I have, using raspbian buster now. I tried a debian net-install at
about 10.4, ran great till I rebooted and the net disappeared. I asked
how to fix it on this list and got told to shuffle off to the main list,
which doesn't support arm stuff, don't bother us.

I'm sorry if the truth hurts the present managements feelings, but there
it is.

With a bit longer view than most, I am hoping that this "new broom" you
represent will fix some of that, and I do think that by this
conversation even happening at all, that it is improving rapidly.
Someday, I'm hoping, as I hope to see equality in my remaining time,
which I'm borrowing with hardware help now, I'll be 87 in about 3 weeks.

> Of course, if you want to do a shipping in the hundreds, thousands or
> further numbers of units, you won't want to use the images we generate
> -- but you might find the vmdb2 scripts we have as a worthy starting
> point for you to customize and build your own images. FWIW, I have a
> script set for the ~10 Raspberries we use at work for driving displays
> with our activities; I only use our "raw" images for testing them.

Thanks Gunnar. I tried to send you a PM 2-3 days back, but it bounced.

[Gene Heskett]

I am not aware that it ever existed. So I install the needed meat to make
it work, via a card reader and the non-compressed tarball is just under
30 megs. apt sees it, leaves it alone. So its pinned 6 other packages
for about 20 months now.

Link to how to docs? I ought to check out something newer than 4.19.xx

Thanks Lennart. Take care & stay well.

[Gene Heskett]

Thank you Reco, bookmarked and printed.

[Vagrant Cascadian]

On 2021-09-10, LinAdmin wrote:
> The unnamed decision makers of Debian some unknown time ago

> decided that Pi and *Pine* stuff won't be supported by Debian.

This is the second time you've stated this, without really adding
meaningful content to the conversation, and people have presented
evidence to the contrary...

If you don't want to help, that's fine, but please at least refrain from
making repetative, vague statements of questionable accuracy.

Debian Developers and many other contributors to Debian are in fact
supporting these and many other platforms on Debian... They have done so
by submitting patches, bug reports, fixes, etc. It would be difficult to
create a comprehensive list of all of them. Check the changelogs for the
linux kernel, u-boot, debian-installer, raspi-firmware... there are lots
of people making decisions to support these platforms in those and even
other packages.

Specifically...

There are at least five pine64.org platforms listed at:

https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/

I believe the same set of images is supported in the Debian bullseye
release. At some point they worked (I personally tested each of them
before adding support), if they don't currently work, please file bug
reports and ideally patches if you can.


While the Raspberry Pi can't fully be supported in Debian "main" due to
the Debian Social Contract and the lack of compatible licenses:

https://www.debian.org/social_contract

There is support for the non-free firmware in "non-free" since 2019:

https://tracker.debian.org/pkg/raspi-firmware

More recently, you can get a UEFI implementation for pi3 and pi4:

https://github.com/pftf

With a UEFI implementation, you can boot the standard debian-installer
.iso images for arm64 platforms:

https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/
or
https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/

And there are "unofficial" images made to be written directly to boot
media produced by Debian Developers available at:

https://raspi.debian.net



Somewhat of an aside, I feel inclined at this point to bring up the
Debian Community Guidelines:

https://people.debian.org/~enrico/dcg/

I find it has some valuable thoughts that help improve my contributions
to Debian.


live well,
vagrant

[Keith Bainbridge]

On Tue, 7 Sep 2021 10:01:49 +0300
Andrei POPESCU <andreim...@gmail.com> wrote:

>>Kind regards,
>>Andrei -- happy Debian user of a PINE A64+ and (still) considering
>>the Pinebook Pro for my next laptop

There's an interesting review of the Pro here:

https://www.jeremymorgan.com/blog/linux/90-days-with-pinebook-pro/

Sounds interesting. Pity they are out of stock


All the best

Keith Bainbridge
keith.bain...@gmail.com

0447 667 468

[Jeffrey Walton]

On Sat, Sep 11, 2021 at 4:27 AM Keith Bainbridge <keit...@gmail.com> wrote:
> ...

> There's an interesting review of the Pro here:
> https://www.jeremymorgan.com/blog/linux/90-days-with-pinebook-pro/
>
> Sounds interesting. Pity they are out of stock

They seem to be always out of stock. I've been trying to buy a
pinebook (and now the pro) for about the last two years. Every few
months I visit the website, and they always show out of stock.

I'm glad the project is doing well, but it would be nice if they had
the hardware in stock.

Jeff

[Peter Ehlert]

On 9/11/21 1:11 AM, Keith Bainbridge wrote:
> On Tue, 7 Sep 2021 10:01:49 +0300
> Andrei POPESCU <andreim...@gmail.com> wrote:
>
>>> Kind regards,
>>> Andrei -- happy Debian user of a PINE A64+ and (still) considering
>>> the Pinebook Pro for my next laptop
> There's an interesting review of the Pro here:
>
> https://www.jeremymorgan.com/blog/linux/90-days-with-pinebook-pro/

good review, thanks

>
> Sounds interesting. Pity they are out of stock

I think I got the very last one in old stock: ordered on June 8, 2021

superior build quality, I really like it, but it is not my daily driver

lurking here for tips on how to get Debian running on it.
Manjaro is not my cup of tea

[Gene Heskett]

On Saturday 11 September 2021 04:11:26 Keith Bainbridge wrote:

> On Tue, 7 Sep 2021 10:01:49 +0300
>
> Andrei POPESCU <andreim...@gmail.com> wrote:
> >>Kind regards,
> >>Andrei -- happy Debian user of a PINE A64+ and (still) considering
> >>the Pinebook Pro for my next laptop
>
> There's an interesting review of the Pro here:
>
> https://www.jeremymorgan.com/blog/linux/90-days-with-pinebook-pro/
>
> Sounds interesting. Pity they are out of stock

It night "sound interesting" if it had sound, but thats the quietest
movie I've watched in months. No audio buttons to be found.

Thanks Keith.

> All the best
>
> Keith Bainbridge
> keith.bain...@gmail.com
>
> 0447 667 468

[Andrei POPESCU]

On Sb, 11 sep 21, 04:30:21, Peter Ehlert wrote:
>
> On 9/11/21 1:11 AM, Keith Bainbridge wrote:
> > On Tue, 7 Sep 2021 10:01:49 +0300
> > Andrei POPESCU <andreim...@gmail.com> wrote:
> >
> > > > Kind regards,
> > > > Andrei -- happy Debian user of a PINE A64+ and (still) considering
> > > > the Pinebook Pro for my next laptop
> > There's an interesting review of the Pro here:
> >
> > https://www.jeremymorgan.com/blog/linux/90-days-with-pinebook-pro/
>
> good review, thanks
>
> >
> > Sounds interesting. Pity they are out of stock

They've had some supply issues, possibly solved soon, the monthly
newsletter has more information on that.

> I think I got the very last one in old stock: ordered on June 8, 2021
>
> superior build quality, I really like it, but it is not my daily driver
>
> lurking here for tips on how to get Debian running on it.
> Manjaro is not my cup of tea

What issues did you encounter with using the Debian Installer?

https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/
https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/README.concatenateable_images

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

[Peter Ehlert]

On 9/11/21 7:24 AM, Andrei POPESCU wrote:
> On Sb, 11 sep 21, 04:30:21, Peter Ehlert wrote:
>> On 9/11/21 1:11 AM, Keith Bainbridge wrote:
>>> On Tue, 7 Sep 2021 10:01:49 +0300
>>> Andrei POPESCU <andreim...@gmail.com> wrote:
>>>
>>>>> Kind regards,
>>>>> Andrei -- happy Debian user of a PINE A64+ and (still) considering
>>>>> the Pinebook Pro for my next laptop
>>> There's an interesting review of the Pro here:
>>>
>>> https://www.jeremymorgan.com/blog/linux/90-days-with-pinebook-pro/
>> good review, thanks
>>
>>> Sounds interesting. Pity they are out of stock
> They've had some supply issues, possibly solved soon, the monthly
> newsletter has more information on that.
>
>> I think I got the very last one in old stock: ordered on June 8, 2021
>>
>> superior build quality, I really like it, but it is not my daily driver
>>
>> lurking here for tips on how to get Debian running on it.
>> Manjaro is not my cup of tea
> What issues did you encounter with using the Debian Installer?

I have done nothing yet, I do plan to try "soon".
I will report my findings when I do.

[Vagrant Cascadian]

On 2021-09-11, Peter Ehlert wrote:
> On 9/11/21 1:11 AM, Keith Bainbridge wrote:
>> On Tue, 7 Sep 2021 10:01:49 +0300
>> Andrei POPESCU <andreim...@gmail.com> wrote:
>>>> Andrei -- happy Debian user of a PINE A64+ and (still) considering
>>>> the Pinebook Pro for my next laptop

...

> superior build quality, I really like it, but it is not my daily driver
>
> lurking here for tips on how to get Debian running on it.

I gave a talk (that had some glitches...) at DebConf21 which has bits
and pieces of what I did to make a live image that boots on both the
pinebook and pinebook-pro:

https://debconf21.debconf.org/talks/88-two-pinebooks-walk-into-a-bar/

with video available at:

https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/

And slides:

https://salsa.debian.org/vagrant/two-pinebooks-walk-into-a-bar

At some point I'd like to firm up the process for making live images for
arm64... but at the moment it's still a bit ad-hoc, though I've managed
a proof of concept! :)

The next feature I need to work into it would be to add UEFI support,
then it could boot any system with UEFI as well as 1-3 systems with
compatible u-boot offsets...


live well,
vagrant

[Oregano]

September 11, 2021 11:30 AM, "Peter Ehlert" <pb...@sdi-baja.com> wrote:

> On 9/11/21 1:11 AM, Keith Bainbridge wrote:
>
>> On Tue, 7 Sep 2021 10:01:49 +0300
>> Andrei POPESCU <andreim...@gmail.com> wrote:
>>
>> Kind regards,
>> Andrei -- happy Debian user of a PINE A64+ and (still) considering
>> the Pinebook Pro for my next laptop
>> There's an interesting review of the Pro here:
>>
>> https://www.jeremymorgan.com/blog/linux/90-days-with-pinebook-pro
>

> good review, thanks
>
>> Sounds interesting. Pity they are out of stock
>
> I think I got the very last one in old stock: ordered on June 8, 2021
>
> superior build quality, I really like it, but it is not my daily driver
>
> lurking here for tips on how to get Debian running on it.
> Manjaro is not my cup of tea
>
>> All the best
>>
>> Keith Bainbridge
>> keith.bain...@gmail.com
>>
>> 0447 667 468

Got lucky in late May myself, but did not appreciate Manjaro either. IIRC Debian installer on an SD card ran OK, but wasn't able to successfully connect to the network, or install to the EMMC, or both. It was probably user error due to not connecting extra power to the docking station to get a good ethernet cable connection... Ordered the USB EMMC adapter and wrote Kali image onto EMMC, because a Kali all-in-one image was available for quick and easy "dd install", Kali is very Debian-testing/sid, and Kali sounds bad-ass. :D By the time the adapter arrived, however, the Debian SD card was forgotten in the SD card slot, so the first couple boots came up with the Debian install process, which caused some confusion until the SD card was removed. Kali is working OK, but I haven't tested sound, and it didn't handle the first low battery gracefully (i.e. sudden power-off), but that could also be user error in messing with Power Settings... Another disappointment is having to go to Sourceforge for an unofficial Tor Browser arm64 port. Minor issues: Kali only used a minimal portion of the EMMC to start, so there wasn't enough room to run the first update until the partition size was expanded. There seems to be slightly more latency when starting applications. Disclaimer: Mine has only been back in action for a couple days. PSA: Don't cut your finger on the Pinebook Pro sharp edges when removing the back cover without RTFM carefully to see the warning. Those edges are sharp!

[Vagrant Cascadian]

On 2021-09-11, Oregano wrote:
> September 11, 2021 11:30 AM, "Peter Ehlert" <pb...@sdi-baja.com> wrote:
>> On 9/11/21 1:11 AM, Keith Bainbridge wrote:
>>> Andrei -- happy Debian user of a PINE A64+ and (still) considering
>>> the Pinebook Pro for my next laptop

...

> Debian installer on an SD card ran OK, but wasn't able to
> successfully connect to the network, or install to the EMMC, or
> both. It was probably user error due to not connecting extra power to
> the docking station to get a good ethernet cable connection...

I have had the odd issue, quite repeatable (and confirmed by at least
one other person), where the ethernet on the usb-c docking station (and
various other functions) only work with the usb-c connector is in one
particular orientation; because USB-C isn't *supposed* to require a
particular orientation there's no obvious marking which side is which,
so I have to find it pretty much by trial and error... someday I'll get
clever and mark it when I find the working orientation.

Fairly late in the bullseye release cycle several things got fixed for
the Pinebook Pro; might be worth trying again if you haven't tried
recently!


live well,
vagrant

[Paul Wise]

On Fri, Sep 10, 2021 at 4:05 PM Gene Heskett wrote:

> So why do we not have a .deb builder for kernels.?

The upstream Linux kernel build system can build .deb files using the
`make deb-pkg` (build .dsc+.deb files) or the `make bindeb-pkg` (build
.deb files).

https://www.kernel.org/doc/makehelp.txt

For rebuilding Debian's version of the Linux kernel, see the Debian
Linux kernel team's documentation:

https://kernel-team.pages.debian.net/kernel-handbook/

--
bye,
pabs

https://wiki.debian.org/PaulWise

[Paul Wise]

On Fri, Sep 10, 2021 at 2:35 PM Gunnar Wolf wrote:

> They are not designed to suit you. I guess you want to build your own
> kernels with the RT_PREEMPT enabled, and that's not something you will
> get with any of the mainstream Linux distributions.

This is incorrect, Debian has had RT kernels built for ages, there are
RT kernels for buster and later on armhf and arm64:

http://packages.debian.org/linux-image-rt-

[Paul Wise]

On Fri, Sep 10, 2021 at 2:13 PM Gunnar Wolf wrote:

> I am one of them. I am willing (and have done so extensively) to put
> time into making Debian easy to use in the Raspberry family, but I am
> convinced raspi-firmware cannot be part of Debian itself.

While raspi-firmware can't be in Debian main, it is in non-free, so
there could be unofficial RPi images hosted on the cdimage.debian.org
server, just like we have installer, live and other images containing
non-free firmware.

[Paul Wise]

On Fri, Sep 10, 2021 at 7:50 AM LinAdmin wrote:

> I have some doubts that debian.net has the same ownership
> than official debian.org?

debian.net and debian.org have the same ownership (Debian, via our
fiscal sponsor SPI). debian.org subdomains are setup by the Debian
sysadmins and mostly run on hardware owned by Debian and systems run
by the Debian sysadmins. debian.net subdomains are registered by
individual Debian members for experiments, temporary or unofficial
services. Gunnar Wolf registered the raspi.debian.net domain for
delivering Debian RPi images.

$ whois debian.org | grep 'Registrant Organization'
Registrant Organization: Software in the Public Interest, Inc. - Debian Project

$ whois debian.net | grep 'Registrant Organization'
Registrant Organization: Software in the Public Interest, Inc. - Debian Project

$ ldapsearch -ZZZLLL -x -h db.debian.org -b ou=users,dc=debian,dc=org
dnsZoneEntry=raspi* uid name dnsZoneEntry
dn: uid=gwolf,ou=users,dc=debian,dc=org
cn: Gunnar
uid: gwolf
sn: Wolf
dnsZoneEntry: raspi IN A 208.97.148.173

[Oregano]

September 11, 2021 11:16 PM, "Paul Wise" <pa...@debian.org> wrote:

> On Fri, Sep 10, 2021 at 7:50 AM LinAdmin wrote:
>
>> I have some doubts that debian.net has the same ownership
>> than official debian.org?
>
> debian.net and debian.org have the same ownership (Debian, via our
> fiscal sponsor SPI). debian.org subdomains are setup by the Debian
> sysadmins and mostly run on hardware owned by Debian and systems run
> by the Debian sysadmins. debian.net subdomains are registered by
> individual Debian members for experiments, temporary or unofficial
> services. Gunnar Wolf registered the raspi.debian.net domain for
> delivering Debian RPi images.

OK, but nslookup raspi.debian.net and whois 208.97.148.173 shows raspi.debian.net is hosted at NightmareHost, which probably explains the very long delays in seeing the site sometimes. I respect Gunnar's support for raspi's, but the choice of host could be much better, IMO.

[Paul Wise]

On Fri, Sep 10, 2021 at 5:04 PM Gene Heskett wrote:

> ... 100 microseconds as the output of the linux-rt list get adopted into

> shipping kernels. That is its target, to become the default kernel.

I believe the intent of the Linux RT developers is to keep it as a
build-time config option, so it will probably always be a separate
build to the regular Linux kernel. Having all the patches merged into
mainline will make it more likely that distros will build an RT
kernel, like Debian already does using the unmerged patches.

[Diederik de Haas]

On zondag 12 september 2021 01:26:37 CEST Oregano wrote:
> OK, but nslookup raspi.debian.net and whois 208.97.148.173 shows
> raspi.debian.net is hosted at NightmareHost, which probably explains the
> very long delays in seeing the site sometimes. I respect Gunnar's support
> for raspi's, but the choice of host could be much better, IMO.

The footer of the homepage of raspi.debian.net contains the following line:
Source code: this website | tool that generates the images | raspi firmware

Actual links:
website: https://salsa.debian.org/raspi-team/web-raspi-img/
tool to generate the images: https://salsa.debian.org/raspi-team/image-specs

You are free to host your images on your own site (or LAN). Then you don't
have to suffer any delays imposed on you by the internet.
You can even customize your own image to suit your needs.

The source code is available. Feel free to make use of it.

[deloptes]

Gene Heskett wrote:

> It night "sound interesting" if it had sound, but thats the quietest
> movie I've watched in months. No audio buttons to be found.

sound appears to be muted. In the latest and greatest firefox it worked
after unmuting

--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[Gunnar Wolf]

Oregano dijo [Sat, Sep 11, 2021 at 11:26:37PM +0000]:

> >> I have some doubts that debian.net has the same ownership
> >> than official debian.org?
> >
> > debian.net and debian.org have the same ownership (Debian, via our
> > fiscal sponsor SPI). debian.org subdomains are setup by the Debian
> > sysadmins and mostly run on hardware owned by Debian and systems run
> > by the Debian sysadmins. debian.net subdomains are registered by
> > individual Debian members for experiments, temporary or unofficial
> > services. Gunnar Wolf registered the raspi.debian.net domain for
> > delivering Debian RPi images.
>
> OK, but nslookup raspi.debian.net and whois 208.97.148.173 shows
> raspi.debian.net is hosted at NightmareHost, which probably explains
> the very long delays in seeing the site sometimes. I respect
> Gunnar's support for raspi's, but the choice of host could be much
> better, IMO.

Actually, I have been a DreamHost client for >20 years, and am quite
happy with them. They provide me more than enough bandwidth and
storage for basically every need I have come across for a very
agreeable price. That's the reason I hosted my images there.

But I understand you might have better preferences. Please provide me
the details for a web space you will sponsor and keep for several
years, and I will move raspi.debian.net there.

[Jeffrey Walton]

On Sat, Sep 11, 2021 at 11:19 PM Gunnar Wolf <gw...@debian.org> wrote:
> ...

> > OK, but nslookup raspi.debian.net and whois 208.97.148.173 shows
> > raspi.debian.net is hosted at NightmareHost, which probably explains
> > the very long delays in seeing the site sometimes. I respect
> > Gunnar's support for raspi's, but the choice of host could be much
> > better, IMO.
>
> Actually, I have been a DreamHost client for >20 years, and am quite
> happy with them. They provide me more than enough bandwidth and
> storage for basically every need I have come across for a very
> agreeable price. That's the reason I hosted my images there.
>
> But I understand you might have better preferences. Please provide me
> the details for a web space you will sponsor and keep for several
> years, and I will move raspi.debian.net there.

To wander a bit off-topic, DreamHost charges 10.00 USD per month for a
VPS/virtual server. You may be able to do better, if needed.

We use IONOS for VPS. IONOS starts as low as 2.00 USD per month. We
get root access, and we can install whatever software we like. We
needed root to run the latest wiki software on top of Ubuntu's LAMP
stack.

Due to wiki software and MySQL, we had to bump to the 5.00 USD per
month plan for 2 GB of RAM. The OOM killer was whacking the MySQL
process and corrupting the wiki database.

I'm not sure how IONOS compares to DreamHost for network bandwidth,
however. We have not (yet?) encountered a problem with throttling.

Jeff

[lkcl]

On September 12, 2021 4:00:08 AM UTC, Jeffrey Walton <nolo...@gmail.com> wrote:

>I'm not sure how IONOS compares to DreamHost for network bandwidth,
>however. We have not (yet?) encountered a problem with throttling.

ah. mythic-beasts.com very kindly explained this one to me.

the majority of ultra-cheap hosting VM providers oversubscribe CPU, RAM, and bandwidth, often to a massive degree.

in the case of CPU and RAM that is done through VM Ballooning, and it means that if the main host happens to have someone else consuming vast resources, *you* get punished.

likewise during heavy overall network usage, you get punished for *other people's* excessive bandwidth.

mythic-beasts make a point of *NOT* doing that.

when they say you get 1 gigabit per second service, you GET 1 gigabit per second service, AT ALL TIMES.
likewise for RAM and CPU, you get what you pay for, 100% of the time.

for hosting something like debian packages it therefore does not make a lot of sense to use sub-standard hosting with ballooning and shared oversubscribed bandwidth because it's going to be a massive sustained load.

ISPs are often happy to sponsor the debian project to provide bandwidth and hosting, they get kudos for doing so plus they're probably using it for their own infrastructure.

l.

[Andrew M.A. Cater]

You got in there on the Community Guidelines just before I did :)

This has been a long thread: I think there's something to be brought out
of this - let's see if I can summarise some of the back and forth.

1. There _is_ support for the Raspberry Pi in Debian. There are unofficial
images from raspi.debian.net maintained by Gunnar Wolf. They're unofficial
for the reasons outlined by Paul Wise: containing non-free firmware.

2. These images use u-boot and dtb primarily. There are images for all
currently released Raspberry Pis. The earlier Pis are not compatible with
the later Pi architectures necessarily - Debian does things differently
to Raspbian.

[it's an interesting point that they could be put into cdimage.debian.org
in the same way that unofficial firmware images for amd64 are already there.
Likewise, almost certainly for the next alternative - certainly something to
consider.]

3. An alternative is to use the UEFI approach from Pete Batard for Pi3 and
Pi4 specifically. This doesn't use dtb by default and uses ACPI. It's a rebuild
of Tianocore. Provided you have the firmwrare, it does allow a user to use
an unmodified Debian arm64 image to install everything else.

4. Other platforms may have more/less support: this is not for want of effort
and a unified approach would be really very helpful. [This might need a
more standard approach to boot methods/co-operation from manufacturers
and is not something to be solved immediately]. Support for Pine / other
Allwinner platforms / other boards may sometimes be difficult for reasons
outside Debian's control.

4. There's scope for all approaches: more help is always appreciated. At
times, it felt like contributors to this discussion were talking past each
other inadvertently whereas they've mostly been in violent agreement.

5. There is always scope for better communication and, certainly, better understanding
of where we are, how we came to reach this point and for everything to be
better documented.

LinAdmin: The "decision makers" from Derbian aren't unnamed: they're
primarily the developers and others who've chipped in on this discussion.
Opinions vary, as you've read, but your help would be appreciated. If you're
not in a position to help, please relay the accurate information from
this list. Your cooperation in this would be greatly appreciated.

With every good wish to all, as ever,

Andy Cater

[lkcl]

On September 12, 2021 2:47:38 PM UTC, "Andrew M.A. Cater" <amac...@einval.com> wrote:

nice summary, Andy. a couple of things that i feel are important to add. first (i accidentally trimmed context) is about debian package distribution.

for those people unfamiliar with it, who have been used to other package management being distributed via "trusted" website download (node, pypi, Mozilla B2G), debian CRITICALLY DOES NOT rely on or trust web sites or SSL Certificates in any way, shape or form.

debian's distribution validation is *fundamentally* tied to the web-of-trust GPG keyring, which is itself signed and distributed as a debian package.

if you are of the belief that the debian *website* or *domain* are the sole exclusive trust authority then you have left yourself open and vulnerable to attacks of many different varieties, too numerous to list here.

please, therefore: trust and check the *GPG signatures*.

>4. Other platforms may have more/less support: this is not for want of
>effort
>and a unified approach would be really very helpful. [This might need a
>more standard approach to boot methods/co-operation from manufacturers
>and is not something to be solved immediately].

second, is about this. sad to say, any expectations of collaboration from manufacturers is expecting far too much.

shockingly, LG's Lawyers for example actually consider it to be a failure *on their part* if you even *notice* that LG's TV products have been criminally infringing copyright law for decades.

Allwinner Chinese employees are paranoid about IP Theft by Westerners because they themselves do it all the time, and therefore expect Westerners to "punish" them by stealing or hacking their networks at their offices.

yes, really.

i was invited to visit the Allwinner offices a few years ago and the Chinese staff treated me like I was there to commit Industrial Espionage. i felt so unsafe as a result, i could not dare consider a return visit.

from a product perspective, products involving ARM SoCs are *NOT* designed for user programmability "convenience". they're not even designed for the *OEM's* convenience!

both Mediatek and LG have a policy of designing products *entirely on behalf* of OEMs. they design it, they program it, they deliver it. LG even *make* the damn products: the first time the OEM ever sees it is when it turns up at the Customs port!

i am basically painting a picture here of the realities of ARM SoCs, which is that the Fabless Semi Companies are ACTIVELY HOSTILE to the entire Free Software Community.

we are a THREAT to them.

how DARE we reverse-engineer THEIR products and steal all THEIR secret commercial information!

never mind the fact that without Free Software they wouldn't even be able to sell one single product: in their minds, one tiny change to one single header file is sufficient justification to flagrantly and blatantly ignore the fundamental tenets of Copyright Law.

even those Companies that understand Copyright Law *still* do not wish to cooperate or collaborate because (a) it costs money to do so (b) it reveals commercially confidental information (c) it doesn't help sell product that (d) is *specifically designed for non-end-user-programmability in the first place*!

much as i and everyone else is terribly frustrated with how badly the Free Software Community is treated by the Fabless Semi companies, expecting *any* type of cooperation from them *or from ARM* is unfortunately completely unrealistic.

Roger spent considerable time kindly explaining how long it took to get Linaro established. Linaro is about the limit of what ARM can do, only working with *willing* participatory Fabless Semi companies to create standards. given the sheer massive diversity with literally thousands of ARM licensees, any attempt at "restrictive" standardisation is going to result in pushback and resultant loss of business for ARM.

it's a shitty sutuation but important to understand the context, so that we do not, as a community, spend too much of our time either complaining or fighting or unrealistically wishing things were different.

personally i am so absolutely fed up with seeing so much of *our* (collective) personal money going into "fixing" the mess that Fabless Semi companies leave behind that i concluded that the only way to properly fix it is to *become* a Fabless Semiconductor ASIC designer, and create an actual SoC that actually properly respects Software Libre to the bedrock (http://libre-soc.org)

unfortunately, due to ARM's licensing model, it can't be an ARM-compatible design. we picked Power ISA instead.

l.

[Oregano]

September 12, 2021 3:19 AM, "Gunnar Wolf" <gw...@debian.org> wrote:

> Oregano dijo [Sat, Sep 11, 2021 at 11:26:37PM +0000]:
>
>>

>> OK, but nslookup raspi.debian.net and whois 208.97.148.173 shows
>> raspi.debian.net is hosted at NightmareHost, which probably explains
>> the very long delays in seeing the site sometimes. I respect
>> Gunnar's support for raspi's, but the choice of host could be much
>> better, IMO.
>
> Actually, I have been a DreamHost client for >20 years, and am quite
> happy with them. They provide me more than enough bandwidth and
> storage for basically every need I have come across for a very
> agreeable price. That's the reason I hosted my images there.
>
> But I understand you might have better preferences. Please provide me
> the details for a web space you will sponsor and keep for several
> years, and I will move raspi.debian.net there.

I was not trying to insult you because of your host choice. Rather to give you feedback from my experience. My experience with NightmareHost was, and continues to be, unsatisfactory. Not all slow sites I often visit are hosted there, but some are. Google's Speedtest says raspi.debian.net is fast, but knowing DH, they probably purposely slowdown access over Tor, and speedup access from testing sites. When I go to www.debian.net, it redirects to debian.org and displays a page within a second or so. When I go to raspi.debian.net, it usually times out three to five times minimum before displaying, which takes several minutes. You're free to take the feedback or ignore it.

[lkcl]

On September 12, 2021 10:01:20 PM UTC, Oregano <oregano...@disroot.org> wrote:
>September 12, 2021 3:19 AM, "Gunnar Wolf" <gw...@debian.org> wrote:
here.
>>
>> But I understand you might have better preferences. Please provide me
>> the details for a web space you will sponsor and keep for several
>> years, and I will move raspi.debian.net there.

Gunnar: can i ask: I take it that you, personally, are not comfortable paying for hosting bandwidth, out of your own personal funds, if the end-users who are downloading images do not themselves offer you any financial compensation or give you donations for doing so?

do you ever receive any such offers that would aid and assist in covering the full cost of the hosting, or for your efforts in maintaining the server?

>I was not trying to insult you because of your host choice.

which i am sure he didn't take it as one.

> Rather to give you feedback from my experience.

which i am sure he appreciated.

>out three to five times minimum before displaying, which takes several
>minutes. You're free to take the feedback or ignore it.

i do have to point out that you're both mis-communicating, here.

Gunnar mentioned that you are free to provide an offer of an alterative hosting service - AND PAY FOR IT (or find a long-term sponsor) as a very polite way of saying, by omission and implication:

"you get what you pay for... and you haven't paid me anything"

in other words, he did not wish to risk annoying or insulting you by pointing out that your report, which is perfectly valid and most appreciated, did *not come with an offer to pay for improved service*

this is one of the rather embarrasing and uncomfortable aspects of Free Software: the assumption that because it's Libre, it must also be monetarily zero cost.

put plainly: hosting those images costs *real money*, for which someone has to pay!

so please: if you find the service that Gunnar provides at no charge to yourself to be inadequate for your needs, *pay him to improve it*!!!

[or, help him to find a sponsor willing to pay for better and long-term service, as he suggested]

it's really that simple, folks!

l.

[Peter Ehlert]

thanks for the input and encoragement

[Oregano]

September 11, 2021 9:19 PM, "Vagrant Cascadian" <vag...@debian.org> wrote:

> On 2021-09-11, Peter Ehlert wrote:
>
>> On 9/11/21 1:11 AM, Keith Bainbridge wrote:
>>> On Tue, 7 Sep 2021 10:01:49 +0300
>>> Andrei POPESCU <andreim...@gmail.com> wrote:
>>
>> Andrei -- happy Debian user of a PINE A64+ and (still) considering
>> the Pinebook Pro for my next laptop
>
> ...
>> superior build quality, I really like it, but it is not my daily driver
>>
>> lurking here for tips on how to get Debian running on it.
>
> I gave a talk (that had some glitches...) at DebConf21 which has bits
> and pieces of what I did to make a live image that boots on both the
> pinebook and pinebook-pro:
>
> https://debconf21.debconf.org/talks/88-two-pinebooks-walk-into-a-bar
>

> with video available at:
>
> https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21
>

> And slides:
>
> https://salsa.debian.org/vagrant/two-pinebooks-walk-into-a-bar
>
> At some point I'd like to firm up the process for making live images for
> arm64... but at the moment it's still a bit ad-hoc, though I've managed
> a proof of concept! :)
>
> The next feature I need to work into it would be to add UEFI support,
> then it could boot any system with UEFI as well as 1-3 systems with
> compatible u-boot offsets...
>
> live well,
> vagrant

Awesome! Very much enjoyed seeing, and hearing, the talk, on and about my Pinebook Pro! With Kali/debian on PineBook Pro: Wifi works; sound works, not very loud, but loud enough to hear the talk; also has difficulty with suspend/hybernate and low battery.

What was the purpose of providing a makefile instead of just a PDF of slides? I already had graphviz, but all the rest took "185 MB of archives" download, and used "605 MB of additional disk space," for 1.2 MB of PDF file? Now I is a developer/builder?!

[Lennart Sorensen]

On Fri, Sep 10, 2021 at 01:17:02PM -0400, Gene Heskett wrote:
> I am not aware that it ever existed. So I install the needed meat to make
> it work, via a card reader and the non-compressed tarball is just under
> 30 megs. apt sees it, leaves it alone. So its pinned 6 other packages
> for about 20 months now.
>
> Link to how to docs? I ought to check out something newer than 4.19.xx
>
> Thanks Lennart. Take care & stay well.

Well I found stuff here:

https://wiki.debian.org/BuildADebianKernelPackage

That mentions the bindeb-pkg and deb-pkg arguments. I am not sure what
the difference is.

--
Len Sorensen

[Gunnar Wolf]

lkcl dijo [Sun, Sep 12, 2021 at 10:21:45PM +0000]:

> >> But I understand you might have better preferences. Please provide me
> >> the details for a web space you will sponsor and keep for several
> >> years, and I will move raspi.debian.net there.
>
> Gunnar: can i ask: I take it that you, personally, are not
> comfortable paying for hosting bandwidth, out of your own personal
> funds, if the end-users who are downloading images do not themselves
> offer you any financial compensation or give you donations for doing
> so?

No, nothing like that -- I am paying for bandwidth+disk space for many
of my personal sites, projects, and what amounts to my data dump. I
have enough space and bandwidth to tuck raspi.debian.net along all
that. I believe the service quality to be more than enough; this is
the first time I see aby complaints regarding my service provider.

> do you ever receive any such offers that would aid and assist in
> covering the full cost of the hosting, or for your efforts in
> maintaining the server?

I prefer not to have to think about international money transfers and
the like. I am paying for this service, and will continue to do so
even if raspi.debian.net found a different hosting.

> Gunnar mentioned that you are free to provide an offer of an
> alterative hosting service - AND PAY FOR IT (or find a long-term
> sponsor) as a very polite way of saying, by omission and
> implication:
>
> "you get what you pay for... and you haven't paid me anything"

I prefer to leave the "paying" out of the question. I don't want
people to think that they can pay me for my time; my time is not for
sale.

> put plainly: hosting those images costs *real money*, for which
> someone has to pay!

It is marginal cost only, it's using resources that are already paid
and available.

> so please: if you find the service that Gunnar provides at no charge
> to yourself to be inadequate for your needs, *pay him to improve
> it*!!!
>
> [or, help him to find a sponsor willing to pay for better and
> long-term service, as he suggested]

Please don't pay me. If you offer a good hosting solution and plan to
keep it viable in the long run, I can be persuaded to move
raspi.debian.net from my current hosting provider.

Thanks,

[Gene Heskett]

On Monday 13 September 2021 10:09:05 Lennart Sorensen wrote:

> On Fri, Sep 10, 2021 at 01:17:02PM -0400, Gene Heskett wrote:
> > I am not aware that it ever existed. So I install the needed meat to
> > make it work, via a card reader and the non-compressed tarball is
> > just under 30 megs. apt sees it, leaves it alone. So its pinned 6
> > other packages for about 20 months now.
> >
> > Link to how to docs? I ought to check out something newer than
> > 4.19.xx
> >
> > Thanks Lennart. Take care & stay well.
>
> Well I found stuff here:
>
> https://wiki.debian.org/BuildADebianKernelPackage
>

And that link has a link to what I wanted to do, but its about 1.5 major
versions of the kernel out of date. It is for the basic 4.3, and I'm
already on an rt-preempt 4.19. Nothing earlier supports the pi's native
video, so the video you see with a 4.3 is hundreds of milliseconds
behind the machine.

5.14-rc1-rt1 was just announced on the rt list

> That mentions the bindeb-pkg and deb-pkg arguments. I am not sure
> what the difference is.

And I have neither man page. What package contains those?

[Lennart Sorensen]

On Mon, Sep 13, 2021 at 02:52:02PM -0400, Gene Heskett wrote:
> And that link has a link to what I wanted to do, but its about 1.5 major
> versions of the kernel out of date. It is for the basic 4.3, and I'm
> already on an rt-preempt 4.19. Nothing earlier supports the pi's native
> video, so the video you see with a 4.3 is hundreds of milliseconds
> behind the machine.

It mentions 4.15 as an example and says to change it to the version you
are actually building.

> 5.14-rc1-rt1 was just announced on the rt list
>
> > That mentions the bindeb-pkg and deb-pkg arguments. I am not sure
> > what the difference is.
>
> And I have neither man page. What package contains those?

They are not commands. They are make targets in the linux kernel source.
So no man pages. So just like you can do 'make menuconfig' you can do
'make bindeb-pkg' once you have done the config.

The linux kernel sources have had the ability to generate debian packages
for quite a few years now.

--
Len Sorensen

[Lennart Sorensen]

On Fri, Sep 10, 2021 at 01:04:30PM -0400, Gene Heskett wrote:
> The beaglebone is for little bitty machines with barely enough hardware
> to qualify as a cnc driver, a raspi4b can run circles around it while
> browsing the web with firefox, I have done it on that pi4b.

The arm side of the beaglebone is certainly not impressive, but the
PRU cores are potentially interesting for driving realtime hardware.
It's what they are for. Of course they are not arm cores, they use their
own instructions so one would have to write code for a TI proprietary
core that only a small number of processors support. But it does mean
you have dedicated cores designed for driving hardware without having
to share resources with the main OS. Certainly the raw arm processing
power of the Pi4 is easier to work with and more portable to other
systems in the future.

--
Len Sorensen

[Lennart Sorensen]

On Mon, Sep 13, 2021 at 03:35:44PM -0400, Lennart Sorensen wrote:
> They are not commands. They are make targets in the linux kernel source.
> So no man pages. So just like you can do 'make menuconfig' you can do
> 'make bindeb-pkg' once you have done the config.
>
> The linux kernel sources have had the ability to generate debian packages
> for quite a few years now.

~/git-trees/linux> make help|grep deb
deb-pkg - Build both source and binary deb kernel packages
bindeb-pkg - Build only the binary kernel deb package

--
Len Sorensen

[Paul Wise]

On Mon, Sep 13, 2021 at 6:07 PM Gunnar Wolf wrote:

> Please don't pay me. If you offer a good hosting solution and plan to
> keep it viable in the long run, I can be persuaded to move
> raspi.debian.net from my current hosting provider.

As an interim step, I suggest talking to the debian.net team, who can
provide VMs on a couple of cloud services, sponsored by Debian Project
funds.

https://wiki.debian.org/Teams/DebianNet

Longer-term you could move to cdimage.debian.org, which has good
bandwidth and also does torrents.

Even longer term Debian could add images to a CDN or other
distribution mechanism.

[Alan Corey]

See https://gitlab.manjaro.org/manjaro-arm/packages/community/pinebookpro-post-install/blob/master/asound.state
for a sound fix, it's just an asound.state file, delete it if it
doesn't work. There are other weirdnesses, like speaker/headphone
sound is 2 cascaded devices, and the speaker may not turn off when you
plug in headphones. I have a workaround using amixer.

#!/bin/bash
# Turn laptop speakers (always card 0) off
amixer -q -c0 cset numid=28 0 &> /dev/null

and

#!/bin/bash
# Turn laptop speakers (always card 0) on
amixer -q -c0 cset numid=28 on &> /dev/null

AFAIK nobody has suspend working.

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

[Paul Wise]

On Mon, Sep 13, 2021 at 1:57 AM Oregano wrote:

> What was the purpose of providing a makefile instead of just a PDF of slides? I already had graphviz, but all the rest took "185 MB of archives" download, and used "605 MB of additional disk space," for 1.2 MB of PDF file? Now I is a developer/builder?!

Documentation has source and build processes just like programs, and
generally only the source goes in a git repository like the salsa one
vagrant linked, the PDF would normally be distributed elsewhere, like
in a .deb binary package or attached to the talk web page.

[Arnaud Patard]

Alan Corey <alan...@gmail.com> writes:

...

>
> AFAIK nobody has suspend working.

Last time (many months ago) I've looked at suspend with mainline, some
people were patching the kernel and it was also relying on rockchip
vendor uboot and vendor atf. For instance, look at the commits in :
https://gitlab.manjaro.org/tsys/linux-pinebook-pro/-/commits/master/.

I've not looked at the rockchip code (as long as the ATF is not binary
only...), but I would not be so surprised to see that there's a
different ucode for the m0 in the ATF.

Nevertheless, I've noticed recently this commit in mainline ATF:
https://github.com/ARM-software/arm-trusted-firmware/commit/2c4b0c05c6546e24eb7209ffb3bb465d4feed164

So, maybe with that suspend is working with mainline
uboot/atf/kernel. Don't know. In case if it's working, I'm also
wondering if the power usage would be the same as the one with vendor
code.

Arnaud

[Gunnar Wolf]

Paul Wise dijo [Tue, Sep 14, 2021 at 04:23:52AM +0000]:

> On Mon, Sep 13, 2021 at 6:07 PM Gunnar Wolf wrote:
>
> > Please don't pay me. If you offer a good hosting solution and plan to
> > keep it viable in the long run, I can be persuaded to move
> > raspi.debian.net from my current hosting provider.
>
> As an interim step, I suggest talking to the debian.net team, who can
> provide VMs on a couple of cloud services, sponsored by Debian Project
> funds.
>
> https://wiki.debian.org/Teams/DebianNet
>
> Longer-term you could move to cdimage.debian.org, which has good
> bandwidth and also does torrents.

Yup - For full disclosure of something that has not yet happened, I
recently talked with Steve McIntyre, and in the next few days I'll
start looking into enabling the move to cdimage.debian.org. So, yay! \o/

[LinAdmin]

On 10.09.21 16:13, Gunnar Wolf wrote:

LinAdmin dijo [Fri, Sep 10, 2021 at 09:51:51AM +0200]:

The unnamed decision makers of Debian some unknown time ago
decided that Pi and *Pine* stuff won't be supported by Debian.

Hey, we do have names!

I am one of them. I am willing (and have done so extensively) to put
time into making Debian easy to use in the Raspberry family, but I am
convinced raspi-firmware cannot be part of Debian itself.

That's why I ensured that all of the footers in
https://raspi.debian.net/ mention that «This site is not an official
Debian project. While the maintainer (Gunnar Wolf) is a Debian
Developer, content herein provided should be considered unofficial».

Greetings,

Hi Gunnar

I very much appreciate your work for Debian and do not at all suspect integrity of your work and the software you distribute.

It also is clear that Debian can not distribute closed source firmware.

There are well established solutions in other cases like the Realtek Ethernet chips etc.

What I would like to see is that the official arm kernels automagically built by Debian could run unchanged on RaPi 32 & 64 bit.

All needed to achieve that goal is described at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981586

"All it needs to get a kernel booting on Pi4 is changing three switches in menuconfig:

CONFIG_PCIE_BRCMSTB=y

CONFIG_RESET_RASPERBERRY=y

RESET_BRCMSTB_RESCAL=y

The resulting kernel is a few KB bigger but does still boot on the other relevant hardware I own: Banana Pi & exynos board."

In that bug report you also can find the requested names of the kind people that made Debian on Rapi what it isn't today :-((


LinAdmin

[Paul Wise]

On Mon, Sep 20, 2021 at 9:19 AM LinAdmin wrote:

> What I would like to see is that the official arm kernels automagically built by Debian could run unchanged on RaPi 32 & 64 bit.

The RPi 4 is 64-bit, is there a reason for running a 32-bit Linux
kernel? (The 64-bit Linux kernel can run 32-bit userspace too).

[Gene Heskett]

On Monday 20 September 2021 09:03:39 Paul Wise wrote:

> On Mon, Sep 20, 2021 at 9:19 AM LinAdmin wrote:
> > What I would like to see is that the official arm kernels
> > automagically built by Debian could run unchanged on RaPi 32 & 64
> > bit.
>
> The RPi 4 is 64-bit, is there a reason for running a 32-bit Linux
> kernel? (The 64-bit Linux kernel can run 32-bit userspace too).

Yes it can, but slower and at higher latency's. Some apps are on the
ragged edge. CNC machinery for instance needs response to an error
condition in a few microseconds. The rpi4 can and does do ok, but its
10x slower than my i5's running 3 other machines here.

[lkcl]

On September 20, 2021 1:03:39 PM UTC, Paul Wise <pa...@debian.org> wrote:
>On Mon, Sep 20, 2021 at 9:19 AM LinAdmin wrote:
>
>> What I would like to see is that the official arm kernels
>automagically built by Debian could run unchanged on RaPi 32 & 64 bit.
>
>The RPi 4 is 64-bit, is there a reason for running a 32-bit Linux
>kernel?

yes: significantly reduced executable size, significantly reduced memory footprint, resulting in better L1/L2 cache usage with consequent power reduction.

the power consumption of the Cortex A53 compared to the Cortex A7 jumped TEN PERCENT and that is down to 64 bit executables. to compensate, ARM now recommends 50% larger L1 caches, which automatically come with an irrediemable power consumption penalty even when running 32 bit binaries.

whilst everyone is rushing headlong into 64 bit in desktop and server land, the abandonment is extremely alarming for the embedded world where power and resources really matter, and can make the difference between a failed and a successful product.

l.

[Gene Heskett]

+10 or more. For those of us who need the armhf variant its a basic
requirement.

[Paul Wise]

On Mon, 2021-09-20 at 13:39 +0000, lkcl wrote:

> significantly reduced executable size, significantly reduced memory
> footprint, resulting in better L1/L2 cache usage with consequent
> power reduction.

It sounds like you are talking about userland and Debian still supports
a 32-bit userland under a 64-bit Linux kernel on 64-bit devices, do
these concerns also apply to the Linux kernel itself?

[lkcl]

On September 21, 2021 12:06:35 AM UTC, Paul Wise <pa...@debian.org> wrote:

>It sounds like you are talking about userland and Debian still supports
>a 32-bit userland under a 64-bit Linux kernel on 64-bit devices,

which... and i apologise, i cannot remember your name, our person-running-CNC-lathes pointed out that the latency on context-switches, presumably because of conversions on system calls between 64 and 32 bit and back, is awful, and making microsecond response time barely achievable.

microsecond response... 1e6.... clock speeds 2e9... bordering on 2,000 instructions for a contextswitch and syscall, any typeconversion is apparently too much.

> do
>these concerns also apply to the Linux kernel itself?

to a lesser extent given the relative size of the linux kernel, we may surmise only the most extreme resource constrained scenarios would be concerned about that, and they're likely to be using yocto, buildroot, Zephyr or other RTOS etc. custom from-source builds.

i had forgotten about the latency issue though, and was fascinated to hear that running CNCs is so borderline.

i wonder if x86 does so much better there due to hyperthreading.

l.

[Gene Heskett]

On Tuesday 21 September 2021 01:07:20 lkcl wrote:

> On September 21, 2021 12:06:35 AM UTC, Paul Wise <pa...@debian.org>
wrote:
> >It sounds like you are talking about userland and Debian still
> > supports a 32-bit userland under a 64-bit Linux kernel on 64-bit
> > devices,
>
> which... and i apologise, i cannot remember your name, our
> person-running-CNC-lathes pointed out that the latency on
> context-switches, presumably because of conversions on system calls
> between 64 and 32 bit and back, is awful, and making microsecond
> response time barely achievable.
>
> microsecond response... 1e6.... clock speeds 2e9... bordering on 2,000
> instructions for a contextswitch and syscall, any typeconversion is
> apparently too much.
>
> > do
> >these concerns also apply to the Linux kernel itself?
>

Absolutely. And we often run kernels you consider obsolete by a decade
just because on older hardware, they run at a better performance level
than more recent versions. We generally build those kernels
independently from the distro.

Checking one of my buster based LinuxCNC iso installs,
4.19.0-17-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.194-3 (2021-07-18)
x86_64

4.19 seems to be a good one for realtime. My rpi4 is running
4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7l
I built that one myself. And since questions about realtime are not given
the grace of an answer from arm folks other than goto hell, we are
definitely on our own where arms are concerned. I had to invent my own
installer but the src tarball is under 30 megs.

> to a lesser extent given the relative size of the linux kernel, we may
> surmise only the most extreme resource constrained scenarios would be
> concerned about that, and they're likely to be using yocto, buildroot,
> Zephyr or other RTOS etc. custom from-source builds.
>
> i had forgotten about the latency issue though, and was fascinated to
> hear that running CNCs is so borderline.
>
> i wonder if x86 does so much better there due to hyperthreading.
>

No, in fact disabling that is a bios setting done before even installing
LinuxCNC. It may make winderz seem to be better, but that context
switch, done by the relatively slow bios memory is a performance killer
even if the code is stashed in L1 cache. I've 5 i5's of various builds
here, and none of them have that enabled even if its not running
machinery. This cheap 6 core i5 certainly doesn't need it and its
actually running at 800 MHz, but capable of 3.7 GHz. Close to zero heat,
all 6 cores are below 32C right now.

Take care all.

[Lennart Sorensen]

On Tue, Sep 21, 2021 at 05:00:12AM -0400, Gene Heskett wrote:
> No, in fact disabling that is a bios setting done before even installing
> LinuxCNC. It may make winderz seem to be better, but that context
> switch, done by the relatively slow bios memory is a performance killer
> even if the code is stashed in L1 cache. I've 5 i5's of various builds
> here, and none of them have that enabled even if its not running
> machinery. This cheap 6 core i5 certainly doesn't need it and its
> actually running at 800 MHz, but capable of 3.7 GHz. Close to zero heat,
> all 6 cores are below 32C right now.

The BIOS has nothing to do with context switching. Hyperthreading doesn't
even do context switching, it has two sets of registers so it can do
free context switching while the other thread is waiting for something.

Hyperthreading's only big problems are that it makes execution speed of
each thread unpredictable and since two threads are sharing a core,
it reduces the performance of single threaded code on that core.

--
Len Sorensen

[Gene Heskett]

On Tuesday 21 September 2021 07:59:42 Lennart Sorensen wrote:

I'm subbed, no need to CC: me.

> On Tue, Sep 21, 2021 at 05:00:12AM -0400, Gene Heskett wrote:
> > No, in fact disabling that is a bios setting done before even
> > installing LinuxCNC. It may make winderz seem to be better, but that
> > context switch, done by the relatively slow bios memory is a
> > performance killer even if the code is stashed in L1 cache. I've 5
> > i5's of various builds here, and none of them have that enabled even
> > if its not running machinery. This cheap 6 core i5 certainly doesn't
> > need it and its actually running at 800 MHz, but capable of 3.7 GHz.
> > Close to zero heat, all 6 cores are below 32C right now.
>
> The BIOS has nothing to do with context switching. Hyperthreading
> doesn't even do context switching, it has two sets of registers so it
> can do free context switching while the other thread is waiting for
> something.

Humph, idea borrowed from the Z-80 of the very late 70's, or possibly
from the TI 9900's, which had no registers, all in memory and it changed
context by resetting the index counter to a different address for a new
set of registers. Same idea, different execution but it worked well.

But it in 3 examples of the Z-80 in about 1981 while I was coding up an
ATS that looked like a transmitter remote control (different FCC rules)
only 1 would reliably swap registers when it read an E6 command. I paid
for two more as the warranty had expired by the time I discovered it, so
in 5 examples, I actually got two that worked. They were about $35/copy
at the time. I mistakenly thought it might have been a step up from the
first micro-controller I used to make a commercial production tool at a
tv station, an RCA 1802.

That was in 1979-80, and turned out to be so handy they were still using
it in 1995. Thats a couple eons in tv station control room gear life.
The RCA Just Worked, the Zilog not so much. I've done several other tv
production related projects since, never touched a Zilog product again.
Very bad aftertaste.

Motorola's 6809, now the smarter Hitachi 6309, a cmos workalike until we
discovered it had more registers than the moto version. A fact that
hitachi is still contractually enjoined from ever confirming the
existance of, they had permission to clone it, but never saw the moto
masks, so they microcoded it, filling up the empty spaces in the 6809
mapping. So that was my fav small cpu for 30 years.

In any event, it sure screws things up in terms of IRQ latency. The other
thing we turn off if we can is the SMS stuff, it can throw a several
millisecond monkey wrench into the gears if software stepping. Not very
often, but will leave its mark (litteraly) on the part being carved at
the time. A gear tooth out of position, which since cutting a gear tooth
is a repetitive operation, means that tooth may be narrower by .001".

> Hyperthreading's only big problems are that it makes execution speed
> of each thread unpredictable and since two threads are sharing a core,
> it reduces the performance of single threaded code on that core.

Another item that impinges on the arm speed is that the arm doesn't have
the concept, so we've been told, of "isolcpus", where a cpu core is
removed from the schedulers execution pool, and later given the job of
handling the irq's. This works well on the wintels, but not as
effectively on the AMD stuff.

My understanding is that you can isolate an arm core but cannot later
assign it a task until a powerdown reset is done. So code that can
service an irq on x86-64 in 4 microseconds, can only do it in about 12
microseconds on arm because a core to do it on has to be selected and
the context switch performed. Fireing up firefox might extend that lag
to 200 microseconds, but otherwise the worst case on the rpi4 is around
50 microseconds but it might take several minutes to record that big a
lag with the kernel I'm using. That has not been a problem with the work
I've done with it.

Is that understanding correct ?

Thanks Lennart. An interesting discussion indeed.

[Lennart Sorensen]

On Tue, Sep 21, 2021 at 11:36:51AM -0400, Gene Heskett wrote:
> Humph, idea borrowed from the Z-80 of the very late 70's, or possibly
> from the TI 9900's, which had no registers, all in memory and it changed
> context by resetting the index counter to a different address for a new
> set of registers. Same idea, different execution but it worked well.

Well those required the software to ask to change the pointer to memory
for the registers. The hyperthreading just has two sets of registers and
switches between them whenever the other thread stalls (so no delay for
any code to run to do the switch). But since to the OS it looks like 2
CPUs, the fact that the amount of clock cycles each thread gets to execute
varies, makes to a mess if you are trying to do predicable realtime.
I certainly can't imagine a real time system working right with
hyperthreading enabled.

> Another item that impinges on the arm speed is that the arm doesn't have
> the concept, so we've been told, of "isolcpus", where a cpu core is
> removed from the schedulers execution pool, and later given the job of
> handling the irq's. This works well on the wintels, but not as
> effectively on the AMD stuff.
>
> My understanding is that you can isolate an arm core but cannot later
> assign it a task until a powerdown reset is done. So code that can
> service an irq on x86-64 in 4 microseconds, can only do it in about 12
> microseconds on arm because a core to do it on has to be selected and
> the context switch performed. Fireing up firefox might extend that lag
> to 200 microseconds, but otherwise the worst case on the rpi4 is around
> 50 microseconds but it might take several minutes to record that big a
> lag with the kernel I'm using. That has not been a problem with the work
> I've done with it.
>
> Is that understanding correct ?

Well I can find people reporting that 'isolcpus' worked on RPi4, but
that core 0 was an exception and could not be isulated (since it is the
boot CPU and the isolation was done before the other cores were booted
it seemed). But it also said 'isolcpus' is deprecated and replaced by
'cpusets'

https://www.kernel.org/doc/html/v5.9/admin-guide/cgroup-v1/cpusets.html

--
Len Sorensen

[Gene Heskett]

bookmarked, that will take some study to grok how that works. Is there a
minimum kernel version?

Thank you Lennart.

[Lennart Sorensen]

On Tue, Sep 21, 2021 at 04:52:15PM -0400, Gene Heskett wrote:
> bookmarked, that will take some study to grok how that works. Is there a
> minimum kernel version?

It appears it has been around for many years. Of course features have
been added over time.

--
Len Sorensen

[Gene Heskett]

I found the man page, which may be the most uptodate writings, but the
setup still seems very complex.

And the machine it would apply to here, is running a nearly 2 yo kernel I
built, but I have no clue if that stuff is enabled in that build.

[LinAdmin]

On 10.09.21 21:40, Vagrant Cascadian wrote:

> On 2021-09-10, LinAdmin wrote:
>> The unnamed decision makers of Debian some unknown time ago
>> decided that Pi and *Pine* stuff won't be supported by Debian.

> This is the second time you've stated this, without really adding
> meaningful content to the conversation, and people have presented
> evidence to the contrary...
>
> If you don't want to help, that's fine, but please at least refrain from
> making repetative, vague statements of questionable accuracy.
>
> Debian Developers and many other contributors to Debian are in fact
> supporting these and many other platforms on Debian... They have done so
> by submitting patches, bug reports, fixes, etc. It would be difficult to
> create a comprehensive list of all of them. Check the changelogs for the
> linux kernel, u-boot, debian-installer, raspi-firmware... there are lots
> of people making decisions to support these platforms in those and even
> other packages.
>
> Specifically...
>
> There are at least five pine64.org platforms listed at:
>
> https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/
>
> I believe the same set of images is supported in the Debian bullseye
> release. At some point they worked (I personally tested each of them
> before adding support), if they don't currently work, please file bug
> reports and ideally patches if you can.
>
>
> While the Raspberry Pi can't fully be supported in Debian "main" due to
> the Debian Social Contract and the lack of compatible licenses:
>
> https://www.debian.org/social_contract
>
> There is support for the non-free firmware in "non-free" since 2019:
>
> https://tracker.debian.org/pkg/raspi-firmware
>
> More recently, you can get a UEFI implementation for pi3 and pi4:
>
> https://github.com/pftf
>
> With a UEFI implementation, you can boot the standard debian-installer
> .iso images for arm64 platforms:
>
> https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/
> or
> https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/
>
> And there are "unofficial" images made to be written directly to boot
> media produced by Debian Developers available at:
>
> https://raspi.debian.net
>
>
>
> Somewhat of an aside, I feel inclined at this point to bring up the
> Debian Community Guidelines:
>
> https://people.debian.org/~enrico/dcg/
>
> I find it has some valuable thoughts that help improve my contributions
> to Debian.
>
>
> live well,
> vagrant

So after my posting of 09-20-21 you kept silence ;)
Still wondering why precisely you brought up Debian
Community Guidelines?

And btw, not only me feels that
"Unfortunately, the Linux desktop community is very toxic.
Wars between fans of desktop environments (DEs),
distributions, package managers, package formats, etc.,
threats, personal attacks, etc. are very common in public
chat rooms and forums."
(Exctract from
https://theevilskeleton.gitlab.io/2021/04/06/why-the-linux-desktop-has-not-yet-been-adopted-by-the-masses.html
<https://theevilskeleton.gitlab.io/2021/04/06/why-the-linux-desktop-has-not-yet-been-adopted-by-the-masses.html>)

live better ;)
LinAdmin

[Andrew M.A. Cater]

On Thu, Sep 23, 2021 at 06:24:22PM +0200, LinAdmin wrote:
> On 10.09.21 21:40, Vagrant Cascadian wrote:
> > On 2021-09-10, LinAdmin wrote:
> >> The unnamed decision makers of Debian some unknown time ago
> >> decided that Pi and *Pine* stuff won't be supported by Debian.
> > This is the second time you've stated this, without really adding
> > meaningful content to the conversation, and people have presented
> > evidence to the contrary...
> >
> > If you don't want to help, that's fine, but please at least refrain from
> > making repetative, vague statements of questionable accuracy.
> >

> > Somewhat of an aside, I feel inclined at this point to bring up the
> > Debian Community Guidelines:
> >
> > https://people.debian.org/~enrico/dcg/
> >
> > I find it has some valuable thoughts that help improve my contributions
> > to Debian.
> >
> >
> > live well,
> > vagrant
>
> So after my posting of 09-20-21 you kept silence ;)
> Still wondering why precisely you brought up Debian
> Community Guidelines?
>

Dear LinAdmin

Vagrant brought up the community guidelines because he felt that you were
actually outside them, I suspect. Making accusations about Debian's
attitude to ARM support repeatedly and against the evidence provided
to the Debian developers who are actually actively engaging in ARM support
is not the most helpful approach if you want to make your point.

debian-arm is an official Debian mailing list. It's subject to the Debian
mailing list code of conduct and the main Debian code of conduct.

Your postings seem to go against:
* Be respectful
* Assume good faith
* Be collaborative

Making the point once would have been enough if you had engaged
constructively with the other participants . Repeating it hasn't helped
especially since your statement appears to be untrue.

If you look at the last paragraph of my reply at
https://lists.debian.org/debian-arm/2021/09/msg00008.html
you'll see one reason why your replies are also off-topic. This list
deals primarily with Debian: Ubuntu and other distributions are, strictly,
off topic here although those here will often try to provide points of
comparison or other help on a best endeavours basis.

> And btw, not only me feels that
> "Unfortunately, the Linux desktop community is very toxic.
> Wars between fans of desktop environments (DEs),
> distributions, package managers, package formats, etc.,
> threats, personal attacks, etc. are very common in public
> chat rooms and forums."
> (Exctract from
> https://theevilskeleton.gitlab.io/2021/04/06/why-the-linux-desktop-has-not-yet-been-adopted-by-the-masses.html
> <https://theevilskeleton.gitlab.io/2021/04/06/why-the-linux-desktop-has-not-yet-been-adopted-by-the-masses.html>)

>
> live better ;)
> LinAdmin
>
>

Andrew Cater
[For the Community Team]
>
>
>