Raspbian 64-bit

[knuxyl]

Are the Raspbian developers actively developing Raspbian 64-bit? The code is available for the 64-bit kernel, a couple of distros already use it like Devuan and SUSE.

[fruitoftheloom]

Are the Raspbian developers actively developing Raspbian 64-bit? The code is available for the 64-bit kernel, a couple of distros already use it like Devuan and SUSE.

AFAIAA there is no real benefit in developing a ARM64 Raspbian, do the RPF have the resources to support 2 distro's ??



CentOS & Fedora ARM64: viewtopic.php?f=51&t=151274

[jamesh]

Are the Raspbian developers actively developing Raspbian 64-bit? The code is available for the 64-bit kernel, a couple of distros already use it like Devuan and SUSE.

Not, I believe they are all third party efforts. It's a manpower/support issue.

[bitbank]

A 64-bit OS for the RPi will eventually happen, but you're on your own for the moment. If you want to run aarch64 Linux today, there are less frustrating ways of doing it. If you need a board with exposed I/O like the RPi, you can buy a Pine64, ODroid, NVidia TX1/TX2, Firefly RK3399, or one of the 96Boards offerings (e.g. Dragonboard 410c). I have a Dragonboard410c. It's basically the same CPU as the RPi3, but faster RAM and I/O. I also have aarch64 Linux running on my Acer Chromebook R13 using Crouton with a minor change to the installation script (see here for instructions - https://github.com/dnschneid/crouton/pull/2874). The R13 is a nice ARM laptop that runs 5-10x faster than the RPI3 and has great battery life. It's both frustrating and sad that aarch64 Linux is taking so long to get into the market. ARM's 64-bit server and end-user efforts appear to be rolling out too slowly.

[Koeshi]

A 64-bit OS for the RPi will eventually happen, but you're on your own for the moment.

SUSE and Arch Linux did it months ago (admittedly the AL version has limited functionally, but it is running a 64-bit kernel).

[Olle2]

Hi guys, I still don't know what I'm doing except having fun!
Found this https://github.com/bamarni/pi64/releases
Tried the first release but got no sound, have not yet tried the second.

“This must be Thursday,' said Arthur to himself, sinking low over his beer. 'I never could get the hang of Thursdays.”

Happy linuxing! Olle

[Olle2]

The latest release has been improved a lot by bamarni.
Try https://github.com/bamarni/pi64/releases and have fun with linux! Olle2

[Olle2]

Updated files are available on https://files.devuan.org/devuan_ascii_rc/embedded/
The PI3B+ is running using all its 64bits, LXQT.
Not Raspbian of course.

Having a nice summer already, here up-north!

[larsth]

Are the Raspbian developers actively developing Raspbian 64-bit? The code is available for the 64-bit kernel, a couple of distros already use it like Devuan and SUSE.

AFAIAA there is no real benefit in developing a ARM64 Raspbian, do the RPF have the resources to support 2 distro's ??



CentOS & Fedora ARM64: viewtopic.php?f=51&t=151274

AFAIAA there is no real benefit in developing a ARM64 Raspbian,

... is wrong. The feature of a 64-bit kernel is virtual memory.

If one has a SSD and a Linux 64-bit kernel it is possible to do:

Open a file - let us say it is 1023 GB in size - and memory map (mmap) it. Now, if a program access a page(=a 4 KB block of memory) of those 1023 GB that are in the virtual memory - backed by the file - the kernel does this:

If there is enough unused physical RAM it will use a page from there.

If there isn't enough free physical memory it does this:

1. The kernel pages out (write to disk) the least used page.
2. The kernel then write the requested page to the now free page in physical memory.
3. The kernel makes a contex swith (from the kernel to the program), and then
4. The MMU of the CPU repeats the machine code instruction that resulted in the page fault.

Virtual memory performance increases by 100% (by a factor of 2), if the pages are mmap'ed read-only. The reason is that the kernel knows that it doesn't need to write a page back to disk, because it can just reread the page again from disk

All this happen without the program knowing this had happened.
This is one of the purposes of virtual memory - run a program on top of an abstraction of memory.

In this example the Raspberry Pi has 1 TB (=1024 GB) of virtual memory, but as every one knows is has "only" 1 GB of physical memory.

If the program, fx a web server - that had mmap'ed a file - and has a very low amount of connections it can actually host a 1 TB file in (virtual) memory. It is, however, more likely that it has lazy mmap'ed many files read-only.

Too many people think about memory as of the computers in the 1970s/1980s - that a program allocates physical memory - it doesn't - It lives in virtual memory, and no where else.

The kernel make decisions about when, and how much a program would use of:

• physical memory,
• anonymous swap (swap files and/or swap partitions)
• and in this example virtual memory that are backed by a file
• This can be boiled down to that the kernel decides everything regarding memory for very program.

Memory that are backed by a file (non-anonymous swap) has preference over anonymous swap.

/Lars

[jahboater]

Too many people think about memory as of the computers in the 1970s/1980s - that a program allocates

You have forgotten Multics in the late 60's that had single level memory - the user could not distinguish between memory (as in ram chips) and disk. And wasn't the Intel 432 based on the same idea?

[larsth]

Too many people think about memory as of the computers in the 1970s/1980s - that a program allocates

You have forgotten Multics in the late 60's that had single level memory - the user could not distinguish between memory (as in ram chips) and disk. And wasn't the Intel 432 based on the same idea?

I am not that old to know about Multics, and Intel 432.

I began using my Amstrad CPC 664, when I was 16 years old (in 1986).
i remember the first time I made machine code instructions by hand to the Zilog Z80 CPU. Very funny to do thing that was not possible by using BASIC.

CP/M 80 / Logo was also great fun

/Lars