JH7110 IMG BXE-4-32 GPU: bare-metal measurements and upstream enablement questions

[KyotoMiyaChan]

Hi all,

I have been bringing up the JH7110 / VisionFive 2 GPU while developing kachoiOS,
a self-developed performance-oriented RISC-V OS kernel. The kachoiOS repository
is not public at this stage, but I would like to share the hardware measurements
that may help the wider JH7110 / PowerVR community.

This is not a claim that the JH7110 GPU is fully supported in mainline Linux or
Mesa. It is a set of bare-metal measurements and questions for the upstream
enablement path.

Measured hardware facts:

• GPU MMIO: 0x18000000, 1 MiB window.
• IRQ: 82.
• Power domain: PD_GPUA.
• BVNC: 36.50.54.182.
• ROGUE_CR_CORE_ID was read as:
  • low@0x20 = 0x003600b6
  • high@0x24 = 0x00240032
  • CORE_ID64 = 0x00240032003600b6
• The GPU firmware processor for this BXE-4-32 core is Rogue MIPS, not the
  separate StarFive E24 block.
• The MIPS firmware path uses MIPS wrapper/remap registers plus SOFT_RESET,
  not the RISC-V FWCORE_BOOT path.
• IRQ82 appears to behave as a firmware event/boot-event channel. For GP-class
  KCCB commands, completion was observed through KCCB consumption/execution
  counters rather than a per-command IRQ.
• Minimal KCCB commands such as SLCFLUSHINVAL and HEALTH_CHECK were consumed
  and executed by the firmware.
• A minimal kicksync-style path reached common-context scheduling, client CCB
  consumption, and UFO update.

Questions:

1. Is anyone already working on a JH7110 GPU DT binding / DTS series for
   drm/imagination?
2. For upstream DT, would maintainers prefer exposing JH7110's GPU clocks as
   the existing core/mem/sys model used by img,powervr-rogue.yaml, or extending
   the binding for the fuller JH7110 clock/reset topology?
3. What is the preferred public firmware packaging path for BVNC 36.50.54.182?
   StarFive packages use rgx.fw.36.50.54.182 and rgx.sh.36.50.54.182, while
   the upstream drm/imagination firmware naming scheme expects names like
   powervr/rogue_36.50.54.182_v1.fw.
4. Would a disabled-by-default JH7110 gpu@18000000 DTS node be useful as a
   first RFC, assuming firmware and userspace support are still experimental?

I can share concise log excerpts and a proposed DTS/binding sketch if useful.

Contact:
Zhang Liang zhanglianggs@gmail.com

[MichaIng]

I guess you know it already, but just for reference: https://rvspace.org/en/project/JH7110_Upstream_Plan

Notably https://patchwork.kernel.org/project/dri-devel/cover/20241120061848.196754-1-keith.zhao@starfivetech.com/, still pending (why?), adds general HDMI/DRM/KMS support. But I do not see the (BXE-4-32) PowerVR GPU driver/integration at the upstream plan at all, even that the general Imagination PowerVR driver infrastructure has been added some years ago. Would be awesome to see some progress there.

However, I cannot help with the technical details and development, sadly, aside of a PINE64 Star64 for testing + a wider range of Star64 and VisionFive 2 testers among our users.

[KyotoMiyaChan]

Hi MichaIng,

Thanks for the references and for offering to help with testing — it is much appreciated.

Just to clarify our position: kachoiOS is a self-contained RISC-V kernel project with its own development roadmap rather than one driven by the Linux upstream schedule. While our immediate goal is not to upstream the complete GPU driver, we are happy to contribute pieces that are independently useful.

One example would be a JH7110 PowerVR Devicetree binding together with a disabled-by-default gpu@18000000 node. That work is relatively self-contained and could be valuable regardless of when full DRM/Imagination support eventually lands. If maintainers are interested, we would be happy to prepare an RFC.

Regarding StarFive upstream plans, I agree that the BXE-4-32 PowerVR GPU is not currently on the public roadmap. The measurements in the original post were intended to document verified hardware behaviour and lower the barrier for anyone interested in future enablement.

If bare-metal testing outside Linux would also be useful to the community, we would be happy to share standalone firmware bring-up images or other diagnostic artifacts as our work progresses. Hopefully those measurements can complement future upstream efforts as well.

[MichaIng]

It would be great to hear back from StarFive devs about why the GPU was not part of the upstream plan in the first place, and whether they would support it, like contributing further missing parts for full enablement, if some volunteer work is done. I don't have much experience with mainline Linux contributors either, but know that Linux maintainers prefer drivers from manufacturers. And often, while e.g. bindings are a dedicated first patch with its own value, it is the first of a patch set which does full enablement for some feature. So being backed by StarFive would surely raise the chance/motivation to get patches for this GPU merged.

[MichaIng]

I was just pointed at some upstreaming work: https://github.com/domibel/linux/tree/powervr_on_jh7110_visionfive2_v7.0.3

But Debian calls is a PoC with rendering performance being "too slow to be practically usable": https://wiki.debian.org/InstallingDebianOn/StarFive/VisionFiveV2#HDMI_and.2For_GPU_support_.28experimental.29