Talk:Raspberry Pi 3 64 bit Install

From Gentoo Wiki
Jump to:navigation Jump to:search
Note
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (~~~~), and indent successive comments with colons (:). Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.

dev-vcs/git segfaults on commit with specified CFLAGS

Talk status
This discussion is still ongoing as of 24 August 2018.

See https://bugs.gentoo.org/662260. Replacing "-march=armv8-a+crc -mtune=cortex-a53" with "-march=native" (or removing it) produced a working git. Otherwise, most any operation beyond cloning a repo would cause a segfault.

--Salfter (talk) 15:12, 24 August 2018 (UTC)

binutils

Talk status
This discussion is still ongoing as of 6 March 2018.

Hint: binutils-2.30 fails with https://sourceware.org/bugzilla/show_bug.cgi?id=22764, binutils-2.29.1 works

Hmm. It seems to work for me. Its in my armv8a binhost at http://bloodnoc.org/~roy/BINHOSTS/gcc-7.x/armv8a/sys-devel/

Feel free to try it. An ebuild may not get a version bump if its changed from not working to working on a single arch. That would cause useless rebuilds for everyone already using it succesfully.

The comment 15 on that bug cvs-commit@gcc.gnu.org 2018-02-05 18:34:02 UTC, says it was fixed. Update your portage repository and try again.

--NeddySeagoon (talk) 20:32, 6 March 2018 (UTC)

Notes For 4.14.y

Talk status
This discussion is still ongoing as of 14 April 2018.

Add Simple FB

[*] Simple framebuffer support

This gets console messages until the VC4 starts.

Conversely, it appears to hang if the VC4 fails to start.

Simple framebuffer

The kernel starts with the best best built in console it can find, or none at all if there is none. Once modules load, the kernel will change the console driver, if there is a better one. That's a kernel design feature, it's not Pi specific.

With only a broken vc4 configured,the console never appears. With Simple Framebuffer and VC4, the kernel provide the hint that VC4 is broken.

Its also a design feature that the kernel cannot detect that VC4 does not work and switch back. Using both is probably the 'least worst' approach.

--NeddySeagoon (talk) 11:41, 4 January 2022 (UTC)


Host Virtualisation Support

libvirtd supports KVM on arm64 now. On the Pi, its probably only a toy but theres a challenge.

On the host, prepare to support arm64 guests.

[*] Virtualization  --->
  │ │           --- Virtualization                                                               │ │  
  │ │           [*]   Kernel-based Virtual Machine (KVM) support                                 │ │  
  │ │           <M>   Host kernel accelerator for virtio net                                     │ │  
  │ │           [ ]   Cross-endian support for vhost (NEW)

Guest Paravirtualisation Support

Turn on Paravirtualisation and all the virtio drivers

(exactly what is TBD)

--NeddySeagoon (talk) 21:11, 14 April 2018 (UTC)

brcmfmac

Talk status
This discussion is still ongoing as of 30 Oct 2018.

brcmfmac43430-sdio.txt not available

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm don't have brcmfmac43430-sdio.txt. But brcmfmac43430-sdio.AP6212.txt and brcmfmac43430-sdio.MUR1DX.txt are found.
Do they replace brcmfmac43430-sdio.txt?
When I replace brcmfmac43430-sdio.txt with AP6212 and MUR1DX I don't see any change in dmesg.

--Necktwi (talk) 14:55, 30 Oct 2018 (IST)

AFIK the linux-firmware repo never distributed the brcmfmac43430 NVRAM file. You may not see any difference in dmesg, but there are differences in the two files. The Raspbian one includes improved BT coexistence when WiFi is enabled. You should use the Raspbian one since it is the official and supported Raspberry Pi distribution.
--BT (talk) 00:00, 31 October 2018 (UTC)

/dev/serial1 for btattach service

Talk status
This discussion is still ongoing as of 13 Oct 201.

Wouldn't it be more prudent to use /dev/serial1 instead of /dev/ttyAMA0 in /etc/init.d/btattach script?

--Necktwi (talk) 11:04, 13 Oct 2019 (IST)

Raspberry Pi Firmware github master branch doesn't boot with 5.10

Talk status
This discussion is still ongoing as of 3 Jan 2022.
user $cd raspberrypi
user $git clone -b master --depth=1 https://github.com/raspberrypi/firmware

should be changed to

user $cd raspberrypi
user $git clone -b stable --depth=1 https://github.com/raspberrypi/firmware

Otherwise the device won't boot. I don't know if this is specific to 5.10 or maybe it was just my build, but I could not get past a black screen or a rainbow screen when using boot files from the master branch. Switching to the stable branch fixes this issue.

Epenguin (talk) 00:43, 4 January 2022 (UTC)

Using git master branches of anything is always a risk. That's why 'live' ebuilds are not keyworded. Go ahead and change the Wiki and maybe add a health warning that if you want to try master, go ahead but if it breaks, you can keep all the pieces. :) --NeddySeagoon (talk) 11:47, 4 January 2022 (UTC)

missing .dtb files

I had to make the .dtb files ater checking out 5.10.y and building as described here.

This makes them for me:

ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- make dtbs

aarch64 on pi 3b

For some reason I was unable to get a booting 64 bit kernel with this approach. So I gave up and did the Pi Quick Install. That worked quickly. Got sshd running, nfs, etc. So then I tried something simple. I create /boot/config.txt with this single line:

arm_64bit=1

And rebooted. Now I get this:

$ uname -a

Linux localhost 5.10.92-v8+ #1514 SMP PREEMPT Mon Jan 17 17:39:38 GMT 2022 aarch64 BCM2835 GNU/Linux

Whoopie. No cross compiling the kernel and mucking around with 32/64 bit .dtb's. default kernel8.img, and *dtb's, from stage3-arm64-openrc-20220123T230658Z.tar.xz just worked. This 64-bit install could be much simplified.

Of course now I have a 64 bit kernel running 32 bit binaries, but I'll live with that for now.

History - "the raspberry pi camera will not work natively here" 64 bit

This is no longer true. I have a Raspberry Pi Zero 2 W with the 64 Bit Bullseye running and I have been able to view the camera input using a Raspberry Pi camera 6mm High Quality using libcamera-vid. I think the assertion quote above should be removed. Yes, I'm having a difficult time getting the camera to stream through a gstreamer rtsp server, but I have been able to view the camera's output in VLC on the unit's desktop.

Jlpoole (talk) 04:28, 5 February 2022 (UTC)

Talk status
This discussion is still ongoing.

GenPi64 Project - A Continuation Of Sakaki's Effort

Rather than go through all the steps on this Install Guide, there are ready to boot images of Gentoo Linux available at the GenPi64 Project which is a fork of Sakaki's effort and builds a full ready-to-use image of Gentoo that runs on a Raspberry Pi 3/4B and Pi 2 Zero W. This fork has been in development every since Sakaki retired and is actively being developed.

Jlpoole (talk) 12:23, 12 January 2024 (UTC)

This is already referenced at Raspberry Pi but I think we should be careful about pushing too hard 3rd party binaries. --Sam (talk) 12:25, 12 January 2024 (UTC)
Good point, Sam. One of the benefits of this project is you can build your own binary using their build process encompassed in the sub project Build.Dist. Perhaps this build-your-own aspect should be highlighted? Two years ago, when I tried Build.Dist on an an AMD Bulldozer circa 2013 with 16 GB RAM, it took about 8 days and nights. Now, it can be built on an AMD 7950+ in about 8 hours according to its lead developer. I will be confirming that shortly as I finally got my Xen server running on a new 7950+ (in part thanks to your, Sam's, help on the virt-manager Bug 921099 I recently filed) where I can build my own Gentoo Linux without relying on anyone's binaries... except for Raspberry Pi's on blobs which everyone has to accept. -- Jlpoole (talk) 12:58, 12 January 2024 (UTC)
Further thought: what if Gentoo used the Build.Dist project to make images for Raspberry Pi? Two benefits: 1) no worry about contaminated binaries since the image was built under the auspices of Gentoo Foundation, 2) makes it easy for Raspberry Pi Users to try out Gentoo in an almost ready-to-run state simply by burning an image on an SD HC card (which they already do for Raspian)? The Oregon State University Open Source Lab already is hosting a Build.dist hosting a paradigm for the GenPi64 project using Jenkins. Maybe the GenPi64 project could be assimilated into Gentoo? Also, it hasn't been tried or tested, but I suspect building an image for the new Raspberry Pi V ought to be a snap and possibly require no tweaking of the current system. That would be very timely and allow Gentoo to ride on the wave of something "new" from Raspberry Pi. -- Jlpoole (talk) 15:28, 12 January 2024 (UTC)