Why moving to 64bit?

[PeterO]

I have no personal desire to see 64-bit on a Pi

So, what has this all been about then ? You've made a lot of noise about something you now claim not to be interested it
PeterO

[geev03]

I would like to run Alpine Linux 64bit on RPi4 . On a Rpi3B , it runs smoothly on a 1GB sd card and with ngnix uses just 49MB RAM serving pages like the attached picture !

Code: Select all

localhost:/# uname -a
Linux localhost 4.19.58-0-rpi #1-Alpine SMP PREEMPT Thu Jul 11 08:47:35 UTC 2019 aarch64 Linux
localhost:/# free -m
              total        used        free      shared  buff/cache   available
Mem:            918          49         790          36          78         834
Swap:             0           0           0
localhost:/# df -m
Filesystem           1M-blocks      Used Available Use% Mounted on
devtmpfs                    10         0        10   0% /dev
shm                        459         0       459   0% /dev/shm
/dev/mmcblk0p1             970        65       905   7% /media/mmcblk0p1
tmpfs                      459        36       423   8% /
tmpfs                       92         0        92   0% /run
/dev/loop0                  24        24         0 100% /.modloop
localhost:/#

[hippy]

I have no personal desire to see 64-bit on a Pi

So, what has this all been about then ?

I am not sure what "this" you refer to.

You've made a lot of noise about something you now claim not to be interested it

Call it "noise" if you want. I was just contributing to a thread of discussion, giving my perspective. And I don't recall ever saying I wasn't interested in 64-bit and related issues.

My two posts in this thread were (1) that it's my opinion that 64-bit is over-rated but would likely have to be adopted, and (2) that it was my belief the RPT would be able to support both 32-bit and 64-bit concurrently.

You then seemed to be challenging that second post by asking if I knew how many staff were in the software team, to which I have additionally responded.

[fruitoftheloom]

3+ years of going round in circles and yet again no resolution.

32bit Userland and an appropriate Kernel / firmware is the way forward as has been mentioned...

..this solution work in x86 Debian RPD !

[hippy]

32bit Userland and an appropriate Kernel / firmware is the way forward ...

But what of software applications which insist on a 64-bit userland to work ?

And what consequences will that have for a 32-bit userland Pi ?

It may be the way forward for now, but for how long ?

[dickon]

There aren't very many of those, and of the ones I can think of, they're all server processes. The Pi Foundation are an educational charity; servers aren't really their target. If you need that sort of software, you're probably quite capable of running it without their help...

[fruitoftheloom]

32bit Userland and an appropriate Kernel / firmware is the way forward ...

But what of software applications which insist on a 64-bit userland to work ?

And what consequences will that have for a 32-bit userland Pi ?

It may be the way forward for now, but for how long ?

Considering the target audience of the Raspberry Pi SBC it is a non issue at this present time.


IF a user needed a full ARM64 Operating System they will quite likely be savvy enough to use a Community Supported Operating System such as Ubuntu-Mate.

[webbsmurfen]

So why not continue to run 32bit and make some kind of solution/simulator for those 64 bit browsers. Is that possible? I know that you can run 32 bit in 64 bit OS, at least in Windows but is that doable in a 32 bit OS to do the opposite?

[jdonald]

webbsmurfen: You can't do that without using a 64-bit kernel, which inevitably brings in some support challenges. If keeping the 32-bit kernel and somehow making this happen, it has been done on Mac OS X and I asked if that were possible on Stack Exchange a while back: What does it take to run 64-bit userland software on a 32-bit kernel?

a few pieces of software that are 64 bit Arm only to compile/install on my pi. Openmw and Dolphin are probably the 2 biggest.

OpenMW tutorials for Raspbian have been around for a while and don't seem to require aarch64.

Dolphin: I think you've found a good poster child once one of these 64-bit distros is ready. A couple weeks ago on reddit someone posted Dolphin on a Pi 3 using Windows on ARM for Pi. It crawled faster than expected considering that it had no 3D acceleration, so with some optimization and speed hacks I could envision this becoming usable on a Pi 4.

Reference: Dolphin 2014 blog post

I know my points are going to get buried with all the traffic in this thread, but figured this bit was worth highlighting.

[hippy]

sakaki seems to have been doing all sort of things to get 64-bit running under 32-bit but I am not sure how integrated all that is, or how accurately "easily" applies -

https://www.raspberrypi.org/forums/view ... p?t=232417

[jdonald]

As mentioned, that requires running a 64-bit kernel.

[bomblord]

webbsmurfen: You can't do that without using a 64-bit kernel, which inevitably brings in some support challenges. If keeping the 32-bit kernel and somehow making this happen, it has been done on Mac OS X and I asked if that were possible on Stack Exchange a while back: What does it take to run 64-bit userland software on a 32-bit kernel?

a few pieces of software that are 64 bit Arm only to compile/install on my pi. Openmw and Dolphin are probably the 2 biggest.

OpenMW tutorials for Raspbian have been around for a while and don't seem to require aarch64.

Dolphin: I think you've found a good poster child once one of these 64-bit distros is ready. A couple weeks ago on reddit someone posted Dolphin on a Pi 3 using Windows on ARM for Pi. It crawled faster than expected considering that it had no 3D acceleration, so with some optimization and speed hacks I could envision this becoming usable on a Pi 4.

Reference: Dolphin 2014 blog post

I know my points are going to get buried with all the traffic in this thread, but figured this bit was worth highlighting.

Hey thank you for reaching out.

The openmw team dropped support for 32bit arm installs about 6 months ago (at least that was the last arm related package release I could find and the commit mentions dropping support for 32 bit arm on the next release) Even setting up a frankendeb package with some old repositories to get the dependencies no longer works (at least on the pi 4).

As for Dolphin yea... as your post details it would be great but doesn't currently work. I would love to try it and see if I can't get some less demanding games running. I have an active topic on the forum where I tried to compile it and basically was given a "tough luck" after I found out that the issue was the Pi 4 Raspbian running a 32 bit userland as they don't support it.

[jdonald]

Good to know about OpenMW.

The Dolphin package is provided on Debian aarch64, so Pi 4 users could try this today without building from source.
1. Grab Sakaki's 64-bit kernel Raspbian image at https://isshoni.org/downloads/ and write it to an SD card.
2. Execute debootstrap and schroot commands (about 15 minutes to build the container?)
3. sudo apt install dolphin-emu

Edit:
4. sudo chmod a+w /dev/shm
5. LIBGL_ALWAYS_SOFTWARE=1 dolphin-emu # V3D doesn't support required OpenGL 3.0 so use llvmpipe

If any games can run today,Wii games run today and that would make for a more interesting screenshot in the next 64-bit OS announcement, but it's slow.

[bomblord]

Good to know about OpenMW.

The Dolphin package is provided on Debian aarch64, so Pi 4 users could try this today without building from source.
1. Grab Sakaki's 64-bit kernel Raspbian image at https://isshoni.org/downloads/ and write it to an SD card.
2. Execute debootstrap and schroot commands (about 15 minutes to build the container?)
3. sudo apt install dolphin-emu

If any games can run today, that would make for a more interesting screenshot in the next 64-bit OS announcement.

I've actually set up Sakaki's setup and installed the dolphin-emu package it throws an error about not being able to create a window after installing.

[jdonald]

Okay this might take some debugging, which I guess I could try now even on a Pi 3B+.

First thing that comes to mind is that I'm not sure if environment variables automatically propagate into the chroot, so if $DISPLAY is blank, try:

Code: Select all

export DISPLAY=:0

before launching Dolphin.

Other times it's something more involved, like in that similar thread I had to run strace to rootcause the issue with Firefox launching.

[pagenotfound]

What I'm getting out of this thread is that some people think it would totally justified that the RPF spend an additional 1.5 million a year so they can keep playing a f...ing RPG and maybe fool around with some database system that belongs on a Google-sized server farm, not on a Pi.

Has anybody provided solid statistics that show how much faster Debian and all its applications run on 64 bit? On ARM? On 4 GB RAM or less? (Let's be nice and not ask about the memory consumption)

Without such statistics I'm going to regard all this talk about instruction sets and multitudes of registers as fantasy. I suspect that the benefit of an increasing number of registers rolls off very quickly. What you want is L1 cache and fast RAM.

It seems some people, when they were still young and impressionable, came across an article by a clueless journalist about the wonderful new world of 64 bit. The article was just a couple of press releases fused into one, but our young folks thought "Yesss, more is better, I need this.."

[bomblord]

What I'm getting out of this thread is that some people think it would totally justified that the RPF spend an additional 1.5 million a year so they can keep playing a f...ing RPG and maybe fool around with some database system that belongs on a Google-sized server farm, not on a Pi.

Has anybody provided solid statistics that show how much faster Debian and all its applications run on 64 bit? On ARM? On 4 GB RAM or less? (Let's be nice and not ask about the memory consumption)

Without such statistics I'm going to regard all this talk about instruction sets and multitudes of registers as fantasy. I suspect that the benefit of an increasing number of registers rolls off very quickly. What you want is L1 cache and fast RAM.

It seems some people, when they were still young and impressionable, came across an article by a clueless journalist about the wonderful new world of 64 bit. The article was just a couple of press releases fused into one, but our young folks thought "Yesss, more is better, I need this.."

I have no stake in this other than that I would like to see an official and fully supported 64 bit setup. I have made no arguments about how much money should be spent or anything else. A topic popped up about 64 bit support and if we want it and I threw my hat in the yes category as a few pieces of software I want to use are 64bit arm only. And yes it's mainly to as you put it..... to play an f...ing RPG. What exactly is wrong with wanting to play an RPG on my raspberry pi?

[geev03]

Is this the best case of memory and disc usage achievable on a 64 bit RPi hardware running a 64 bit OS ?

Code: Select all

login as: gv
gv@192.168.1.234's password:
Welcome to Alpine!

The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See <http://wiki.alpinelinux.org/>.

You can setup the system with the command: setup-alpine

You may change this message by editing /etc/motd.

localhost:/$ su
Password:

localhost:/# apk update
fetch http://uk.alpinelinux.org/alpine/v3.10/main/aarch64/APKINDEX.tar.gz
3.10.1 [/media/mmcblk0p1/apks]
v3.10.1-59-g08cb18d753 [http://uk.alpinelinux.org/alpine/v3.10/main]
OK: 5625 distinct packages available
localhost:/# uname -a
Linux localhost 4.19.58-0-rpi #1-Alpine SMP PREEMPT Thu Jul 11 08:47:35 UTC 2019 aarch64 Linux
localhost:/# free -m
              total        used        free      shared  buff/cache   available
Mem:            918          51         787          36          79         833
Swap:             0           0           0
localhost:/# df -m
Filesystem           1M-blocks      Used Available Use% Mounted on
devtmpfs                    10         0        10   0% /dev
shm                        459         0       459   0% /dev/shm
/dev/mmcblk0p1             970        65       905   7% /media/mmcblk0p1
tmpfs                      459        37       423   8% /
tmpfs                       92         0        92   0% /run
/dev/loop0                  24        24         0 100% /.modloop
localhost:/#

[Heater]

No of course not:

Code: Select all

dataplicity@pi64-aalto:/$ uname -a
Linux pi64-aalto 4.11.12-pi64+ #1 SMP PREEMPT Sun Jul 30 20:18:20 CEST 2017 aarch64 GNU/Linux
dataplicity@pi64-aalto:/$ free -m
              total        used        free      shared  buff/cache   available
Mem:            919         163         100          18         655         722
Swap:             0           0           0
dataplicity@pi64-aalto:/$ df -m
Filesystem     1M-blocks  Used Available Use% Mounted on
/dev/root          30011  5020     23756  18% /
devtmpfs             455     0       455   0% /dev
tmpfs                460     0       460   0% /dev/shm
tmpfs                460    19       441   5% /run
tmpfs                  5     0         5   0% /run/lock
tmpfs                460     0       460   0% /sys/fs/cgroup
/dev/mmcblk0p1        63    25        38  40% /boot
tmpfs                 92     0        92   0% /run/user/1000
dataplicity@pi64-aalto:/$ 

That is my Pi 3 running Pi64 with a 32GB SD card.

[geev03]

Alpine Linux , using less than 100 MB memory & disc , is running on a Pi 3 with a 1GB SD Card..

[Heater]

I have no idea what you are getting at. Alpine Linux is designed for creating small systems. Looks like that is exactly what you have there. What is the problem and/or question?

[Gavinmc42]

PiCore will run on 128MB card

[hippy]

What I'm getting out of this thread is that some people think it would totally justified that the RPF spend an additional 1.5 million a year so they can keep playing a f...ing RPG and maybe fool around with some database system that belongs on a Google-sized server farm, not on a Pi.

My concern is none of that. I don't even want 64-bit. But I am required to have it if I want to use the latest version of software like Visual Studio Code which is 64-bit only under Raspbian.

While I can keep running the old 32-bit versions of such software those will not get the latest updates and additions which I may desire, want or need to use, won't get bug or security fixes.

Alternatively I can use some third-party 64-bit OS other than Raspbian which isn't as well supported. Or I can use some other platform entirely.

But, more importantly, where a company provides tools which require the latest 64-bit version of something which does not run on a Pi, then using a Pi and 32-bit Raspbian would not be something they could recommend to customers. That would become something customers would be advised to steer clear of rather than embrace.

I would rather be telling people to buy a Pi than telling them not to, because it is not suited to what they want to do.

[jdonald]

There's a Raspbian 32-bit build of VScode OSS 1.36.1 here: https://github.com/futurejones/code-oss ... 4/releases
It's not 1.37, although I haven't seen a 1.37 arm64 build either (?)

Just now I was able to run Luigi's Mansion in dolphin-emu on sakaki's 64-bit kernel Raspbian Pi 4 image. In addition to making sure to run within an X session, you also need to sudo chmod a+x /dev/shm anytime you start a new chroot session. Same issue with Firefox arm64 or anything that calls shm_open().

As of now it's too slow to be playable (see kernel thread).

[ejolson]

Has anybody provided solid statistics that show how much faster Debian and all its applications run on 64 bit? On ARM? On 4 GB RAM or less? (Let's be nice and not ask about the memory consumption)

For most people it's not so much about how fast but whether a program even runs on 32-bit.

Since it is difficult for many open-source projects to maintain 32-bit compatibility, more and more have become 64-bit only. Even with only 4GB of RAM there is a convenience in having a large virtual address space that favours 64-bit; moreover, almost all desktop computers are 64-bit and those machines are still the development target for most desktop and server applications.

From a limited resource point of view, since it is becoming more and more difficult to make a 32-bit operating system work well, it would simplify things to go 64-bit. Unfortunately, it appears the device drivers for the Raspberry Pi are not quite ready for that. Moreover, while the driver problem is likely to be solved soon, there is still the requirement that Raspbian be compatible across the entire Raspberry Pi line.