64-bit operating system

[rpdom]

It would be better if a new OS was released with the next RPi family which is ARM64.

Is it? Or is that just speculation?

I agree that it will probably be AARCH64, but unless you have some insider knowledge I'd say nothing is certain. It wouldn't be the first time we've been surprised by the RPF

(I don't have any insider knowledge at all. Hoping to get on the Pi "Fight Club", especially as I seem to have a lot more free time to test things right now)

[fruitoftheloom]

It would be better if a new OS was released with the next RPi family which is ARM64.

Is it? Or is that just speculation?

I agree that it will probably be AARCH64, but unless you have some insider knowledge I'd say nothing is certain. It wouldn't be the first time we've been surprised by the RPF

(I don't have any insider knowledge at all. Hoping to get on the Pi "Fight Club", especially as I seem to have a lot more free time to test things right now)

No speculation, I will leave it to other posters to live in cloud cuckoo land, it is just common sense to go all out for AArch64 ARM64, going backwards would be a retrograde step considering the first ARMv8 CPU was released in 2011.


Anyway the point I was making is that ARMHF ARM32 Raspbian OS is suitable as it is as it installs on ALL current as at December 2019 RPi SBC's...........

[davidcoton]

Anyway the point I was making is that ARMHF ARM32 Raspbian OS is suitable as it is as it installs on ALL current as at December 2019 RPi SBC's...........

That's a very futuristic statement -- is your crystal ball back online? Care to tell us all how to resurrect ours?

[jamesh]

It would be better if a new OS was released with the next RPi family which is ARM64.

Is it? Or is that just speculation?

I agree that it will probably be AARCH64, but unless you have some insider knowledge I'd say nothing is certain. It wouldn't be the first time we've been surprised by the RPF

(I don't have any insider knowledge at all. Hoping to get on the Pi "Fight Club", especially as I seem to have a lot more free time to test things right now)

Are you on the beta programme? ISTR you probably are?

[fruitoftheloom]

Anyway the point I was making is that ARMHF ARM32 Raspbian OS is suitable as it is as it installs on ALL current as at December 2019 RPi SBC's...........

That's a very futuristic statement -- is your crystal ball back online? Care to tell us all how to resurrect ours?

That was a typo.... obviously 2018

[jdonald]

a) We do not have the support stuff to support two different OS's.

This got buried among the "brain dumps" but a few posts back I pushed for the idea of treating this as initially a capability mode rather than a new image. That is, include kernel8.img with Raspbian so people can boot into 64-bit mode. Following a similar pattern as the OpenGL driver, ideally there would be a flag in raspi-config to enable/disable it, with the default being off.

(To be clear, I'm only suggesting providing the kernel. Users who desire Eric's GL driver, gcc-aarch64-linux-gnu, or anything else from 64-bit userland don't get that preinstalled, but at least have a starting point to work with if they choose.)

The downside is that you'd have more support questions of "<insert driver here> doesn't work in 64-bit mode?" or "how do I install 64-bit userland <some software> on Raspbian?" but most of these "Why isn't Raspbian 64-bit?" threads would go away. Even if 64-bit Raspbian users would be practically limited to static compiles/chroot/Docker/LXC, we'd be in a better position to do apples-to-apples 32-bit vs 64-bit tests, rather than so much theorizing about performance as we do in this thread. It could be a net win.

problems with it in certain circumstances. The camera is one, where the white balance routines uses the quads, BUT in Eric's driver in ARM space, it doesnt know when the camera might be doing it, and that causes conflicts. So we need to change the WB routines to run nicely with the ARM side driver.

From this description, don't we have to tackle the same problem with the OpenGL driver + Fake KMS? And RPF does officially support the driver in 32-bit mode, right?

[code_exec]

An ARM64 Raspbian would basically just be 'ARM64 Debian with Raspberry Pi Desktop'. Why? Because Debian already has an ARM64 port which works on the Raspberry Pi 3. Remember, Raspbian was made because Debian armhf was compiled for the ARMv7 architecture that the original Raspberry Pi did not have, and Debian armel (ARMv4t) did not make best use of the Pi's hardware since it used software for floating point applications instead of hardware. If the original Pi had an ARMv7 SoC, Raspbian probably wouldn't exist and would most likely be 'Debian with Raspberry Pi Desktop and applications'. The RPF wouldn't need to recompile Debian ARM64 packages for the Pi 3, since these packages already work. All they'd need to do to make an ARM64 'Raspbian' distro would be to recompile the Raspberry Pi desktop for ARM64 and add it to a Debian ARM64 image.

[Rascas]

without the closed-source graphics driver, there is no hardware video decoding and the OpenGLES performance is much worse.

Shouldn't video decoding still work with Fake KMS? Per:

edit the vc4-kms-v3d overlay to:

Code: Select all

dtoverlay=vc4-fkms-v3d

you will end up with Eric's arm side v3d driver, supporting desktop GL from X, but using the original firmware for the kms part.
This means that tvservice, dispmanx, omxplayer(*), raspivid etc should work as before, but you can also run desktop GL apps from X. The one thing you cannot do with this driver is use firmware side 3D.

GLES performance: I agree that's a problem and hope this part gets better over time. As for Kodi, you mentioned that it's a lot slower but from what I've seen it doesn't even attempt to run (goes straight to the "failed to add service" message). Is there some compile flag or commandline option to get Kodi to try to run with Mesa EGL/GLES?

Note that in Dom's statement, OMXPlayer has an asterisk. I didn't know, but if you read the rest of that topic, you need to pass --no-osd for OMXPlayer to work with open source VC4 Fake KMS OpenGL driver. I can confirm that, this way, it works. Although everything else that needs access to the Pi's firmware side GL driver (Broadcom) still doesn't work. That includes VLC and Chromium with hardware video decoding (via MMAL), Kodi ( compiled with OpenGLES), most of game emulators (also if compiled with OpenGLES), etc.

PS: Kodi available on Raspbian (in the RPi Foundation repo) is compiled with OpenGLES (for best performance and access to hardware video decoding) and requires access to the firmware side GL driver (Broadcom). For Kodi to work with open source VC4 Fake KMS driver, you need to compile it yourself with OpenGL support instead.

[jamesh]

From this description, don't we have to tackle the same problem with the OpenGL driver + Fake KMS? And RPF does officially support the driver in 32-bit mode, right?

The driver is still in beta on 32bit for precisely the reasons above - interactions with other existing software isn't 100% there. Still quite a lot more work required. And that even before we move to 64bits.

[jamesh]

An ARM64 Raspbian would basically just be 'ARM64 Debian with Raspberry Pi Desktop'. Why? Because Debian already has an ARM64 port which works on the Raspberry Pi 3. Remember, Raspbian was made because Debian armhf was compiled for the ARMv7 architecture that the original Raspberry Pi did not have, and Debian armel did not make best use of the Pi's hardware. If the original Pi had an ARMv7 SoC, Raspbian probably wouldn't exist and would most likely be 'Debian with Raspberry Pi Desktop and applications'. The RPF wouldn't need to recompile Debian ARM64 packages for the Pi 3, since these packages already work. All they'd need to do to make an ARM64 'Raspbian' distro would be to recompile the Raspberry Pi desktop for ARM64 and add it to a Debian ARM64 image.

Anyone who starts a sentence with "All they'd need to do..." is not fully cognicent with the issues.

Yes, we are aware of the available repos from other providers, and will almost certainly leverage them. We'd then just need to get everything else not in those repos working.

[fruitoftheloom]

An ARM64 Raspbian would basically just be 'ARM64 Debian with Raspberry Pi Desktop'. Why? Because Debian already has an ARM64 port which works on the Raspberry Pi 3. Remember, Raspbian was made because Debian armhf was compiled for the ARMv7 architecture that the original Raspberry Pi did not have, and Debian armel (ARMv4t) did not make best use of the Pi's hardware since it used software for floating point applications instead of hardware. If the original Pi had an ARMv7 SoC, Raspbian probably wouldn't exist and would most likely be 'Debian with Raspberry Pi Desktop and applications'. The RPF wouldn't need to recompile Debian ARM64 packages for the Pi 3, since these packages already work. All they'd need to do to make an ARM64 'Raspbian' distro would be to recompile the Raspberry Pi desktop for ARM64 and add it to a Debian ARM64 image.

I was under the impression Armbian was released because many SBC's could not natively run Debian ARMHF or ARM64 ??

[rpdom]

Are you on the beta programme? ISTR you probably are?

I did send an email FAO you, but didn't get a reply.

[mfa298]

I was under the impression Armbian was released because many SBC's could not natively run Debian ARMHF or ARM64 ??

I thought Armbian generally used the Debian repos for most packages. The main part Armbian provide is a current kernel/bootloader (u-boot).

Certainly on most of the non Raspberry flavoured boards I've played with it's possible to compile a suitable kernel and u-boot and then just use Debian's repositories for userspace.

[code_exec]

An ARM64 Raspbian would basically just be 'ARM64 Debian with Raspberry Pi Desktop'. Why? Because Debian already has an ARM64 port which works on the Raspberry Pi 3. Remember, Raspbian was made because Debian armhf was compiled for the ARMv7 architecture that the original Raspberry Pi did not have, and Debian armel (ARMv4t) did not make best use of the Pi's hardware since it used software for floating point applications instead of hardware. If the original Pi had an ARMv7 SoC, Raspbian probably wouldn't exist and would most likely be 'Debian with Raspberry Pi Desktop and applications'. The RPF wouldn't need to recompile Debian ARM64 packages for the Pi 3, since these packages already work. All they'd need to do to make an ARM64 'Raspbian' distro would be to recompile the Raspberry Pi desktop for ARM64 and add it to a Debian ARM64 image.

I was under the impression Armbian was released because many SBC's could not natively run Debian ARMHF or ARM64 ??

Most ARM SBCs should be able to run Debian armhf if they use the ARMv7 or ARMv8 architecture. If they use ARMv6 or ARMv5te, they should be able to run Debian armel.

https://wiki.debian.org/ArmHardFloatPort
https://wiki.debian.org/ArmEabiPort

[W. H. Heydt]

An ARM64 Raspbian would basically just be 'ARM64 Debian with Raspberry Pi Desktop'. Why? Because Debian already has an ARM64 port which works on the Raspberry Pi 3. Remember, Raspbian was made because Debian armhf was compiled for the ARMv7 architecture that the original Raspberry Pi did not have, and Debian armel (ARMv4t) did not make best use of the Pi's hardware since it used software for floating point applications instead of hardware. If the original Pi had an ARMv7 SoC, Raspbian probably wouldn't exist and would most likely be 'Debian with Raspberry Pi Desktop and applications'. The RPF wouldn't need to recompile Debian ARM64 packages for the Pi 3, since these packages already work. All they'd need to do to make an ARM64 'Raspbian' distro would be to recompile the Raspberry Pi desktop for ARM64 and add it to a Debian ARM64 image.

That goes directly to my point that, unless the RPF decides to support two images, unless and until the Pi0/Pi0W get a 64-bit capable CPU core, a general migration to 64-bit won't happen. I will grant that I don't see a "road map" to get those boards upgraded, but that doesn't mean there isn't one.

[jdonald]

Which goes to my point.

[Gavinmc42]

Brain dumps like this are not helpful, this one contains a number of inaccuracies. You also do some very smart people a disservice by saying what they haven't done, and overly given credit to others for relatively simple achievements.

The reasons why we (The RPF) haven't yet done a 64bit OS are numerous. But the main ones : a) We do not have the support stuff to support two different OS's. b) The interface from ARM to VC4 is currently based on the 32bit architecture of the VC4. Moving to a 64bit host OS means that interfaces need a lot of work. Memory addresses move from 32 to 64 bits - and the interface supports only 32, so a load of work would be need to shim it.

That said, we are certainly going to need to do a specific 64bit OS at some point. Eric's driver takes us a long way towards that, but there are still problems with it in certain circumstances. The camera is one, where the white balance routines uses the quads, BUT in Eric's driver in ARM space, it doesnt know when the camera might be doing it, and that causes conflicts. So we need to change the WB routines to run nicely with the ARM side driver. Making EVERYTHING required work correctly with a 64 bit OS is not a trivial task.

Yep brain dump for sure, but I did not mean to gloss over anyone's work, especially those unknown to me.
Making everything work is not what I asked or want.
I just pointed out a few things that are working in 64bit, not perfectly but usable now.
Those few things might seem simple achievements to some who do that for a living but not to me, a user of these magical things.

Pi's are hardware and Pi's don't have to run Raspbian, but a single version Raspbian helps RFP's mission.
RPF's Mission is my mission, learning programming but to a point of making and rolling out gadgets that do stuff.
To stay close to current technology in hardware and software, that to me, requires learning 64bit coding.
Multicore 64 bits is where the interesting stuff is going on.

All my hardware projects to date have been 32bit, only two had Raspbian, the others use PiCore or Ultibo.
Some people seem to get fixated on the issue of there is no 64bit Raspbian, therefore there is no 64bit OS.
True there is no 64bit OS that uses all the hardware/software features, camera, codecs etc yet.
But what do people use Pi's for?
Most still probably don't need 64bit, those that want 64bit, why?

If I try a 64bit OpenGL demo and find out the driver does not support more than 65536 vertices then I have learned something.
Is that limit software or hardware? no idea yet.
Pushing the limits of what Pi's can do is part of the fun.
Eric's (and others ) VC4 OpenGL driver works much better now than it did 6 months ago and I expect 6 months from now it will be even better still.

How much of the VC4/QPU's does the new OpenGL driver use?
I don't know, will piglit help? How do you test Mesa?
Does it use the Arm' cores to software render?
If so, does that free up some QPU's for OpenCL stuff?
Lots of questions with answers that will change over time.

For all I know, RPF have a 64bit Raspbian that works right now but without the extras.
OpenGL on Gentoo64 works out of the box, the latest Raspbian crashes for me when I enable OpenGL
Since I want to learn 64bit OpenGL coding, what choice do I have? Use Linux Mint on a PC

[jahboater]

Most still probably don't need 64bit, those that want 64bit, why?

You paid lots of money for a new car with an 8 cylinder engine and you later discover that the engine management computer is restricting it to using 4 cylinders only ...

Be patient!
64-bit Raspbian will come. Perhaps with the Pi4.

The fact that Raspbian is 32-bit is actually useful for verifying code still works on 32-bit platforms.

[jamesh]

Most still probably don't need 64bit, those that want 64bit, why?

You paid lots of money for a new car with an 8 cylinder engine and you later discover that the engine management computer is restricting it to using 4 cylinders only ...

Be patient!
64-bit Raspbian will come. Perhaps with the Pi4.

The fact that Raspbian is 32-bit is actually useful for verifying code still works on 32-bit platforms.

TBH, you paid a tiny amount of money for a car with an 8 cylinder engine.

[jamesh]

How much of the VC4/QPU's does the new OpenGL driver use?
I don't know, will piglit help? How do you test Mesa?
Does it use the Arm' cores to software render?
If so, does that free up some QPU's for OpenCL stuff?
Lots of questions with answers that will change over time.

For all I know, RPF have a 64bit Raspbian that works right now but without the extras.
OpenGL on Gentoo64 works out of the box, the latest Raspbian crashes for me when I enable OpenGL
Since I want to learn 64bit OpenGL coding, what choice do I have? Use Linux Mint on a PC

In reverse order (and deleting the wonky brain dump)

Whats the difference between 64bit OpenGL coding and 32bit OpenGL coding? Not enough to be be relevent to anything. Just use the 32bit version.
Something wrong with your installation.
No we don't although we have been thinking what to do.

No.
Yes
No idea
The OGL driver uses the Quads - they do the heavy 3D lifting, that is what they were designed for, whilst the ARMs control them. In the firmware version, that control is done by the VC4 itself.

[Gavinmc42]

[Whats the difference between 64bit OpenGL coding and 32bit OpenGL coding?/quote]
I have no idea, I'm a noob about 3D stuff, but without a 64bit OS I cannot tell you
Lots to learn about Mesa3D and the demos seem to be the logical place to start.
Perhaps I can get OpenGL running on Raspbian and bench test Mesa samples and WebGL in Chromium.

Something wrong with your installation.

Probably, I don't use Raspbian as much as I used to so I'm falling behind in what is needed to keep it going.

The OGL driver uses the Quads - they do the heavy 3D lifting, that is what they were designed for, whilst the ARMs control them. In the firmware version, that control is done by the VC4 itself.

Good to know.

Not too clear about the VPU's usage differences yet.
Never even knew about the HVS until I saw the registers in the GPU driver code.
The VideoCore Reference guide may as well be written in Latin, the letters I know but lots of the words are meaningless.
Page 44 - Cube Map Mode... hey, can I use this to accelerate Minecraft cubeworlds?

I tested most of the other 64bits, Gentoo64 was the first that worked without hassle for me.
I don't have to be patient anymore, why would I go back to 32bit Raspbian to learn OpenGL?
Every other box I am learning it on is 64bit. I can compare x86 OpenGL against ARMv8 OpenGL.
OpenGL is interesting but only part of lesson.

Arm Compute Library has lots of stuff and forms the base of all ARM's other libs, ML, NN etc.
The Compute lib can use NEON (and Mali OpenCL) and I suspect it will run faster in 64bit mode.
I'm a hardware guy, wasted horsepower offends my rev head sensibilities.

There is so much to learn about Pi type SoC's I have to reduce the set to something manageable and also useful for the future.
That for me means 64bit and NEON. even Microsoft now acknowledges ARM architecture is important.

[TBH, you paid a tiny amount of money for a car with an 8 cylinder engine./quote
Perhaps single cylinder moped (BCM2835) and flat 4 Subaru? 64bit is the turbo version?
Octocore Pi4 is the V8?
Chromium has a V8 engine, we are not there yet, more engine tuning required.

Tiny amount? Yep perhaps, but they add up once you get past a few dozen .
Still cheaper than a new Games PC?

Be patient!
64-bit Raspbian will come. Perhaps with the Pi4.

We have been told not to hold our breath waiting
Gentoo64 means I don't have too, mind you, Gentoo's emerge system is way different than Debian's apt-get.
Adding another package management system to the knowledge bank probably won't hurt too much?
Maybe then I will be ready for Arch or Fedora OS or even Redox OS?

[jamesh]

You still appears to be under the misaprehension that 64 bit programming requires 'something else'. It doesn't. It's exactly the same as 32 bit programming, but with more bits. (note, from a high level language point of view, in assembler, there are some more instruction in the 64bit instruction set I believe, but I don't use assembler any more, so fairly moot from my point of view)

I learnt to program on an 8 bit micro. The algorithms are still the same now as they were then. And even though difference from 8 to to 32 bits is massively more than that from 32 to 64, the lessons learnt on those 8 bit micro's then are still as applicable now.

But if you have a 64 bit system that works for you, then use it. May as well!

[Gavinmc42]

But if you have a 64 bit system that works for you, then use it. May as well!

Exactly, that's my point, if it works use it.

A 64bit Raspbian would be nice, but Debian based OS's are for nice stable everyday usage.
There are other OS's that are more bleeding edge, that use the latest drivers, that may fix old bugs and have unknown new bugs.
People sitting twiddling thumbs saying "I'm waiting for Raspbian64" could have a long wait.
There is a lot that needs to work and perhaps some stuff that may never work?

Linux is a multi user, multi tasking, General Purpose OS.
Lots of times it may be overkill for a single person single task use, like gaming.
Gaming does tend to require more from the hardware than most things

For IoT it could be single task and no user, even 8 bit CPUs can do most of this.
It is only when WiFi/BT comms gets involved that 32bits comes in handy.

So why is 64bits needed?
Insert reason here __________
a) Some people might like to know answers before they have the need.
b) Some people might have a job that requires them to know the answers just in case anyone asks.
c) Some people are just curious or like living on the edge of technology.
d) Some people know it could be done but need to learn the skills to do it.
e) All of the above

What percentage of Pi users actually need a 64bit OS? I suspect it is very tiny.
But Pi's rely on a Linux OS infrastructure, that infrastructure is nearly all 64bit now.
The thousands of people involved in all the code that keeps things like GCC, Clang, LLVM, Debian, Arch, Fedora, Ubuntu, Windows, Chromium, Firefox, Mathematica, Gimp, Blender etc etc all ticking along use mostly 64bit tools.

Out of all these people and companies like Intel, Microsoft, Google, Mozilla, IBM, ......,
RPF is a tiny, tiny piece of it, but pulling way above their weight
There will be an official RPF 64bit OS one day.
We just have to buy more Pi's so they have more money to hire more people to do it.
Or we could just wait or use what works now.

This question will pop up again and again "Why is there no 64bit Raspbian OS?"
Does the OS have to be made by RPF? Does it even have to be Linux?
Pi's are pieces of hardware that run software.
That software can be anything, perhaps one day, even Windows?

When you buy a Pi it may come with a SDcard with software on it
Noobs allows the user to pick an OS, but there is no contract that says you must use one of these OS's.
People are free to use what works for them, that freedom is more important than just one OS.
Unless of course you want to teach coding to kids(or oldsters) then you would be silly to use anything but Raspbian.

Apple has a big presence in schools here in Oz, iPads, Macbooks, but can you learn coding on them?
They really very expensive for performance not much better, starting from - 1.2GHz dual-core Intel Core m3 with Turbo Boost up to 3.0GHz and 4MB L3 cache. Mind you their displays are really nice.

Why is there no Pi display with retina resolution is a more important question than 64bit OS's.
Wait for the Pi4? Not really, the PiTop V2 is probably close enough at 14" 1980 x 1080?
Is it the display that makes Apples so expensive? A Pi $35 display?

Another brain dump sorry, it's 41C here and no aircon, too hot to program

[chwe]

I was under the impression Armbian was released because many SBC's could not natively run Debian ARMHF or ARM64 ??

we* don't compile debs which you can download from official debian/ubuntu repos.. With the 64bit SoCs currently supported by Armbian we deliver ARM64 userspace and for the others armhf.

I was under the impression Armbian was released because many SBC's could not natively run Debian ARMHF or ARM64 ??

I thought Armbian generally used the Debian repos for most packages. The main part Armbian provide is a current kernel/bootloader (u-boot).

Certainly on most of the non Raspberry flavoured boards I've played with it's possible to compile a suitable kernel and u-boot and then just use Debian's repositories for userspace.

The main part is hard to define. Heretical I would argue that the main part is support for random 3th party hardware issues, general linux support and some board related issues. Support takes more and more time the more people use it..

From a developers point of view, Armbian is one of the few distributions which deliver kernel and bootloader updates via apt. For me Armbian is Debian/Ubuntu (with a few tweaks) + recent Kernel + (often) recent u-boot. A few of us do kernel-work (mostly apply patches before they reach mainline and some which may never be added to mainline and sometimes fix out of tree kernels), a few of us do usespace related stuff (e.g. we allow to copy your living image to internal eMMC or USB attached storage where available/possible - not every SoC behaves here similar, some require some special treatment) and a few do u-boot ATF plumbing..

*whereas we is hard to define, Armbian has over 100 different contributors with (partly) different interests.

towards 64bit/32bit for low memory SBCs (and I would count 1GB somewhere on the lower side) it's IMO questionable if the 64bit compiled stuff is really worth it. It tends to consume more memory and stuff gets probably slowed down due to bottlenecked by low memory. We even considered to deliver 32bit rootfs for the low memory 64bit boards.. Not sure if RPi on 64bit will be such an improvement..

[jdonald]

Since I want to learn 64bit OpenGL coding, what choice do I have?

This got me thinking about what it takes to make this happen on Raspbian. In theory LXC can work with accelerated graphics but it's hard enough on desktops to begin with, and I haven't seen it done with Docker. So how about a less-restrictive chroot?

Start with Crazyhead's Raspbian + 64-bit kernel image, then:

Code: Select all

sudo raspi-config # enable OpenGL driver
sudo apt install -y debootstrap schroot
cat << EOF | sudo tee /etc/schroot/chroot.d/pi64
[pi64]
description=VC4 arm64 testing
type=directory
directory=/srv/chroot/pi64
users=pi
root-groups=root
profile=desktop
personality=linux
preserve-environment=true
EOF
sudo debootstrap --arch arm64 /srv/chroot/pi64
sudo schroot -c pi64 -- apt install -y mesa-utils minetest sudo

schroot -c pi64

That last command will open a (pi64)pi@raspberrypi:~ $ shell prompt where you can try:

Code: Select all

glxgears &
minetest &

Although the steps are simpler than LXC, be prepared to wait much longer when it first builds the chroot.

This is similar to what sakaki showed a few pages back, except her example was a 64-bit OS chrooting into a 32-bit one. Here we're going from 32-bit to 64-bit.

While this enables a wider variety of applications compared to Docker/LXC it's not perfect. For example firefox:arm64 crashed on me initially because it couldn't write to /dev/shm. I worked around that by running sudo schroot -c pi64 -- chmod a+w /dev/shm