9:10 a.m.
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
10:52 a.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
1:17 p.m.
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
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
5:31 a.m.
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
8:57 a.m.
On Fri, Dec 29, 2023 at 11:32 AM Barry Scott <barry(a)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
>
5:15 a.m.
New subject: F38->F39
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
5:55 a.m.
New subject: F38->F39
On Sat, Dec 30, 2023 at 6:16 AM David Legg <dwlegg(a)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
7:21 a.m.
New subject: F38->F39
On Sat, Dec 30, 2023 at 11:16 AM David Legg <dwlegg(a)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
7:36 a.m.
New subject: F38->F39
Please see
https://discussion.fedoraproject.org/t/f38-to-f39-dnf-system-upgrade-can-...
as another work around.
On Sat, Dec 30, 2023, 05:22 Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Sat, Dec 30, 2023 at 11:16 AM David Legg <dwlegg(a)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(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
10:31 a.m.
New subject: F38->F39
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(a)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
4:40 a.m.
New subject: F38->F39
On Sat, Dec 30, 2023 at 4:31 PM David Legg <dwlegg(a)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(a)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
5:27 a.m.
New subject: F38->F39
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.
>
9:14 p.m.
New subject: F38->F39
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(a)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(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
4:38 a.m.
New subject: F38->F39
On Sun, Dec 31, 2023 at 3:14 AM Gregory Carter <gjcarter2(a)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(a)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(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
>
> --
> _______________________________________________
> 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
129
days inactive
183
days old
15 comments
7 participants
participants (7)
-
Barry Scott -
Brad Smith -
Daniel Miranda -
David Legg -
Gregory Carter -
Jeffrey Walton -
Peter Robinson