Raspberry Pi's Raspbian OS Finally Spins 64-bit Version

[betty567]

Raspbian has to be the worst OS for Raspberry Pi, although in all fairness Ubuntu and Fedora are also pretty bad. Despite being averse to Arch Linux, I must admit that Manjaro is by far the best if you want to run something graphical, Raspbian is a lag-fest no matter how lightweight your desktop environment.

[mangeek]

The host OS is ThreadX...

I think the OS for the GPU was (not sure if it still is on the BCM2711) ThreadX, but that never ran on the ARM core. The Pi was weird and booted the GPU at power on, which would then load the firmware for starting the CPU. So while the GPU ran a proprietary 32-bit OS, it was basically just a bootloader as far as the CPU was concerned.

[arQon]

Why wouldn't it? RPi has been a common platform for watching stolen movies with OpenELEC since 2012.

That's a very different scenario to what OP is asking, which was "s video decoding in hardware (h.264 & h.265) working now?", and the answer to that is a solid "no", the same way it's always been, other than when running an extremely-hacked version of VLC, and only on raspbian's very-modded 32-bit kernels.

The fact that you can use a pi4 to *transcode* video, provided you DON'T have a DRM client running, isn't of any use to anyone attempting to e.g. watch YouTube on it inside a desktop session. I'm pretty sure that's the context the OP was asking about.

[jaxa]

The bigger problem with the pi, this Microsoft thing inside the chip aside, was the addition of packages.microsoft.com (proprietary software), without consent, to all raspi OS devices one year ago (end of January)

Not a problem for most people. The biggest problem is likely the weak, proprietary GPU.

[schestowitz]

The bigger problem with the pi, this Microsoft thing inside the chip aside, was the addition of packages.microsoft.com (proprietary software), without consent, to all raspi OS devices one year ago (end of January)

[coder]

The host OS is ThreadX which, last I heard, was 32 bit only. A linux kernel at 64 bits is the guest OS. That's the kludge I'm talking about. And by 'hardware' being 64-bit native, it would depend on the host being 64 bit as well and again, I haven't heard of ThreadX being 64 bits now.

According to the wikipedia article, ThreadX actually runs on the Pi's GPU:

https://en.wikipedia.org/wiki/ThreadX#Products_using_it

If that's true, then 32-bits vs 64-bits is almost a non-issue, since it's on a completely different processor.

[coder]

I'm guessing it's the way it does on x86 PAE, or in ARM's nomenclature LPAE, Large Physical Address Extension. Extends the physical address space from 32 bits to 40 bits or 44 bits depending on the ARM CPU. I'd imagine addressing RAM beyond a 32 bit space would require extra CPU cycles with a 32 bit OS so having a properly 64 bit clean and optimized kernel and user space would likely save on RAM addressing cycles alone.

Back in the x86 PAE era, you'd still typically have 32-bit userspace apps, which was fine for most purposes. Only specialized software, like some database servers, would typically use PAE to access > 32-bit virtual address space within a single process.

If you're interested, look up Physical Address Extension and segmented memory to learn more.

Nah, I just wondered whether Pi OS actually supported that. I have heard of people running a 64-bit kernel and 32-bit userspace, which seems the most natural way to do it.

I have a Pi v3 that's been running the 64-bit beta OS for about 8 months. Actually, it's off most of the time, but that's what I've been using on it. I figured this day would eventually come, and soon the 64-bit version will have better support than 32-bit.

FWIW, my ODROID N2+ is running Ubuntu 20.04 LTS. That's been working pretty well, but I haven't used it for anything serious.

[rclark]

I've been using the beta PI OS 64 since it came out. For me it has been very solid, but then I wasn't really 'testing' it. I run it headless on a RPI4 4G booting off a USB 3.0 SSD . I've been using it as a way to learn 64Bit Arm Assembly for the most part. So my usage has been SSH, SFTP and nano. I'll be using it only on my RPI4s and CM4s. Glad to see it finally officially released. If only you could find a RPI4 or CM4 in the wild. Seem really scarce right now.

Note that in the 32 bit PI OS, an application 'only' could get 3GB (1GB of the 4GB potential is reserved) of memory to use, whereas the 64bit, it is all available. Not that there are many applications that need that much memory! Another advantage of the 64bit, is more CPU registers available to use, so potentially more efficient.

[willmore]

The hardware and 64-bit OS are totally native. There's actually less 'kludging' going on with 64-bit on these things than 32-bit.

The host OS is ThreadX which, last I heard, was 32 bit only. A linux kernel at 64 bits is the guest OS. That's the kludge I'm talking about. And by 'hardware' being 64-bit native, it would depend on the host being 64 bit as well and again, I haven't heard of ThreadX being 64 bits now.

[jaxa]

Huh? Using a 64-bit kernel, or how does that work?

On 32-bit:

https://www.tomshardware.com/news/raspberry-pi-64-bit-os-released

"On Raspberry Pi 4, we use the ARM Large Physical Address Extension (LPAE) to access up to 8GB of memory, subject to the constraint that any process is limited to accessing 3GB (we reserve the top 1GB of the virtual address space for the kernel)," Hollingworth explains.

Every Chromium tab uses its own process, and so on.