Re: Details on Raspberry Pi 5 support timelines
by Sally A.haj
On Sun, 2024-03-17 at 21:51 +0000, Peter Robinson wrote:
> On Sun, 17 Mar 2024 at 21:38, Sally A.haj <sallyahaj(a)yahoo.com>
> wrote:
> >
> > Hi Peter,
> > Thank you for all your efforts.
> >
> > I just thought about rpmfusion's images for RPix, while they are
> > using
> > the downstream kernel, they might consider adding the support for
> > RPi5,
> > this one instead of make a new remix, if that make sense.
>
> I have no idea what RPix is. My intention is to ultimately get
> everything into Fedora, the remix is intended to be short lived and
> assist in moving forward the upstreaming.
I got your point.
The project of rpmfusion seems in a different direction:
https://rpmfusion.org/Howto/RaspberryPi
Their images are for RPi 3 B/B+ & 4 B/400
>
> > Sally
> >
> > On Sun, 2024-03-17 at 18:21 +0000, Peter Robinson wrote:
> > > Hi Folks,
> > >
> > > I finally got some time over the weekend to dig into Fedora on
> > > the
> > > RPi5.
> > >
> > > The TL;DR is that there won't be any way of even basic support
> > > officially for F-40 GA.
> > >
> > > For those interested in more details.....
> > >
> > > The main pieces missing from the upstream kernel to boot to a
> > > login
> > > prompt over serial is appear to be the following:
> > > * The SoC pinctrl driver
> > > * Support in the mmc storage driver for the SoC variant
> > > * Minor bits for the gpio driver
> > >
> > > I'm not aware of any efforts to get anything upstream, I've not
> > > seen
> > > patches on lists etc.
> > >
> > > We have the firmware (bcm/u-boot) pieces in place in Fedora 40
> > > and
> > > the
> > > kernel will start to boot and you get serial console output
> > > except
> > > you
> > > end up at a dracut prompt due to lack of storage.
> > >
> > > I am considering doing a Fedora kernel with patches in copr, and
> > > probably a F-40 remix minimal image, to enable minimal boot so
> > > other
> > > low level developers can use it as a basis for further
> > > investigation
> > > for things like upstream development. I don't have a timeline for
> > > this
> > > yet but I suspect late April. At the moment this looks like it'll
> > > be
> > > mSD, WiFi, serial console support and not much else. I've not
> > > looked
> > > at PCIe, the RP1 chip, or any other peripherals at all.
> > >
> > > I'll reply to this thread if/when I have any further updates,
> > > feel
> > > free to reference it elsewhere.
> > >
> > > Until there's either a kernel or kernel+image unless you can
> > > contribute to upstream kernel pieces there's probably nothing
> > > that
> > > can
> > > be done like "testing". If you can do kernel and would like to
> > > assist
> > > me feel free to reachout outside of this thread.
> > >
> > > 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
> >
> --
> _______________________________________________
> 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
1 month, 1 week
Re: No devices with F39 on Raspberry Pi
by Peter Robinson
On Sun, Oct 29, 2023 at 6:22 PM Peter Robinson <pbrobinson(a)gmail.com> wrote:
>
> On Sun, Oct 29, 2023 at 4:24 PM Peter Boy <pboy(a)uni-bremen.de> wrote:
> >
> > Just checked the F39 rc1.2 on an raspi4 with Server Edition.
> >
> > The fix for the display issue (https://bugzilla.redhat.com/show_bug.cgi?id=2241252) does work for Server, too.
>
> Can you update the RHBZ and add karma so that can go stable.
>
> > But there is a next issue:
> >
> > If I try to adjust the LVM volume to the size of the SD card, I can enlarge the partition mmcblk0p3 using cfdisk as usual without issues. But with pvresize I get
> >
> > > $ sudo pvresize /dev/mmcblk0p3
> > > [sudo] password for pb:
> > > Cannot use /dev/mmcblk0p3: device is not in devices file
> > > 0 physical volume(s) resized or updated / 0 physical volume(s) not resized
> >
> >
> > A lsblk
> >
> > > # lsblk
> > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> > > mmcblk0 179:0 0 59.5G 0 disk
> > > ├─mmcblk0p1 179:1 0 600M 0 part /boot/efi
> > > ├─mmcblk0p2 179:2 0 1G 0 part /boot
> > > └─mmcblk0p3 179:3 0 57.9G 0 part
> > > └─fedora-root 253:0 0 5.4G 0 lvm /
> > > zram0 252:0 0 3.7G 0 disk [SWAP]
> >
> >
> > looks fine and as expected.
> >
> > And with cockpit -> storage the category „devices“ is empty (instead of listing a LVM volume fedora as to expect). It seems, there is something badly wrong with the image. Hence the error message with arm-installer after writing the image onto disk:
> >
> > > = Writing image complete!
> > > mount: /tmp/root: unknown filesystem type 'LVM2_member'.
> > > dmesg(1) may have more information after failed mount system call.
> >
> > as mentioned in an earlier mail and as discussed at the go/no-go meeting (https://meetbot.fedoraproject.org/fedora-meeting/2023-10-26/f39-final-go_... )
> >
> >
> > The bottom line is that Server Edition is still unusable on Raspi4 and any other SBC, unfortunately. What to do and how to proceed (the next go/no-go meeting is in 4 days expecting rc 1.4 tomorrow or shortly after) ?
>
> Did you file a bug so it can be tracked and discussed in a central
> location? Please reference it here too.
BTW have you tested with the new arm-image-installer
(arm-image-installer-3.9-2.fc39) ? I've just added that to the update,
it fixes some bits with LVM.
Peter
5 months, 4 weeks
Re: No devices with F39 on Raspberry Pi
by Peter Robinson
On Sun, Oct 29, 2023 at 4:24 PM Peter Boy <pboy(a)uni-bremen.de> wrote:
>
> Just checked the F39 rc1.2 on an raspi4 with Server Edition.
>
> The fix for the display issue (https://bugzilla.redhat.com/show_bug.cgi?id=2241252) does work for Server, too.
Can you update the RHBZ and add karma so that can go stable.
> But there is a next issue:
>
> If I try to adjust the LVM volume to the size of the SD card, I can enlarge the partition mmcblk0p3 using cfdisk as usual without issues. But with pvresize I get
>
> > $ sudo pvresize /dev/mmcblk0p3
> > [sudo] password for pb:
> > Cannot use /dev/mmcblk0p3: device is not in devices file
> > 0 physical volume(s) resized or updated / 0 physical volume(s) not resized
>
>
> A lsblk
>
> > # lsblk
> > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> > mmcblk0 179:0 0 59.5G 0 disk
> > ├─mmcblk0p1 179:1 0 600M 0 part /boot/efi
> > ├─mmcblk0p2 179:2 0 1G 0 part /boot
> > └─mmcblk0p3 179:3 0 57.9G 0 part
> > └─fedora-root 253:0 0 5.4G 0 lvm /
> > zram0 252:0 0 3.7G 0 disk [SWAP]
>
>
> looks fine and as expected.
>
> And with cockpit -> storage the category „devices“ is empty (instead of listing a LVM volume fedora as to expect). It seems, there is something badly wrong with the image. Hence the error message with arm-installer after writing the image onto disk:
>
> > = Writing image complete!
> > mount: /tmp/root: unknown filesystem type 'LVM2_member'.
> > dmesg(1) may have more information after failed mount system call.
>
> as mentioned in an earlier mail and as discussed at the go/no-go meeting (https://meetbot.fedoraproject.org/fedora-meeting/2023-10-26/f39-final-go_... )
>
>
> The bottom line is that Server Edition is still unusable on Raspi4 and any other SBC, unfortunately. What to do and how to proceed (the next go/no-go meeting is in 4 days expecting rc 1.4 tomorrow or shortly after) ?
Did you file a bug so it can be tracked and discussed in a central
location? Please reference it here too.
5 months, 4 weeks
No devices with F39 on Raspberry Pi
by Peter Boy
Just checked the F39 rc1.2 on an raspi4 with Server Edition.
The fix for the display issue (https://bugzilla.redhat.com/show_bug.cgi?id=2241252) does work for Server, too.
But there is a next issue:
If I try to adjust the LVM volume to the size of the SD card, I can enlarge the partition mmcblk0p3 using cfdisk as usual without issues. But with pvresize I get
> $ sudo pvresize /dev/mmcblk0p3
> [sudo] password for pb:
> Cannot use /dev/mmcblk0p3: device is not in devices file
> 0 physical volume(s) resized or updated / 0 physical volume(s) not resized
A lsblk
> # lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> mmcblk0 179:0 0 59.5G 0 disk
> ├─mmcblk0p1 179:1 0 600M 0 part /boot/efi
> ├─mmcblk0p2 179:2 0 1G 0 part /boot
> └─mmcblk0p3 179:3 0 57.9G 0 part
> └─fedora-root 253:0 0 5.4G 0 lvm /
> zram0 252:0 0 3.7G 0 disk [SWAP]
looks fine and as expected.
And with cockpit -> storage the category „devices“ is empty (instead of listing a LVM volume fedora as to expect). It seems, there is something badly wrong with the image. Hence the error message with arm-installer after writing the image onto disk:
> = Writing image complete!
> mount: /tmp/root: unknown filesystem type 'LVM2_member'.
> dmesg(1) may have more information after failed mount system call.
as mentioned in an earlier mail and as discussed at the go/no-go meeting (https://meetbot.fedoraproject.org/fedora-meeting/2023-10-26/f39-final-go_... )
The bottom line is that Server Edition is still unusable on Raspi4 and any other SBC, unfortunately. What to do and how to proceed (the next go/no-go meeting is in 4 days expecting rc 1.4 tomorrow or shortly after) ?
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
5 months, 4 weeks
Re: Fedora Linux 39 Final blocker status summary #3
by Jeffrey Walton
On Fri, Oct 20, 2023 at 7:56 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
>
> Hi folks! We're still trying to get F39 done, so time for another
> status update...
>
> Action summary
> ==============
>
> Accepted blockers
> -----------------
>
> 1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED: releng
> to push the fix stable
>
> 2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED: desktop
> team (and adamwill) to keep trying to come up with a fix
>
> 3. shim - https://bugzilla.redhat.com/2113005 - NEW: assume this will
> be waived
>
> 4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: ARM
> team (pbrobinson) to fix it
>
> 5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED: ARM
> team to evaluate and fix if possible, ARM/QA to test on more systems if
> possible
>
> 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at
> all to come up with a genius fix, otherwise we'll likely have to
> document this
>
>
> Bug-by-bug detail
> =================
>
> Accepted blockers
> -----------------
>
> 1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED
> kdump is enabled by default on desktops
>
> This is basically fixed, just waiting to be pushed stable.
>
> 2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED
> Netinstall ISO renders a black screen when using kickstart install
> (bare metal and VM)
>
> Well, we kinda had a fix for this, but it turns out to break something
> even worse (now anaconda isn't visible on the Workstation live image).
> So we're still stuck trying to find a perfect fix, unfortunately.
> Desktop team plus me to keep cranking away on it.
>
> 3. shim - https://bugzilla.redhat.com/2113005 - NEW
> Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to
> boot on some boards
>
> Let's just assume this is gonna be waived.
>
> 4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED
> Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi
> 4
>
> Peter says "So we've basically got to the bottom of the problem and
> worked out the issue, I now just need to come up with a fix.", so
> that's what we're waiting on.
>
> 5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED
> Fedora Server 39 does not boot on Raspberry Pi 4 (RPi4) from microSD
> card slot
>
> This one's also waiting on ARM team (i.e. Peter), but seems somewhat
> less clear-cut of a blocker, so we're kinda waiting for his take on
> that, plus testing from other Raspberry Pi owners would be useful.
>
> 6. distribution - https://bugzilla.redhat.com/2242759 - NEW
> dnf system-upgrade fails on some RPi4 due to system boot date that pre-
> dates gpg key
>
> We're still kinda kicking around ideas for "fixing" this, but I think
> if push comes to shove, we'll wind up revoting or waiving it as not
> practically fixable.
I'm just spitballing here for item (6), but can you install a dummy
package on the RPI's with no real time clock, and interpret the
presence of the package to mean "skip time checks"? Maybe something
like skip-time-check.rpm?
We used to experience these kinds of problems a lot back in the early
2000s on mobile devices without a SIM card. The phone would reboot,
but was unable to acquire time from the network because there was no
access to the mobile network. It was especially common for old test
phones. You would have your current mobile phone with service, and 4
or 5 test phones without SIM cards.
Jeff
6 months
Fedora Linux 39 Final blocker status summary #3
by Adam Williamson
Hi folks! We're still trying to get F39 done, so time for another
status update...
Action summary
==============
Accepted blockers
-----------------
1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED: releng
to push the fix stable
2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED: desktop
team (and adamwill) to keep trying to come up with a fix
3. shim - https://bugzilla.redhat.com/2113005 - NEW: assume this will
be waived
4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: ARM
team (pbrobinson) to fix it
5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED: ARM
team to evaluate and fix if possible, ARM/QA to test on more systems if
possible
6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at
all to come up with a genius fix, otherwise we'll likely have to
document this
Bug-by-bug detail
=================
Accepted blockers
-----------------
1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED
kdump is enabled by default on desktops
This is basically fixed, just waiting to be pushed stable.
2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED
Netinstall ISO renders a black screen when using kickstart install
(bare metal and VM)
Well, we kinda had a fix for this, but it turns out to break something
even worse (now anaconda isn't visible on the Workstation live image).
So we're still stuck trying to find a perfect fix, unfortunately.
Desktop team plus me to keep cranking away on it.
3. shim - https://bugzilla.redhat.com/2113005 - NEW
Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to
boot on some boards
Let's just assume this is gonna be waived.
4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED
Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi
4
Peter says "So we've basically got to the bottom of the problem and
worked out the issue, I now just need to come up with a fix.", so
that's what we're waiting on.
5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED
Fedora Server 39 does not boot on Raspberry Pi 4 (RPi4) from microSD
card slot
This one's also waiting on ARM team (i.e. Peter), but seems somewhat
less clear-cut of a blocker, so we're kinda waiting for his take on
that, plus testing from other Raspberry Pi owners would be useful.
6. distribution - https://bugzilla.redhat.com/2242759 - NEW
dnf system-upgrade fails on some RPi4 due to system boot date that pre-
dates gpg key
We're still kinda kicking around ideas for "fixing" this, but I think
if push comes to shove, we'll wind up revoting or waiving it as not
practically fixable.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
6 months, 1 week
Fedora Linux 39 Final blocker status summary #2
by Adam Williamson
Hi folks! We're still trying to get F39 done, so time for another
status update...
Action summary
==============
Accepted blockers
-----------------
1. curl - https://bugzilla.redhat.com/2243182 - ON_QA: QA to test and
karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-0f8d1871d8
2. distribution - https://bugzilla.redhat.com/2243034 - ASSIGNED:
maintainers to try and squeeze out any possible space savings, FESCo to
consider https://pagure.io/fesco/issue/3082
3. ghostscript - https://bugzilla.redhat.com/2241112 - ON_QA: QA to
test and karma
https://bodhi.fedoraproject.org/updates/FEDORA-2023-c2665a9ff3
4. initial-setup - https://bugzilla.redhat.com/2241274 - ON_QA: QA (and
pwhalen, who reported the bug) to test and karma
https://bodhi.fedoraproject.org/updates/FEDORA-2023-133bdc4283
5. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED: desktop
team to investigate and fix, now this is well triaged
6. shim - https://bugzilla.redhat.com/2113005 - NEW: stakeholders to
consider waiving again at go/no-go
7. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: ARM
team to investigate and fix
8. distribution - https://bugzilla.redhat.com/2242759 - NEW:
stakeholders to consider whether any 'fix' is realistic, implement if
so
Proposed blockers
-----------------
1. anaconda - https://bugzilla.redhat.com/2243206 - POST: blocker
voters to vote, anaconda team to fix if accepted
Bug-by-bug detail
=================
Accepted blockers
-----------------
1. curl - https://bugzilla.redhat.com/2243182 - ON_QA
CVE-2023-38545 curl: a heap based buffer overflow in the SOCKS5 proxy
handshake [fedora-all]
The fix for this is in updates-testing and just needs testing and
karma.
2. distribution - https://bugzilla.redhat.com/2243034 - ASSIGNED
Fedora 39: Server boot aarch64 image exceeds maximum size
This image is oversize because of increases in the size of qualcomm
firmware. (The sizes of aarch64 and x86_64 images differ somewhat
because they include different firmware packages; x86_64 is fine ATM).
We can't drop the new firmware files (says pbrobinson) and I couldn't
see any obvious other place to save 6M when I looked at this. In any
case, the 700M size limit makes no practical sense for aarch64 (700M is
set as the limit because it's the size of a CD; hands up if you have an
aarch64 device with a CD-but-not-DVD drive!), and we are probably
reaching the limits of its usefulness as a protection against "bloat",
since linux-firmware is constantly increasing in size even if we don't
introduce any new "bloat" to the installer environment. So I've
proposed https://pagure.io/fesco/issue/3082 to bump the size limit to
1G for the aarch64 image at least. If FESCo goes for that proposal,
this would be addressed.
3. ghostscript - https://bugzilla.redhat.com/2241112 - ON_QA
CVE-2023-43115 ghostscript: GhostPDL can lead to remote code execution
via crafted PostScript documents [fedora-all]
The fix for this is in updates-testing and just needs testing and
karma.
4. initial-setup - https://bugzilla.redhat.com/2241274 - ON_QA
initial-setup text fails on hardware
The fix for this is in updates-testing and just needs testing and
karma. Especially it'd be great if pwhalen could test and confirm as he
reported the issue.
5. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED
Netinstall ISO renders a black screen when using kickstart install
(bare metal and VM)
I've managed to narrow this down to a specific mutter pull request
which caused the problem, and found a small change (discovered by
someone from upstream to address a different symptom) that avoids this
bug. Now up to the desktop team to decide what the best real fix is.
6. shim - https://bugzilla.redhat.com/2113005 - NEW
Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to
boot on some boards
Sadly we will probably have to waive this one more time, at this point
in the cycle it's not realistic to start backporting kernel changes.
7. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED
Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi
4
pbrobinson has said he's working on this, unless anyone else expert in
uboot-tools stuff wants to help, not much more to be done.
8. distribution - https://bugzilla.redhat.com/2242759 - NEW
dnf system-upgrade fails on some RPi4 due to system boot date that pre-
dates gpg key
We seem to have developed a pretty good understanding of this one now,
but based on that understanding, it may not be realistically possible
to "fix" it - the only interventions proposed so far that might "fix"
it seem rather too radical to introduce as updates to a stable release
(F38), which is where they'd have to go. Unless anyone has a bright
idea, we might just have to accept that this isn't realistically
fixable and waive it to be addressed with documentation.
Proposed blockers
-----------------
1. anaconda - https://bugzilla.redhat.com/2243206 - POST
anaconda should allow installations on drives providing installation
source
This is at -3, +1 in voting currently. Needs more votes. If it happens
to be accepted, anaconda team would have to decide on a fix.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
6 months, 1 week
Re: PCIe slot on Raspberry Pi CM4
by Peter Robinson
On Mon, Sep 4, 2023 at 3:34 AM James Clark <jjc(a)jclark.com> wrote:
>
> I am trying to connect an i210-T1 to the PCIe slot on a Raspberry Pi CM4 with the official IO board. The problem is it won't boot. I tried this in Fedora 38 initially. Now I've installed a recent nightly (Fedora-Server-39-20230828.n.0.aarch64.raw.xz) and I've connected a USB TTL adapter. It appears to be a U-Boot problem. I get the following over and over again
The PCIe does work because the USB-3 is a VIA PCIe attached device on
the RPi4, I wonder what interesting things this card is doing to cause
this error. Do you have more details like make/model of the card, is
it single or multiport etc?
> U-Boot 2023.10-rc3 (Aug 21 2023 - 00:00:00 +0000)
>
> DRAM: 992 MiB (effective 7.9 GiB)
> RPI Compute Module 4 (0xd03141)
> Core: 212 devices, 16 uclasses, devicetree: board
> MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> In: serial,usbkbd
> Out: serial,vidconsole
> Err: serial,vidconsole
> Net: eth0: ethernet@7d580000
> PCIe BRCM: link up, 2.5 Gbps x1 (SSC)
> "Error" handler, esr 0xbf000002
> elr: 00000000000b52b0 lr : 00000000000b526c (reloc)
> elr: 000000003df812b0 lr : 000000003df8126c
> x0 : 000000000000dead x1 : 0000000000100000
> x2 : 0000000000008000 x3 : 00000000fd508000
> x4 : 000000003db399f0 x5 : 0000000000000001
> x6 : 000000003df82bb8 x7 : 000000003db39fc0
> x8 : 000000003df82c90 x9 : 000000003db3992c
> x10: 0000000000000002 x11: 0000000000000140
> x12: 000000003db39918 x13: 000000003db39fc0
> x14: 00000000ffffffff x15: 000000003db39b78
> x16: 000000003df82c90 x17: 0000000000c0c0c0
> x18: 000000003db47d60 x19: 000000003db399f0
> x20: 0000000000000001 x21: 000000003db53f00
> x22: 0000000000000000 x23: 0000000000010000
> x24: 000000003dfc58fc x25: 000000000001ff00
> x26: 000000000000ffff x27: 0000000000000000
> x28: 000000003db53b10 x29: 000000003db39950
>
> Code: 350001f4 f94017e0 39400000 92401c00 (d5033fbf)
> Resetting CPU ...
>
> resetting ...
>
> James
>
>
> _______________________________________________
> 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
7 months, 3 weeks
Re: PCIe slot on Raspberry Pi CM4
by James Clark
Well, it might help... Does Manjaro use U-Boot on the CM4? If so, what version?
James
On Mon, Sep 4, 2023 at 9:57 AM Randy DuCharme <radio.ad5gb(a)gmail.com> wrote:
>
> I realize this is of zero help - but had similar issues wit F38. I
> needed my RPi to be working so shifted over to Manjaro.
>
> Zero issues !
>
> Jus' sayin'
>
>
>
>
> On 9/3/2023 9:33 PM, James Clark wrote:
> > I am trying to connect an i210-T1 to the PCIe slot on a Raspberry Pi
> > CM4 with the official IO board. The problem is it won't boot. I tried
> > this in Fedora 38 initially. Now I've installed a recent nightly
> > (Fedora-Server-39-20230828.n.0.aarch64.raw.xz) and I've connected a
> > USB TTL adapter. It appears to be a U-Boot problem. I get the
> > following over and over again
> >
> > U-Boot 2023.10-rc3 (Aug 21 2023 - 00:00:00 +0000)
> >
> > DRAM: 992 MiB (effective 7.9 GiB)
> > RPI Compute Module 4 (0xd03141)
> > Core: 212 devices, 16 uclasses, devicetree: board
> > MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
> > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> > In: serial,usbkbd
> > Out: serial,vidconsole
> > Err: serial,vidconsole
> > Net: eth0: ethernet@7d580000
> > PCIe BRCM: link up, 2.5 Gbps x1 (SSC)
> > "Error" handler, esr 0xbf000002
> > elr: 00000000000b52b0 lr : 00000000000b526c (reloc)
> > elr: 000000003df812b0 lr : 000000003df8126c
> > x0 : 000000000000dead x1 : 0000000000100000
> > x2 : 0000000000008000 x3 : 00000000fd508000
> > x4 : 000000003db399f0 x5 : 0000000000000001
> > x6 : 000000003df82bb8 x7 : 000000003db39fc0
> > x8 : 000000003df82c90 x9 : 000000003db3992c
> > x10: 0000000000000002 x11: 0000000000000140
> > x12: 000000003db39918 x13: 000000003db39fc0
> > x14: 00000000ffffffff x15: 000000003db39b78
> > x16: 000000003df82c90 x17: 0000000000c0c0c0
> > x18: 000000003db47d60 x19: 000000003db399f0
> > x20: 0000000000000001 x21: 000000003db53f00
> > x22: 0000000000000000 x23: 0000000000010000
> > x24: 000000003dfc58fc x25: 000000000001ff00
> > x26: 000000000000ffff x27: 0000000000000000
> > x28: 000000003db53b10 x29: 000000003db39950
> >
> > Code: 350001f4 f94017e0 39400000 92401c00 (d5033fbf)
> > Resetting CPU ...
> >
> > resetting ...
> >
> > James
> >
> >
> >
> > _______________________________________________
> > 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
>
> --
> Randall DuCharme (Radio AD5GB)
> Powered entirely by Open Source software.
>
> _______________________________________________
> 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
7 months, 3 weeks