Upstream: RFC the AR100 driver before writing v1 #31

New issue

Open

opened 2026-08-27 23:36:39 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-08-27 23:36:39 +00:00

Owner

sunxi_arisc.c is the largest and least certain piece of this work — and the one most likely
to be rejected in its current form.

Mainline sunxi's direction for the ARISC coprocessor is crust, an open-source replacement
firmware, with SCPI/PSCI on newer SoCs. A driver whose purpose is to talk to Allwinner's vendor
blob runs against that direction.

So do not write a polished v1 and hope. Post an RFC, or simply describe the findings on
linux-sunxi and ask. Those are the same people who would review it, and the answer changes
whether this is a week or a month of work.

Regardless of the driver's fate, the protocol reverse-engineering is likely to be useful to
them: 27-ar100-protocol.md,
28-ar100-firmware-re.md, 37-arisc-driver.md.

Needs a DT binding as well as the driver. Depends on issue #4.

⚠️ Nothing has been submitted. See 42-upstreaming.md for routing,
order, mechanics, and the DCO / AI-assistance caveats. Patches are exported to patches/,
which is not the same as proposing them.

`sunxi_arisc.c` is the largest and least certain piece of this work — and the one most likely to be rejected *in its current form*. Mainline sunxi's direction for the ARISC coprocessor is **crust**, an open-source replacement firmware, with SCPI/PSCI on newer SoCs. A driver whose purpose is to talk to Allwinner's vendor blob runs against that direction. **So do not write a polished v1 and hope.** Post an RFC, or simply describe the findings on linux-sunxi and ask. Those are the same people who would review it, and the answer changes whether this is a week or a month of work. Regardless of the driver's fate, the protocol reverse-engineering is likely to be useful to them: [27-ar100-protocol.md](27-ar100-protocol.md), [28-ar100-firmware-re.md](28-ar100-firmware-re.md), [37-arisc-driver.md](37-arisc-driver.md). Needs a DT binding as well as the driver. Depends on issue #4. --- ⚠️ **Nothing has been submitted.** See [42-upstreaming.md](42-upstreaming.md) for routing, order, mechanics, and the DCO / AI-assistance caveats. Patches are exported to `patches/`, which is not the same as proposing them.

tiagoagueda added the

kernel

upstream

P3-normal

labels

2026-08-27 23:36:39 +00:00

tiagoagueda referenced this issue

2026-08-27 23:36:39 +00:00

Upstream the accumulated sun9i fixes #20

tiagoagueda commented

2026-08-30 14:26:48 +00:00

Author

Owner

The mirror has directly relevant prior art that should shape the RFC.

AR100/HardwareSharing is an extended design discussion about exactly the problem this issue
is about: what happens when both Linux and firmware on the AR100 want the same hardware. It is
written around Crust (github.com/crust-firmware/crust), which the wiki describes as the most
mature AR100/SCP firmware to date, with demonstrated suspend/resume on A64 and H5 boards including
the Pinebook. Sending patches lists it as a maintained project with its own tree.

Why this matters for our RFC:

There is an existing convention for who owns R_TWI, R_RSB, R_CPUCFG and the module
gates/resets when an SCP firmware is present. Proposing a Linux-side AR100 driver that ignores
it will draw exactly that objection on the list.
The page notes no official decision has been made on the name or maintainership of the SCP
firmware, and that Crust does not implement the specification the page describes. So this is
contested ground, not settled ground - which is an argument for RFC rather than v1, i.e. it
supports what this issue already proposes.
Our situation differs in a way worth stating explicitly in the RFC: we run a vendor AR100
blob (arisc-v0.0.80.bin) and talk to it, rather than replacing it with free firmware. That is
a third position between "no AR100" and "Crust", and it is the part reviewers will have the
least context for.

Worth reading AR100/HardwareSharing in full before writing the cover letter.

From a deep pass over the offline linux-sunxi.org mirror (a80/linux-sunxi.org/wiki-backup, 4095 pages, snapshot 2026-08-29). linux-sunxi.org content is CC BY-SA; the pages named above are the attribution.

The mirror has directly relevant prior art that should shape the RFC. **`AR100/HardwareSharing`** is an extended design discussion about exactly the problem this issue is about: what happens when both Linux and firmware on the AR100 want the same hardware. It is written around **Crust** (`github.com/crust-firmware/crust`), which the wiki describes as the most mature AR100/SCP firmware to date, with demonstrated suspend/resume on A64 and H5 boards including the Pinebook. `Sending patches` lists it as a maintained project with its own tree. Why this matters for our RFC: - There is an **existing convention** for who owns `R_TWI`, `R_RSB`, `R_CPUCFG` and the module gates/resets when an SCP firmware is present. Proposing a Linux-side AR100 driver that ignores it will draw exactly that objection on the list. - The page notes no official decision has been made on the name or maintainership of the SCP firmware, and that Crust does not implement the specification the page describes. So this is contested ground, not settled ground - which is an argument for RFC rather than v1, i.e. it supports what this issue already proposes. - Our situation differs in a way worth stating explicitly in the RFC: we run a **vendor** AR100 blob (`arisc-v0.0.80.bin`) and talk to it, rather than replacing it with free firmware. That is a third position between "no AR100" and "Crust", and it is the part reviewers will have the least context for. Worth reading `AR100/HardwareSharing` in full before writing the cover letter. --- *From a deep pass over the offline linux-sunxi.org mirror (`a80/linux-sunxi.org/wiki-backup`, 4095 pages, snapshot 2026-08-29). linux-sunxi.org content is CC BY-SA; the pages named above are the attribution.*

tiagoagueda referenced this issue from a commit

2026-08-30 14:27:46 +00:00

Deep-read the linux-sunxi mirror against the tracker (#73 #74 #75)