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@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@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/arm@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No comments:
Post a Comment