1:48 p.m.
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/arm@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue