Request firmware for BananaPi-F3, IMG BXE-2-32 GPU

BananaPi-F3 SoC has IMG-BXE-2-32 GPU. I would like to try and test the new upstream driver with it. Could you please provide the firmware?

Thanks, Michał

Hi Michal, thank you for your interest :)

The process for releasing a firmware binary for BXE-2-32 has been kicked off. I'll post back here once the firmware and corresponding device information has been pushed to our public repositories.

A couple of things to mention. Firstly, we currently have quite a lot of downstream Mesa changes that we're about to start upstreaming. The most up-to-date branch with our work is https://gitlab.freedesktop.org/imagination/mesa/-/tree/dev/zink?ref_type=heads.

Secondly, there's still a number of things in the driver that are specific to AXE-1-16M, which has been our primary target for Vulkan 1.0 & GLES 3.1 conformance. These AXE-1-16M bits will cause issues for other GPUs. Over the coming months, we'll be working on BXS-4-64 support, which will results in those AXE-1-16M specific bits being replaced with more generic implementations. Although this will help towards getting other GPUs working, there will be further work required to get each GPU fully functional and passing Khronos conformance.

Hi, Thank you very much for your response. Once the firmware is available, I will try testing it on the mainline Linux kernel with the relevant dependent drivers ported on the BananaPi-F3.

It seems to me that the last paragraph of your response is also relevant to another comment I made on a different issue here. As I mentioned, I failed to boot the firmware on the THEAD-1520 SoC. Based on my debugging and examination of the firmware data structures shared with the CPU, as well as the firmware execution stack, it seems that the firmware never started executing. This might be due to incorrect programming through the control registers. You mentioned that the driver was only ever tested on AXE-1-16M, so it's understandable that some programming through control registers might be missing. I was trying to understand how the flow to get the firmware to boot should look based on the original drm/img-rogue driver provided for the SoC, though I haven't been able to figure it out yet.

However, since you and your colleagues are working on making the driver code more generic, I assume that the BXM-4-64 will eventually be supported as well. One thing I can do right now is prepare the mainline kernel for the driver update by creating an upstream series for the dependent drivers (e.g., clocks and drivers for the Always-On module) that allows the GPU to power up.

Would you be comfortable with me citing this thread in the upstream series I’m going to send? I would motivate the series by stating that a suitable upstream driver, 'drm/imagination', exists for the on-SoC GPU, intended to support BXM-4-64, and is currently being worked on, though it has not yet successfully booted the firmware. Therefore, it makes sense to introduce the dependent driver code in preparation for the driver being fully functional soon. (for now it only loads firmware, but fails to boot it yet).

Regards, Michał

Sorry for not getting back to you on the other thread about the firmware failing to boot. I've been meaning to reply for a while, but have been trying to juggle a lot of things.

The BXM-4-64 has a MIPS firmware process like the AXE-1-16M, so, in theory, there shouldn't be any specific changes needed in the kernel driver for the BXM-4-64. Have you tried porting RGXDumpRGXRegisters() and RGXDumpMIPSState() from drm/img-rogue to see if that gives any clues?

I notice that the BXM-4-64 firmware is configured slightly differently to the AXE-1-16M firmware. You'll need to change ROGUE_FW_HEAP_MIPS_SHIFT in the upstream imagination/powervr driver from 24 to 25 to account for this. I'm not sure this will help, but it's a change that should be made locally nevertheless.

In terms of supporting more GPUs, we'll certainly be expanding out support to other Rogue based GPUs. BXM-4-64 is on our radar for one that is interesting support. However, we don't have a firm timeline right now for when this will be supported. That being said, the work we're doing towards BXS-4-64 should certainly help towards making BXM-4-64 functional, but not necessarily Khronos conformant.

If you're happy to upstream the kernel drivers the GPU driver depends on then that will be very much appreciated! This is currently a bit of a barrier for getting BXM-4-64 working, so will be very helpful.

I've just pushed an updated firmware binary that's configured the same way as the AXE-1-16M firmware. Let me know if you have any luck with the updated version.

Thanks, will give it a go and let you know. Meanwhile I was trying to get one of the dependent drivers on the THEAD-1520 LicheePi4A SoC upstream https://lore.kernel.org/all/20241014123314.1231517-1-m.wilczynski@samsung.com/. It's taking some time but hopefully it would be merged at some point.

Hi @frankbinns

I wanted to update you that the new firmware has successfully resolved the boot issue and now allows the driver to probe correctly. I’m currently trying to run vulkaninfo and various Vulkan demo programs to make sure everything works.

The next step will be preparing an upstream series for submission, which will include the necessary SoC-specific glue code that must execute before the GPU probe. I’ll share the series once it’s ready and make sure to include you in the review process.

Thank you for your assistance in overcoming this roadblock.

Best regards, Michał

Hi @mwilczynski,

Thanks for the update, that's encouraging to hear! Which Mesa branch are you using for your testing? I guess the dev/devinfo branch?

Just to give you a quick update from our side, we're just about to send out a kernel patch series adding support for our BXS-4-64 GPU. As part of this series, our DT bindings have been clarified and should make it fairly trivial to add other GPUs, such as the BXE-2-32 and the BXM-4-64. We're also very close to sending out a Mesa MR for the foundations of our reworked shader compiler. This will make it much easier to add support for other GPUs and will get us a lot closer to replacing the AXE-1-16M specifics in the driver with something that works across all our Rogue based GPUs.

Yeah I'm using the dev/devinfo, as it contains the device info for BXM-4-64. Thanks for the heads up, will watch for any mailing list submissions, and re-base my series on top of them.

mentioned in commit mesa@289aae12

mentioned in commit 33d096e0

I've just pushed the firmware binary and device info. These are added in commits: 33d096e0 mesa@289aae12

mentioned in commit drm/nouveau@5d4d263e

mentioned in issue #3

Thank you @frankbinns! What would be the best way to try it on Bianbu 2.0.4 (kernel 6.6.36)? I am trying to figure out 3D accelerated graphics story on spacemit Muse Book laptop and couldn't find powervr/rogue_36.29.52.182_v1.fw in linux-firmware package. There is only /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.zst. Should I wait for upstream to pick up, or build this fork's powervr branch?

mentioned in commit mesa@16dd67f9