Raspberry Pi hardware accelerated media support
by Neal Gompa
Hey folks,
I was just looking up Fedora's hardware support for the Raspberry Pi
platform vs the Raspberry Pi OS, and I noticed in the FAQ that we
indicate that the camera and accelerated media stuff doesn't work in
Fedora[1].
I know that previously this depended on weird blobs and a fork of the
OpenMAX libraries, but it seems today that Raspberry Pi OS' kernel
uses v4l2 for this and has some staging drivers that seem suitable for
upstream[2]. Taking a look at the latest in Linus' tree yields that
most of it isn't staged there yet[3], and searching linux-arm-kernel@
doesn't *seem* to yield any recent patch submission for them[4].
All of this to ask: does anyone know what the plan around this stuff
is and when we might see this in Fedora Linux? Am I missing something
in particular that would make this clearer, like a tracker of some
kind or something?
Thanks in advance and best regards!
[1]: https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/#_does_the_a...
[2]: https://github.com/raspberrypi/linux/tree/rpi-5.15.y/drivers/staging/vc04...
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/d...
[4]: https://lore.kernel.org/linux-arm-kernel/
--
真実はいつも一つ！/ Always, there's only one truth!
2 years, 2 months
Re: F37 Change: RetireARMv7 (System-Wide Change proposal)
by Peter Robinson
On Mon, Feb 7, 2022 at 11:00 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
>
> On Sun, 2022-02-06 at 14:54 +0100, David Bold wrote:
> >
> >
> > I just tried to install Fedora on RPi, and I ended up on [1] where I
> > downloaded an image. That was unfortunately armv7 - and I needed to go
> > to [2] - which was not linked in the descriptions [3,4]. Also the wiki
> > lists first the armv7 [5]
> >
> > [1] https://arm.fedoraproject.org/
> > [2] https://alt.fedoraproject.org/alt/
> > [3] https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/
> > [4]
> > https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/#installing-...
> > [5] https://www.fedoraproject.org/wiki/Architectures/ARM/Fedora_Linux_35
>
> So yeah, I think cleaning up and modernizing all this should be in-
> scope for the Change, thanks for highlighting it.
This is already in motion as part of the work being done by the design
team on the website, it's unrelated to this change and has been in
motion for some time. All the arm/alt pages are going away and all
arches for each artifact will just be on the edition/spin/lab pages.
> The arm.fp.o site and the docs page you used are both, I think, older
> things that date from before we really supported aarch64 much at all,
> and they clearly haven't been updated. The "current" approach is not
> great either, though. If you just go in through the front door of the
> docs page you'd go to "User Documentation" for "Fedora Linux 35", which
> takes you here: https://docs.fedoraproject.org/en-US/fedora/f35/
>
> from where I guess you'd go to
> https://docs.fedoraproject.org/en-US/fedora/f35/install-guide/Downloading...
> , which has an "ARM images" section which points you to
> https://fedoraproject.org/wiki/Architectures/ARM . That page then
> points you to
> https://fedoraproject.org/wiki/Architectures/ARM/Installation , which
> does at least cover aarch64, but seems to give armhfp equal or higher
> prominence.
>
> It would be great if we can get a doc person to take a look at all
> these pages referenced above and try to streamline them, modernize
> them, and get them all singing from the same hymn sheet, I guess.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
2 years, 2 months
Re: F37 Change: RetireARMv7 (System-Wide Change proposal)
by Adam Williamson
On Sun, 2022-02-06 at 14:54 +0100, David Bold wrote:
>
>
> I just tried to install Fedora on RPi, and I ended up on [1] where I
> downloaded an image. That was unfortunately armv7 - and I needed to go
> to [2] - which was not linked in the descriptions [3,4]. Also the wiki
> lists first the armv7 [5]
>
> [1] https://arm.fedoraproject.org/
> [2] https://alt.fedoraproject.org/alt/
> [3] https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/
> [4]
> https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/#installing-...
> [5] https://www.fedoraproject.org/wiki/Architectures/ARM/Fedora_Linux_35
So yeah, I think cleaning up and modernizing all this should be in-
scope for the Change, thanks for highlighting it.
The arm.fp.o site and the docs page you used are both, I think, older
things that date from before we really supported aarch64 much at all,
and they clearly haven't been updated. The "current" approach is not
great either, though. If you just go in through the front door of the
docs page you'd go to "User Documentation" for "Fedora Linux 35", which
takes you here: https://docs.fedoraproject.org/en-US/fedora/f35/
from where I guess you'd go to
https://docs.fedoraproject.org/en-US/fedora/f35/install-guide/Downloading...
, which has an "ARM images" section which points you to
https://fedoraproject.org/wiki/Architectures/ARM . That page then
points you to
https://fedoraproject.org/wiki/Architectures/ARM/Installation , which
does at least cover aarch64, but seems to give armhfp equal or higher
prominence.
It would be great if we can get a doc person to take a look at all
these pages referenced above and try to streamline them, modernize
them, and get them all singing from the same hymn sheet, I guess.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2 years, 2 months
Re: Fedora support for NanoPi-R1?
by Peter Robinson
On Tue, Nov 30, 2021 at 2:19 PM Derek Atkins <derek(a)ihtfp.com> wrote:
>
>
> On Tue, November 30, 2021 8:53 am, Peter Robinson wrote:
>
> >> I've been using Wandboards, which I've liked, but I discovered that what
> >> I
> >> was using just wasn't powerful enough to do what I wanted to do.. So I
> >> was looking for replacements for my wandboards. I have a handful of
> >> these
> >> R1 devices from work, so I've been able to play with them and verify
> >> that,
> >> yes, it can do what I want and perform much better than the wandboard
> >> quad
> >> did.
> >
> > The R1 is based on a Allwinner H3, it's a quad core Cortex-A7, it's
> > not really any more powerful than the quad core Wandboard TBH.
>
> Perhaps, but it IS faster/more powerful. Not that you can trust the
> "bogomips" results, but the R1 definitely reports a "higher" number ;)
> Specifically, the WB reports 6, and the R1 reports 64.
> And I was able to get more audio streams through the R1 than the Wandboard
> running shairport-sync.
>
> On the other hand, I do need to go verify that I *WAS* running a quad
> wandboard for that server; I honestly don't recall now (and the device is
> now offline) so I can't quickly check.
>
> >> Let me turn this around; what board (with case) would *YOU* recommend
> >> for
> >> some small, low-power arm-based server platforms?
> >
> > I always reply to that with the question what are you doing with them?
> > What are your feature requirements? Eth? Dual eth? WiFi, etc.....
>
> I've got three ARM systems deployed right now:
> 1) DHCP/DNS/Unifi Controller
> 2) Asterisk
> 3) My shairport-sync server (~16 streams)
>
> Right now I've got #3 on an R1 with Armbian Buster -- the only
> non-RPM-based distro I'm running!
>
> #2 is fine as a wandboard quad. I'm not having issues there.
>
> #1 is running on a Wandboard Quad, which has 2GB RAM. Currently it is
> reporting:
>
> [~]# free
> total used free shared buff/cache
> available
> Mem: 2061172 871612 140692 804 1048868
> 1162612
> Swap: 982420 11008 971412
>
> Granted, it works here, but I'd like to "update" from the old version of
> Fedora running there onto a newer version, but the main issue is the unifi
> controller. The issue was with mongodb-server, where I had to rebuild it
> myself to get it to work on the platform. If I'm going to upgrade to F35
> on the WB I might need to do that again (unless it will continue to
> support mongodb 4.0.3).
>
> Unfortunately there is still not an armhfp build of mongo -- although
> there is one for aarch64, so if I stay with that (instead of aarch64) I'll
> still have to rebuild mongo again -- so I guess to replace this system I'd
> want an aarch64 board with sufficient RAM to run mongo and unifi. I don't
> mind using an SD for storage (certainly for mongo). The system currently
> uses 6G of storage, which would fill most of the 8G eMMC devices. But I
> am concerned about the 1G.
There will never be mongodb for 32 bit, it's architecture doesn't allow it.
Personally 32 bit is basically coming to an end, we're proposing
retiring it from Fedora 37, which means Fedora 36, supported until
June 2023 will be the last release that's supported.
I would probably suggest a Raspberry Pi 4, you can get with up to 8GB
of RAM and they work well now for non graphical applications.
[1] https://fedoraproject.org/wiki/Changes/RetireARMv7
2 years, 4 months
Re: Wiki claims RPi 4 is not supported
by Peter Robinson
On Fri, Sep 24, 2021 at 7:23 PM Stefan Wahren <stefan.wahren(a)i2se.com> wrote:
>
> Am 24.09.21 um 04:47 schrieb Donatom M:
> > I just restarted my fedora-arm system on raspberry pi 4 after days of
> > using another system and found that the sound does in fact work (I
> > shut off all devices but my bluetooth speaker in the pavucontrol
> > configuration window -- misconfiguration in pavucontrol likely was the
> > reason I could not get audio to work before).
> >
> > So I would say that the mainline fedora-ARM aarch64 kernel is
> > functioning pretty well on my system: video works well as does audio,
> > all usb ports work (usb 2 and 3) and I am able to start up on an SSD
> > with no problem. Wifi and bluetooth have been functional out of the box.
>
> I was imprecise in my mail about audio support. HDMI audio (provided by
> vc4) should work, the audio jack (provided by bcm2835-audio) should not.
That's mostly my experience, that HDMI audio works most of the time,
but we've had a bunch of random regressions upstream, it seems to come
and go hence why my general point is that it's not supported,
ultimately in fact now I see that as generally the case for vc4 as a
whole it used to be very stable but now it's stability in general
seems to vary greatly.
Peter
2 years, 7 months
Re: Wiki claims RPi 4 is not supported
by Stefan Wahren
Am 24.09.21 um 04:47 schrieb Donatom M:
> I just restarted my fedora-arm system on raspberry pi 4 after days of
> using another system and found that the sound does in fact work (I
> shut off all devices but my bluetooth speaker in the pavucontrol
> configuration window -- misconfiguration in pavucontrol likely was the
> reason I could not get audio to work before).
>
> So I would say that the mainline fedora-ARM aarch64 kernel is
> functioning pretty well on my system: video works well as does audio,
> all usb ports work (usb 2 and 3) and I am able to start up on an SSD
> with no problem. Wifi and bluetooth have been functional out of the box.
I was imprecise in my mail about audio support. HDMI audio (provided by
vc4) should work, the audio jack (provided by bcm2835-audio) should not.
Regards
2 years, 7 months
Re: Wiki claims RPi 4 is not supported
by Peter Robinson
>> I just restarted my fedora-arm system on raspberry pi 4 after days of using another system and found that the sound does in fact work (I shut off all devices but my bluetooth speaker in the pavucontrol configuration window -- misconfiguration in pavucontrol likely was the reason I could not get audio to work before).
>>
>> So I would say that the mainline fedora-ARM aarch64 kernel is functioning pretty well on my system: video works well as does audio, all usb ports work (usb 2 and 3) and I am able to start up on an SSD with no problem. Wifi and bluetooth have been functional out of the box.
Well bluetooth is an interesting choice as it definitely has issues
because there's not an upstream firmware so it sort of works but has a
lot of issues. If it works for you great
>> The system does take about two minute to boot up. I am using openbox with full xorg capability.
Well I'm not sure what you mean by "full xorg capability" in this
context as it will be non accelerated which is probably OK for
something as basic as openbox but for the desktops that the other
99.9% use such as GNOME/KDE/XFCE it's really not a great experience.
>> It seems that there is a good case for stating that raspberry pi 4B is supported by the fedora-ARM 64 bit kernel (aarch64) on the Fedora-ARM wiki. Now perhaps things don't work as well on a Fedora Workstation which is very bloated -- I don't know but I do know that on a less demanding system (like openbox), everything seems to be running well.
I completely disagree, you don't provide a strong case at all, it's
not even on a mainstream desktop environment, it's one that's probably
0.1% of the Fedora RPi user community.
For starters there's no accelerated graphics upstream, as stated a
number of times before. The person who was working on that stopped
because the device would lock up randomly due to power state
transitions and the details of that isn't public so needs someone from
the RPi foundation to provide the right information. I think that
request is outstanding 6+ months now.
We have a regression upstream with booting systems headless[1]
probably one of the biggest RPi usecases in Fedora.
And we've even has issues with booting them in the lead up to F-35
Beta and while we now have a work around the RPi foundation team can't
even agree whether their firmware works or regresses [2].
And that just 3 examples of why I, as the maintainer of the Raspberry
Pi in Fedora, don't think it's not in a state where we can state
support for the Raspberry Pi 4 in Fedora. Frankly with some of the
recent regressions and the lack of interest from RPi to actually
support general purpose distributions I am strongly reconsidering the
support status of all generations of the Raspberry Pi.
I've been the maintainer of the RPi since we started supporting it in
Fedora 25, and was involved in the entire process right from the
outset and having hate actual hate mail and actual physical threats
over this device I am well aware of what state we need the device to
be in before I make that change in the wiki or anywhere else.
If you wish to take over the maintainer-ship I will gladly step aside!
Peter
[1] https://www.spinics.net/lists/arm-kernel/msg922125.html
[2] https://github.com/raspberrypi/firmware/issues/1619#issuecomment-925982112
2 years, 7 months
Re: Wiki claims RPi 4 is not supported
by Donatom M
On Thu, Sep 23, 2021 at 7:47 PM Donatom M <donatom.martino(a)gmail.com> wrote:
> I just restarted my fedora-arm system on raspberry pi 4 after days of
> using another system and found that the sound does in fact work (I shut off
> all devices but my bluetooth speaker in the pavucontrol configuration
> window -- misconfiguration in pavucontrol likely was the reason I could not
> get audio to work before).
>
> So I would say that the mainline fedora-ARM aarch64 kernel is functioning
> pretty well on my system: video works well as does audio, all usb ports
> work (usb 2 and 3) and I am able to start up on an SSD with no problem.
> Wifi and bluetooth have been functional out of the box.
>
> The system does take about two minute to boot up. I am using openbox with
> full xorg capability.
>
> It seems that there is a good case for stating that raspberry pi 4B is
> supported by the fedora-ARM 64 bit kernel (aarch64) on the Fedora-ARM wiki.
> Now perhaps things don't work as well on a Fedora Workstation which is very
> bloated -- I don't know but I do know that on a less demanding system (like
> openbox), everything seems to be running well.
>
>
>
>
>
>
> On Wed, Sep 22, 2021 at 9:21 AM Peter Robinson <pbrobinson(a)gmail.com>
> wrote:
>
>> On Wed, Sep 22, 2021 at 5:14 PM Donatom M <donatom.martino(a)gmail.com>
>> wrote:
>> >
>> > Someone on this thread mentioned that Archlinux-ARM uses raspberry pi
>> linux kernel. That might be for the 32 bit version but when you are running
>> 64 bit on the raspberry pi it seems that the kernel is a regular linux
>> kernel for ARM architecture. [url]
>> https://kiljan.org/2021/05/28/64-bit-arch-linux-arm-on-a-raspberry-pi-4-m...
>> [/url]
>> >
>> > I bring this up because I believe Fedora ARM could use the same kernel
>> (non-raspberry pi modified) and thereby get all features (audio, etc.)
>> working out of the box.
>>
>> As the maintainer I've already investigated that, if it's "working"
>> it's not an upstream kernel as not all things are upstream. One of the
>> upstream maintainers commented explicitly on that earlier in the
>> thread. It's not like I don't actually read just about all of the
>> upstream kernel commits for each cycle to see what changes.
>>
>> > On Tue, Sep 21, 2021 at 3:52 PM Donatom M <donatom.martino(a)gmail.com>
>> wrote:
>> >>
>> >> Okay. Thanks, Peter.
>> >>
>> >> On Tue, Sep 21, 2021 at 1:07 PM Peter Robinson <pbrobinson(a)gmail.com>
>> wrote:
>> >>>
>> >>> On Tue, Sep 21, 2021 at 9:00 PM Donatom M <donatom.martino(a)gmail.com>
>> wrote:
>> >>> >
>> >>> > How do I do that. I thought it would be automatic.
>> >>>
>> >>> Reply All.
>> >>>
>> >>> > On Tue, Sep 21, 2021 at 12:20 PM Peter Robinson <
>> pbrobinson(a)gmail.com> wrote:
>> >>> >>
>> >>> >> Please leave the mailing list on replied.
>> >>> >>
>> >>> >> > I would agree that fedora 34 arm has some disadvantages when run
>> on Raspberry Pi 4 with xorg server. I have fedora installed onto a SSD
>> drive. As another member mentioned, I have found that audio does not work
>> out of the box. I have not tried to get audio to work because audio was not
>> important to me on this build. I would hope that Raspberry Pi support and
>> fedora-arm would work on remedying the few problems that exist.
>> >>> >> >
>> >>> >> > I would like to note that I also have Archlinux-Arm with X
>> server on an SD card (128 GiG) and everything works without any problem at
>> all, so I would think that if Arch-ARM can build a system that is fully
>> functional on Raspberry Pi 4, so can Fedora-ARM. All of my systems are
>> running 64 bit with Raspberry Pi 4, by the way.
>> >>> >>
>> >>> >> Archlinux-Arm uses the downstream Raspberry Pi fork of the kernel.
>> >>> >>
>> >>> >> > On Tue, Sep 21, 2021 at 1:32 AM Peter Robinson <
>> pbrobinson(a)gmail.com> wrote:
>> >>> >> >>
>> >>> >> >> > >> On this page it states that the RPi4 is not supported.
>> >>> >> >>
>> >>> >> >> That is correct, there's a very large cavernous gap between
>> "may work
>> >>> >> >> for a number of purposes including yours" and something that
>> will work
>> >>> >> >> for the vast majority of users.
>> >>> >> >>
>> >>> >> >> The core "supported" status will change when the standard GUI
>> runs
>> >>> >> >> fully accelerated and users have WiFi/sound and the things that
>> are
>> >>> >> >> associated with a reasonable desktop experience as that's the
>> default
>> >>> >> >> means a lot of new users expect. That's what I, as the RPi
>> maintainer,
>> >>> >> >> did when we introduced "supported" RPi3. Any less than that the
>> >>> >> >> support queries are too high.
>> >>> >> >>
>> >>> >> >> > >>
>> https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_4
>> >>> >> >> > >
>> >>> >> >> > > yes the statement about hardware support isn't quite
>> correct anymore.
>> >>> >> >> > > But there is still a noticeable difference between the
>> mainline kernel
>> >>> >> >> > > (which Fedora uses) and the vendor kernel from the
>> Raspberry Pi Foundation.
>> >>> >> >> > >
>> >>> >> >> > > Most notably are:
>> >>> >> >> > > - audio support
>> >>> >> >> > > - V3D support
>> >>> >> >>
>> >>> >> >> Those two are critical.
>> >>> >> >>
>> >>> >> >> > An update to say clearly that only server/headless worked
>> then would better the. The blanket “it does not work”. I is only that I
>> looked deeper that I found out that it
>> >>> >> >> > might work.
>> >>> >> >>
>> >>> >> >> The Wiki page explicitly does not say "it does not work" it
>> says it's
>> >>> >> >> not supported. The words are chosen specifically. By saying it's
>> >>> >> >> supported a user can rock up when something doesn't work and
>> ask for
>> >>> >> >> support or assistance, if something breaks we block the release
>> etc.
>> >>> >> >> By saying it's not supported a user may try it and if it works
>> for
>> >>> >> >> them great, but if it breaks while we'll attempt to fix it that
>> may
>> >>> >> >> take time and it may not get fixed.
>> >>> >> >>
>> >>> >> >> > Oh and would need a warning that the boot is very slow.
>> >>> >> >> > I see a black screen for a couple of minutes before I see any
>> output
>> >>> >> >> > from the kernel or systemd.
>> >>> >> >>
>> >>> >> >> Oh look, a user asking for "support".... see my points above!
>> >>> >> >>
>> >>> >> >> > > A lot users doesn't accept this. Instead of blaming the
>> vendor to focus
>> >>> >> >> > > on its own kernel branch, they blame Fedora for using the
>> mainline
>> >>> >> >> > > kernel. So that's the reason to say it's not officially
>> supported.
>> >>> >> >>
>> >>> >> >> It's one reason, but not the only ones.
>> >>> >> >>
>> >>> >> >> > >> There a lots of messages in this mailing archieve showing
>> that people are
>> >>> >> >> > >> getting Fedora to work on RPi4.
>> >>> >> >>
>> >>> >> >> Yes, and that's the idea, a more advanced user will be able to
>> >>> >> >> ascertain it works, and it has for a *long* time and likely be
>> able to
>> >>> >> >> do most of what they want to do.
>> >>> >> >>
>> >>> >> >> > >> Is there still a reason to claim its not supported?
>> >>> >> >> > >> If so what should I be watching out for/avoiding with the
>> RPi4?
>> >>> >> >> > > For a headless / server setup there shouldn't be no general
>> issues.
>> >>> >> >>
>> >>> >> >> For a headless server it should be fine, but a general user
>> comes via
>> >>> >> >> Fedora Workstation and expect and accelerated desktop and sound
>> and we
>> >>> >> >> don't have them working ATM.
>> >>> >> >>
>> >>> >> >> Peter
>> >>> >> >> - The Fedora Raspberry Pi "maintainer"
>> >>> >> >> _______________________________________________
>> >>> >> >> 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 on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
2 years, 7 months
Re: Wiki claims RPi 4 is not supported
by Donatom M
I just restarted my fedora-arm system on raspberry pi 4 after days of using
another system and found that the sound does in fact work (I shut off all
devices but my bluetooth speaker in the pavucontrol configuration window --
misconfiguration in pavucontrol likely was the reason I could not get audio
to work before).
So I would say that the mainline fedora-ARM aarch64 kernel is functioning
pretty well on my system: video works well as does audio, all usb ports
work (usb 2 and 3) and I am able to start up on an SSD with no problem.
Wifi and bluetooth have been functional out of the box.
The system does take about two minute to boot up. I am using openbox with
full xorg capability.
It seems that there is a good case for stating that raspberry pi 4B is
supported by the fedora-ARM 64 bit kernel (aarch64) on the Fedora-ARM wiki.
Now perhaps things don't work as well on a Fedora Workstation which is very
bloated -- I don't know but I do know that on a less demanding system (like
openbox), everything seems to be running well.
On Wed, Sep 22, 2021 at 9:21 AM Peter Robinson <pbrobinson(a)gmail.com> wrote:
> On Wed, Sep 22, 2021 at 5:14 PM Donatom M <donatom.martino(a)gmail.com>
> wrote:
> >
> > Someone on this thread mentioned that Archlinux-ARM uses raspberry pi
> linux kernel. That might be for the 32 bit version but when you are running
> 64 bit on the raspberry pi it seems that the kernel is a regular linux
> kernel for ARM architecture. [url]
> https://kiljan.org/2021/05/28/64-bit-arch-linux-arm-on-a-raspberry-pi-4-m...
> [/url]
> >
> > I bring this up because I believe Fedora ARM could use the same kernel
> (non-raspberry pi modified) and thereby get all features (audio, etc.)
> working out of the box.
>
> As the maintainer I've already investigated that, if it's "working"
> it's not an upstream kernel as not all things are upstream. One of the
> upstream maintainers commented explicitly on that earlier in the
> thread. It's not like I don't actually read just about all of the
> upstream kernel commits for each cycle to see what changes.
>
> > On Tue, Sep 21, 2021 at 3:52 PM Donatom M <donatom.martino(a)gmail.com>
> wrote:
> >>
> >> Okay. Thanks, Peter.
> >>
> >> On Tue, Sep 21, 2021 at 1:07 PM Peter Robinson <pbrobinson(a)gmail.com>
> wrote:
> >>>
> >>> On Tue, Sep 21, 2021 at 9:00 PM Donatom M <donatom.martino(a)gmail.com>
> wrote:
> >>> >
> >>> > How do I do that. I thought it would be automatic.
> >>>
> >>> Reply All.
> >>>
> >>> > On Tue, Sep 21, 2021 at 12:20 PM Peter Robinson <
> pbrobinson(a)gmail.com> wrote:
> >>> >>
> >>> >> Please leave the mailing list on replied.
> >>> >>
> >>> >> > I would agree that fedora 34 arm has some disadvantages when run
> on Raspberry Pi 4 with xorg server. I have fedora installed onto a SSD
> drive. As another member mentioned, I have found that audio does not work
> out of the box. I have not tried to get audio to work because audio was not
> important to me on this build. I would hope that Raspberry Pi support and
> fedora-arm would work on remedying the few problems that exist.
> >>> >> >
> >>> >> > I would like to note that I also have Archlinux-Arm with X server
> on an SD card (128 GiG) and everything works without any problem at all, so
> I would think that if Arch-ARM can build a system that is fully functional
> on Raspberry Pi 4, so can Fedora-ARM. All of my systems are running 64 bit
> with Raspberry Pi 4, by the way.
> >>> >>
> >>> >> Archlinux-Arm uses the downstream Raspberry Pi fork of the kernel.
> >>> >>
> >>> >> > On Tue, Sep 21, 2021 at 1:32 AM Peter Robinson <
> pbrobinson(a)gmail.com> wrote:
> >>> >> >>
> >>> >> >> > >> On this page it states that the RPi4 is not supported.
> >>> >> >>
> >>> >> >> That is correct, there's a very large cavernous gap between "may
> work
> >>> >> >> for a number of purposes including yours" and something that
> will work
> >>> >> >> for the vast majority of users.
> >>> >> >>
> >>> >> >> The core "supported" status will change when the standard GUI
> runs
> >>> >> >> fully accelerated and users have WiFi/sound and the things that
> are
> >>> >> >> associated with a reasonable desktop experience as that's the
> default
> >>> >> >> means a lot of new users expect. That's what I, as the RPi
> maintainer,
> >>> >> >> did when we introduced "supported" RPi3. Any less than that the
> >>> >> >> support queries are too high.
> >>> >> >>
> >>> >> >> > >>
> https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_4
> >>> >> >> > >
> >>> >> >> > > yes the statement about hardware support isn't quite correct
> anymore.
> >>> >> >> > > But there is still a noticeable difference between the
> mainline kernel
> >>> >> >> > > (which Fedora uses) and the vendor kernel from the Raspberry
> Pi Foundation.
> >>> >> >> > >
> >>> >> >> > > Most notably are:
> >>> >> >> > > - audio support
> >>> >> >> > > - V3D support
> >>> >> >>
> >>> >> >> Those two are critical.
> >>> >> >>
> >>> >> >> > An update to say clearly that only server/headless worked then
> would better the. The blanket “it does not work”. I is only that I looked
> deeper that I found out that it
> >>> >> >> > might work.
> >>> >> >>
> >>> >> >> The Wiki page explicitly does not say "it does not work" it says
> it's
> >>> >> >> not supported. The words are chosen specifically. By saying it's
> >>> >> >> supported a user can rock up when something doesn't work and ask
> for
> >>> >> >> support or assistance, if something breaks we block the release
> etc.
> >>> >> >> By saying it's not supported a user may try it and if it works
> for
> >>> >> >> them great, but if it breaks while we'll attempt to fix it that
> may
> >>> >> >> take time and it may not get fixed.
> >>> >> >>
> >>> >> >> > Oh and would need a warning that the boot is very slow.
> >>> >> >> > I see a black screen for a couple of minutes before I see any
> output
> >>> >> >> > from the kernel or systemd.
> >>> >> >>
> >>> >> >> Oh look, a user asking for "support".... see my points above!
> >>> >> >>
> >>> >> >> > > A lot users doesn't accept this. Instead of blaming the
> vendor to focus
> >>> >> >> > > on its own kernel branch, they blame Fedora for using the
> mainline
> >>> >> >> > > kernel. So that's the reason to say it's not officially
> supported.
> >>> >> >>
> >>> >> >> It's one reason, but not the only ones.
> >>> >> >>
> >>> >> >> > >> There a lots of messages in this mailing archieve showing
> that people are
> >>> >> >> > >> getting Fedora to work on RPi4.
> >>> >> >>
> >>> >> >> Yes, and that's the idea, a more advanced user will be able to
> >>> >> >> ascertain it works, and it has for a *long* time and likely be
> able to
> >>> >> >> do most of what they want to do.
> >>> >> >>
> >>> >> >> > >> Is there still a reason to claim its not supported?
> >>> >> >> > >> If so what should I be watching out for/avoiding with the
> RPi4?
> >>> >> >> > > For a headless / server setup there shouldn't be no general
> issues.
> >>> >> >>
> >>> >> >> For a headless server it should be fine, but a general user
> comes via
> >>> >> >> Fedora Workstation and expect and accelerated desktop and sound
> and we
> >>> >> >> don't have them working ATM.
> >>> >> >>
> >>> >> >> Peter
> >>> >> >> - The Fedora Raspberry Pi "maintainer"
> >>> >> >> _______________________________________________
> >>> >> >> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
2 years, 7 months
Re: Use kodi 19 from rpm fusion on fedora 34 with raspberry pi 2
by Felipe Diefenbach
Ho ho ho, Thx, Thx a lot, it did work like a charm now.
It really need to be lowercase.
grubby --update-kernel /boot/vmlinuz-$(uname -r) --args="cma=256M"
: ) I'm so happy. Thx Thx Man.
Sorry but I didn't make the bridge between the desktop image parameters and the kodi use (dammm :~ )
When I tryed to use same parameters in the /boot/efi/config.txt, and they didn't work and I didn't figure out it need to be in the kernel command line.
If possible, add the solution in the forum do fedora, and mention it need to use it with kodi
---- Ativado Qui, 23 set 2021 12:23:42 -0300 Peter Robinson <pbrobinson(a)gmail.com> escreveu ----
On Thu, Sep 23, 2021 at 4:01 PM Felipe Diefenbach
<mailto:felipe@conexaoinfraestrutura.inf.br> wrote:
>
> Yes, I gived:
>
> The problem stay's the same, or, the parameters didn't affect anything at all.
>
> dmesg | grep -i CMA
>
> [ 0.000000] Reserved memory: created CMA memory pool at 0x29800000, size 64 MiB
> [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> [ 0.000000] Kernel command line: BOOT_IMAGE=(hd0,msdos2)/vmlinuz-5.13.16-200.fc34.armv7hl root=UUID=9ce87fe4-b0f9-4cb1-9ee9-0e3270f8cc42 ro CMA=256M
> [ 0.000000] Memory: 668172K/786432K available (10489K kernel code, 2423K rwdata, 5576K rodata, 2048K init, 557K bss, 52724K reserved, 65536K cma-reserved, 0K highmem)
the cma may need to be lowercase
> [ 6.757255] CMA=256M
> [ 126.230817] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
>
> And:
>
> [ 129.951932] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> [ 129.959162] vc4-drm soc:gpu: [drm] V3D: 35728kb BOs (14)
> [ 129.967073] vc4-drm soc:gpu: [drm] V3D shader: 36kb BOs (9)
> [ 129.974906] vc4-drm soc:gpu: [drm] dumb: 4116kb BOs (5)
> [ 129.982702] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1)
> [ 129.990523] vc4-drm soc:gpu: [drm] total purged BO: 288kb BOs (9)
> [ 224.255219] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:74:crtc-3] flip_done timed out
> [ 224.255242] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
> [ 224.273316] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:74:crtc-3] commit wait timed out
> [ 234.495100] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
> [ 234.503091] vc4-drm soc:gpu: [drm] *ERROR* Timed out waiting for commit
>
>
>
> ---- Ativado Qui, 23 set 2021 09:51:35 -0300 Peter Robinson <mailto:pbrobinson@gmail.com> escreveu ----
>
> On Thu, Sep 23, 2021 at 1:17 PM Felipe Diefenbach
> <mailto:felipe@conexaoinfraestrutura.inf.br> wrote:
> >
> > I tried to use the kernel parameter on boot, but isn't work.
>
> You don't give output of "dmesg | grep -i cma" for the new kernel boot.
>
> > The problem seems to be the same as previous problem.
> >
> > Maybe i have to try the desktop image instead the minimal image ? There would have some big difference between minimal and desktop image to justify use one or another, instead to use minimal X on minimal image ?
> >
> > Or maybe would this be a problem with kodi and i need report this in another forum.
> >
> > Or maybe is another mistake i made.
> >
> > Please, if I would need to send you more details about setup or system, ask me and i will forward this, if i need to get help in other location, please redirect me to the proper location
> >
> > thank you anyway.
> >
> >
> > ---- Ativado Seg, 20 set 2021 16:38:31 -0300 Felipe Diefenbach <mailto:felipe@conexaoinfraestrutura.inf.br> escreveu ----
> >
> > I used this:
> >
> > Fedora-Minimal-34-1.2.armhfp.raw.xz
> > https://mirror1.cl.netactuate.com/fedora/releases/34/Spins/armhfp/images/...
> >
> > before your instructions, i see this in dmesg:
> >
> > dmesg | grep -i CMA
> >
> > [ 0.000000] Reserved memory: created CMA memory pool at 0x29800000, size 64 MiB
> > [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
> > [ 0.000000] Kernel command line: BOOT_IMAGE=(hd0,msdos2)/vmlinuz-5.13.16-200.fc34.armv7hl root=UUID=9ce87fe4-b0f9-4cb1-9ee9-0e3270f8cc42 ro CMA=256M
> > [ 0.000000] Memory: 668172K/786432K available (10489K kernel code, 2423K rwdata, 5576K rodata, 2048K init, 557K bss, 52724K reserved, 65536K cma-reserved, 0K highmem)
> > [ 6.757255] CMA=256M
> > [ 126.230817] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 126.277649] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 126.339697] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 126.406259] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 126.562712] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 126.615279] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 126.677529] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 129.748644] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 129.795836] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 129.848677] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 129.904766] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 129.951932] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> >
> > And:
> >
> > [ 129.951932] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > [ 129.959162] vc4-drm soc:gpu: [drm] V3D: 35728kb BOs (14)
> > [ 129.967073] vc4-drm soc:gpu: [drm] V3D shader: 36kb BOs (9)
> > [ 129.974906] vc4-drm soc:gpu: [drm] dumb: 4116kb BOs (5)
> > [ 129.982702] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1)
> > [ 129.990523] vc4-drm soc:gpu: [drm] total purged BO: 288kb BOs (9)
> > [ 224.255219] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:74:crtc-3] flip_done timed out
> > [ 224.255242] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
> > [ 224.273316] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:74:crtc-3] commit wait timed out
> > [ 234.495100] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
> > [ 234.503091] vc4-drm soc:gpu: [drm] *ERROR* Timed out waiting for commit
> >
> > I will go read the common bugs, but i remember breffly to read this page before.
> >
> > this is my kodi unit for systemd.
> >
> > cat /usr/lib/systemd/system/kodi.service
> > [Unit]
> > Description = kodi-standalone using xinit
> > After = remote-fs.target systemd-user-sessions.service
> >
> > [Service]
> > User = root
> > Group = root
> > PAMName = login
> > Type = simple
> > ExecStart = /usr/bin/xinit /usr/bin/dbus-launch /usr/bin/kodi-standalone -- :0 -nolisten tcp
> > Restart = on-abort
> >
> > [Install]
> > WantedBy = multi-user.target
> >
> > I follow this guide to install kodi: https://kodi.wiki/view/Archive:Install_Kodi_on_Fedora_26_using_RPMFusion_...
> >
> >
> > ---- Ativado Seg, 20 set 2021 15:56:36 -0300 Peter Robinson <mailto:pbrobinson@gmail.com> escreveu ----
> >
> > > cat /etc/redhat-release
> > > Fedora release 34 (Thirty Four)
> >
> > Did you download a specific desktop image?
> >
> > > [ 0.000000] Memory: 668172K/786432K available (10489K kernel code, 2423K rwdata, 5576K rodata, 2048K init, 557K bss, 52724K reserved, 65536K cma-reserved, 0K highmem)
> >
> > That tells me you're running with the default of 64Mb of CMA so
> > depending on your DE with kodi I'm not surprised.
> >
> > > cat /boot/efi/config.txt | grep 256
> > > #cma_hwm=256
> > > gpu_mem=256
> > >
> > > I tryed with mixing of parameters but have no sucess
> >
> > It will need to be a kernel command line:
> > grubby --update-kernel /boot/vmlinuz-$(uname -r) --args="CMA=256M"
> >
> > There's details in the Fedora common bugs:
> > https://fedoraproject.org/wiki/Common_F34_bugs#Desktop_images_may_require...
> >
> >
> > >
> > > ---- Ativado Seg, 20 set 2021 14:06:10 -0300 Peter Robinson <mailto:pbrobinson@gmail.com> escreveu ----
> > >
> > > On Mon, Sep 20, 2021 at 4:40 PM Felipe Diefenbach
> > > <mailto:felipe@conexaoinfraestrutura.inf.br> wrote:
> > > >
> > > > I have recently migrate from OSMC (debian like SO) to fedora 34 in the rasberry pi 2 (armhf), but when I try to use kodi from rpm fusion a get this error.
> > >
> > > You don't mention which image you're using as your base.
> > >
> > > You probably need to increase the CMA allocation on the kernel command line.
> > >
> > > Running "dmesg | grep -i CMA" will likely give you the information you need.
> > >
> > > Also note the rpi media offload stuff isn't yet upstream so won't work
> > > to do HW accelerated video decode.
> > >
> > > Peter
> > >
> > > > [ 305.423847] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > > > [ 305.431015] vc4-drm soc:gpu: [drm] V3D: 27556kb BOs (10)
> > > > [ 305.438839] vc4-drm soc:gpu: [drm] V3D shader: 24kb BOs (6)
> > > > [ 305.446602] vc4-drm soc:gpu: [drm] dumb: 4116kb BOs (5)
> > > > [ 305.454337] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1)
> > > > [ 305.462075] vc4-drm soc:gpu: [drm] total purged BO: 260kb BOs (2)
> > > > [ 305.494522] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > > > [ 305.501868] vc4-drm soc:gpu: [drm] V3D: 27556kb BOs (10)
> > > > [ 305.509713] vc4-drm soc:gpu: [drm] V3D shader: 24kb BOs (6)
> > > > [ 305.517498] vc4-drm soc:gpu: [drm] dumb: 4116kb BOs (5)
> > > > [ 305.525284] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1)
> > > > [ 305.533149] vc4-drm soc:gpu: [drm] total purged BO: 260kb BOs (2)
> > > > [ 305.578081] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > > > [ 305.585266] vc4-drm soc:gpu: [drm] V3D: 27568kb BOs (13)
> > > > [ 305.593099] vc4-drm soc:gpu: [drm] V3D shader: 24kb BOs (6)
> > > > [ 305.600850] vc4-drm soc:gpu: [drm] dumb: 4116kb BOs (5)
> > > > [ 305.608583] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1)
> > > > [ 305.616587] vc4-drm soc:gpu: [drm] total purged BO: 264kb BOs (3)
> > > > [ 305.646201] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> > > > [ 305.653393] vc4-drm soc:gpu: [drm] V3D: 27564kb BOs (12)
> > > > [ 305.661389] vc4-drm soc:gpu: [drm] V3D shader: 24kb BOs (6)
> > > > [ 305.669165] vc4-drm soc:gpu: [drm] dumb: 4116kb BOs (5)
> > > > [ 305.677026] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1)
> > > > [ 305.684835] vc4-drm soc:gpu: [drm] total purged BO: 264kb BOs (3)
> > > >
> > > >
> > > > I tryed getting some information on this issue from Google but stuck in nothing very usefull.
> > > > So, could someone help me ?
> > > >
> > > > Architecture: armv7l
> > > > Byte Order: Little Endian
> > > > CPU(s): 4
> > > > On-line CPU(s) list: 0-3
> > > > Thread(s) per core: 1
> > > > Core(s) per socket: 4
> > > > Socket(s): 1
> > > > Vendor ID: ARM
> > > > Model: 5
> > > > Model name: Cortex-A7
> > > > Stepping: r0p5
> > > > CPU max MHz: 900.0000
> > > > CPU min MHz: 600.0000
> > > > BogoMIPS: 38.40
> > > > Flags: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
> > > >
> > > > [root@krisiun ~]# cat /proc/meminfo
> > > > MemTotal: 751516 kB
> > > > MemFree: 169628 kB
> > > > MemAvailable: 624916 kB
> > > > Buffers: 19580 kB
> > > > Cached: 430532 kB
> > > > SwapCached: 32 kB
> > > > Active: 126604 kB
> > > > Inactive: 382212 kB
> > > > Active(anon): 860 kB
> > > > Inactive(anon): 58644 kB
> > > > Active(file): 125744 kB
> > > > Inactive(file): 323568 kB
> > > > Unevictable: 0 kB
> > > > Mlocked: 0 kB
> > > > HighTotal: 0 kB
> > > > HighFree: 0 kB
> > > > LowTotal: 751516 kB
> > > > LowFree: 169628 kB
> > > > SwapTotal: 750588 kB
> > > > SwapFree: 749820 kB
> > > > Dirty: 20 kB
> > > > Writeback: 0 kB
> > > > AnonPages: 58672 kB
> > > > Mapped: 96696 kB
> > > > Shmem: 800 kB
> > > > KReclaimable: 20184 kB
> > > > Slab: 46528 kB
> > > > SReclaimable: 20184 kB
> > > > SUnreclaim: 26344 kB
> > > > KernelStack: 1384 kB
> > > > PageTables: 3320 kB
> > > > NFS_Unstable: 0 kB
> > > > Bounce: 0 kB
> > > > WritebackTmp: 0 kB
> > > > CommitLimit: 1126344 kB
> > > > Committed_AS: 372256 kB
> > > > VmallocTotal: 245760 kB
> > > > VmallocUsed: 9908 kB
> > > > VmallocChunk: 0 kB
> > > > Percpu: 1040 kB
> > > > CmaTotal: 65536 kB
> > > > CmaFree: 57984 kB
> > > >
> > > >
> > > > _______________________________________________
> > > > arm mailing list -- mailto:arm@lists.fedoraproject.org
> > > > To unsubscribe send an email to mailto: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 on the list, report it: https://pagure.io/fedora-infrastructure
> > >
> > >
> > >
> >
> >
> >
> >
> >
> > _______________________________________________
> > arm mailing list -- mailto:arm@lists.fedoraproject.org
> > To unsubscribe send an email to mailto: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 on the list, report it: https://pagure.io/fedora-infrastructure
>
>
>
2 years, 7 months