Here is an interesting article on enabling the built-in 64 bit kernel in Raspbian. (which includes R4R and possibly ROS)
The instructions, summarized, are:
Backup your current instance to a spare SD card.
Run rpi-update and allow it to continue despite the dire warnings.
Since you have a backup, (You DID make a backup, right?), you can safely ignore them.
Reboot and run uname -a and you should see:
Linux raspberrypi 5.4.59-v7l+ #1336 SMP Wed Aug 19 16:09:04 BST 2020 armv7l
The “armv7l” is the key that you’re still running a 32 bit kernel.
In the [Pi-4] section of /boot/config.txt, add arm_64bit=1, reboot, and re-run uname -a.
You should see:
Linux raspberrypi 5.4.59-v8+ #1336 SMP PREEMPT Wed Aug 19 16:16:01 BST 2020 aarch64 GNU/Linux
The “aarch64” is the key that you’re now running the 64 bit kernel.
For Pi-3 users:
If you want to try this with a Pi-3, do everything noted above, except that you put the arm_64bit=1 line somewhere else in the config.txt file.
Give it a try and see how it works.
Don’t forget to post results.
P.S.
Your Mileage May Vary, this is why you made a backup.
(You DID make backups, right?)
Things that require getting Down and Dirty with the hardware itself, (like flashing firmware), may not work or may do unpredictable things.
i.e. I would expect it not to work, but if it does, interesting!
In the true spirit of The Experimenter’s, (Hacker’s), Creed, don’t go whining to Modular Robotics/Dexter if things don’t work out right and/or it crashes your robot.
Instead, report results here and revert to your backup. (Removing/commenting out the arm_64bit=1 line should also work. It’s worth a try.)
Â
Everyone said, (and they still say), that Nikola Tesla was nuttier than a fruit-cake.
(George Westinghouse, (a brilliant man in his own right), used to say Tesla was the smartest man he’d ever met and the only man he knew who had a really good grip on electrical field theory.)
Aren’t YOU the one that invited me to Boldly Go where No 'Bot Has Gone Before?
Â
Not to mention that, at least on the last couple of Buster releases, 99% of the changes are unnecessary as they are already baked in.
Just to “clear the air” (and punch the “reset” button), after the last series of experiments, I reverted back to a clean 2019-12-19 Buster release and copied my experimental folders and the few changes - primarily in the crontab file - needed to bring it up to date.
Since it already includes the needed kernel8.img file for 64 bit support, all I had to do was plop the arm_64bit=1 statement into my config.txt and away I go!
So far, (famous last words!), everything has been OK. If anything goes wrong all I have to do is comment out the one line in my config.txt file, reboot, and I’m back to the normal installation.
Because most of the “userland” utilities are 32-bit based, there may not be a lot of improvement. Possibly some, but not blazing speed-ups.
However things that are primarily kernel based, (I/O is a good example), will see a significant speedup.
Because this kernel is (supposedly) set to use “hardware” based preemption, it’s less likely that a blocking process will time-starve other, possibly unrelated, processes. Of course, if transactions need to be atomic or protected, it’s good programming practice to make sure by using the appropriate locks and/or semaphores.
This may result in the system being more “snappy” overall since potential time-hogging processes will be forced to yield regularly.
Part of what I am doing here is to compare the userland functionality of both systems.
I set up the 64 bit environment by un-commenting the “magic words” in Charlie’s config.txt file.
I do stuff, like development or messing around.
If I notice any discrepancies, I revert back to the 32 bit environment by commenting out the “magic words” and rebooting.
If the discrepancy disappears, I document it.
If it doesn’t, I figure out what happened, fix it, and then revert back to the 64 bit kernel and see if the behavior is the same.
If nothing else, I am (hopefully) collecting useful data for the people working on the 64 bit version of Raspbian. Â If I discover something specific to the 'bot, I am hoping that communicating this to M.R. will help.
One gentleman over at the Raspberry Pi O/S 64 bit forum posted a very interesting “benchmark” over at the Pianoteq form.  Apparently this guy is a music enthusiast and is using his Pi as a recording/synthesizing/rendering tool, (impressive by any standard), and posted a benchmark of performing some music conversion on both 32 and 64 bit kernels.
I’m no music synthesizer expert, but it looked impressive to me.
Rendering, either audio or video, is a processor intensive task not unlike AI/speech recognition.  Perhaps it’s time to give the 64 bit kernel a spin?
P. S.
The entire thread looks impressive from the point of view if trying to squeeze every ounce of performance from each and every processor cycle.
In other words, if you’re doing things that require near real-time performance, this might be the difference between a Pi that’s merely adequate and a Pi that qualifies as a Hot Smokin’ Weapon.
Not as bloody as it sounds. There are still a few quirks, but compared to the releases of a few months ago, it’s ready for release!
I have an installation of Raspberry Pi O/S 64 that I want to try a spin of R4R on.
One experiment I am going to try is installing a 64 bit image, running the special "curl [something or other, I’ll go look it up] command that loads the lion’s share of the environment, and try some of the stuff I’m doing in a 64bit environment with many utilities re-released as 64-bit executables.
I might also try copying over the Dexter and dexter_update directories and desktop and see how that goes.
It really might be worth a try.
@cyclicalobsessive, If I come up with a spin that doesn’t fall flat, would you like a copy?
I don’t have an automated regression test suite for Carl, and just changing a line a day is breaking less used functions but not revealing the issues laying in wait until just when I need to be able to trust those functions.
I went over a year before trying any R4R update and then “moved in” to a now withdrawn version. While the move taught me a lot, I can’t point to any operational benefits for Carl. I’m not signing up for another OS test.
I’m always too focused on creating new features, to stop progress in order to build a regression test suite. I would like to have a second GoPiGo3 to try concepts out on, but that would also take time away from working on Carl.
Carl has become so non-deterministic that he needs an independent “Health Monitor” to alert me when some operating parameter starts exceeding “normal” (cpu temp, swap space, cpu load, loss of WiFi, I2C clogged, and the parameter I have not integrated a sensor for yet - current draw.)