RPI4: Why is everything still 32-bit?

[sal55]

I just bought a 64-bit RPI4 to supercede my RPI1 from 2012 or so. I wanted to port my 64-bit language tools to it.

After quite a lot of preliminary work on a PC, I then discovered that the Raspbian I was using was a 32-bit system!

I'd like to ask what the point is of selling a 64-bit machine (quad 64-bit even) when most software that goes with it is still 32-bit? I understand the RPi has been 64-bit from at least RPI3 too.

From looking around, there appear to be some half-finished 64-bit OSes. I just tried Gentoo, but compared with Raspbian (which makes the RPi4 look like a PC almost) it's rather poor. (Strange behaviour with USB drives; 'apt-get' command apparently missing).

I also had a go at Ubuntu, but the article that described the early version omitted to provide a login name and password (but that is not a GUI version, which is needed to mitigate the problem of HDMI overscanning that affects all OSes I've tried, and is completely immune to config changes or fixes).

So, any news of when a full 64-bit OS might be stable? If it's a year, fine, I'll send this RPI4 back or put it on the shelf, but I just wished this was properly advertised.

[jamesh]

It's been well publicised for some years that Raspbian is 32bit. This is for a number of reason - firstly backwards compatibility with previous models and the Pi0. We only need one distro and it runs on all devices. This means a lot less maintenance work - we are a small team. Secondly, related, we are a small team! There's quite a bit of work involved with moving the entire distro over the 64bit, including some rather tricky work on anything that talks to the GPU, which is 32bit.

That said, we now have a test 64bit kernel - search this forum for information, but this will be combined with a 32bit userland, for the reason mentioned above. - the amount of work needed to update all the libraries that talk to the GPU.

EDIT: Here's the 64bit kernel thread. https://www.raspberrypi.org/forums/view ... 9&t=250730

[Heater]

I would image that anyone capable of porting language tools would have no difficulty finding and installing a 64 bit Linux for a Pi. Even I can do it! I have been running a 64 bit Debian on Pi 3B for ages.

Gentoo is an excellent distribution. In fact I'd say that for the ability to use packages recent releases of software it is preferable to Debian/Raspbian which, understandably, tends to be rather conservative in it's updates.

Of course Gentoo has no apt-get. It has it's own packaging system.

I suggest not sending your Pi back .You can get a lot of useful mileage out of it now rather than waiting for a 64 bit Raspbian.

[epoch1970]

Ah yes, apt needs a Gentoo portage...

[LTolledo]

Raspbian is provided for FREE.... at no cost to the user.

If you want something that suits you... better find something else and pay for it.

[royhenderson]

Both Oracle and Suse offer 64bit images for the RPi - although at this point they are aimed at the RPi-3 rather than RPi-4.

However, I am reaching the conclusion that the Pi has become a victim of its own success to some degree. I think it's a brilliant solution for many situations but sometimes its primary mission and also its cost are overlooked and it receives unfair criticism with 64bit Raspbian towards the top of the list.

[Moonmarch]

Considering more Linux distributions will end the development of 32 bit operating systems people are going to ask what will happen to Raspbian, what is going to happen to all of the old computers that can't run Windows 10 or other 64 bit operating systems, that is one of the reasons why Linux is relevant to the present day 32 bit operating systems not all computers will have 8 GB of ram not all programs are required to be multi threaded not all software will use a large amount of ram, the RPI computers are priced at $35 what hardware would you expect to be included with the RPI computer, and most important what software will be compatible with the hardware.

You can view Raspbian as being a binary that runs on all RPI computer platforms should the RPI foundation form a 64 bit branch of the Raspbian OS or even consider moving towards developing a different OS, well the 64 bit OS is not ready for a public release I'm sure you can find 64 bit OS for the RPI computer on Gituhub even if a Linux OS is compatible with the RPI computer how long will the OS receive updates before the download links or websites are removed, here is a article about lightweight Linux operating systems:

Best lightweight Linux distro of 2019:
https://www.techradar.com/news/best-lig ... nux-distro

[Milliways]

One thing all of the above ignore is the stated Foundation position; no one has established a convincing use case for 64 bit.

With 1GiB RAM almost doubling code size makes no sense.

Now that the Pi4 has 4GiB RAM it may become worthwhile.

[sakaki]

From looking around, there appear to be some half-finished 64-bit OSes. I just tried Gentoo, but compared with Raspbian (which makes the RPi4 look like a PC almost) it's rather poor. (Strange behaviour with USB drives; 'apt-get' command apparently missing).

sal55,

as Heater mentions, apt-get isn't going to work on Gentoo (just as it won't on, say, Arch Linux), since Gentoo is a non-Debian-derived distro, with its own, distinct package manager (Portage). As noted in the project's readme, the cognate command (to apt-get) on Gentoo is emerge (for a useful cross-reference, please see here).

Also, please note that the Gentoo image uses a different desktop environment from Raspbian (Xfce, as opposed to LXDE), so things like automounting USB drives may behave slightly differently to the way you expect. This can easily be customized using the various control panels provided, however.

Overall though, gentoo-on-rpi-64bit is a relatively feature-complete 64-bit OS for the RPi4 (reasonable support for accelerated video, dual displays, h/w codecs, WiFi & Bluetooth, camera module, etc.), which ships with a decently full set of pre-compiled apps (LibreOffice v6.3.0.4, Firefox Quantum v68.0.2, Chromium v76.0.3809.87, Thunderbird v60.8.0, VLC v3.0.7.1, Kodi v18.0, GIMP v2.10.12 etc.) and system tools (GCC v9.2.0, Clang v8.0.1, IcedTea v3.13.0 (OpenJDK 8), Go v1.12.9, Rust v1.37.0 etc.) It has an active userbase (although a tiny fraction of Raspbian's o/c), and has seen a recent bugfix release (v1.5.1) to address problems they uncovered with the initial (v1.5.0) RPi4-compatible image. So, while it almost certainly isn't fully bug free, it's in pretty solid shape for day-to-day use.

That said, Gentoo definitely isn't for everyone. Indeed, you might want to check out my raspbian-nspawn-64 image: this uses the official 64-bit kernel jamesh alluded to above, a vanilla 32-bit 'host' Raspbian Buster userland, together with a 64-bit Debian Buster 'guest' userland (booted in a lightweight, systemd-nspawn container). Since the guest OS is Debian, you can install aarch64 apps there using the familiar 'apt-get' rubric; when so installed, launchers for them automatically get added to the host's desktop menu, to allow you to easily use them:





hth,

sakaki

[rin67630]

Considering more Linux distributions will end the development of 32 bit operating systems...

Really, Debian has such plans?

[Gavinmc42]

First time poster?
There is now more than one 64bit OS for Pis and Gentoo64 has been working for 2 years on the Pi3B's.
64bit OS's have been a bit DIY, time will fix that and there will be more Linux and other Distributions that just work.

Aarch64 OS's and "all" the software that might run on them are still to be ported from the x86 world.
Some software is clean and just recompiles(emerges) on Gentoo64 and some does not due to unported dependencies.

With Gentoo64 it does take longer to emerge stuff, but sometimes it works better than Raspbian when it does.

[ShiftPlusOne]

Considering more Linux distributions will end the development of 32 bit operating systems...

Really, Debian has such plans?

No, but some distributions have stopped making i686 images because the hardware is getting hard to come by, so it's more difficult to test. They still have the packages in the repo, because you need some of those for wine and steam. That's not related to armhf at all.

The other thing people point to is a handful of packages which have dropped 32 but support. It's possible that it may become more of a trend.

[sal55]

One thing all of the above ignore is the stated Foundation position; no one has established a convincing use case for 64 bit.

My question remains: why 64-bit processors are being used if the 64-bit instruction set (64-bit registers, 64-bit arithmetic) is not being taken advantage of.

In the PC world, it's been difficult to get hold of anything that is 32 bits for some years. So my own two languages have been based around a 64-bit 'int' for a while (most C's still have it as 32-bit). Implementing 64-bit arithmetic on 32-bit hardware is less efficient.

With 1GiB RAM almost doubling code size makes no sense.

I'm not familiar with arm64, but on x64, code size is not going to double; there might be the odd extra instruction prefix. The only thing that will double in size will be pointers (plus large arrays of int64, but if you don't need int64, you use int32; and if you do, then it will be the same on arm32).

Even there, it is possible to have a language that works with 32-bit pointers. (My first compiler for x64 did this, and gave about a 5% performance advantage, but I dropped it because it became tricky to interact with external libraries or the OS which used 64-bit pointers, especially when the top half was significant - not all 1s or 0s. But an entire OS doing this might work.)

(I haven't yet tried the 64-bit Raspbian kernel that has been mentioned; I'll have to get another microSD card. But I don't really know Linux so don't understand what will be 32-bits and what will be 64-bits. For my stuff I will need a C compiler (and later arm64 assembler) that compiles to 64-bit code that will then run, which will require suitable 64-bit libraries.

In the longer term, however, even if I get my programs working, no one else can use them unless they also have a 64-bit OS.)

[DougieLawson]

One thing all of the above ignore is the stated Foundation position; no one has established a convincing use case for 64 bit.

My question remains: why 64-bit processors are being used if the 64-bit instruction set (64-bit registers, 64-bit arithmetic) is not being taken advantage of.

You clearly missed https://www.raspberrypi.org/forums/view ... 5#p1539974
It's a question of the cost of supporting two versions of Raspbian and lack of warm bodies at Raspberry Pi Towers.

You can run the Raspberry Pi Foundation V8 kernel on later model 2Bs, 3Bs, 3B+s and 4Bs.
You can run Sakaki-san's Gentoo64 or Raspbian64 (using the RPF 64-bit kernel) on any of those.

https://github.com/sakaki-/gentoo-on-rpi3-64bit
https://www.raspberrypi.org/forums/view ... 1#p1535451

[dickon]

One thing all of the above ignore is the stated Foundation position; no one has established a convincing use case for 64 bit.

My question remains: why 64-bit processors are being used if the 64-bit instruction set (64-bit registers, 64-bit arithmetic) is not being taken advantage of.

Progress. If they hadn't, you'd be complaining they hadn't... Also, architectural improvements like OoO execution, bigger caches, and whatnot make them more performant than older, 32b-only cores.

In the PC world, it's been difficult to get hold of anything that is 32 bits for some years. So my own two languages have been based around a 64-bit 'int' for a while (most C's still have it as 32-bit). Implementing 64-bit arithmetic on 32-bit hardware is less efficient.

ILP64 is rather unusual. Most systems use LP64; IIRC Windows uses LLP64 (because, well, Microsoft. They seem to still think that a word is 16b...).

If you're being deliberately different, you should be prepared for some hoops you're likely to need to jump through.

(I haven't yet tried the 64-bit Raspbian kernel that has been mentioned; I'll have to get another microSD card. But I don't really know Linux so don't understand what will be 32-bits and what will be 64-bits. For my stuff I will need a C compiler (and later arm64 assembler) that compiles to 64-bit code that will then run, which will require suitable 64-bit libraries.

In the longer term, however, even if I get my programs working, no one else can use them unless they also have a 64-bit OS.)

64b kernel (and associated modules and whatnot), with a 32b userland. If you want a 64b userland as well, just install debian arm64 (using the Raspbian arm64 kernel, for driver support; AIUI this is being upstreamed, but these things take time) and be done with it.

[jamesh]

One thing all of the above ignore is the stated Foundation position; no one has established a convincing use case for 64 bit.

My question remains: why 64-bit processors are being used if the 64-bit instruction set (64-bit registers, 64-bit arithmetic) is not being taken advantage of.

In the PC world, it's been difficult to get hold of anything that is 32 bits for some years. So my own two languages have been based around a 64-bit 'int' for a while (most C's still have it as 32-bit). Implementing 64-bit arithmetic on 32-bit hardware is less efficient.

With 1GiB RAM almost doubling code size makes no sense.

I'm not familiar with arm64, but on x64, code size is not going to double; there might be the odd extra instruction prefix. The only thing that will double in size will be pointers (plus large arrays of int64, but if you don't need int64, you use int32; and if you do, then it will be the same on arm32).

Even there, it is possible to have a language that works with 32-bit pointers. (My first compiler for x64 did this, and gave about a 5% performance advantage, but I dropped it because it became tricky to interact with external libraries or the OS which used 64-bit pointers, especially when the top half was significant - not all 1s or 0s. But an entire OS doing this might work.)

(I haven't yet tried the 64-bit Raspbian kernel that has been mentioned; I'll have to get another microSD card. But I don't really know Linux so don't understand what will be 32-bits and what will be 64-bits. For my stuff I will need a C compiler (and later arm64 assembler) that compiles to 64-bit code that will then run, which will require suitable 64-bit libraries.

In the longer term, however, even if I get my programs working, no one else can use them unless they also have a 64-bit OS.)

Because a A72 running in 32 bit mode is still faster than an equivalent clocked A53, or any of the earlier Pi ARM cores. So it's worth moving to the 64bit chip, because they are faster even in 32bit mode.

Code size doesn't get much larger, but memory requirements do increase because pointers are now 64 bit.

[sal55]

(I haven't yet tried the 64-bit Raspbian kernel that has been mentioned; I'll have to get another microSD card. But I don't really know Linux so don't understand what will be 32-bits and what will be 64-bits. For my stuff I will need a C compiler (and later arm64 assembler) that compiles to 64-bit code that will then run, which will require suitable 64-bit libraries.

Update: I've redownloaded a normal Raspbian OS (I'd had to reuse its SD card to try other OSes), and it works as normal. (Actually, better than normal as that seems to fix the overscan problem on HDMI TVs where the display edges are off the screen.)

I tried this config.txt line from the 64-bit kernel thread: 'arm_64bit=1', but it failed to load at all. (Fortunately I could edit config.txt on a PC.) I hadn't tried 'sudo rpi-update' first since when Raspbian booted, it had already looked for latest updates. But after doing 'rpi-update', it rebooted so that 'uname -a' reports 'aarch64'.

However, 'getconf LONG_BIT' (there seem to be a million ways of testing for 32 or 64 bits; some of them work) reported '32'. But then, 'lscpu' says 'aarch64'. gcc however still compiles to 32-bits, and there doesn't seem to be a way to update it. A newly downloaded tcc said its '-m64' option was not implemented.

I don't know enough about Linux to find my way around all this. Will this kernel run a 64-bit ELF executable as a 64-bit process? Will there be a 64-bit libc_so.6 library? If so, then eventually I can wrote ELFs directly and don't need to care about anything else, but for now I need to rely on existing tools like gcc, as and tcc. So I need to try some other experimental OSes.

(In the meantime I will also try and resurrect the 32-bit C target of my compilers, but they will be implementing all-64-bit code (and some 128-bit!) on a 32-bit processor, so that is not ideal.)

[rin67630]

In the PC world, it's been difficult to get hold of anything that is 32 bits for some years.

That is just not true!
The king of desktop OSes Windows has almost 90% market share and still provides a 32 Bit version.

[rin67630]

Just remember:
The Pi is not conceived to play in the formula one ligue.
It is designed to be an education and tinkering low cost SOC based computer.
Raspbian has a policy of backward compatibility, that I hope will not be broken for a long time.
If someone uses it for power-hungry apps, it's their choice, but we should not take much advice of their needs.
You are free to install 64bit OSes on your Pi.

[sal55]

In the PC world, it's been difficult to get hold of anything that is 32 bits for some years.

That is just not true!
The king of desktop OSes Windows has almost 90% market share and still provides a 32 Bit version.

(For hardware or software? With some effort, you might be able to get a 32-bit Windows OS installed as a custom configuration, or running as a virtual OS or whatever (which doesn't help me, or anyone I'm advising, as I know nothing about that; I can only buy off-the-shelf or advise to do so). 32-bit processors I suspect are harder when buying new consumer equipment.

This was actually a serious problem as I had a number of old programs which I'd forgotten were 16-bit, as 16-bit runs under 32-bit, but not under 64 (an MS decision as x64 I believe is capable of doing so). 32-bit on 64-bit is fine.)

[rin67630]

With some effort, you might be able to get a 32-bit Windows OS installed ...

32-bit Windows installs flawlessly on current 64 bit HW.

This was actually a serious problem as I had a number of old programs which I'd forgotten were 16-bit, as 16-bit runs under 32-bit, but not under 64 (an MS decision as x64 I believe is capable of doing so). 32-bit on 64-bit is fine.)

I have a 64 bit Windows running the excellent Midisoft Studio 4 sequencer, which is 16bit, directly .
It's amazing what was done with so few resources, and storing files in 8.3 all-cap DOS format ist an interesting remembrance of the time I was young and stupid...
Anyhow you can use always a virtual XP machine with 256MB ram on virtualbox.

[sal55]

Just remember:
The Pi is not conceived to play in the formula one ligue.
It is designed to be an education and tinkering low cost SOC based computer.
Raspbian has a policy of backward compatibility, that I hope will not be broken for a long time.
If someone uses it for power-hungry apps, it's their choice, but we should not take much advice of their needs.
You are free to install 64bit OSes on your Pi.

Recent PIs have been advertised as using 64-bit processors. It seems reasonable to me that they should run 64-bit programs! In other words, if a line in a program is:

int64 a,b,c; a := b+c

then the 2 loads, 1 add, and 1 store (of a simplistic compiler) will be 4 64-bit ops, not 8 32-bit ones, nor use two extra registers. If worried about power, then using fewer instructions may need less power (I'm guessing).

AFAIK a 64-bit OS still runs 32-bit applications, so it shouldn't break backwards compatibility.

[rin67630]

It seems reasonable to me that they should run 64-bit programs!

What did you not understand with:
"It is designed to be an education and tinkering low cost SOC based computer.
Raspbian has a policy of backward compatibility..."

[sal55]

It seems reasonable to me that they should run 64-bit programs!

What did you not understand with:
"It is designed to be an education and tinkering low cost SOC based computer.

Yet that low-cost buys you a 1500MHz quad-64-bit processor with 1000-4000 MB of memory and with dozens of 64-bit registers. It is a very powerful machine (the first one I wrote compilers on and for was 2.5MHz, 8-bit with 0.016MB memory).

You're saying we shouldn't be allowed to program them in 64-bit mode? If people want to charge for those 64-bit OSes, then fine; we after all have to buy the hardware, and buy the SD cards to put the OSes on. (However, there seem to be loads of free Linuxes for PCs.)

Raspbian has a policy of backward compatibility..."

It what way would it break compatibility? Is ARM64 different from x64 in that a processor executing in 64-bit mode cannot also be running 32-bit binaries? Does it need to be all-32-bit or all-64-bit for every piece of software?

I can understand that if it switched to a different processor altogether there would be a problem!

[jamesh]

AFAIK a 64-bit OS still runs 32-bit applications, so it shouldn't break backwards compatibility.

Wrong sort of backwards compatibility. We need the OS to work on ALL version of the Pi, including the ones with 32bit cores. A 64 bit kernel will not run on a 32 bit core.

64 bit is coming. Meanwhile, 32 bit works for the vast majority of users. Like, 99.99999% of them.

And there is no reason why code should not be compilable on 32 or 64 bit machines. Just write architecture independent code, make no assumptions about int (assuming C) or pointer size. Not difficult unless you are writing assembler, which is mostly unnecessary nowadays given the strength of compilers.