Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[gene heskett]

On Monday, January 24, 2022 1:50:55 PM EST Andrei POPESCU wrote:
> On Du, 23 ian 22, 20:23:18, gene heskett wrote:
> > 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)

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.

> 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 

Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[gene heskett]

On Tuesday, January 25, 2022 2:41:22 PM EST gene heskett wrote:
> On Tuesday, January 25, 2022 1:26:39 PM EST Andrew M.A. Cater wrote:
> > On Tue, Jan 25, 2022 at 06:17:16PM +0100, LinAdmin wrote:
> > > 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.
> > 
> > > LinAdmin
> > > 
> > > On 24.01.22 02:23, gene heskett wrote:
> > > > 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.
> 
> > 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.
> 
> > 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 

Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[gene heskett]

On Tuesday, January 25, 2022 1:26:39 PM EST Andrew M.A. Cater wrote:
> On Tue, Jan 25, 2022 at 06:17:16PM +0100, LinAdmin wrote:
> > 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.
> 
> > LinAdmin
> > 
> > On 24.01.22 02:23, gene heskett wrote:
> > > 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.

> 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.
> 
> 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 

Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[Andrew M.A. Cater]

On Tue, Jan 25, 2022 at 06:17:16PM +0100, LinAdmin wrote:
> 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.
 
> LinAdmin
> 
> On 24.01.22 02:23, gene heskett wrote:
> > 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
 

Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[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.


LinAdmin

On 24.01.22 02:23, gene heskett wrote:

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.

Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[gene heskett]

On Monday, January 24, 2022 1:50:55 PM EST Andrei POPESCU wrote:
> On Du, 23 ian 22, 20:23:18, gene heskett wrote:
> > 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/
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.
> 
> 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,

It may be, thanks Andrei.

> 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 

Re: where, besides raspian can I find a full armhf installer that works on an rpi4b?

[Andrei POPESCU]

On Du, 23 ian 22, 20:23:18, gene heskett wrote:
> 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


signature.asc
Description: PGP signature