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 On 4/4/23, Tim Small <t...@buttersideup.com> wrote: > 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. >> > -- ------------- Education is contagious.
