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.
I'm typing on one of my trusty Raspberry Pi 3B machines which I set up
with Debian armhf
Hi Alan,
On Sat, Apr 01, 2023 at 09:01:42PM -0400, Alan Corey wrote:
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.
ema@raspi:~
$ sudo dmesg | grep 'Machine model'
[ 0.000000] Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
ema@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
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.
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.
On Sun, Apr 02, 2023 at 09:51:23PM -0400, Alan Corey wrote:
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
On Sun, Apr 02, 2023 at 09:51:23PM -0400, Alan Corey wrote:
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.
On Sun, Apr 02, 2023 at 09:51:23PM -0400, Alan Corey wrote:
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.
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.
On 03/04/2023 12:56, Lennart Sorensen wrote:
On Sun, Apr 02, 2023 at 09:51:23PM -0400, Alan Corey wrote:
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 491 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 99:35:10 |
| Calls: | 9,681 |
| Calls today: | 2 |
| Files: | 13,725 |
| Messages: | 6,174,732 |