64-bit operating system

[sakaki]

richlion2,

If you just want to try something out quickly, my bootable gentoo-on-rpi3-64bit image (the one Gavinmc42 refers to) is downloadable from GitHub - please see the project page (with full instructions) here (thanks to procount, it's also available via PINN, under the name "Gentoo64", should you prefer that route).

It is Gentoo, but the image boots directly to an Xfce4 desktop, and contains a reasonable precompiled userland package set (LibreOffice 6.0.2, Firefox Quantum 58.0.1, VLC 2.2.8, GIMP 2.9.8 etc), so you don't have to compile or configure anything just to get going. VC4 GL rendering support is provided, and the RPi3's Bluetooth, sound and WiFi (dual band on the RPi3+) are supported too. The project is backed by a weekly-autobuild "binhost" - so you can (should you choose) keep your system up-to-date via binary packages, rather than building updates from source.

Of course, when you do feel like building things, gcc 7.3 (with distcc support, should you want that), a full dev library set, and clang 6 are included on the image too ^-^

However, if you'd rather create a 64-bit Gentoo system from scratch for the RPi3, please see my Gentoo Forums post here, which has links to the relevant wiki pages etc. (in particular, see NeddySeagoon's excellent guide).

hth, any problems just ask (either here, or you can post in the project's sticky thread on the Gentoo forum; we don't bite!)

sakaki

(Edit: apologies Gavinmc42, just noticed you already answered this while I was typing ><)

[sakaki]

If you are running the v1.2.1 gentoo-on-rpi3-64bit image, and having trouble with the LAN7515 on your RPi3B+, I've just pushed a new binary kernel package, which contains some fixes.

To get it, open a terminal, become root (default password: raspberrypi64) and issue:

Code: Select all

pi64 ~ # emaint sync --repo rpi3
pi64 ~ # emerge --update --verbose bcmrpi3-kernel-bin

Let the emerge command run to completion (it should take no more than 15 minutes), then reboot your rpi3 (B or B+).

You should then be using the updated kernel! Check by running "uname -r" - it should return "4.14.33-v8-0a76b56e61cf+".

sakaki

PS Ethernet on the shipped v1.2.1 image actually seems reasonably usable on the RPi3 B+, so you should be able to do the above upgrade on a B+ via a wired connection, if this is only option available to you. If you only want to play with the image, there's no need to worry about this upgrade either.

[vinnieb]

Finally had some time to explore a 64 bit build a bit more - I took a build from here https://github.com/Crazyhead90/pi64/rel ... 2018-04-17 as was only one I could easily find with 64bit kernel+user land for Pi 3B+.

I've been interested for a while why some OpenCV functions are a bit slow on the Pi as it doesn't feel linearly related to raw CPU speed difference. Anyway, seemed a good enough reason to dig into it some more. Building latest OpenCV natively on both 32bit Raspbian and 64bit from previous link, the results surprised me (this is focussed on image processing):

https://drive.google.com/file/d/1u8kLMP ... 95f_7/view

32 bit showing significantly quicker across the board! I wondered if maybe there were more packages present in the Raspbian image, so I spent a fair bit of time adding a bunch into the 64bit flavour, lapack and eigen libs incase they were an issue.. and.. no difference.

For comparison I included my laptop results too, that about 6 years old, i5-3230M CPU @ 2.60GHz. On that big difference, I wonder if theres been more optimisation for Intel features like IPP, and maybe NEON hasn't received much attention yet.

Anyway, might be useful for anyone wondering if 64 bit is worth it for their use case.

[Gavinmc42]

I don''t think OpenCV has been optimized yet for Aarch64.
It is also a big general purpose CV bunch of code for Desktop PC power number crunching.

One of the things I wanted an Aarch64 OS for was trying to understand/improve things like CV.
Sakaki shows how to compile ARM's Compute library for Gentoo64.
This has NEON code but also Mali GPU code which we cannot use on Pi's.
However there is some OpenCL sort of working on the Pi QPU's which may be used instead?

Really optimized code will probably need assembler plus NEON/GPU and according to ARM, Aarch64 is cleaner than Aarch32.
It will take me years to get any good at it, by which time all Pi's hopefully will be 64bit?

Probably the 32bit code is faster because the SDRAM is the limitation, only one fetch?
Actually is the SDRAM 16 or 32bit wide? OK 32bit, so two fetches for 64bit code?
Pi4 will have 64bit wide memory DDR4?

RPF are right in that a 64bit OS is not a big improvement (it can be worse) at the moment.
However learning 64bit coding now will be good for future, faster Pi's where it should make a difference.

Do the benchmarks run from the cache memory?
Aarch64 has more registers so is the code making best use of them?
To make the best use of the Aarch64 more stuff needs to be done on the SoC.
Most OS's don't let you pick, which is why I moved most of my development to Ultibo 2 years ago

[jahboater]

and according to ARM, Aarch64 is cleaner than Aarch32.

Its been streamlined and optimized for modern ARM CPU's.

So all the really slow stuff has been removed. That is things like ldm/stm, most conditional execution, writing directly to the pc. These features do not work well with out-of-order processors. The opcodes are more regular and faster to decode. The NEON registers are now laid out in the usual manner. Some fast new instructions were added.

Of course they also doubled the number of registers (removing the conditional execution bits in the opcode allowed 5 bits per register instead of 4 - apart from being a disaster for OOO processors).

[Gavinmc42]

And next year Google wants Android apps to have 64bit versions.
The writing is on the wall.

I am impressed with GCC 7.3 on Gentoo64 it seems to compile the stuff I want so far.
Now if only there was a Laz/FPC Aarch64 version

[Cromarty]

It's rubbish to say there is no point in a 64-bit OS.

What about the fact I am trying to run a MongoDB cluster? MongoDB after about 3.2 or thereabouts, does not support 32 bit and the Wired Tiger database engine doesn't either.

So for MongoDB I need 64-bits.

I am sure there are other applications that would benefit from it

[Heater]

Cockroachdb is another example.

[jahboater]

I see the latest ARM CPU, the Cortex-A76, mandates a 64-bit kernel.

[adamreisnz]

Especially since 64 bit is not needed for 99% of users and applications of a Pi.

I really detest such baseless statements. Can you show me what you base these figures on?

We need a 64 bit OS to be able to update MongoDB to 3.2+. But because that needs a 64 bit OS, we are stuck with MongoDB 2 which has already reached EOL and thus potentially contains security vulnerabilities.

I guess we're just part of the 1%?

Surely a new Pi can also come with a new 64 bit OS, even if that is not backwards compatible with the older Pi models?

[Heater]

adamreisnz,

Can you show me what you base these figures on?

Hmmm... that's easy.

99.999% of Raspberry Pi are being used with a 32 bit operating system and their users are quite happy with it.

Ergo "64 bit is not needed for 99% of users and applications of a Pi."

Those fractional percent of users that want to use software that requires a 64 bit OS can easily find one and probably have the skills to use it. For example I set up a cluster of Pi running CockroachDB using Pi64.

Surely a new Pi can also come with a new 64 bit OS, even if that is not backwards compatible with the older Pi models?

Surely it could. But who is going to do that? Most of what we have on the Pi is there because of the work of volunteers. Are you volunteering to create such and OS and support it long into the future?

[fruitoftheloom]

Especially since 64 bit is not needed for 99% of users and applications of a Pi.

I really detest such baseless statements. Can you show me what you base these figures on?

We need a 64 bit OS to be able to update MongoDB to 3.2+. But because that needs a 64 bit OS, we are stuck with MongoDB 2 which has already reached EOL and thus potentially contains security vulnerabilities.

I guess we're just part of the 1%?

Surely a new Pi can also come with a new 64 bit OS, even if that is not backwards compatible with the older Pi models?

https://code.overdrivenetworks.com/blog ... el-b-plus/

[jamesh]

adamreisnz,

Can you show me what you base these figures on?

Hmmm... that's easy.

99.999% of Raspberry Pi are being used with a 32 bit operating system and their users are quite happy with it.

Ergo "64 bit is not needed for 99% of users and applications of a Pi."

Those fractional percent of users that want to use software that requires a 64 bit OS can easily find one and probably have the skills to use it. For example I set up a cluster of Pi running CockroachDB using Pi64.

Surely a new Pi can also come with a new 64 bit OS, even if that is not backwards compatible with the older Pi models?

Surely it could. But who is going to do that? Most of what we have on the Pi is there because of the work of volunteers. Are you volunteering to create such and OS and support it long into the future?

A fully working 64bit version of Raspbian is more than just recompiling for 64bit and providing a repo. A chunk of work needs to be done to fix up communications with the 32bit Videocore4, which is non-trivial. We just haven't done it yet. Or indeed figured out a way of doing it that doesn't hammer performance. The Eric Anholt driver does go some way to nagating this issue as a lot of the work is done on the ARM, so less needed from the VC4.

At some point of course, we will need to officially support a 64bit OS. When that is? Who knows.

[RicardoX]

At some point of course, we will need to officially support a 64bit OS. When that is? Who knows.

In the meanwhile for those who need the 64 bits kernel, I wrote a how-to on my blog: https://ricknox.com/blog/64-bit-kernel-raspberry-pi/

[ejolson]

99.999% of Raspberry Pi are being used with a 32 bit operating system and their users are quite happy with it.

It seems a little known fact that customer satisfaction for Raspberry-Pi products is even higher than for the products of any other company, even Rolls-Royce.

The most compelling reason for 64-bit processing, in my opinion, is that everyone else is doing it. Desktop computers have been 64-bit since 2005 with the Intel EM64T and the AMD Athlon 64-bit processors. Over the last 13 years mainstream software development has switched to targeting 64-bit architectures. For example, web browsers such as Firefox target 64-bit. I suspect the same for development of Libre Office, Java and many database systems.

[W. H. Heydt]

When will Raspbian be 64-bit? Some time before January 2038. What "roadblocks" are there preventing it from happening soon? There is both a large installed base and some popular versions of the Pi that can't run 64-bit.

Therefore what I see as necessary to a general migration to 64-bit is the launch of...
a 64-bit capable versions of the Pi0, Pi0W, and A+. That last one is---at least in theory--feasible now. The first two...not so much.

Failing the launch of a 64-bit capable Pi0/Pi0W/A+, the RPF would have to support two versions Raspbian. A 32-bit "legacy" version, plus the 64-bit version. At what point do those who insist that a 64-bit version must exist soon think the RPF should either spend the money to support two versions (and for how long?) or cut off the older or less capable Pis? This is especially critical with the Pi0/Pi0W as there doesn't appear to be a replacement SoC "on hand" like there is for the A+.

[mfa298]

Therefore what I see as necessary to a general migration to 64-bit is the launch of...
a 64-bit capable versions of the Pi0, Pi0W, and A+. That last one is---at least in theory--feasible now. The first two...not so much.

And based on what JamesH said above potentially for a fully operational 64-bit OS we might need something that's not VideoCore4 based (or it might need some updates)

That's based on reading between the lines of:

A chunk of work needs to be done to fix up communications with the 32bit Videocore4, which is non-trivial. We just haven't done it yet. Or indeed figured out a way of doing it that doesn't hammer performance.

My assumption is this is mainly for things like interfacing the Camera and media decoders.

We need a 64 bit OS to be able to update MongoDB to 3.2+. But because that needs a 64 bit OS, we are stuck with MongoDB 2 which has already reached EOL and thus potentially contains security vulnerabilities.

The alternative question might be why does MongoDB need a 64 bit OS, is there some real limitation that means they absolutely cannot use a 32bit OS any more or is it just the developers being lazy or trying to push an agenda?

[ejolson]

a 64-bit capable versions of the Pi0, Pi0W, and A+.

It is worth noting that poorer counties whose schools continued using older PCs that included the BASIC programming language did not fall off the computer literacy scale the same way as richer counties that kept the schools up to date.

The stability that results from keeping things exactly the way they are for ten years at a time gives teachers an opportunity to solidly integrate reading and writing of computer programs into the curriculum. Continual change to make things up to date creates disruptions that discourage the creation of suitable educational materials.

In my opinion, updating the official Raspbian operating system from Wheezy to Jessie to Stretch has made learning well how to use the Pi too complicated and rendered many tutorials obsolete. Hopefully the official change from 32-bit to 64-bit will be less disruptive.

[Heater]

W. H. Heydt,

When will Raspbian be 64-bit? Some time before January 2038.

I guess you are referring to the rollover the Unix time tick there. That is not a good reason to go to 64 bits. That issue is already catered for even on 32 bit systems.

I'm in two or three minds about all this...

On the one hand one hand given the enormous resources required by Libre Office, web browsers, Java and such like I would never consider relying on those things on a Raspi. Moving to a 64 bit OS and software does not magically remove the real hardware limitations of memory space and performance a Pi has.

Quite why a browser needs to be 64 bit at this time escapes me. I just checked the memory usage of my Chrome with a dozen tabs open. It was a lot but the biggest one of those was using only 100 or so megabytes.

On the other hand...to address mfa298's question:

The alternative question might be why does MongoDB need a 64 bit OS, is there some real limitation that means they absolutely cannot use a 32bit OS any more or is it just the developers being lazy or trying to push an agenda?

I'm no database guy but my simplistic understanding is as follows:

1) A database, whichever way you do it, is ultimately a file or files that can be huge. Many times bigger than your physical memory or the virtual address space your processor has. Think terabytes and exabytes.

2) It can make your database software very much simpler if you can map all that data in the files into your virtual address space. Basically you just want to deal with a data structure in memory and not have to do all that file seeking and reading/writing. Let the OS do that with it's memory manager.

4) You can't map big, terabyte, exabyte, database files into a 32 bit address space.

Now that is shitty if you never expect your Mongo database to be bigger that 2 giga bytes. But such a database is intended for much bigger things.

[W. H. Heydt]

W. H. Heydt,

When will Raspbian be 64-bit? Some time before January 2038.

I guess you are referring to the rollover the Unix time tick there. That is not a good reason to go to 64 bits. That issue is already catered for even on 32 bit systems.

That was what I had in mind. On the other hand, there is already software that people want to run on Pis that simply isn't available in a 32-bit version. That trend is likely to continue, making it harder and harder to run a full featured and complete system in 32-bit.

[W. H. Heydt]

Therefore what I see as necessary to a general migration to 64-bit is the launch of...
a 64-bit capable versions of the Pi0, Pi0W, and A+. That last one is---at least in theory--feasible now. The first two...not so much.

And based on what JamesH said above potentially for a fully operational 64-bit OS we might need something that's not VideoCore4 based (or it might need some updates)

That's based on reading between the lines of:

A chunk of work needs to be done to fix up communications with the 32bit Videocore4, which is non-trivial. We just haven't done it yet. Or indeed figured out a way of doing it that doesn't hammer performance.

My assumption is this is mainly for things like interfacing the Camera and media decoders.

I saw jamesh post. To me it reads that it would be a right pain to use VC4 in a 64-bit system, but that it's not impossible. The problem with the Pi0/Pi0W/A+ and the Model A, Model B, and B+, as well, is that you simply can't run 64-bit code on them.

We already see cases where we have to tell people that they can't run this or that piece of software on a Pi0 or Pi0W because it won't run on a BCM2835.

As I said, the problem for the A+ has an actual solution which has been mentioned by Dr. Upton. That is, release a Pi3A/Pi3A+ (whatever you want to call it). There is no corresponding solution for the P0 and Pi0W.

What I actually expect to happen, probably in something like 10 to 15 years, is for there to be a "last version" of Raspbian-32 released that will support all "legacy" boards and a new, "Raspbian-64" launched that will be maintained going forward from there. One might hope that--starting with the Pi4B (perhaps as early as next spring) a successor to the VC4 will be in place that can play well with a 64-bit system. Then by the time the RPF has to bite the bullet and go 64-bit, there will be a A-series Pi that will work with it and--somehow, don't ask *me* how--there will be a newer version of the Pi0/Pi0W that is also compatible. The overall idea being that by the time the transition takes place, *most* Pis in use will already be ready for it--because the vast majority of Pi are "64-bit ready" and the few that aren't can just chug along on the last 32-bit version. (Consider...does anyone now give a thought to how a new release will run on a Model A or a 256MB Model B? They're still out there, you know.)

[Heater]

W. H. Heydt,

I know what you mean.

But I don't understand why it is so.

The 64 bit architecture started to go mainstream with the AMD Athlon in 1999. Very soon there were 64 bit Linux distributions. All those thousands of packages they use worked, or were soon fixed up to work, on both 32 and 64 bit machines. Windows did not go 64 bit until much later, in 2005.

So why now are people refusing to support 32 bit?

I can possibly understand databases, as I said above. I can possibly understand Firefox, which as far as I can tell is switching to Rust and I imagine the Rust compiler guys can't be bothered with 32 bit code generators.

[ejolson]

somehow, don't ask *me* how--there will be a newer version of the Pi0/Pi0W that is also compatible.

What makes the Pi Zero interesting for many is more the small size and low power consumption than the small price. With existing 64-bit SOC packages, where to place the memory becomes a problem unless components are mounted on both sides. With existing 64-bit SOC packages, power consumption is a problem unless all cores are disabled but one and that remaining core is clocked in the sub-gigahertz range. Would anyone be interested in a tiny Pi with one 64-bit ARMv8 core clocked at 700 Mhz, 1GB of memory and a single micro USB port at a price 5 times greater than the current Pi Zero? I think the answer to this question is why Raspbian has remained 32-bit so far.

[mfa298]

On the other hand...to address mfa298's question:

The alternative question might be why does MongoDB need a 64 bit OS, is there some real limitation that means they absolutely cannot use a 32bit OS any more or is it just the developers being lazy or trying to push an agenda?

I'm no database guy but my simplistic understanding is as follows:

1) A database, whichever way you do it, is ultimately a file or files that can be huge. Many times bigger than your physical memory or the virtual address space your processor has. Think terabytes and exabytes.

2) It can make your database software very much simpler if you can map all that data in the files into your virtual address space. Basically you just want to deal with a data structure in memory and not have to do all that file seeking and reading/writing. Let the OS do that with it's memory manager.

4) You can't map big, terabyte, exabyte, database files into a 32 bit address space.

Now that is shitty if you never expect your Mongo database to be bigger that 2 giga bytes. But such a database is intended for much bigger things.

Yet the likes of mysql and postgres seemed to be able to manage it on 32 bit systems. Whilst my memory is a bit hazy now I remember having a mysql databases back in the early 00s which were almost certainly 32 bit systems and multi GB databases. I'd imagine I could still set something similar up on a pi with the limiting factor probably being the IO speed rather than 32bit OS.

So what I think we're saying with your points 2 & 4 (im not sure what happened to point 3) is that the MongoDB folk are taking the easy way out, rather than it being impossible for them to operate on a 32 bit system.

Having worked in a team where we had some huge databases, tables with billions of rows. I've also seen that solutions where your data is stored in a single large file doesn't always scale that well. Whilst the import was going on there was a significant slowdown as the number of rows increased.

[W. H. Heydt]

W. H. Heydt,

I know what you mean.

But I don't understand why it is so.

The 64 bit architecture started to go mainstream with the AMD Athlon in 1999. Very soon there were 64 bit Linux distributions. All those thousands of packages they use worked, or were soon fixed up to work, on both 32 and 64 bit machines. Windows did not go 64 bit until much later, in 2005.

The first 64-bit Linux distro to hit the market--at least that I know of--was SuSE 9.2 in 2003. I built a dual-Opteron box in Fall 2003 and picked SuSE for just that purpose. (2 x Opteron-240, 2GB EEC RAM, 3 x 36GB WD Raptor 10Krpm + 500GB 7200 rpm, 24x CD writer, nVidia 5200 gpraphics card. Fans all over the place. Weighs 40 lbs. A $2000 machine at the time. And it's my "benchmark" for where I'd like to see the Pi get to. I/O speed and memory are all that are missing at this point.)

So why now are people refusing to support 32 bit?

More to the point, given the general limitations of the Pi (mostly the RAM capacity), what does one need to do that actually *needs* to be 64-bit?

I can possibly understand databases, as I said above. I can possibly understand Firefox, which as far as I can tell is switching to Rust and I imagine the Rust compiler guys can't be bothered with 32 bit code generators.

Even databases are a stretch. A Pi is able to run a reasonable database. Anything to big to run on a 32-bit system is probably going to involve an impractical amount of storage for a Pi. When your storage system costs orders of magnitude more than the base system, something is wrong.

When it becomes economically feasible to build a Pi and sell it for $35 with 4GB+ of RAM, then 64-bit will start making sense. I think that will happen...someday. I may not be around to see it, but it's kind of inevitable.