Looking for an armhf install image

[Alan Corey]

I'm typing on one of my trusty Raspberry Pi 3B machines which I set up
with Debian armhf about a year ago and forgot how I did it. A couple
evenings spent searching and downloading got me nowhere so I thought
I'd ask here since it's Debian arm. At one point there were images
requiring you to concatenate 2 parts to create the image then boot
from that, that may be what I'm running. I just want to make more of
these. The uname I get here is Linux upstairs 5.10.0-15-armmp #1 SMP
Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux

armmp? I thought it was just armhf Bullseye is fine, I want something stable.

Alan Corey

[Alan Corey]

Never mind, I'm just looking at
https://raspi.debian.net/tested-images/ which is about what I'm
looking for. I also found a complete(?) set of raspbian archives back
to 2012 at http://downloads.raspberrypi.org/raspbian/images/

Post by Alan Corey
I'm typing on one of my trusty Raspberry Pi 3B machines which I set up
with Debian armhf about a year ago and forgot how I did it. A couple
evenings spent searching and downloading got me nowhere so I thought
I'd ask here since it's Debian arm. At one point there were images
requiring you to concatenate 2 parts to create the image then boot
from that, that may be what I'm running. I just want to make more of
these. The uname I get here is Linux upstairs 5.10.0-15-armmp #1 SMP
Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux
armmp? I thought it was just armhf Bullseye is fine, I want something stable.
Alan Corey
--
-------------
Education is contagious.

[Emanuele Rocca]

Hi Alan,

Post by Alan Corey
I'm typing on one of my trusty Raspberry Pi 3B machines which I set up
with Debian armhf

The Raspberry Pi 3 has a 64-bit CPU, you can install Debian arm64 instead of
armhf on it.

***@raspi:~
$ sudo dmesg | grep 'Machine model'
[ 0.000000] Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
***@raspi:~
$ lscpu | head
Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: ARM
Model name: Cortex-A53
Model: 4
Thread(s) per core: 1

[Alan Corey]

I know I can but it will be twice as slow, which is why I want armhf.
Under 64 bit both the data and pointers will be twice as big. With
unlimited memory that would be OK but a Pi CPU can only access 1 GB.
I've tried 64 bit.

Post by Emanuele Rocca
Hi Alan,

Post by Alan Corey
I'm typing on one of my trusty Raspberry Pi 3B machines which I set up
with Debian armhf

The Raspberry Pi 3 has a 64-bit CPU, you can install Debian arm64 instead of
armhf on it.
$ sudo dmesg | grep 'Machine model'
[ 0.000000] Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
$ lscpu | head
Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: ARM
Model name: Cortex-A53
Model: 4
Thread(s) per core: 1

[Diederik de Haas]

Post by Alan Corey
I know I can but it will be twice as slow, which is why I want armhf.
Under 64 bit both the data and pointers will be twice as big. With
unlimited memory that would be OK but a Pi CPU can only access 1 GB.
I've tried 64 bit.

For the RPi 3 Debian only supports the 64bit kernel, thus arm64.

[Lennart Sorensen]

Post by Alan Corey
I know I can but it will be twice as slow, which is why I want armhf.
Under 64 bit both the data and pointers will be twice as big. With
unlimited memory that would be OK but a Pi CPU can only access 1 GB.
I've tried 64 bit.

It's certainly a balance trade off. The pointers will be twice as large.
The data will be whatever size the code asked for. Only in the case that
the code asked to use a long will be be 32 bit in one case and 64 bit
in the other case. Most code isn't that sloppy about their data types.

In terms of actual code, apparently the A53 core runs 64 bit code about
20% faster than 32 bit code, so it comes down to whether you are doing
execution heavy or data heavy work.

[Alan Corey]

Well, somewhere I got this and I like it, I'd like to have more. On a Pi 3b:

Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Vendor ID: ARM
Model: 4
Model name: Cortex-A53
Stepping: r0p4
CPU max MHz: 1200.0000
CPU min MHz: 600.0000
BogoMIPS: 51.20
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: half thumb fastmult vfp edsp neon
vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

Post by Lennart Sorensen

Post by Alan Corey
I know I can but it will be twice as slow, which is why I want armhf.
Under 64 bit both the data and pointers will be twice as big. With
unlimited memory that would be OK but a Pi CPU can only access 1 GB.
I've tried 64 bit.

It's certainly a balance trade off. The pointers will be twice as large.
The data will be whatever size the code asked for. Only in the case that
the code asked to use a long will be be 32 bit in one case and 64 bit
in the other case. Most code isn't that sloppy about their data types.
In terms of actual code, apparently the A53 core runs 64 bit code about
20% faster than 32 bit code, so it comes down to whether you are doing
execution heavy or data heavy work.
--
Len Sorensen

[Jeffrey Walton]

On Mon, Apr 3, 2023 at 8:03 AM Lennart Sorensen

Post by Lennart Sorensen

Post by Alan Corey
I know I can but it will be twice as slow, which is why I want armhf.
Under 64 bit both the data and pointers will be twice as big. With
unlimited memory that would be OK but a Pi CPU can only access 1 GB.
I've tried 64 bit.

It's certainly a balance trade off. The pointers will be twice as large.
The data will be whatever size the code asked for. Only in the case that
the code asked to use a long will be be 32 bit in one case and 64 bit
in the other case. Most code isn't that sloppy about their data types.
In terms of actual code, apparently the A53 core runs 64 bit code about
20% faster than 32 bit code, so it comes down to whether you are doing
execution heavy or data heavy work.

There's one exception to 64-bit speedups that I am aware of. On A-57's
in 64 bit mode, ASIMD (formerly NEON) shifts used to be awful slow. It
was measurable. I'm not sure if it is still the case. See, for
example, http://github.com/weidai11/cryptopp/issues/367 .

It is better to use the integer units instead of the SIMD unit for
shifts in 64-bit mode.

Jeff

[Tim Small]

I could be wrong, but I also thought that processor errata
fixes/workarounds for 64 bit capable ARM processors are only
(consistently) applied to the 64 bit kernel.

i.e. if you run a 64-bit-capable ARM processor such as the A53 with a
32-bit Linux kernel, then you might hit unpatched processor errata,
whereas wouldn't be vulnerable to those when running a 64-bit Linux kernel.

Now it may well be that for a widely used machine like the Pi 3, that
the errata fixes for the A53 core have made it into the 32 bit kernel
anyway.

In the more general case, running a 32 bit user space with a 64 bit
kernel might be an option?

Tim.

Post by Lennart Sorensen

Post by Alan Corey
I know I can but it will be twice as slow, which is why I want armhf.
Under 64 bit both the data and pointers will be twice as big. With
unlimited memory that would be OK but a Pi CPU can only access 1 GB.
I've tried 64 bit.

It's certainly a balance trade off. The pointers will be twice as large.
The data will be whatever size the code asked for. Only in the case that
the code asked to use a long will be be 32 bit in one case and 64 bit
in the other case. Most code isn't that sloppy about their data types.
In terms of actual code, apparently the A53 core runs 64 bit code about
20% faster than 32 bit code, so it comes down to whether you are doing
execution heavy or data heavy work.

[Alan Corey]

I'm not sure exactly how debootstrap works but it seems to let me set
up an armhf install, and running file on the resulting /bin/bash shows
it's 32-bit. I get a good chroot simulating a drive but it doesn't
boot yet. It's 263 MB and I copied it with cp -ar to a blank SD card.

For whatever reason I'm talking about the same issue in the thread at
https://forums.debian.net/viewtopic.php?p=770867#p770867

Post by Tim Small
I could be wrong, but I also thought that processor errata
fixes/workarounds for 64 bit capable ARM processors are only
(consistently) applied to the 64 bit kernel.
i.e. if you run a 64-bit-capable ARM processor such as the A53 with a
32-bit Linux kernel, then you might hit unpatched processor errata,
whereas wouldn't be vulnerable to those when running a 64-bit Linux kernel.
Now it may well be that for a widely used machine like the Pi 3, that
the errata fixes for the A53 core have made it into the 32 bit kernel
anyway.
In the more general case, running a 32 bit user space with a 64 bit
kernel might be an option?
Tim.

Post by Lennart Sorensen

Post by Alan Corey
I know I can but it will be twice as slow, which is why I want armhf.
Under 64 bit both the data and pointers will be twice as big. With
unlimited memory that would be OK but a Pi CPU can only access 1 GB.
I've tried 64 bit.

It's certainly a balance trade off. The pointers will be twice as large.
The data will be whatever size the code asked for. Only in the case that
the code asked to use a long will be be 32 bit in one case and 64 bit
in the other case. Most code isn't that sloppy about their data types.
In terms of actual code, apparently the A53 core runs 64 bit code about
20% faster than 32 bit code, so it comes down to whether you are doing
execution heavy or data heavy work.