Gentoo on bpi-f3

I’m completing the instructions on how to build an image for the bpi-f3 in Gentoo from the ground up:

  • u-boot and opensbi right now do not have an ebuild, I’m using the latest bianbu forks for them
  • linux-6.1.15 + vendor support is also externally built, with patches to enable sensors and a backport that fixes the multithread support so rust can run fine.
  • I leveraged crossdev directly to make building all faster.
  • It sports gcc-14.1.1_p20240622 and glibc-2.39-r9

Since gcc can autovectorize RVV1.0 I made a very experimental image enabling the vector extension and setting the vl to 256 since that’s what the CPU supports.

While I’m trying to write everything down here is the first image built this way, in case you want to experiment with it. (beware it has few known broken bits here and there)

1 Like

Cheers for your work. I got Gentoo working on mine a couple of days ago.

Thought id check your image out to see if I had missed anything obvious, but /etc/portage is empty? is this to be expected? I admit ive not booted it and just mounted it via kpartx to have a look but was curious.


The image is incomplete since I wanted to make sure it booted and didn’t populate it with the bits catalyst adds, it is missing the make.conf since it got created as a crossdev experiment.

Hopefully I’ll manage to complete it during this weekend.

If you have a working rootfs you may just update the kernel and if you want to risk a bit more try rebuilding with CFLAGS=-O3 -march=rv64gcv_zvl256b.

Ah you mean -march=rv64gcv_zvl256b?

Quick question though, you had any luck getting X working? llvm 18 doesnt compile and 17 does but spits out a load of errors that I need to try and figure out.

Yes, typo.

I did not try to use the frame buffer at all so far. I’ll try building it soon.

The scripts I’m preparing are/will be in GitHub - lu-zero/crossdev-stages: Build Gentoo stages leveraging crossdev, but just using a standard stage3 and rebuilding as needed did work well.

1 Like

I got to test a bit more and I suggest to stay clear of rv64gcv_zvl256b, it seems to produce code that assumes it is ok to unaligned vector loads when it is not.

For those curious here is the upstream bug for gcc-14.

1 Like