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

[Quackdoc]

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

It may be a small ship, but a small ship was fine for jack sparrow it'd be fine for me as well

[stormcrow]

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

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. If it's anything like PAE it's just a way of bringing segmented memory architecture forward to reach above the 32 bit 4GB address limit. I'm not that familiar with ARM's family tree, however, so I'm guessing on how LPAE is architected.

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

[willmore]

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. If it's anything like PAE it's just a way of bringing segmented memory architecture forward to reach above the 32 bit 4GB address limit. I'm not that familiar with ARM's family tree, however, so I'm guessing on how LPAE is architected.

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

Page tables map virtual addresses to physical ones. LPAE lets those physical addresses be larger than 32 bits. Pointers in user and kernel space are always *virtual*, so they have to get translated to physical addresses. For user space, there is no difference. For the kernel, there's a lot more pain because you can't just use a pointer to address all of memory, you have to go through extra steps. Maybe that's what you mean by "extra CPU cycles". User space doesn't (have to do extra work) as a pointer always had to get translated through a page table to a physical address. The Kernel used to just have one entry that said "virtual addresses map 1:1 to physical addresses" and went about life thinking that was true. So implementing PAE/LPAE took some doing. Fortunately, that happened on the Intel side with the Pentium Pro, so the support for it is very old and solid. So, by the time LPAE came around in the ARM world, adding it wasn't a big deal--all the heavy lifting had been done years before.

[mangeek]

I'm really curious how they pulled off the magic to get the guest OS to be 64 bits when the host was just 32. There's got to be a lot of painful kludging going on there.!

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.

[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.

[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.

[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.

[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.

[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.

[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)