arm January 2022

arm@lists.fedoraproject.org

14 participants
19 discussions

BeagleBone Black cannot boot with Fedora 34/35
by Zamir SUN 04 Apr '23

04 Apr '23

Hi, Recently I reflashed my BeagleBone Black. However, I find it simply cannot go beyond uboot with Fedora 34 or Fedora 35. Images I tried: Fedora-Minimal-35-20211020.n.0.armhfp.raw.xz Fedora-Minimal-34-1.2.armhfp.raw.xz If I press the button when plug the power cable, it will loop forever like the following U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +0000) Trying to boot from MMC1 U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +0000) Trying to boot from MMC1 U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +0000) Trying to boot from MMC1 CCCCCCCC U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +0000) Trying to boot from MMC1 If I don't press the button it will boot directly to the system in emmc. I've tried different tf cards and concluded it's not the card issue. The latest image that works for me on BBB is Fedora-Minimal-armhfp-33-1.2-sda.raw.xz It's interesting that the image has a different name schema that F34/F35 ones(the sda in filename). I roughly remember I also tried F33 without 'sda' - Fedora-Minimal-33-1.3.armhfp.raw.xz and IIRC this also cannot boot. So is there any different for images with or without -sda ? Can anyone offer some suggestions how I can test or boot F35 on BBB? Thanks in advance! -- Zamir SUN GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ 想了解更多中文资讯，访问 https://zh.fedoracommunity.org/

2 3

Fedora on Pinephone Pro & path to upstreaming
by Be 13 Feb '22

13 Feb '22

Hello, I've been using Fedora on my Pinephone for like 9 months or so and my Pinephone Pro Explorer Edition just arrived the other day. The original Pinephone's boot order had the microSD card before the eMMC which made it really easy to try different OSes. By contrast, on the Pinephone Pro, the boot order in hardware is: 1. SPI flash 2. eMMC 3. microSD From the factory, there is a u-boot image on the eMMC drive which will boot an OS from the SD card before the eMMC and there is nothing on the SPI flash. This is problematic because it's really easy to accidentally get the device into an unbootable state when installing an OS to the eMMC drive if the factory uboot build is erased. There is a way to temporarily disable the eMMC drive in hardware to make it boot from SD, but that's not obvious or convenient. So, currently, the Pine wiki (https://wiki.pine64.org/wiki/PinePhone_Pro) advises against replacing the stock Manjaro OS on the eMMC drive and few distros are providing prebuilt images. People working on different distros have been coordinating how to deal with this. The plan is to use a fairly new project, Tow Boot, and flash it to the SPI flash: https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html Putting the platform firmware on the SPI flash chip separate from the eMMC drive will make the process of installing OSes easier and more foolproof. Support for the Pinephone Pro in Tow Boot is almost ready with support for the Pinephone Pro's SPI flash just added today, albeit it needs a little polishing. Tow Boot on the SPI flash will make the process of installing an OS similar to x86; distros just need to create a UEFI bootable system and do not need to worry about shipping platform firmware. Tow Boot also obviates the need for JumpDrive. Simply pressing the volume up button on boot will expose the eMMC drive as a USB mass storage device, refer to https://github.com/Tow-Boot/Tow-Boot/pull/67 for details about the UX design. Hopefully future Pinephon e Pro batches will ship with Tow Boot on the SPI flash from the factory, but for now users will need to install it by booting a Linux system from an SD card. A Tow Boot installer image like that has already been made for the Pinebook Pro, so I think one for the Pinephone Pro will be ready to test soon. This is great new for Fedora because I think it means we can use the normal Fedora tools for building ARM images to create UEFI bootable images without needing the scripts in https://github.com/nikhiljha/pp-fedora-sdsetup that were made for the Pinephone. Using Fedora tooling to build the Pinephone Pro images opens up the path to smartphone support in upstream Fedora. I've been digging around in scattered documentation and talking to Conan Kudo on Matrix and IIUC, the way the upstream images are built is that Punji calls `koji image-build` which calls livemedia-creator. Please correct me if I've misunderstood this. I've tried to figure out how to build aarch64 images locally on my x86-64 laptop and made a bit of progress using Mock with livemedia-creator as documented at https://weldr.io/lorax/livemedia-creator.html#using-mock-and-no-virt-to-cre… Thanks to the efforts getting Fedora on the original Pinephone, good progress has been made getting Plasma Mobile and Phosh packaged in upstream Fedora. There are still a handful of packages in the https://copr.fedorainfracloud.org/coprs/njha/mobile/ COPR repository that aren't upstream. I think enough has been upstreamed at this point that we can start working on base Plasma Mobile and Phosh Kickstart files to use with livemedia-creator that could eventually make it upstream. For now, we'll still need device-specific Kickstarts for the downstream kernel packages which could %include the base Plasma Mobile or Phosh Kickstart. Fortunately for the Pinephone Pro, distros are coordinating to avoid the fragmentation that has happened with kernels for the original Pinephone and development effort is being coordinated on the https://gitlab.com/pine64-org/linux/-/tree/pine64-kernel-ppp-5.16.y/ repository. One important feature that we haven't gotten working on the Pinephone is full disk encryption. One issue blocking this is that Plymouth (the software in the initrd that asks for the LUKS password) does not have an on screen keyboard: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/144 Also, the Anaconda GUI wasn't designed for small touchscreen devices without a keyboard. Fortunately this could change with the recently announced rewrite of the Anaconda GUI: https://discussion.fedoraproject.org/t/anaconda-is-getting-a-new-suit/35916… Does this seem like a reasonable plan? Is there anything I've overlooked?

6 18

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠fedoraproject.org 30 Jan '22

30 Jan '22

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2022-02-01 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: gpioset on rpi4 running F35 kernel 5.15.15-200.fc35.aarch64
by Stefan Wahren 24 Jan '22

24 Jan '22

Am 22.01.22 um 12:42 schrieb David W. Legg: > Ah, do you mean the red power LED that stays on after boot? Yes > > If so, will an updated F35 kernel fix it, or should I go back to F34? I'm just a kernel developer and not involved into Fedora. So cannot answer this question. > > :D > > On 22/01/2022 11:23, Stefan Wahren wrote: >> is the issue about the LEDs already solved? If not, this is the same.

3 3

arm-image-installer --supported – incomplete list or intentional?
by Peter Boy 24 Jan '22

24 Jan '22

With Fedora 35 as well as current rawhide the list of supported devices displayed by arm-image-installer is a subset of boards supported in /usr/share/arm-image-installder/board.d and /usr/share/uboot. That' s a bit irritating, at least for new users. Is this intentional due to a special meaning of „supported“ or rather lack of updating? Peter

2 2

arm-image-install doesn't work for me on F35 - bug?
by Peter Boy 23 Jan '22

23 Jan '22

I just tried today to install Arm Rawhide candidate on my Rock Pi 4 and and was only successful after modifying arm-image-installer. Originally i got: > - - - - - - < [root@zbox ~]# arm-image-installer --image=Fedora-Server-Rawhide-20220118.n.0.aarch64.raw.xz --target=rock-pi-4-rk3399 --media=/dev/sdb ===================================================== = Selected Image: = Fedora-Server-Rawhide-20220118.n.0.aarch64.raw.xz = Selected Media : /dev/sdb = U-Boot Target : rock-pi-4-rk3399 ===================================================== ***************************************************** ***************************************************** ******** WARNING! ALL DATA WILL BE DESTROYED ******** ***************************************************** ***************************************************** Type 'YES' to proceed, anything else to exit now = Proceed? = Proceed? YES = Writing: = Fedora-Server-Rawhide-20220118.n.0.aarch64.raw.xz = To: /dev/sdb .... 7485333504 Bytes (7,5 GB, 7,0 GiB) kopiert, 178 s, 42,1 MB/s 0+835568 Datensätze ein 0+835568 Datensätze aus 7516192768 Bytes (7,5 GB, 7,0 GiB) kopiert, 178,864 s, 42,0 MB/s = Writing image complete! (no output for a very long time) = No U-Boot files found for rock-pi-4-rk3399. > - - - - - - < The reason was an unsuitable value in the variable prefix. I modified line 532 and could successfully copy the image file and boot the rock pi > - - - - - - < if [ "$IOT_IMAGE" = "1" ]; then # dd doesnt support wildcards, echo to expand PREFIX=$(echo $OSTREE_PREFIX) elif [ "$BTRFS" = "1" ]; then PREFIX="/tmp/root/root/" else # PREFIX=/tmp/root # <=== PREFIX="“ # <=== fi # determine uboot and write to disk if [ "$TARGET" != "" ]; then echo "=== DEBUG Target: $TARGET " echo "=== DEBUG PATH: ${PREFIX}/usr/share/uboot/${TARGET} " echo "=== DEBUG BOARDDIR: ${BOARDDIR}/${TARGET} " echo if echo "$TARGET" | grep -q 'rpi[234]' || [ "$TARGET" = "olpc_xo175" ]; then . "${BOARDDIR}/${TARGET}" elif [ -d "${PREFIX}/usr/share/uboot/${TARGET}" ]; then . "${BOARDDIR}/${TARGET}" else echo "= No U-Boot files found for $TARGET." fi else echo "= No U-boot will be written." TARGET="board" fi > - - - - - - < The F35 system I used to copy the image file is fully updated as of today. Best Peter

1 0

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠fedoraproject.org 23 Jan '22

23 Jan '22

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2022-01-25 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

gpioset on rpi4 running F35 kernel 5.15.15-200.fc35.aarch64
by David W. Legg 22 Jan '22

22 Jan '22

2 1

Re: Kernel update -> 5.15.13-200.fc35.aarch64
by David W. Legg 18 Jan '22

18 Jan '22

3 3

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠fedoraproject.org 16 Jan '22

16 Jan '22

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2022-01-18 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm January 2022