64-bit operating system

[sakaki]

If firmware-based features like DispmanX or accelerated decode require a 32-bit kernel, isn't there zero benefit to running Fake KMS here? It seems like this might only cause issues when developing and testing true KMS apps (?)

Apologies for the delay in replying to this jdonald, I had meant to post something earlier ><

My original plan was to cut over to kms as default with release 1.3.0 of the image, but there were some residual issues thrown up during testing that I couldn't immediately resolve (for example, HDMI audio output on the PiTop variant), so I stuck with fkms as default for now (as this has been working reasonably well on 64 bit since early 2017).

With the 1.3.1 release, end-users can however easily change their driver (and some other config.txt settings) via a GUI control panel, and the system also auto-reverts to the 'last known good' config on reboot if not explicitly confirmed, to prevent people locking themselves out via inappropriate HDMI mode* etc (yes it is easy to modify the /boot/config.txt on a PC, but it is still a fiddly thing to do / explain):



The current options for driver (i.e. combo of dt overlay, kernel module and mesa userland driver) are fkms, kms and fallback framebuffer.

best, sakaki

* As a further precaution against this, the list of modes available in the drop-down is filtered to those the currently connected display reports as supporting.

[code_exec]

I'm planning on implementing something similar to sakaki's RPi3 Configuration into my Ubuntu 18.04 ARM64 desktop images at some point. While I have modified the raspi-config script to work with ARM64 and expect the firmware to be mounted at /boot/firmware, several of the functions are unusable. Changing keyboard layout, enabling the experimental OpenGL driver, and changing the GPU memory split are a few things which don't work.

[sakaki]

code_exec,

the code and ui layout for the above app can be found at https://github.com/sakaki-/pyconfig_gen (GPL-3), if that's of any use as a starting point. It's a very simple PyQt5 app; not much that is Gentoo-specific in there.

I got the idea for it from https://github.com/raspberrypi-ui/rc_gui (the GTK version of raspi-config; it calls through to raspi-config to carry out some features).

hth, sakaki

[jdonald]

Thanks for the helpful VideoCore architecture outline, 6by9.

I have yet to see the bcm2835-unicam module on any 64-bit Pi OS. Perhaps this would be a good feature for the next Gentoo release.

[Gavinmc42]

Not sure if 64bit camera access is a requirement but I suspect it would help.
One day left, last chance.
https://www.khronos.org/rfq/openvx-impl ... i-platform

I guess we will know in May if it can be done.

[rplantz]

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

Let's face it, I don't need most of the things I have, including my Raspberry Pis.

I'm rewriting my assembly language book that uses the Raspberry Pi, and I would like to use AARCH64 because it's a cleaner architecture. I want to keep things as "standard" as possible so that students don't get sidetracked working on OS issues. Thus my use of Raspian in the book.

The current version of the book works quite well. It's online. Students buy a Raspberry Pi, and they can read the book with the browser and do their programming assignments in a terminal window. The rewrite is to create a print version for a publisher.

I realize that my application is a very small percentage of RPis, and that creating a 64-bit version of Raspbian is a huge job. But it sure would be more satisfying. It's a "want" not a "need."

[davidcoton]

I realize that my application is a very small percentage of RPis, and that creating a 64-bit version of Raspbian is a huge job. But it sure would be more satisfying. It's a "want" not a "need."

[dangerous mode]
PREDICTION
64 bit Raspbian will happen.
Possibly unofficially before officially.
We just don't know when
[/dangerous mode]

[Gavinmc42]

While waiting for a 64bit Debian based Raspbian use another 64bit OS that works.
I'm using Gentoo64, mostly because of Sakaki's brilliant support.

Eventually Aarch, Suse, Fedora, Ubuntu etc will make easy to use and reliable versions too.
Debian version will then easier, most issues already solved for RPF

I suspect the 32bit interface to the VC4 stuff can be solved, by someone with the skillset and the time.
Perhaps by running 3 cores in Aarch64 and the 4th in Aarch32 state or using 32bit pointer defines?

Crystal ball gazing even with flat batteries there will be 64bit Raspbian
But I can understand why RPF don't see it as no1 priority., probably not even in the top 10 issues for them.
That will change before Pi4 is out
I'm hoping the Pi4 will be the Desktop replacement PC, that will need to be 64bit

[ejolson]

I'm rewriting my assembly language book that uses the Raspberry Pi, and I would like to use AARCH64 because it's a cleaner architecture.

Using 64-bit for the book seems like a reasonable idea. By the time the book goes to press 64-bit will likely be standard even on Raspberry Pi.

For now one could guess the official 64-bit operating system for the Pi (if and when it occurs) will be more like Debian than Gentoo. At the same time, these two operating systems differ mostly from a system administration point of view. Assembly programming is likely much the same on either. Good luck with the book!

[ejolson]

While waiting for a 64bit Debian based Raspbian use another 64bit OS that works.
I'm using Gentoo64, mostly because of Sakaki's brilliant support.

Does anyone know if Scratch 3 programming in a web browser works better using a 64-bit operating system on the Pi? There are reports that Scratch 3 on regular Raspbian lags noticeably.

[timrowledge]

Does anyone know if Scratch 3 programming in a web browser works better using a 64-bit operating system on the Pi? There are reports that Scratch 3 on regular Raspbian lags noticeably.

Wait a while and I’ll have the proper NuScratch running on AARCH64.

[ejolson]

Does anyone know if Scratch 3 programming in a web browser works better using a 64-bit operating system on the Pi? There are reports that Scratch 3 on regular Raspbian lags noticeably.

Wait a while and I’ll have the proper NuScratch running on AARCH64.

That sounds great! It would be interesting to see if NuScratch enjoys any benefits from running in 64-bit mode.

Still, I wonder whether a 64-bit browser might run the online version of Scratch 3 better than 32-bit versions of Raspbian.

[Gavinmc42]

Try this?
https://vimeo.com/163806120
Been a long time since I tried Scratch, is it now worth a second look?

[jdonald]

Anyone know where to download or how to build an aarch64 cross compiler for armhf systems? On Debian or Ubuntu for x86_64 you can just run sudo apt install gcc-aarch64-linux-gnu, but this doesn't seem to be available in any armhf repositories. Likewise, the aarch64 systems don't have a gcc-arm-linux-gnueabihf package.

This would benefit hybrid 64-bit systems like Crazyhead's, and even open up some tinkering possibilities on 32-bit Pi systems with the use of static linking and qemu.

I once built an aarch64 compiler for an armhf host using jahboater's script, but without libc and related libraries it wasn't useful by itself. crosstool-ng with it's Raspberry Pi 3 config may be the proper way to build everything, but from what I can tell requires a lot of patience for troubleshooting. Early into the process I get an error about missing aarch64-linux-gnu-gcc when building libgmp with no hints of where to go from there.

[Gavinmc42]

I used Sakaki's dual Raspbian img.
https://www.raspberrypi.org/forums/view ... 25a46ab87f
So far it seems the least painful way to get compilers going.
But Debian is a safe OS so defaults are a bit dated.

gcc 6.3, clang 3.9, fpc 3.0.0, rustc 1.24 two version of each installed with the usual apt-get.
One to cross compile to armhf and one native aarch64.
Still need to make ponyc (needs clang 3.9) and Go.

Once working on Raspian64, should be able to copy the binaries to other 64bit Pi OS's?
Probably should try newer versions, but most of those come with Gentoo64 anyway.
So I could copy them from Gentoo64 to Raspbian32/64?

QEMU GPU emulation of OpenGLES and Vulkan is making progress.
Maybe one day that x86 Raspbian will emulate OpenGLES?

Compiling compilers on the uSD card can lead to smoking hot SD cards, so from now on I intend to use a USB SSD drive.
Full Pi aarch64 RISC-V cross compiler compiling took 13+ hours.
So I was thinking Sakaki's 32/64 Raspbian could become a networked compiler compiling Pi.

Not many have done these things before so google is a bit blank.

[globiboulga666]

Hi everybody,

I'm working on a very "simple" thing that didn't get mentioned into the previous posts, and on which I believe running on a 32 bit OS is strongly reducing my performances : 64 bits "double" floating point calculation (into a 3D based point scanning / reconstruction application). I got 2 distance sensors on top of mechanical precision arms, with 250 Hz sampling for the arm (not the CPU ), and 2 KHz for both of the optical distance sensors.

Recording of the values, and high precision dating of the values (which one came before or after which one) is fast. Recording to RAM does not require any CPU power (0% from LXDE usage monitor, 13.5% (out of 400% because of 4 cores) from "top" command, and very few RAM finally.

The multi-core architecture made me possible to to multi-thread things in order to have a really fast/real time recording (no pauses/hangs on main-thread activity). Knowing the fixed sampling time of the sensors also permits to "arrange" the time-stamps in a way that perfectly recover the real-time precision (given the fact that data can only be more or less late once received, but in reality the physical time spent between each sample was the same). Time offset between robot and sensors is also taken into account. (Well just to say : it works super fine).

But : 3D reconstruction of all the recorded data is too slow. It's a big serie of different "for" loops in which "sensor 1" position and "sensor 2" positions and orientations are calculated from the robot position (and angles) and tool coordinates (offsets and cos / sin calculations). After that, for each distance measurement, we create a "intermediate robot-sensor position" which give the ability to have several measurement point between 2 received robot positions. On those values, we apply the optical measurement distance to the correct XYZ orientation (using cos, sin, and offsets) as an offset to the robot-sensor position.
Before that we also play the "timestamps correction" loop, which again, implies double calculation about period/frequency, comparisons, most "on time" values at the begining of the scan, end of the scan, so the initial time and perfect frequency is applied to overwrite "raw" timestamps.

After 5 seconds of scan, It's really fast on a modern computer (~0.5 seconds ?) but takes more than 10 seconds into the Raspberry Pi 3 B+, which is disappointing (we would have liked reception and reconstruction being outside of the GUI Windows based PC, so RPi was perfect to run those programs).
Functions have been made really clean in order to keep simplicity into all of the steps, robot position calculations are avoided if the measured value is "nothing" in order to save CPU time, and I'm reaching the limit of what I'm able to improve... before realising that "double" were 64 bits.

My point is :
It's not impossible that the code could be "improved" by experts about assembler things and guess about register access optimisations, splitting "for" loops differently with CPU pipe lining arrangements in head... but I'll have to compare results and performance with 32 "floats" to see how much it changes. Which is too bad for a 64 bits board

I also marked every 64 bits project I've seen on this forum
https://wiki.ubuntu.com/ARM/RaspberryPi ... ISO_images
https://github.com/bamarni/pi64
https://wiki.gentoo.org/wiki/Raspberry_ ... it_Install
https://github.com/Crazyhead90/pi64/releases
https://github.com/sakaki-/gentoo-on-rpi3-64bit
https://github.com/jdonald/raspbian-multiarch
https://ubuntu-mate.org/raspberry-pi/
But I'm afraid of those things that needs to learn again, try, crash, correct, debug etc and not being available/updated with the years so I'll check them carefully.

Here is for the feedback ! I'm an average dude for which 64 bits "1 cycle" double floating point calculation by the CPU would have been useful. Thanks to everyone who participated to this discussion, I hope my feedback can be useful for anyone, someday, somewhere !

[6by9]

Hi everybody,

<snip>
Here is for the feedback ! I'm an average dude for which 64 bits "1 cycle" double floating point calculation by the CPU would have been useful. Thanks to everyone who participated to this discussion, I hope my feedback can be useful for anyone, someday, somewhere !

I can't see in your post anything to say that you have actually tried it on a 64bit OS on the Pi and found it any better.

5 minutes worth of optimisation is always worthwhile.
- Trig functions are almost always painfully slow. What precision do you need on those, and you may be better using a quick lookup table instead of computing it every time. Symmetry on sine and cosine save you 75% on the lookup table, and implementing one implements the other.
- Consider what precision you need elsewhere. You'll generally save time even on an efficient processor.
- Consider the caching of the data. A modern x86 has several megabytes of cache, which is probably sufficient to swallow most of your dataset. The Pi has 256kB IIRC. Loading the same data multiple times over has a performance hit.

Horses for courses.

[jahboater]

64-bit double precision floating-point hardware is available on all Pi's.
On ARMv8 (the Pi3, Pi3B+, etc) it is fully IEEE compliant.

64-bit floating point arithmetic is done in the NEON SIMD unit which is very fast.
NEON is quad issue, so the reciprocal latency is probably less than one cycle for common things.

Floating point is the same speed with a 64-bit OS as it is with a 32-bit OS.

So I am not sure what your problem is - have you actually tried it ???
(just use type "double" in C).

64-bit integers are another matter.

[jamesh]

I've checked your post, may have missed it, but what language is your code written in?

[globiboulga666]

Hi, thanks for your answers
I'm using C++, and "double" variables.
jahboater, what you mean it that it is already using 64 bits wide instructions into the CPU ?

I didn't tried it for now, that was just something that suddenly came to me yesterday while doing the summary of what works, and what will have to be improved.

I'm not at work this week so I'll manage to find the time to test all this on next week, but I guess it means that going to a 64 bit OS won't change anything for me right ?

6by9 when I wrote the codes that are using sin and cos, for rX, rY and rZ into several calculations, I placed them into variables that are used several times after.
I already saw someone filling a L.U.T. instead of using cos and sin functions into some Microchip micro-controllers, so I guess the idea can be good. Expected precision is "the best as possible" but robot repeatability isn't better than 30 µm on almost 2 meters paths. When reaching stable motor temperature conditions. If some femtometers are going away that's not really tragic.

If some of you are curious, here is some extract of some of the main calculations loops - I'm pretty sure some of you will yell at me because of some optimisations I didn't see but you are welcome

Code: Select all

for (int i = 0; i<StilValueList->size(); i++)
{
    int Point1_rawvalue = StilValueList->at(i).v1;
    int Point2_rawvalue = StilValueList->at(i).v2;

    if ((Point1_rawvalue != 0) || (Point2_rawvalue != 0))
    {
        double vp1 = Point1_rawvalue;
        double vp2 = Point2_rawvalue;

        vp1 = (vp1 / 32767) * measuringRange; //to µm
        vp2 = (vp2 / 32767) * measuringRange; //to µm

        double X, Y, Z, RX, RY, RZ;
        bool bRet = GetRobotPosition(X, Y, Z, RX, RY, RZ, StilValueList->at(i).time - timeOffset, *RobotPosList);

        if (bRet == true)
        {
            
            double XTool[3], YTool[3], ZTool[3];
            WprToXyzWorld(RX, RY, RZ, XTool, YTool, ZTool);

            if (vp1 > 0.0) 
            {
                double XyzPointToWrite[3];
                XyzPointToWrite[0] = X + (ZTool[0] * (vp1 - altitude_at_TCP) / 1000.0);
                XyzPointToWrite[1] = Y + (ZTool[1] * (vp1 - altitude_at_TCP) / 1000.0);
                XyzPointToWrite[2] = Z + (ZTool[2] * (vp1 - altitude_at_TCP) / 1000.0);

                QString localText;
                localText.sprintf("%lf\t%lf\t%lf\t%lf", XyzPointToWrite[0], XyzPointToWrite[1], XyzPointToWrite[2], vp1);
                if (dataName.isEmpty() == true) localText += "\n";
                else localText += "\t" + dataName + "\n";
                textBuffer += localText;
            }
            
            if (vp2 > vp1) 
            {
                double XyzPointToWrite[3];
                XyzPointToWrite[0] = X + (ZTool[0] * (vp2 - altitude_at_TCP) / 1000.0); 
                XyzPointToWrite[1] = Y + (ZTool[1] * (vp2 - altitude_at_TCP) / 1000.0); 
                XyzPointToWrite[2] = Z + (ZTool[2] * (vp2 - altitude_at_TCP) / 1000.0); 

                QString localText;
                localText.sprintf("%lf\t%lf\t%lf\t%lf", XyzPointToWrite[0], XyzPointToWrite[1], XyzPointToWrite[2], vp2);
                if (dataName.isEmpty() == true) localText += "\n";
                else localText += "\t" + dataName + "\n";
                textBuffer += localText;
            }
        }
    }
}

Code: Select all

void WprToXyzWorld(double RX, double RY, double RZ, double *X,double *Y,double *Z)
{
    double W = RX;
    double P = RY;
    double R = RZ;
    
    double ModuleXY, ArgumentXY; 
    double DblMemo; 

    //robot is speaking in degrees
    W = W * 6.283185307179586476925286766559 / 360.0;
    P = P * 6.283185307179586476925286766559 / 360.0;
    R = R * 6.283185307179586476925286766559 / 360.0;

    //calculated once
    double CosW, SinW, CosP, SinP, CosR, SinR;
    CosW = cos(W); SinW = sin(W);
    CosP = cos(P); SinP = sin(P);
    CosR = cos(R); SinR = sin(R);

    //easy for X
    X[0] = CosP * CosR; 
    X[1] = CosP * SinR; 
    X[2] = -SinP; 
    
    //not too hardcore for Y
    DblMemo = SinW*SinP; 
    ModuleXY = sqrt( (CosW*CosW) + ( DblMemo * DblMemo ) );
    ArgumentXY = atan2(CosW,DblMemo);
    Y[0] = ModuleXY * cos(ArgumentXY + R); 
    Y[1] = ModuleXY * sin(ArgumentXY + R); 
    Y[2] = SinW*CosP; 

    //almost same for Z
    DblMemo = CosW*SinP; 
    ModuleXY = sqrt( (SinW*SinW) + ( DblMemo * DblMemo ) ); 
    ArgumentXY = atan2(-SinW,DblMemo);
    Z[0] = ModuleXY * cos(ArgumentXY + R);
    Z[1] = ModuleXY * sin(ArgumentXY + R);
    Z[2] = CosW * CosP; 
}

PS : Sorry in advance if this has finally nothing to do in this subject, but you will probably be better than me into ensuring that.
If some test has to be done, of course I'll do those tests ASAP (but ASAP is next week unfortunately).

[jahboater]

Hi, thanks for your answers
I'm using C++, and "double" variables.
jahboater, what you mean it that it is already using 64 bits wide instructions into the CPU ?

I never said anything like that.
I think you mean ....
"double" variables are 64-bit floating point - called "binary64", nothing to do with instruction width (which is always 32-bits here).
So you are currently using the 64-bit floating-point hardware - and your "double" variables will be held in 64-bit floating-point registers.
When you add two doubles together, say "a = b + c", it gets compiled into something like "fadd d1,d4, d3", where d4 etc are 64-bit registers.

The sin() and cos() functions in the C math library are as accurate as it gets (for the precision).

[okenido]

I don't think 64 bit is worth for the raspberry pi 3, i did several tests in bare metal and AARCH64 was slower by 15-20%, probably due to the fact that pointers are twice the size compared to 32 bit so the memory bandwidth is more easily saturated.
Even my code using NEON instructions performed worse, despite the higher number of registers available.
It may depends on the application, but 64 bit in overall seems overrated for this device.
I think we need to compare this to the x86 PCs, the transition to 64 bit happened when we needed more than 4GB RAM, and at this time x86 CPU's were already more powerful than a RPI 3. Maybe it will make sense for the RPI 4 depending on its hardware

[algorithm]

- Trig functions are almost always painfully slow. What precision do you need on those, and you may be better using a quick lookup table instead of computing it every time. Symmetry on sine and cosine save you 75% on the lookup table, and implementing one implements the other.

In C, per degree:

Code: Select all

static const float sinetable[91] = {
	0.0f     ,0.017452f,0.034899f,0.052336f,0.069756f,0.087156f,0.104528f,0.121869f,0.139173f,0.156434f,
	//etc., snipped
	1.0f
};

float sine(int deg)
{
	// domain = [-179..180]
	while (deg <= -180)
		deg += 360;
	while (deg > 180)
		deg -= 360;

	// per quadrant
	if (deg >= 90)
		return sinetable[180 - deg];
	if (deg >= 0)
		return sinetable[deg];
	if (deg >= -90)
		return -sinetable[-deg];
	return -sinetable[180 + deg];
}

float cosine(int deg)
{
	// domain = [-179..180]
	while (deg <= -180)
		deg += 360;
	while (deg > 180)
		deg -= 360;

	// per quadrant
	if (deg >= 90)
		return -sinetable[deg - 90]; 
	if (deg >= 0)
		return sinetable[90 - deg];
	if (deg >= -90)
		return sinetable[90 + deg];
	return -sinetable[-deg - 90];
}

[algorithm]

My guess is the change might be driven not by speed/addressing requirements (going forward) or backwards hardware compatibility, but software availability. E.g. I see VS Code and Electron are eol-ing their 32-bit support.

[Gavinmc42]

I see VS Code and Electron are eol-ing their 32-bit support.

And the main Browser guys EOL 32bit versions?

Chromium and Firefox seem to work better in Sakaki's Gentoo64, that's a good enough reason for me.
Apart from the fact I want to learn Arm 64bit coding on the Pi's.