Raspberry Pi 5 support - how to contribute?

[Daniel Miranda]

Hello,

I've recently - and somewhat surprisingly - already got my hands into a Raspberry Pi
5. I would like to contribute to make it supported , as the Pi4 is.

I have extensive Fedora experience, but not with ARM, and how the whole ecosystem works.
What would be useful to get started with a test image for the Pi5? Or if that's not
yet possible, what information or resources can be of use to get to that points?

Thanks!

Daniel M

[Peter Robinson]

Hi Daniel,

>  I've recently - and somewhat surprisingly - already got my hands
> into a Raspberry Pi 5. I would like to contribute to make it supported , as the Pi4 is.
I'm still awaiting mine, apparently it's due "soon"

>  I have extensive Fedora experience, but not with ARM, and how the
> whole ecosystem works. What would be useful to get started with a test image for the Pi5?
> Or if that's not yet possible, what information or resources can be of use to get to
> that points? 
So TBH I'm not 100% sure what needs to be done as yet until my device arrives.

The biggest problem with the RPi5 is the new RP1 chip as a LOT of
things hang off that. Looking at the chip design [1] a lot of the
peripherals now hang off what is basically a PCIe-EP <-> AXI bridge.
Most of the rest of the peripheral IP appears to be off the shelf,
USB, Sound etc, and should just work once that first driver lands
upstream. I am not sure who is looking at that driver and if there are
any plans in place to push that upstream.

The graphics and other pieces are already headed upstream.

The other piece of the pie (pun intended) is the early boot process,
I'll look at that once I get a device. AFAICT that actually looks
quite similar to existing bits, but again it depends on how things
like mSD are placed on the system and what dependencies are needed.

Long story short most of the work required will be low level kernel
pieces, and while I've had a little look at patches I've not got a
full plan yet. Let me know what pieces you're interested in looking
at.

Peter

[1] https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf

[Peter Robinson]

Hi Folks,

Just thought I'd post an update here now I've got one and spent a few
hours today poking around with a vanilla RPiOS minimal image.

>  > I've recently - and somewhat surprisingly - already got my
> hands into a Raspberry Pi 5. I would like to contribute to make it supported , as the Pi4
> is.
>
>  I'm still awaiting mine, apparently it's due "soon"
>
>  > I have extensive Fedora experience, but not with ARM, and how the whole ecosystem
> works. What would be useful to get started with a test image for the Pi5? Or if that's
> not yet possible, what information or resources can be of use to get to that points?
>
>  So TBH I'm not 100% sure what needs to be done as yet until my device arrives.
>
>  The biggest problem with the RPi5 is the new RP1 chip as a LOT of
>  things hang off that. Looking at the chip design [1] a lot of the
>  peripherals now hang off what is basically a PCIe-EP <-> AXI bridge.
>  Most of the rest of the peripheral IP appears to be off the shelf,
>  USB, Sound etc, and should just work once that first driver lands
>  upstream. I am not sure who is looking at that driver and if there are
>  any plans in place to push that upstream.
>
>  The graphics and other pieces are already headed upstream.
>
>  The other piece of the pie (pun intended) is the early boot process,
>  I'll look at that once I get a device. AFAICT that actually looks
>  quite similar to existing bits, but again it depends on how things
>  like mSD are placed on the system and what dependencies are needed. 
So a quick look indicates there will be quite a bit of work to do.
Some general notes:
* The graphics for acceleration via HDMI is headed upstream
* The mSD card and WiFi uses the sdhci-brcmstb driver, for both linux
and U-Boot which is upstream but needs patches
* The PCIe uses the upstream pcie-brcmstb driver, like in the rpi4,
but again needs some patches
* The vast majority of everything else hangs of the RP1 chip which is
a uses a weird PCIe-EP to AXI bus bridge thing which AFAICT needs a
MFD driver to be upstreamed to unlock the fairly generic IP that
provides the rest.
* The rest of the main generic IP that makes up the RP1 chip that the
vast majority of users care about are mostly upstream drivers that
just need minor patches to deal with the quirks that make up the RP1
chip.
* Wired network: macb driver NIC with broadcom PHY - upstream needs patches
* dw-axi-dmac DMA controller needs patches
* USB is dwc3 needs patches
* Sound upstream needs patches
* RP1 embedded GPIO/SPI/I2C/sdhci/TTL upstream needs patches
* Things like MIPI (DSI and CSI), video offload, pwm and a bunch of
other IP don't have enough detail to know as yet

So the long story short is ATM nothing will work with vanilla upstream
kernel yet unless you could serial console and display. I'm hoping
that various kernel people will start to poke around and get pieces
upstream, the biggest individual piece of work is definitely the PCIe
end point to AXI bridge driver piece as without that nothing on the
RP1 chip will work.

But getting a basic device booting with serial console, mSD for
storage and WiFi and PCIe, for a HAT shouldn't be too hard, I'll
likely start to play with a kernel in copr and do a basic minimal
image (via the new osbuild support) for those that want something to
start to play with but that will be as time permits.

Peter

[David Legg]

Everybody thanks you, Peter.

:D

On 18/11/2023 19:17, Peter Robinson wrote:
> Hi Folks,
>
> Just thought I'd post an update here now I've got one and spent a few
> hours today poking around with a vanilla RPiOS minimal image.
>
>>> I've recently - and somewhat surprisingly - already got my hands into a
Raspberry Pi 5. I would like to contribute to make it supported , as the Pi4 is.
>> I'm still awaiting mine, apparently it's due "soon"
>>
>>> I have extensive Fedora experience, but not with ARM, and how the whole
ecosystem works. What would be useful to get started with a test image for the Pi5? Or if
that's not yet possible, what information or resources can be of use to get to that
points?
>> So TBH I'm not 100% sure what needs to be done as yet until my device
arrives.
>>
>> The biggest problem with the RPi5 is the new RP1 chip as a LOT of
>> things hang off that. Looking at the chip design [1] a lot of the
>> peripherals now hang off what is basically a PCIe-EP <-> AXI bridge.
>> Most of the rest of the peripheral IP appears to be off the shelf,
>> USB, Sound etc, and should just work once that first driver lands
>> upstream. I am not sure who is looking at that driver and if there are
>> any plans in place to push that upstream.
>>
>> The graphics and other pieces are already headed upstream.
>>
>> The other piece of the pie (pun intended) is the early boot process,
>> I'll look at that once I get a device. AFAICT that actually looks
>> quite similar to existing bits, but again it depends on how things
>> like mSD are placed on the system and what dependencies are needed.
> So a quick look indicates there will be quite a bit of work to do.
> Some general notes:
> * The graphics for acceleration via HDMI is headed upstream
> * The mSD card and WiFi uses the sdhci-brcmstb driver, for both linux
> and U-Boot which is upstream but needs patches
> * The PCIe uses the upstream pcie-brcmstb driver, like in the rpi4,
> but again needs some patches
> * The vast majority of everything else hangs of the RP1 chip which is
> a uses a weird PCIe-EP to AXI bus bridge thing which AFAICT needs a
> MFD driver to be upstreamed to unlock the fairly generic IP that
> provides the rest.
> * The rest of the main generic IP that makes up the RP1 chip that the
> vast majority of users care about are mostly upstream drivers that
> just need minor patches to deal with the quirks that make up the RP1
> chip.
> * Wired network: macb driver NIC with broadcom PHY - upstream needs patches
> * dw-axi-dmac DMA controller needs patches
> * USB is dwc3 needs patches
> * Sound upstream needs patches
> * RP1 embedded GPIO/SPI/I2C/sdhci/TTL upstream needs patches
> * Things like MIPI (DSI and CSI), video offload, pwm and a bunch of
> other IP don't have enough detail to know as yet
>
> So the long story short is ATM nothing will work with vanilla upstream
> kernel yet unless you could serial console and display. I'm hoping
> that various kernel people will start to poke around and get pieces
> upstream, the biggest individual piece of work is definitely the PCIe
> end point to AXI bridge driver piece as without that nothing on the
> RP1 chip will work.
>
> But getting a basic device booting with serial console, mSD for
> storage and WiFi and PCIe, for a HAT shouldn't be too hard, I'll
> likely start to play with a kernel in copr and do a basic minimal
> image (via the new osbuild support) for those that want something to
> start to play with but that will be as time permits.
>
> Peter
> --
> _______________________________________________
> arm mailing list -- arm(a)lists.fedoraproject.org
> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue