arm July 2021

arm@lists.fedoraproject.org

14 participants
14 discussions

f33 support for odroid N2+ (Amlogic S922X)
by Adrian Sevcenco 10 Aug '21

10 Aug '21

Hi! While theoretically should be possible, i would like to hear some confirmation that f33 can work on odroid N2 ... Moreover, if it can work, all i have to do is to write the image on eMMC, isn't it? Disclaimer: it's my first time playing in arm world, so many things are strange to me.. Thanks a lot!! Adrian

2 2

RPi4 Workstation edition - Dsplay goes to sleep -logged or unlogged- and won't wake up!
by Benjamin M 01 Aug '21

01 Aug '21

Thank you for the great work on an unofficially supported platform -yet. Before filling a bug, I was wondering if you were aware of this issue/workaround. A quick search on BZ yield nothing... Luckily, SSH access wireless or not still possible. FWIW, a few weeks ago, I was able to blindly switch to a virtual console, login and initiate reboot/shutdown, but that doesn't seem to do the trick anymore. Regards, BM

4 6

pinebook strange behavior
by Alessio 31 Jul '21

31 Jul '21

I installed the 5.13.1-300 kernel. Booting this kernel, the display (after the GRUB menu) becomes black. Serial connection works. I booted again the 5.13 kernel, but no way, the display is black. So I selected the previous 5.12.14-300 kernel, and the display continues to be black. Mh? Uninstalling the 5.13.1 kernel and booting again with the 5.12.14 one, then the display starts to work again. Do you have any idea why if the 5.13 rpm is installed the display doesn't work even booting a previous kernel? (Or I'm missing something?) Ciao, A.

7 11

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠fedoraproject.org 25 Jul '21

25 Jul '21

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2021-07-27 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.libera.chat The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://calendar.fedoraproject.org//meeting/9910/

1 0

Fedora ARM & AArch64 Status Meeting Minutes - 2021-07-20
by Paul Whalen 20 Jul '21

20 Jul '21

======================================================== #fedora-meeting-2: Fedora ARM and AArch64 Status Meeting ======================================================== Meeting started by pwhalen at 15:00:18 UTC. The full logs are available athttps://meetbot.fedoraproject.org/fedora-meeting-2/2021-07-20/fedora_arm_… . Meeting summary --------------- * roll call (pwhalen, 15:00:19) * 1) ==== Userspace Status ==== (pwhalen, 15:02:39) * No reported issues. (pwhalen, 15:07:15) * 2) ==== Kernel Status ==== (pwhalen, 15:07:21) * kernel-5.14.0-0.rc2.23.fc35 (pwhalen, 15:09:36) * LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=1781939 (pwhalen, 15:09:36) * Please test and report any issues to the list or #fedora-arm. (pwhalen, 15:10:52) * 3) ==== Bootloader Status ==== (pwhalen, 15:12:37) * uboot-tools-2021.07-1.fc35 (pwhalen, 15:12:46) * LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=1778078 (pwhalen, 15:12:46) * 4) ==== Fedora 35 ==== (pwhalen, 15:19:54) * Fedora 35 mass rebuild scheduled to start tomorrow (July 21). (pwhalen, 15:20:20) * A glibc test hangs upon pthread cancellation when glibc is compiled with annobin turned on (pwhalen, 15:21:01) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1951492 (pwhalen, 15:21:01) * Latest nominated compose (pwhalen, 15:25:13) * LINK: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test (pwhalen, 15:25:13) * Rawhide arm/aarch64 disk images fail to boot on Raspberry Pi SBCs (pwhalen, 15:25:39) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1975375 (pwhalen, 15:25:49) * 5) == Open Floor == (pwhalen, 15:28:38) Meeting ended at 15:32:31 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * pwhalen (44) * pbrobinson (11) * zodbot (7) * rbutler1728 (1) * coremodule (1) * jlinton (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠fedoraproject.org 18 Jul '21

18 Jul '21

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2021-07-20 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.libera.chat The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://calendar.fedoraproject.org//meeting/9910/

1 0

Bug 1951492 - A glibc test hangs upon pthread cancellation when glibc is compiled with annobin turned on
by Ben Cotton 14 Jul '21

14 Jul '21

Hi ARM folks, Peter said BZ 1951492[1] is a blocker for the mass rebuild. Since that was two months ago, I wanted to check and see if it's still an issue or if there's been a workaround or fix. Matthew has been following up on the maintainer side. The mass rebuild is scheduled to begin in a week[2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1951492 [2] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

u-boot blues
by Fred van Zwieten 13 Jul '21

13 Jul '21

Hi, So Fedora 34 minimal aarch64 boots and runs pretty good on my rpi4 4GB (great work!). I have a powered USB 3 hub attached to it, and on that an arduino mega with rflink [1]. When I attach this after booting, it is recognised correctly, but when connected while booting, it runs into a boot-loop: [image: image.png] Others within the domotica community also have this issue and it seems to be related to the use of u-boot [2]. This is also why rapsbian based distros like dietpi boot without issue as they do not use u-boot afaik. I am not familiar with u-boot at all. Is there a way to exclude this device from the boot device discovery somehow (as I suspect this is where it goes wrong). [1] https://www.nodo-shop.nl/nl/rflink-gateway/168-rflink-868-arduino-antenne-u… [2] https://github.com/home-assistant/operating-system/issues/1011 Thanks! - Fred

3 2

Re: u-boot blues
by Fred van Zwieten 13 Jul '21

13 Jul '21

Hi Brad, Works like a charm! Also boots from an usb thumb drive in the powered usb hub. Next stop: migrate :-) thx again - Fred On Tue, Jul 13, 2021 at 3:16 PM Fred van Zwieten <fvanzwie(a)redhat.com> wrote: > Hi Brad, > > Thanks! Will try this and report back > > - Fred > > Op di 13 jul. 2021 om 15:05 schreef Brad Smith <bradley.g.smith(a)gmail.com> > >> Hi Fred - >> >> This thread ( >> https://www.raspberrypi.org/forums/viewtopic.php?f=51&t=292630 ) >> outlines an approach using UEFI that works well for me. I have not tried >> newer versions of the UEFI boot code yet as this has been stable on 4 RPi >> 4s (8 gb). This was done with F33. The update to F34 was smooth and without >> problem. >> >> Brad >> >> On Tue, Jul 13, 2021 at 5:42 AM Fred van Zwieten <fvanzwie(a)redhat.com> >> wrote: >> >>> Hi Brad, >>> >>> Definitely interested! >>> >>> Thanks! >>> >>> - Fred >>> >>> On Tue, Jul 13, 2021 at 2:36 PM Brad Smith <bradley.g.smith(a)gmail.com> >>> wrote: >>> >>>> Good morning >>>> >>>> Another option is to bypass u-boot entirely. I can provide a link if >>>> interested. Not at the computer with the bookmark otherwise i would just >>>> send. >>>> >>>> Brad >>>> >>>> On Tue, Jul 13, 2021, 04:43 Fred van Zwieten <fvanzwie(a)redhat.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> So Fedora 34 minimal aarch64 boots and runs pretty good on my rpi4 4GB >>>>> (great work!). >>>>> >>>>> I have a powered USB 3 hub attached to it, and on that an arduino mega >>>>> with rflink [1]. When I attach this after booting, it is recognised >>>>> correctly, but when connected while booting, it runs into a boot-loop: >>>>> >>>>> [image: image.png] >>>>> >>>>> Others within the domotica community also have this issue and it seems >>>>> to be related to the use of u-boot [2]. This is also why rapsbian based >>>>> distros like dietpi boot without issue as they do not use u-boot afaik. >>>>> >>>>> I am not familiar with u-boot at all. Is there a way to exclude this >>>>> device from the boot device discovery somehow (as I suspect this is where >>>>> it goes wrong). >>>>> >>>>> [1] >>>>> https://www.nodo-shop.nl/nl/rflink-gateway/168-rflink-868-arduino-antenne-u… >>>>> [2] https://github.com/home-assistant/operating-system/issues/1011 >>>>> >>>>> Thanks! >>>>> >>>>> - Fred >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>

1 0

Re: Kernel update has lost XMOS USB hardware
by Peter Robinson 12 Jul '21

12 Jul '21

Please leave the list on replies. On Fri, Jul 9, 2021 at 1:30 PM David W. Legg <dwlegg(a)gmail.com> wrote: > > On 09/07/2021 12:38, Peter Robinson wrote: > > Adding arm@ list back in. > > > > On Fri, Jul 9, 2021 at 12:37 PM Peter Robinson<pbrobinson(a)gmail.com> wrote: > >> On Fri, Jul 9, 2021 at 12:30 PM David W. Legg<dwlegg(a)gmail.com> wrote: > >>> On 09/07/2021 11:24, Peter Robinson wrote: > >>> > >>>> On Fri, Jul 9, 2021 at 10:10 AM David W. Legg<dwlegg(a)gmail.com> wrote: > >>>>> I tried updating my Fedora 34 kernel from- > >>>>> > >>>>> 5.11.17-300 > >>>>> > >>>>> to > >>>>> > >>>>> 5.12.14-300 > >>>>> > >>>>> and it no longer recognises my XMOS USB device: > >>>>> > >>>>> $ cat /proc/asound/cards > >>>>> > >>>>> 0 [ALSA ]: bcm2835_alsa - bcm2835 ALSA > >>>>> bcm2835 ALSA > >>>>> 1 [vc4hdmi0 ]: vc4-hdmi - vc4-hdmi-0 > >>>>> vc4-hdmi-0 > >>>>> 2 [vc4hdmi1 ]: vc4-hdmi - vc4-hdmi-1 > >>>>> vc4-hdmi-1 > >>>>> 4 [H20 ]: USB-Audio - HU300 HiFi 2.0 > >>>>> Yunyue Audio HU300 HiFi 2.0 at usb-0000:01:00.0-1.3, high speed > >>>>> > >>>>> So, device number 4 is missing with the 5.12.14-300 kernel. > >>>>> > >>>>> Given that the rpi4 is not yet supported, whom should I tell about this apparent bug, please? > >>>> What's a "XMOS USB hardware"? I doubt being USB it's specific to the > >>>> RPi4, does it work on another devices such as an x86 device? Can you > >>>> give more information about the device, what driver does it use when > >>>> it worked, what's the output of the lsusb line for it etc. > >>> Thanks, for replying, Peter. > >>> > >>> It is the sound card #4 mentioned above, labelled H20. It is a USB to > >>> I2S audio interface to an ES9038 DAC. > >>> > >>> I can try it with an x86_64 PC when a new card arrives at some point in > >>> the future. > >> I don't know what you mean by that. > >> > >>> lsusb says it is this:- > >>> > >>> Bus 001 Device 003: ID 20b1:0008 XMOS Ltd HU300 HiFi 2.0 > >>> > >>> > >>> It uses the snd_usb_audio driver, according to lsmod. > >>> > >>> Should I just report it on Bugzilla, saying that it is > >>> hardware-non-specific? > >> Do other USB devices work in the RPi? > >> > >> Was this an upgrade from and older Fedora release at some point in the > >> past? If so does running rpi-uboot-update and rebooting fix it? > > It was a fresh F34 installation some months ago, but with minimal updates. > > Last week updated just the kernel and my usb audio card was not recognised. As asked above do other USB devices still work? > Yesterday, I updated everything, with the same results. Did you run rpi-uboot-update?

2 4

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠fedoraproject.org 11 Jul '21

11 Jul '21

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2021-07-13 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.libera.chat The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://calendar.fedoraproject.org//meeting/9910/

1 0

Re: Kernel update has lost XMOS USB hardware
by Peter Robinson 09 Jul '21

09 Jul '21

Adding arm@ list back in. On Fri, Jul 9, 2021 at 12:37 PM Peter Robinson <pbrobinson(a)gmail.com> wrote: > > On Fri, Jul 9, 2021 at 12:30 PM David W. Legg <dwlegg(a)gmail.com> wrote: > > > > On 09/07/2021 11:24, Peter Robinson wrote: > > > > > On Fri, Jul 9, 2021 at 10:10 AM David W. Legg<dwlegg(a)gmail.com> wrote: > > >> I tried updating my Fedora 34 kernel from- > > >> > > >> 5.11.17-300 > > >> > > >> to > > >> > > >> 5.12.14-300 > > >> > > >> and it no longer recognises my XMOS USB device: > > >> > > >> $ cat /proc/asound/cards > > >> > > >> 0 [ALSA ]: bcm2835_alsa - bcm2835 ALSA > > >> bcm2835 ALSA > > >> 1 [vc4hdmi0 ]: vc4-hdmi - vc4-hdmi-0 > > >> vc4-hdmi-0 > > >> 2 [vc4hdmi1 ]: vc4-hdmi - vc4-hdmi-1 > > >> vc4-hdmi-1 > > >> 4 [H20 ]: USB-Audio - HU300 HiFi 2.0 > > >> Yunyue Audio HU300 HiFi 2.0 at usb-0000:01:00.0-1.3, high speed > > >> > > >> So, device number 4 is missing with the 5.12.14-300 kernel. > > >> > > >> Given that the rpi4 is not yet supported, whom should I tell about this apparent bug, please? > > > What's a "XMOS USB hardware"? I doubt being USB it's specific to the > > > RPi4, does it work on another devices such as an x86 device? Can you > > > give more information about the device, what driver does it use when > > > it worked, what's the output of the lsusb line for it etc. > > > > Thanks, for replying, Peter. > > > > It is the sound card #4 mentioned above, labelled H20. It is a USB to > > I2S audio interface to an ES9038 DAC. > > > > I can try it with an x86_64 PC when a new card arrives at some point in > > the future. > > I don't know what you mean by that. > > > lsusb says it is this:- > > > > Bus 001 Device 003: ID 20b1:0008 XMOS Ltd HU300 HiFi 2.0 > > > > > > It uses the snd_usb_audio driver, according to lsmod. > > > > Should I just report it on Bugzilla, saying that it is > > hardware-non-specific? > > Do other USB devices work in the RPi? > > Was this an upgrade from and older Fedora release at some point in the > past? If so does running rpi-uboot-update and rebooting fix it?

1 0

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠fedoraproject.org 09 Jul '21

09 Jul '21

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2021-07-06 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.libera.chat The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://calendar.fedoraproject.org//meeting/9910/

3 2

Issue with Mono on armv7hl segfaulting
by Timotheus Pokorra 08 Jul '21

08 Jul '21

Hello, since August 2020 we have an issue with Mono Segfault on armv7hl. This is one bug report (keepass): https://bugzilla.redhat.com/show_bug.cgi?id=1878365 It seems to segfault on processing resource files with resgen.exe Same issue here (pinta): https://bugzilla.redhat.com/show_bug.cgi?id=1869214 and for nunit: https://bugzilla.redhat.com/show_bug.cgi?id=1923663 The easy solution was to disable builds for armv7hl, with excludearch. We have disabled it for Pinta and Keepass and nunit2. That causes now a number of packages not to build on armv7hl, because they require nunit2 to build. The question is: how can we get this fixed? Or should we disable Mono for armv7hl overall, in https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros.… Thanks for any suggestions, Timotheus

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm July 2021