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
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
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
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@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
Peter,
I just received my Pi 5 8GB board and wondered what the current situation is regarding Pi 5 state of kernels etc.
If I can usefully help test anything I am happy to help out.
Barry
On Fri, Dec 29, 2023 at 11:32 AM Barry Scott barry@barrys-emacs.org wrote:
Peter,
I just received my Pi 5 8GB board and wondered what the current situation is regarding Pi 5 state of kernels etc.
No change from my last update
If I can usefully help test anything I am happy to help out.
Barry
Is this likely to work, please?
dnfinstall dnf-plugin-system-upgrade dnfsystem-upgrade download --releasever=39 dnfsystem-upgrade reboot
I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few extra packages. Thanks.
:D
On Sat, Dec 30, 2023 at 6:16 AM David Legg dwlegg@gmail.com wrote:
Is this likely to work, please?
dnf install dnf-plugin-system-upgrade dnf system-upgrade download --releasever=39 dnf system-upgrade reboot
The published procedure is at dnf-system-upgrade, https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/.
I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few extra packages. Thanks.
I don't recall seeing discussions that dnf-system-upgrade does not work on Aarch64. Most problems I see are due to RPMFusion lagging behind Fedora's release cadence.
Jeff
On Sat, Dec 30, 2023 at 11:16 AM David Legg dwlegg@gmail.com wrote:
Is this likely to work, please?
dnf install dnf-plugin-system-upgrade dnf system-upgrade download --releasever=39 dnf system-upgrade reboot
I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few extra packages. Thanks.
You are probably likely to be better off doing a distro-sync because it happens online, the new rpm gpg process has issues with the rpi4 due to the lack of a battery backed RTC.
dnf --releasever=39 --setopt=deltarpm=false distro-sync
Please see https://discussion.fedoraproject.org/t/f38-to-f39-dnf-system-upgrade-can-fai... as another work around.
On Sat, Dec 30, 2023, 05:22 Peter Robinson pbrobinson@gmail.com wrote:
On Sat, Dec 30, 2023 at 11:16 AM David Legg dwlegg@gmail.com wrote:
Is this likely to work, please?
dnf install dnf-plugin-system-upgrade dnf system-upgrade download --releasever=39 dnf system-upgrade reboot
I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few
extra packages. Thanks.
You are probably likely to be better off doing a distro-sync because it happens online, the new rpm gpg process has issues with the rpi4 due to the lack of a battery backed RTC.
dnf --releasever=39 --setopt=deltarpm=false distro-sync
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
Thanks, Gents. I used Peter Robinson's command (below) and it worked fine, performing the upgrade from F38 to F39 in about half an hour.
The only thing that 'broke' was gpiofind, which has disappeared. On closer inspection, it is not really needed in F39, but I did have to rework all my gpioset commands.
I noticed that commands of the kind,
gpioset -p 5s line=0
(to assert a line for, say, 5 seconds) do not really work. Such a command just asserts the line for ever rather than for just 5 seconds. The man page does say that the -p flag gives you "at least" the time specified, but just asserting the line for ever does not really seem in the spirit of the command (to me).
Thanks for you help Brad and Peter,
:D
On 30/12/2023 13:21, Peter Robinson wrote:
On Sat, Dec 30, 2023 at 11:16 AM David Legg dwlegg@gmail.com wrote:
Is this likely to work, please?
dnf install dnf-plugin-system-upgrade dnf system-upgrade download --releasever=39 dnf system-upgrade reboot
I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few extra packages. Thanks.
You are probably likely to be better off doing a distro-sync because it happens online, the new rpm gpg process has issues with the rpi4 due to the lack of a battery backed RTC.
dnf --releasever=39 --setopt=deltarpm=false distro-sync
On Sat, Dec 30, 2023 at 4:31 PM David Legg dwlegg@gmail.com wrote:
Thanks, Gents. I used Peter Robinson's command (below) and it worked fine, performing the upgrade from F38 to F39 in about half an hour.
Good news.
The only thing that 'broke' was gpiofind, which has disappeared. On closer inspection, it is not really needed in F39, but I did have to rework all my gpioset commands.
Yes, we moved to the new libgpiod v2, I believe the gpiofind functionality was rolled into something else (the README or upstream notes may help there).
I noticed that commands of the kind,
gpioset -p 5s line=0
(to assert a line for, say, 5 seconds) do not really work. Such a command just asserts the line for ever rather than for just 5 seconds. The man page does say that the -p flag gives you "at least" the time specified, but just asserting the line for ever does not really seem in the spirit of the command (to me).
Interesting, may be worth feeding this back to upstream. Let me know if I can help.
Thanks for you help Brad and Peter,
:D
On 30/12/2023 13:21, Peter Robinson wrote:
On Sat, Dec 30, 2023 at 11:16 AM David Legg dwlegg@gmail.com wrote:
Is this likely to work, please?
dnf install dnf-plugin-system-upgrade dnf system-upgrade download --releasever=39 dnf system-upgrade reboot
I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few extra packages. Thanks.
You are probably likely to be better off doing a distro-sync because it happens online, the new rpm gpg process has issues with the rpi4 due to the lack of a battery backed RTC.
dnf --releasever=39 --setopt=deltarpm=false distro-sync
Oh, and I also had to go into cpan and reinstall a couple of Perl modules, MP3::Tag and MP4::Info and their dependencies.
On 31/12/2023 10:40, Peter Robinson wrote:
...
The only thing that 'broke' was gpiofind, which has disappeared. On closer inspection, it is not really needed in F39, but I did have to rework all my gpioset commands.
Wait another month or two. Otherwise make sure you have a bugzilla account and be prepared to write a bug report if it does not.
I did what you suggested for F37-F38. It mostly worked.
It broke my USB Ethernet which was fixed about a month later after I wrote a fairly detailed bug report.
On Sat, Dec 30, 2023 at 4:16 AM David Legg dwlegg@gmail.com wrote:
Is this likely to work, please?
dnf install dnf-plugin-system-upgrade dnf system-upgrade download --releasever=39 dnf system-upgrade reboot
I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few extra packages. Thanks.
:D
-- _______________________________________________ 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
On Sun, Dec 31, 2023 at 3:14 AM Gregory Carter gjcarter2@gmail.com wrote:
Wait another month or two. Otherwise make sure you have a bugzilla account and be prepared to write a bug report if it does not.
I did what you suggested for F37-F38. It mostly worked.
It broke my USB Ethernet which was fixed about a month later after I wrote a fairly detailed bug report.
Do you have a link to the bug report, I was not aware of any breakages and never saw any with the USB eth on the older RPi units.
On Sat, Dec 30, 2023 at 4:16 AM David Legg dwlegg@gmail.com wrote:
Is this likely to work, please?
dnf install dnf-plugin-system-upgrade dnf system-upgrade download --releasever=39 dnf system-upgrade reboot
I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few extra packages. Thanks.
:D
-- _______________________________________________ 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
-- _______________________________________________ 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
-
Barry Scott -
Brad Smith -
Daniel Miranda -
David Legg -
Gregory Carter -
Jeffrey Walton -
Peter Robinson