(Sorry- resending this email because I accidentally hit "reply" instead of reply all. This is the first time I'm using a mailing list.)
> On Feb 20, 2020, at 1:00 AM, Till Hofmann <thofmann(a)fedoraproject.org> wrote:
> But I don't understand yet what you're intending to do: wlroots is built
> for both aarch64 and armv7hl, so what exactly is missing?
Oh, I meant to update phosh and phoc to be compatible with the current version of wlroots in the repository. The current version of phoc requires wlroots 0.7, which is not packaged for arm64.
What about including the device in arm-image-installer?
since GCC 10 introduction to Fedora, mozjs68 package started to fail
to compile on armv7.
Apparently, some data structures changed their size:
> /builddir/build/BUILD/firefox-68.5.0/js/src/vm/Shape.h:807:58: error:
> static assertion failed: Things inheriting from gc::Cell must have a size
> that's a multiple of gc::CellAlignBytes
> /builddir/build/BUILD/firefox-68.5.0/js/src/vm/JSScript.h:3408:59: error:
> static assertion failed: Size of LazyScript must be an integral multiple of
> 3408 | static_assert(sizeof(LazyScript) % js::gc::CellAlignBytes == 0,
Nuking all those static_assert checks  resulted in unusable binary, so
that's unfortunately not a way forward. Bug has been reported to mozilla
The last successful build was made in GCC 9 side tag.
I am currently busy with other more pressing issues, so I'll try to add
more meaningful information to this thread later, if needed.
However, if anybody could take a look at it, I'll be grateful and send tons
of virtual cookies!
Thanks a lot
Hi! I got Fedora working on PinePhone the other day, and it works surprisingly well, even though it's just desktop GNOME.
It's a 5.6 kernel with...
... this device tree: https://megous.com/git/linux/tree/arch/arm64/boot/dts/allwinner/sun50i-a6... (branch: pp-5.6)
... and this u-boot: https://megous.com/git/u-boot/ (branch: opi-v2020.01)
... and some modifications to make bluetooth, sound, cameras, etc. work
How would I go about putting this into Fedora so people could (for example) get Fedora on their PinePhones with arm-image-installer?
Also slightly offtopic, but the version of phoc (needed to run phosh, which is Librem's mobile UI) in the repositories depends on libwlroots 0.7, which is not packaged for ARM and doesn't compile with the GCC 10 (wow that's a high version) in rawhide. Can I submit PRs on https://src.fedoraproject.org/? It doesn't look like people usually do that...
I have a fair number of Raspberry Pi V3 B/B+ and Raspberry Pi V2 B
systems running Fedora 31 (and a V4 I would like to get on Fedora -
still waiting). I have Fedora 31 aarch64 installed on most of the V3
and armv7l/armhfp on the V2 systems. Running dnf updating today,
updated to the 5.4.19 kernel and the update of the aarch64 images
seemed to hang while running the kernel-core script for over an
hour. Looking from another terminal and running top (running dnf
upgrade remotely over ssh), looks like grubby is hung burning CPU time
and eating memory (and I have lots of cache). Couple machines
eventually crashed, and I killed grubby on a couple of others, and the
dnf eventually ran to completion on the later 2. In all cases (5 -
aarch64 systems) I was left with totally unbootable systems. The ones
with screens go straight to the U-Boot prompt or trying to reboot over
and over again looking for storage and then looking at eth0 and then
rebooting and never show the kernel selection prompt. The few
armv7l/armhfp systems haven't seem to have gotten that the 5.4.19
upgrade yet. I've still got two booted and running aarch64 systems
running (haven't rebooted) and I'm going to try and roll that update
Any thoughts to were to go from here? Not sure what to report this
under in Bugzilla.
Michael H. Warfield (AI4NB) | (o) +1 706 850-8773 | mhw(a)WittsEnd.com
/\/\|=mhw=|\/\/ | (c) +1 678 463-0932 | http://www.wittsend.com/mhw/
ARIN whois: MHW9-ARIN | An optimist believes we live in the best of all
PGP Key: 0xC0EB9675674627FF | possible worlds. A pessimist is sure of it!
I have installed fedora 31 on my Odroid XU4. However I have noticed a
problem with the uboot image in uboot-images-armv7 (2019.10). I have
used the uboot image /usr/share/uboot/odroid-xu3/u-boot.bin and I have
found it has the fdtfile environment variable set to
"exynos5422-odroid.dtb". In checking the boot partition of the fedora
system the dtb directory does not contain exynos5422-odroid.dtb.
My work around is to create a link from exynos5422-odroid.dtb to
exynos5422-odroidxu4.dtb in the dtb directory. Another is to edit the
fdtfile environment at the uboot prompt when booting the XU4.
Neither of the above are really satisfactory as the link needs creating
again when there is a kernel update. editing the variable at the boot
prompt is even worse as it needs to be done for every boot.
Is there a better way I can fix this or does the uboot-images-armv7
package need fixing?
(sorry if you get this twice -- I wasn't subscribed with this address
so I think my message was held for moderation or just blocked)
I've got an x86_64 F29 desktop and I'm trying to run Fedora-Minimal-31
ARM on QEMU. I was following the instructions in the various F25/26/27
"run on QEMU" pages and I've been able to get the system to boot under
virt-manager, but once it gets to "Reached Basic System" in the
virt-manager console, it stops and never reaches the first-boot setting.
I never get asked to set a password. I never get a login screen.
I just found a reference to an older web page about QEMU and ARM:
https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu but this page
was last touched in 2016.
Any assistance would be grand.
Derek Atkins 617-623-3745
Computer and Internet Security Consultant