RPi4 Compatibility?

[tdubz1]

Is your Gentoo OS be compatible with the new RPi 4 or will it be? The new Pi has a much faster processor and you can buy a model which has 4GB RAM. Just wondering because I am thinking of purchasing one and think that these specs will make a great difference to the performance of the Pi and would be very cool to have a 64-bit OS working on it. Cheers, tdubz1

[sakaki-]

The current version isn't compatible with the Pi4 as it stands. However, I have just received one of these new Pi boards, and have started to play with it.

So, no promises, but we'll see what comes along as regards a bootable image ^-^

[sakaki-]

Just FYI, I've been able to bring the gentoo-on-rpi3-64bit userland up on an RPi4 under a bcm2711_defconfig kernel (brief notes here).

Screenshot:

This is only a proof of concept: any production-quality release will be gated on upstream progress on the 64-bit kernel, which (at this time) is not ready for prime time (1GiB memory clamp, SD card issues etc.) So we're realistically 1 to 2 months away from that.

Best, sakaki

[tdubz1]

Sounds good! Looking forward to the future of this!

[xlazom00]

It will be nice if we have whole image compiled specifically for cortex A72
and other one for cortex A53 to see difference.

[sakaki-]

I am working on the 1.5.0 release of the image now; as you may have seen, the 64-bit kernel autobuilds for the Pi4 are now in place, which is a major element of this, so things are getting closer.

As to the userland binaries, I intend to switch from -march=armv8-a+crc -mtune=cortex-a53 to -march=armv8-a+crc -mtune=cortex-a72 on the 1.5.0 image, and for the binhost going forward. Since the arch is common (and only mtune is changing) between the Pi3 and Pi4 processors, code generated in this way will still run on the older generation Pi3 board (per the gcc docs), but will be optimized for the out-of-order pipeline provided by the newer Pi4 SoC. I think this is a valid approach, since most people will shift to Pi4s in time, and the performance difference penalty (of running A72 tuned code on an A53) is likely to be small. And in any event, I don't have the support bandwidth to maintain a full binhost for two separate mtune variants going forward.

There's also an argument for sticking with A53 tuning of course, since that's the slower processor where the performance difference will be more noticeable, but, having weighed things up, I have come to the conclusion (as just mentioned) that shifting to A72 tuning is the better approach.

[sakaki-]

Brief update on this - the full userland has now been rebuilt under -march=armv8-a+crc -mtune=cortex-a72, and pushed to the binhost. The Portage rsync server has also been updated (new timestamp 4 Aug 2019).

So, if you know what you are doing you can now try to install tbz2 binary packages for the new mtune ^-^

With kernel autobuilds and the ground-up (emptytree) userland rebuild done, image assembly for 1.5.0 now in progress. Still some things to complete, like an updated pyconfig_gen application etc. But, ETA around 2 weeks to release, barring real-world NMIs.

Best, sakaki

[jdtsmith]

Does this build preserve OMX/MMAL capability?

[sakaki-]

@jdtsmith, MMAL isn't something I've looked at recently - my bandwidth has been saturated getting the 1.5.0 image together tbh (now in hard freeze), and the v4l2{,m2m} stuff provides basic camera / h/w codec access for 64-bit userland right now.

The best thing might be to post a question on the raspberry pi forums, perhaps in this thread (although it is a bit old now), to query the status. Last time I did look at this, there were user/kernel space pointer-size mismatch issues which prevented a 64-bit userland from accessing MMAL/OpenMAX IL correctly (all distros, see e.g. this post by 6by9, ff), but tbh I'm not sure if these have recently been addressed. Sorry I can't be of more help on this one right now ><

Best, sakaki

[sakaki-]

1.5.0 is shipped
Enjoy ^-^

Best, sakaki

[sakaki-]

Closing now.

[sakaki-]

@jdtsmith,

an RPi-engineer-authored PR for 64-bit MMAL userland (with the pointer remapping etc.) is now available for test (raspberrypi/userland#586). So hopefully this feature will be available soon, certainly for release v1.5.2 of this image.

hth, sakaki

[jdtsmith]

Thanks. In the meantime @tmm1 has managed a workaround using the ISP hardware via V4L2. But this could be interesting.