tiagoagueda/a80
tiagoagueda/a80
1
0
Fork 0
Code Issues 35 Pull requests Projects Releases Packages Wiki Activity Actions

PowerVR G6230: bring the GPU up under mainline Linux #55

New issue
Open
opened 2026-08-29 15:39:01 +00:00 by tiagoagueda · 1 comment
tiagoagueda commented 2026-08-29 15:39:01 +00:00
Owner
Copy link

The PowerVR G6230 has never been driven under mainline. This tracks the work to
change that, using the vendor's kernel-mode DDK source rather than an open driver.

Full plan: 55-gpu-linux-plan.md. Feasibility and evidence: 54-powervr-feasibility.md.

Why this is possible at all

The upstream open driver (drm/powervr + Mesa pvr) cannot drive this chip: it needs a
per-core firmware blob named by BVNC, and there is no rogue_1.75.2.30_v1.fw in linux-firmware
and never will be. It also depends on (ARM64 || RISCV && 64BIT) and we are ARMv7.

What makes it tractable is that A80_SDK_20140728_lichee.tar.gz on ouranos contains
lichee/linux-3.4/modules/rogue_km/ - 427 files, dual GPL/MIT, whose hwdefs carries a
1.V.2.30 core config. That source supports our exact silicon.

Hardware constants (from the vendor platform layer, not guessed)

Item Value
GPU registers 0x02000000, size 0x01000000
GPU control block 0x01c08000
GPU interrupt GIC_SPI 97
Core Rogue G6230, BVNC 1.75.2.30
Supply axp15_dcdc3 (sys_config.fex [rgx_para])

The IRQ cross-checks: the vendor's real-silicon branch gives HDMI +88, and our working HDMI
node uses GIC_SPI 88, so the mapping is direct.

Mainline already has the GPU clocks in ccu-sun9i-a80.c (pll_gpu, gpu_core,
gpu_memory, gpu_axi, bus-gpu-ctrl). Nothing to write there.

Expectations

Four Cortex-A7s only, because of #53, and no hardware video decode. A working GPU buys a smooth
desktop or Kodi UI. It will not play 1080p H.264 any better than today. If the goal is a
media box, booting the vendor Android 4.4 build gets there this week for zero engineering.

Sub-issues, in dependency order

Issue Needs board?
Gate #56 - Find an A80 lichee SDK carrying rogue_km at DDK 1.4 no
1 #57 - sun9i-a80 has no GPU device tree node no
2 #58 - Forward-port pvrsrvkm from kernel 3.4 to mainline no
3 #59 - GPU first light: confirm the RGX core ID, then boot the firmware yes
4 #60 - PowerVR userspace: GLES on fbdev, then buffer sharing with sun4i-drm yes

#56 comes first and is a genuine gate - it decides whether the end result is accelerated
Debian (DDK 1.4 glibc userspace) or Android-only (DDK 1.3, our matched pair). Do not sink effort
into #58 before it is answered, since the answer does not change #57 or #58 technically but does
change whether the outcome is worth having.

#57 and #58 are pure desk work. Nothing touches the board before #59.

Gates

  • A (#58): module builds, loads, probes, /dev/pvrsrvkm appears, no oops.
  • B (#59): firmware boots, FW heartbeat / KCCB responds.
  • C (#60): an es2gears-class test renders on the TV.
**The PowerVR G6230 has never been driven under mainline.** This tracks the work to change that, using the vendor's kernel-mode DDK source rather than an open driver. Full plan: `55-gpu-linux-plan.md`. Feasibility and evidence: `54-powervr-feasibility.md`. ## Why this is possible at all The upstream open driver (`drm/powervr` + Mesa `pvr`) **cannot** drive this chip: it needs a per-core firmware blob named by BVNC, and there is no `rogue_1.75.2.30_v1.fw` in `linux-firmware` and never will be. It also `depends on (ARM64 || RISCV && 64BIT)` and we are ARMv7. What makes it tractable is that `A80_SDK_20140728_lichee.tar.gz` on ouranos contains `lichee/linux-3.4/modules/rogue_km/` - 427 files, **dual GPL/MIT**, whose `hwdefs` carries a `1.V.2.30` core config. That source supports our exact silicon. ## Hardware constants (from the vendor platform layer, not guessed) | Item | Value | |---|---| | GPU registers | `0x02000000`, size `0x01000000` | | GPU control block | `0x01c08000` | | GPU interrupt | `GIC_SPI 97` | | Core | Rogue G6230, BVNC `1.75.2.30` | | Supply | `axp15_dcdc3` (`sys_config.fex [rgx_para]`) | The IRQ cross-checks: the vendor's real-silicon branch gives HDMI `+88`, and our working HDMI node uses `GIC_SPI 88`, so the mapping is direct. Mainline **already has** the GPU clocks in `ccu-sun9i-a80.c` (`pll_gpu`, `gpu_core`, `gpu_memory`, `gpu_axi`, `bus-gpu-ctrl`). Nothing to write there. ## Expectations Four Cortex-A7s only, because of #53, and no hardware video decode. A working GPU buys a smooth desktop or Kodi UI. **It will not play 1080p H.264 any better than today.** If the goal is a media box, booting the vendor Android 4.4 build gets there this week for zero engineering. ## Sub-issues, in dependency order | | Issue | Needs board? | |---|---|---| | **Gate** | #56 - Find an A80 lichee SDK carrying rogue_km at DDK 1.4 | no | | 1 | #57 - sun9i-a80 has no GPU device tree node | no | | 2 | #58 - Forward-port pvrsrvkm from kernel 3.4 to mainline | no | | 3 | #59 - GPU first light: confirm the RGX core ID, then boot the firmware | **yes** | | 4 | #60 - PowerVR userspace: GLES on fbdev, then buffer sharing with sun4i-drm | yes | **#56 comes first and is a genuine gate** - it decides whether the end result is accelerated Debian (DDK 1.4 glibc userspace) or Android-only (DDK 1.3, our matched pair). Do not sink effort into #58 before it is answered, since the answer does not change #57 or #58 technically but does change whether the outcome is worth having. #57 and #58 are pure desk work. **Nothing touches the board before #59.** ## Gates - **A** (#58): module builds, loads, probes, `/dev/pvrsrvkm` appears, no oops. - **B** (#59): firmware boots, FW heartbeat / KCCB responds. - **C** (#60): an `es2gears`-class test renders on the TV.
tiagoagueda commented 2026-08-30 13:27:55 +00:00
Author
Owner
Copy link

The gate is open. #56 is resolved: github.com/cubieboard/CC-A80-kernel-source carries
rogue_km at 1.4@3064661 - the same build number as the libpvr_dri_if.so we hold - and its
version string reads Rogue_DDK_Linux_XOrg, not Android_RSCompute.

So the shape of this issue is settled, and it is the good branch: a matched glibc km/um pair
exists, with the sunxi system layer (services/system/rgx_sunxi/) and a Linux build target
(build/linux/sunxi_linux/Makefile) on kernel 3.4.39. No libhybris, no booting Android 4.4 for
acceleration.

Archived at ~/a80/vendor/CC-A80-rogue_km-1.4@3064661.tar.zst with checksums; see ARCHIVE.md.

The forward-port to mainline (#58) is still the hard part - this is a 3.4-era DDK - but it is now
a porting problem with a known-correct starting point rather than a hunt.

**The gate is open.** #56 is resolved: `github.com/cubieboard/CC-A80-kernel-source` carries `rogue_km` at `1.4@3064661` - the *same build number* as the `libpvr_dri_if.so` we hold - and its version string reads `Rogue_DDK_Linux_XOrg`, not `Android_RSCompute`. So the shape of this issue is settled, and it is the good branch: **a matched glibc km/um pair exists**, with the sunxi system layer (`services/system/rgx_sunxi/`) and a Linux build target (`build/linux/sunxi_linux/Makefile`) on kernel 3.4.39. No libhybris, no booting Android 4.4 for acceleration. Archived at `~/a80/vendor/CC-A80-rogue_km-1.4@3064661.tar.zst` with checksums; see `ARCHIVE.md`. The forward-port to mainline (#58) is still the hard part - this is a 3.4-era DDK - but it is now a porting problem with a known-correct starting point rather than a hunt.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
blocked-physical
Needs someone next to the board

  
cleanup
Tidying, leftovers, cosmetics

  
hardware
Bringing up a peripheral

  
infra
Build host, backups, reproducibility

  
kernel
Kernel or device-tree work

  
P1-critical
Do first: irreversible or actively exposed

  
P2-high
Blocks production use

  
P3-normal
Should be done

  
P4-later
Nice to have / large

  
reliability
Stays up, comes back by itself

  
security
Exposure, credentials, hardening

  
upstream
Getting patches into mainline

  
wontfix
Recorded so nobody investigates again

No labels
blocked-physical
cleanup
hardware
infra
kernel
P1-critical
P2-high
P3-normal
P4-later
reliability
security
upstream
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
tiagoagueda/a80#55
No description provided.