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!
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.
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
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.
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.
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
At $45 with 3GB RAM, optional eMMC (35 for 64 GB), WiFi, etc., it seemsinteresting, 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!
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
On 2021-09-04, LinAdmin wrote:I wish I had known that 2 years ago, I bought a couple rock64's but all I
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
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.
(...)
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.
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
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.
Whatever floats your boat.
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].
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.
Hi Reco,
On 2021.09.07 10:42, Reco wrote:
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.
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.
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 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.
But still, if [1] haven't stalled - all this discussion we're having
today would be pointless.
[1] https://github.com/christinaa/rpi-open-firmware
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.
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.
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.
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,
But this hypothetical addon looks user-modifiable to me, so ... see
above.
I agree that using a separate media would be a viable workaround in this
case
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.
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.
On September 7, 2021 4:16:27 PM UTC, Pete Batard <pete@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 orequivalent 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 DebianDevelopers will not find themselves in the situation of being legally liable for distribution of potentially dangerous firmware.
i am ESPECIALLY getting fed up of people not fully and properly understanding the realities of the situation
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.
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.
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.
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...
On September 9, 2021 4:17:08 PM UTC, Vagrant Cascadian <vagrant@debian.org> wrote: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.
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
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 timesat 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 ownface.
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 peopleon this list feel miserable and underappreciated for the work that they do. unpaid.
l.
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
[...]
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.
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.
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,
"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 orincentive, which would result in a contractual or moral obligation where both parties satisfactorily get what they want]
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
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,
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!
Hi.
On Sat, Sep 04, 2021 at 09:51:30AM +0200, LinAdmin wrote:
The unnamed decision makers of Debian some unknown time agoExcept that Raspberry Pis are supported by Debian.
decided that Pi and Pine stuff won't be 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
I have some doubts that debian.net has the same ownership
than official debian.org?
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
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.
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.
The unnamed decision makers of Debian some unknown time ago
decided that Pi and *Pine* stuff won't be supported by Debian.
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
So why do we not have a .deb builder for kernels.?
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.
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_Usin
gBeagleBoneRealTimeMicrocontrollers.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.
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.
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
The unnamed decision makers of Debian some unknown time ago
decided that Pi and *Pine* stuff won't be supported by Debian.
...
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
Kind regards,
Andrei -- happy Debian user of a PINE A64+ and (still) considering
the Pinebook Pro for my next laptop
On Tue, 7 Sep 2021 10:01:49 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:
There's an interesting review of the Pro here:Kind regards,
Andrei -- happy Debian user of a PINE A64+ and (still) considering
the Pinebook Pro for my next laptop
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.bainbridge.3216@gmail.com
0447 667 468
On Tue, 7 Sep 2021 10:01:49 +0300
Andrei POPESCU <andreimpopescu@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.bainbridge.3216@gmail.com
0447 667 468
On 9/11/21 1:11 AM, Keith Bainbridge wrote:
On Tue, 7 Sep 2021 10:01:49 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:
There's an interesting review of the Pro here:Kind regards,
Andrei -- happy Debian user of a PINE A64+ and (still) considering
the Pinebook Pro for my next laptop
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
On Sb, 11 sep 21, 04:30:21, Peter Ehlert wrote:I have done nothing yet, I do plan to try "soon".
On 9/11/21 1:11 AM, Keith Bainbridge wrote:They've had some supply issues, possibly solved soon, the monthly
On Tue, 7 Sep 2021 10:01:49 +0300good review, thanks
Andrei POPESCU <andreimpopescu@gmail.com> wrote:
There's an interesting review of the Pro here:Kind regards,
Andrei -- happy Debian user of a PINE A64+ and (still) considering
the Pinebook Pro for my next laptop
https://www.jeremymorgan.com/blog/linux/90-days-with-pinebook-pro/
Sounds interesting. Pity they are out of stock
newsletter has more information on that.
I think I got the very last one in old stock: ordered on June 8, 2021What issues did you encounter with using the Debian Installer?
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
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
On 9/11/21 1:11 AM, Keith Bainbridge wrote:
On Tue, 7 Sep 2021 10:01:49 +0300
Andrei POPESCU <andreimpopescu@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.bainbridge.3216@gmail.com
0447 667 468
On 9/11/21 1:11 AM, Keith Bainbridge wrote:...
On Tue, 7 Sep 2021 10:01:49 +0300
Andrei POPESCU <andreimpopescu@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.
September 11, 2021 11:30 AM, "Peter Ehlert" <pb21a@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...
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.
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.
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.
... 100 microseconds as the output of the linux-rt list get adopted into shipping kernels. That is its target, to become the default kernel.
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.
It night "sound interesting" if it had sound, but thats the quietest
movie I've watched in months. No audio buttons to be found.
...
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 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.
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
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].
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.
September 12, 2021 3:19 AM, "Gunnar Wolf" <gwolf@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.
I was not trying to insult you because of your host choice.
Rather to give you feedback from my experience.
out three to five times minimum before displaying, which takes several >minutes. You're free to take the feedback or ignore it.
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 <andreimpopescu@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 driverI gave a talk (that had some glitches...) at DebConf21 which has bits
lurking here for tips on how to get Debian running on it.
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
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 <andreimpopescu@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
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.
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?
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"
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]
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.
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.
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?
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.
September 11, 2021 9:19 PM, "Vagrant Cascadian" <vagrant@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 <andreimpopescu@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?!
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?!
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.
AFAIK nobody has suspend working.
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.
LinAdmin dijo [Fri, Sep 10, 2021 at 09:51:51AM +0200]:
The unnamed decision makers of Debian some unknown time agoHey, we do have names!
decided that Pi and *Pine* stuff won't be supported by Debian.
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,
What I would like to see is that the official arm kernels automagically built by Debian could run unchanged on RaPi 32 & 64 bit.
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).
On Mon, Sep 20, 2021 at 9:19 AM LinAdmin wrote:
What I would like to see is that the official arm kernelsautomagically 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?
On September 20, 2021 1:03:39 PM UTC, Paul Wise <pabs@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.
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?
On September 21, 2021 12:06:35 AM UTC, Paul Wise <pabs@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.
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.
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.
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".
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 ?
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.
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".
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.htm
l
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.
bookmarked, that will take some study to grok how that works. Is there a minimum kernel version?
On 2021-09-10, LinAdmin wrote:
The unnamed decision makers of Debian some unknown time agoThis is the second time you've stated this, without really adding
decided that Pi and *Pine* stuff won't be supported by Debian.
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
On 10.09.21 21:40, Vagrant Cascadian wrote:
On 2021-09-10, LinAdmin wrote:
The unnamed decision makers of Debian some unknown time agoThis is the second time you've stated this, without really adding meaningful content to the conversation, and people have presented
decided that Pi and *Pine* stuff won't be supported by Debian.
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?
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
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...
...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.
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."
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/
PS. Sadly, your personal site/blog times out, and requires retries to eventually appear.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 56:13:45 |
| Calls: | 6,652 |
| Calls today: | 4 |
| Files: | 12,200 |
| Messages: | 5,330,867 |