Discussion:
where, besides raspian can I find a full armhf installer that works on an rpi4b?
(too old to reply)
gene heskett
2022-01-24 01:30:01 UTC
Permalink
I thought I had some cornered earlier today, but when written to u-sd
and booted, were arm64.

For low latency reasons when a realtime kernel is installed it must be
for armhf.

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, 1940)
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>
Andrei POPESCU
2022-01-24 19:00:02 UTC
Permalink
Post by gene heskett
I thought I had some cornered earlier today, but when written to u-sd
and booted, were arm64.
For low latency reasons when a realtime kernel is installed it must be
for armhf.
Disclaimer: I don't know much about the RPi4b, take below with a big
grain of salt.


This wiki https://wiki.debian.org/RaspberryPi4#Booting_from_USB indeed
mentions only ARM64 images, but it also suggests recent devices can boot
from USB, in which case you might want to try images from here:

https://www.debian.org/devel/debian-installer/


Another alternative might be to take the YAML spec files for vmdb from
here and tweak to use armhf instead of arm64:

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

(could be as easy as replacing 'arch: arm64' with 'arch: armhf' in the
qemu-debootstrap step)

Hope this helps,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
gene heskett
2022-01-24 20:40:02 UTC
Permalink
Post by Andrei POPESCU
Post by gene heskett
I thought I had some cornered earlier today, but when written to u-sd
and booted, were arm64.
For low latency reasons when a realtime kernel is installed it must be
for armhf.
Disclaimer: I don't know much about the RPi4b, take below with a big
grain of salt.
This wiki https://wiki.debian.org/RaspberryPi4#Booting_from_USB indeed
mentions only ARM64 images, but it also suggests recent devices can
https://www.debian.org/devel/debian-installer/
I found at a link from the above page, a testing iso in armhf flavor.
If it boots, i'll test install the kernel being built. This I think is
progress, or at least educational.
Post by Andrei POPESCU
Another alternative might be to take the YAML spec files for vmdb from
https://raspi.debian.net/daily-images/
(could be as easy as replacing 'arch: arm64' with 'arch: armhf' in the
qemu-debootstrap step)
Hope this helps,
It may be, thanks Andrei.
Post by Andrei POPESCU
Andrei
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, 1940)
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>
gene heskett
2022-01-26 00:00:01 UTC
Permalink
Post by Andrei POPESCU
Post by gene heskett
I thought I had some cornered earlier today, but when written to u-sd
and booted, were arm64.
For low latency reasons when a realtime kernel is installed it must be
for armhf.
Disclaimer: I don't know much about the RPi4b, take below with a big
grain of salt.
This wiki https://wiki.debian.org/RaspberryPi4#Booting_from_USB indeed
mentions only ARM64 images, but it also suggests recent devices can
https://www.debian.org/devel/debian-installer/
Another alternative might be to take the YAML spec files for vmdb from
https://raspi.debian.net/daily-images/
(could be as easy as replacing 'arch: arm64' with 'arch: armhf' in the
qemu-debootstrap step)
I have looked at some of that, seems stuck on arm64. Pass the salt ;o)

I'm about halfway thru building a 5.16.2-rt19 kernel7l right now on the
rpi4. Maybe that will work. That is about as bleeding edge as can be
built right now. But I see it building modules it will never use on a pi.
So I need to run menuconfig and turn a bunch of that stuff off.
Post by Andrei POPESCU
Hope this helps,
Andrei
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, 1940)
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>
LinAdmin
2022-01-25 17:30:04 UTC
Permalink
When on 16 Mar 2021 I gave the solution in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981586

I was told from the omnipotent gurus of Debian that nobody
needs 32 Bit and the bug was closed.

After that, everybody requiring 32 Bit went with Ubuntu 20.4
LTS which is not as stubborn as Debian.

LinAdmin
Post by gene heskett
I thought I had some cornered earlier today, but when written to u-sd
and booted, were arm64.
For low latency reasons when a realtime kernel is installed it must be
for armhf.
Cheers, Gene Heskett.
Andrew M.A. Cater
2022-01-25 18:30:02 UTC
Permalink
Post by LinAdmin
When on 16 Mar 2021 I gave the solution in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981586
I was told from the omnipotent gurus of Debian that nobody needs 32 Bit and
the bug was closed.
After that, everybody requiring 32 Bit went with Ubuntu 20.4 LTS which is
not as stubborn as Debian.
No - not quite. That's not what the bug history says. You will find that
Ubuntu isn't supported on all Pi models, for example, but only on later
models that are ARMv7. In general, people are opting for 64 bit for Pi 3 and
Pi 4 - see also Fedora.

If you actually talk to the people doing the work, you often find the reasons
why - they're not all "omnipotent gurus" and they're generally approachable.

As it stands today, we can't support the Raspberry Pi (at any version) with
an official Debian installer because of the method of booting and the need
for non-free firmware. There's a good port for UEFI - and that's what
Fedora is also using, for example - but the need for non-free firmware
persists.
Post by LinAdmin
LinAdmin
Post by gene heskett
I thought I had some cornered earlier today, but when written to u-sd
and booted, were arm64.
For low latency reasons when a realtime kernel is installed it must be
for armhf.
Cheers, Gene Heskett.
?? Why must it be armhf - a Pi 4 is massively faster/more capable than
a Pi 1 ?? Could you explain what difference 32 bitness makes?

All the very best, as ever,

Andy Cater
gene heskett
2022-01-25 19:50:01 UTC
Permalink
Post by Andrew M.A. Cater
Post by LinAdmin
When on 16 Mar 2021 I gave the solution in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981586
I was told from the omnipotent gurus of Debian that nobody needs 32
Bit and the bug was closed.
After that, everybody requiring 32 Bit went with Ubuntu 20.4 LTS
which is not as stubborn as Debian.
No - not quite. That's not what the bug history says. You will find
that Ubuntu isn't supported on all Pi models, for example, but only on
later models that are ARMv7. In general, people are opting for 64 bit
for Pi 3 and Pi 4 - see also Fedora.
If you actually talk to the people doing the work, you often find the
reasons why - they're not all "omnipotent gurus" and they're generally
approachable.
As it stands today, we can't support the Raspberry Pi (at any version)
with an official Debian installer because of the method of booting and
the need for non-free firmware. There's a good port for UEFI - and
that's what Fedora is also using, for example - but the need for
non-free firmware persists.
Post by LinAdmin
LinAdmin
Post by gene heskett
I thought I had some cornered earlier today, but when written to u-sd
and booted, were arm64.
For low latency reasons when a realtime kernel is installed it must be
for armhf.
Cheers, Gene Heskett.
?? Why must it be armhf - a Pi 4 is massively faster/more capable than
a Pi 1 ?? Could you explain what difference 32 bitness makes?
Simple Andy, and has been explained many times. The bigger stack frame of
arm64 negatively impacts the IRQ latency, making the response to an IRQ
take several microseconds longer. Running a fully preempt-rt kernel on an
i5 can get that time down to 4 u-secs unless you're running something
that needs the nvidia proprietary video driver, which can tie things up
with the irq's locked out for 3+ milliseconds. That's a full showstopper.

On armhf, on a 2gig rpi4b, a kernel I built,

4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7l
GNU/Linux,

almost 2 years ago makes about 12 microseconds which is fast enough to
run over half a ton of 75 yo sheldon lathe I rebuilt for cnc control. The
Linuxcnc latency-test won't even run on an arm64 because the realtime irq
capability isn't there, and when measured by other means can be 100
microseconds worse. That's valuable time lost that will manifest itself
in machine crashes that break expensive tooling. Even the half your
little fingernail sized carbide chips that tip our cutting tools cost $20
or more a copy if we buy the better stuff.

The guys that inhabit the linux-rt list are putting a lot of what they've
learned back into the regular linux kernel, with the future target being
capable of doing this reatime work, but its not all done yet. And its a
heck of a lot faster now than it was at 2.2 because of this, despite the
line count being multiplied by 4 or more since then.

It is Linus's stated target that this happens.

But there is a lot of work yet to be done too, lots of legacy code that
needs re-written to take advantage of what has been learned.

We are the folks who if we want music while we work, will find a radio
and turn it on. Its a different environment for sure but in the long
view it will come together.

We are the unreasonable people G. B. Shaw wrote about when he said all
progress is made by unreasonable people, reasonable folks adapt to the
status quo and get on with it even when things are not optimal.
Post by Andrew M.A. Cater
All the very best, as ever,
To you too Andy, take care and stay well, all of you reading this to see
what trash talk Gene is spewing today.
Post by Andrew M.A. Cater
Andy Cater
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, 1940)
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>
gene heskett
2022-01-25 22:40:01 UTC
Permalink
Post by gene heskett
Post by Andrew M.A. Cater
Post by LinAdmin
When on 16 Mar 2021 I gave the solution in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981586
I was told from the omnipotent gurus of Debian that nobody needs 32
Bit and the bug was closed.
After that, everybody requiring 32 Bit went with Ubuntu 20.4 LTS
which is not as stubborn as Debian.
No - not quite. That's not what the bug history says. You will find
that Ubuntu isn't supported on all Pi models, for example, but only on
later models that are ARMv7. In general, people are opting for 64 bit
for Pi 3 and Pi 4 - see also Fedora.
If you actually talk to the people doing the work, you often find the
reasons why - they're not all "omnipotent gurus" and they're
generally
approachable.
As it stands today, we can't support the Raspberry Pi (at any version)
with an official Debian installer because of the method of booting and
the need for non-free firmware. There's a good port for UEFI - and
that's what Fedora is also using, for example - but the need for
non-free firmware persists.
Post by LinAdmin
LinAdmin
Post by gene heskett
I thought I had some cornered earlier today, but when written to u-sd
and booted, were arm64.
For low latency reasons when a realtime kernel is installed it
must
be
for armhf.
Cheers, Gene Heskett.
?? Why must it be armhf - a Pi 4 is massively faster/more capable than
a Pi 1 ?? Could you explain what difference 32 bitness makes?
Simple Andy, and has been explained many times. The bigger stack frame
of arm64 negatively impacts the IRQ latency, making the response to an
IRQ take several microseconds longer. Running a fully preempt-rt
kernel on an i5 can get that time down to 4 u-secs unless you're
running something that needs the nvidia proprietary video driver,
which can tie things up with the irq's locked out for 3+ milliseconds.
That's a full showstopper.
On armhf, on a 2gig rpi4b, a kernel I built,
4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7l
GNU/Linux,
almost 2 years ago makes about 12 microseconds which is fast enough to
run over half a ton of 75 yo sheldon lathe I rebuilt for cnc control.
The Linuxcnc latency-test won't even run on an arm64 because the
realtime irq capability isn't there, and when measured by other means
can be 100 microseconds worse. That's valuable time lost that will
manifest itself in machine crashes that break expensive tooling. Even
the half your little fingernail sized carbide chips that tip our
cutting tools cost $20 or more a copy if we buy the better stuff.
The guys that inhabit the linux-rt list are putting a lot of what
they've learned back into the regular linux kernel, with the future
target being capable of doing this reatime work, but its not all done
yet. And its a heck of a lot faster now than it was at 2.2 because of
this, despite the line count being multiplied by 4 or more since then.
It is Linus's stated target that this happens.
But there is a lot of work yet to be done too, lots of legacy code that
needs re-written to take advantage of what has been learned.
We are the folks who if we want music while we work, will find a radio
and turn it on. Its a different environment for sure but in the long
view it will come together.
We are the unreasonable people G. B. Shaw wrote about when he said all
progress is made by unreasonable people, reasonable folks adapt to the
status quo and get on with it even when things are not optimal.
Post by Andrew M.A. Cater
All the very best, as ever,
To you too Andy, take care and stay well, all of you reading this to
see what trash talk Gene is spewing today.
Post by Andrew M.A. Cater
Andy Cater
Cheers, Gene Heskett.
FWIW, I unpacked a fresh 64G u-sd card, wrote the 20211030 raspian
bullseye armhf.img install to it. Then mounted it and edited
/etc/dhcpdcp.conf to fill in the fallback data at the bottom of that file
and wrote my hosts file over what was there, and edited hostname to name
it.

Placed the card in my pi and powered it up, skipping the wifi discovery.
It is now in the midst of installing about 130 updates since that release
was spun. So the fix is now published. When that gets done, I'll mount
my work drive and see if I can install the newly built realtime kernel.

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, 1940)
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>
Loading...