[fedora-arm] Re: F38 on RPi4-8G

[Jeremy Linton]

Hi,

On 4/25/23 16:40, Randy DuCharme wrote:
Am I the only one having difficulties with this?  It's worse than half 
as fast as f37 was, NTP/Chrony refuses to work. I could go on. 
Afraid I'm going to have to ditch this.  Kernel's been building for 7 
hours now.  Clocking, over-clocking, governors, schedulers make no 
difference.  Btrace, strace points to nothing. CPU load through the roof 
though yet I don't see anything especially noteworthy.


Thoughts?

F38 is behaving similarly to f37 on my rpi's so...

You might try installing the kernel tools, and flipping on the 
debuginfos and running something like `perf top 
--vmlinux=/usr/lib/debug/lib/modules/`uname -r`/vmlinux` if you see its 
spending a lot of time in the kernel.


What process is taking all the cpu time? You might turn on the 
mem/cpu/io pressure stall fields in htop and see what is being reported 
as the major bottleneck.. but i'm guessing your on a SD or a USB disk?


Its a big weakness of that platform that it doesn't have a reasonable 
disk interface (aka sata/nvme/etc). So one of the failure modes I've 
seen with bad SD/USB disks is that they get incredibly slow (think 
KB/sec) before they die. The stress of downloading a couple GB, delta 
RPM'ing it, installing, etc, could have pushed your disk closer to 
failure. I've killed a fair number of disks before I switched to 
USB->sata enclosures with proper SATA SSDs*, and one of the first 
indications is the whole machine starts just acting slow. 15 second 
login times from the shell, seconds to start things like htop, etc.


I guess it could also be thermal throttling if your building kernels as 
you report below. I've got a fairly beefy heatsink on mine in order to 
keep the temps below the throttling limits.



As far as time does something like `systemctrl restart 
systemd-timesyncd` fix your time issues?



* (I've recently started using samsung T7's which are blisteringly fast 
on proper USB3 controllers, which sadly doesn't include the rpi4 though)







___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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

[fedora-arm] Re: Wiki claims RPi 4 is not supported

[Jeremy Linton]

Hi,

On 9/19/21 8:53 AM, Barry wrote:




On 19 Sep 2021, at 11:17, Stefan Wahren  wrote:

Hi,


Am 18.09.21 um 21:58 schrieb Barry Scott:
On this page it states that the RPi4 is not supported.

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


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.

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.


That is part of why its still "unsupported", the platform is still a bit 
unstable in many ways. The slow boot is likely the same as this problem:


https://github.com/raspberrypi/firmware/issues/1619

which should really be titled "GET_CLOCK behavior change causing 
problems everywhere". There are various less than ideal workarounds at 
this point, but for most users the best plan is probably to just revert 
to an older firmware that works as expected.


Particularly for this problem, it would be useful if you mentioned the 
uboot version your getting from Fedrora, as AFAIK pbrobinson pushed a 
workaround to uboot that should make it better.











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.


There a lots of messages in this mailing archieve showing that people are
getting Fedora to work on RPi4.

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.


Food to know.

Barry



Barry


___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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 -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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 -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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

[fedora-arm] Re: Difference on booting Raspberry Pi 4B (8GB)

[Jeremy Linton]

On 2/1/21 11:30 AM, Andreas Reschke wrote:

Hi there,

I've received as a gift a Raspberry Pi 4B (8GB). While installing Fedora 
on it I see difference behavior on booting.


a) booting from USB3 
(https://fwmotion.com/blog/operating-systems/2020-09-05-installing-fedora-workstation-onto-pi4/) 


change: replace Fedora 32 with 33

Comment: Fedora boot fast but Bluetooth and Wifi isn't available


What you are seeing is the difference between ACPI and DT. The ACPI 
wifi/etc is being fixed https://github.com/pftf/RPi4/issues/26.


But you can flip the firmware mode from ACPI-DT and that will solve some 
of the problems, but you should probably just wait for the next release 
if your not building it yourself.




b) installing Fedora with arm-image-installer
Comment: Fedora boot slow and Bluetooth and Wifi are available

How can I solve this?

Thanks
Andreas
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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

___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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

[fedora-arm] Re: RPI4 8G with UEFI for Pi: How to enable VC4?

[Jeremy Linton]

Hi,

On 1/15/21 2:29 PM, Peter Robinson wrote:

Sorry for not being clear. Yes, I mean the Tianocore firmware.


So I've added Jeremy to my reply as he's the maintainer of this
firmware but as it's EDK2 and ACPI, as opposed to device tree, I'm not
sure it's intended to work.

As the driver would need ACPI support and the firmware would need the
appropriate ACPI tables to describe the hardware. I'm not sure what
the plans there are for support for the GPU on that firmware is, the
timeline or if there is any plans there.


There are plans but no dates. :) So, no it doesn't work at the moment.

As mentioned putting the dt overlays/etc on the sd card and flipping it 
to DT mode to see if that works is a good place to start if you want to 
try getting it working. Although if your also trying to boot from SD you 
will need to wait until the next firmware release to also use wifi/etc 
because the default DTs don't entirely know how to change the SD/Wifi 
pin routing.


I think the half dozen or so of us fixing stuff on that platform also 
have our hands full with various boot failures at the moment. Once that 
gets cleared up we can start looking at further ACPI functionality 
extensions.


I would suggest opening a bug on the github page, and/or jumping on the 
discord channel.


___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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

[fedora-arm] Re: RPI4 8G with UEFI for Pi: How to enable VC4?

[Jeremy Linton]

Hi,

On 1/15/21 2:29 PM, Peter Robinson wrote:

Sorry for not being clear. Yes, I mean the Tianocore firmware.


So I've added Jeremy to my reply as he's the maintainer of this
firmware but as it's EDK2 and ACPI, as opposed to device tree, I'm not
sure it's intended to work.

As the driver would need ACPI support and the firmware would need the
appropriate ACPI tables to describe the hardware. I'm not sure what
the plans there are for support for the GPU on that firmware is, the
timeline or if there is any plans there.


Plans yes, no dates.

I would suggest that if it works with a mainline overlay it should be 
possible to put that in the overlay's directory and add it to the 
config.txt and change it from ACPI->DT in the firmware. But.. at the 
moment you also should probably make sure your also changing the SD 
config for DT too (it will be in the next release).


So at the moment your sorta going to have to hack it on your own, the 
few of us patching the uefi firmware have our hands full with various 
boot failures that have crept up over the last month too :(


(PXE, USB and SD failures have been burning most of my spare time, did 
you know people were iscsi booting the rpi too? LOL)

___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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

[fedora-arm] Re: Students and engineers interested in contributing to Fedora Linux on Raspberry Pi

[Jeremy Linton]

Hi,

Welcome!

On 1/13/21 3:42 PM, Joel Savitz wrote:

Good afternoon,

A group of computer science undergraduates and I are interested in
contributing to the usability of Fedora Linux on the Raspberry Pi 4.

I was a part of this group as an undergrad and we developed a compatibility
layer for translating RPi.GPIO syntax into calls to libgpiod. It is
currently available on PyPi and under review for inclusion in Fedora:
https://github.com/underground-software/RPi.GPIO2
https://pypi.org/project/RPi.GPIO2/

The maintainer of the (broken) RPi.GPIO fedora package agreed to obsolete
it in favor of our new package, which is a drop in replacement for RPi.GPIO
(hence the 2), however I have not heard from him since September.

Anyway, we are looking for a new project or area of Fedora on the Raspberry
Pi to improve over the upcoming semester. Does anyone have any suggestions?


From my perspective, the main issues with the rpi4 and fedora surround 
low level firmware/driver problems. That is what keeps it from "just 
working" as expected with a standard fedora image.


As such you might want to take a look at:
https://github.com/lategoodbye/rpi-zero/issues/43
which is the running conversation about upstream kernel features that 
need work.


On the firmware side you might look at 
https://github.com/pftf/RPI4/issues which is a mix of bugs and future 
features required to make the platform behave as expected.


There is probably a uboot related list too, but I don't know where it 
is. Peter can probably comment.


Finally besides Trusted Firmware, there is a project that seeks to 
replace the videocore firmware as well 
https://github.com/librerpi/rpi-open-firmware. If that happens it would 
remove another longstanding binary blob used to boot the platform.


There are of course others, but that should provide a few starting places.

Welcome again!
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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

[fedora-arm] Re: RPI4 8G - usb ssd boot Fedora Server with UEFI for Pi

[Jeremy Linton]

Hi,

On 1/3/21 12:46 PM, Zach Villers wrote:

I recently got Fedora 33 Server booting on my RPI 4 - 8G using the RPI4 UEFI 
firmware. The usb3 adapter I used worked fine with Raspbian, but with Fedora 
33, there was an issue. I've worked around this issue and another involving F33 
complaining about the lack of sd card. These are my brief notes, hopefully they 
help someone. If a longer write up or a bug report would be helpful, I'm happy 
to do so. Also looking for feedback if I could have done anything 
better/different.

Hardware:
RPI 4B - 8G model
128G "Inland" brand ssd - OEM Phison - Model 'SATA AAD'
Orico Brand SATA to USB3 external enclosure - model 'ORICO 2139U3'
   - uses JMicron Technology Corp. JMS578 chip - Sata 6Gb/s

UEFI Firmware: https://github.com/pftf/RPi4/releases/tag/v1.21
After Fedora install;
- switched advanced settings in UEFI from 'ahci' to 'devicetree'
- removed 3G ram limit


So, I think you meant you switched from acpi to devicetree. This doesn't 
really buy you much at the moment unless you also change the sd config 
to emmc2. That is because linux doesn't know how to change the 
undocumented SD routing, so the sd card is routed to the PIO arasan, and 
the wifi is routed to the emmc2 controller. Hence the piles of messages 
your seeing below. Of course if you change the emmc2 setting you will be 
stuck with the firmware settings until you upgrade firmware versions.


There are patches to fix this: 
https://edk2.groups.io/g/devel/topic/patch_v4_0_7_rpi4_enable/79453713?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,20,79453713


as well as the ACPI patches for the SD/wifi. So when all this is done, 
the recommended setting is going to be acpi/emmc2/no 3G limit/PCIe conduit.







### Problems

1. Pi treats usb drive as uas device causing extremely slow read/write - ext4 
fs would not mount rw
   '''
   [ 1247.365069] usb 2-1: reset SuperSpeed Gen 1 USB device number 3 
using xhci_hcd
   [ 1247.387663] scsi host0: uas_eh_device_reset_handler success
   [ 1279.648929] sd 0:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 
uas-tag 4 inflight: CMD IN
   [ 1279.648937] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x28 28 00 03 fa 
64 50 00 01 00 00
   [ 1279.649085] sd 0:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 
uas-tag 2 inflight: CMD IN
   [ 1279.649091] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x28 28 00 00 00 
10 00 00 04 00 00
   [ 1279.649553] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 
uas-tag 1 inflight: CMD IN
   [ 1279.649559] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 
0c 00 00 04 00 00
   [ 1286.049165] sd 0:0:0:0: tag#4 uas_eh_abort_handler 0 uas-tag 5 
inflight: CMD
   [ 1286.049173] sd 0:0:0:0: tag#4 CDB: opcode=0x0 00 00 00 00 00 00
   [ 1286.065838] scsi host0: uas_eh_device_reset_handler start
   '''
2. Pi is missing sdhc card ( mostly annoying, could've just turned off kernel 
message echo to console? )
   '''
mmc1: Timeout waiting for hardware cmd interrupt.
mmc1: sdhci: === SDHCI REGISTER DUMP ===
mmc1: sdhci: blah
   '''

### Solutions
1. uas device
- add usb quirk to kernel args in /etc/default/grub
   '''
GRUB_CMDLINE_LINUX="usb-storage.quirks=152d:0578:u"
   '''
 - add quirk to config.txt (is this necessary?)
 - rebuild grub with grub2-mkconfig
 - dracut -f (not sure if I needed to do this?)
2. sdhc card
- block(black)list sdhc drivers
- /etc/modprobe.d/no_sdhc.conf
   '''
blacklist sdhci
blacklist sdhci_platform
blacklist sdhci_iproc
install sdhci /bin/false
install sdhci_platform /bin/false
install sdhci_iproc /bin/false
   '''
 - From [finishing steps for rhel 
8](https://access.redhat.com/solutions/41278)
- added 'sdhci.blacklist=1 rd.driver.blacklist=sdhci' to the above 
GRUB_CMDLINE_LINUX
- rebuilt grub again
- (make a copy of and) rebuilt initramfs
   'dracut --omit-drivers sdhci -f'

### Things I didn't do
1. fool around with kdump
2. Edit the installer kernel CMDLINE to blacklist the sdhci module and add the 
usb quirks

### Other Helpful notes
Article - 
https://fwmotion.com/blog/operating-systems/2020-09-04-installing-fedora-server-onto-pi4/


___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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

[fedora-arm] Re: Support for Raspberry PI 4

[Jeremy Linton]

Hi,

On 12/14/20 2:15 PM, Matthew Miller wrote:

On Mon, Dec 14, 2020 at 01:39:26PM +0100, Daan Hoogland wrote:

and in addition, do you think this is a lot of work to get to
fedora33? can you shortlist it?


I've asked Peter to _not_ personally shortlist this. I know it's a hugely
important piece of hardware, but it's also a constantly moving target and
it's blocking getting other stuff done and literally, not figuratively,
sucking the life-force from him like (figuratively, this time) the machine
in the Princess Bride.

Plainly, we need more people who can help with the Raspberry Pi.



Peter deserves an incredible amount of credit for the work he as put 
into getting an keeping these boards working.


That said, this situation is exactly why the SBSA/SBBR and now 
SystemReady specifications were created by ARM. These vendor provided 
BSPs don't scale, aren't secure, and leave people wanting to run 
alternative OSs in the dark (be that Fedora, *bsd, or whatever).


So, in the case of the rpi4 I think the longer term solution is to stop 
making the rpi Peter's (and everyone else directly involved in fedora) 
problem. As such there is the PFTF which is aiming to create enough of a 
platform abstraction to run unmodified linux distros/etc on the rpi3 and 
4. Its a fine product for the rpi3 (uefi+dt), and a work in progress for 
the rpi4 (uefi+acpi). Its still community maintained but the community 
includes not just fedora, or linux developers but people working on 
windows, vmware, *bsd's, etc. So the talent pool is larger.  Its of 
course an upstream first project too, and the pi foundation is aware of it.


It has been capable of running the base fedora iso/installers for a 
while now. Of course with a number of restrictions, which are slowly 
being worked through (besides the GPU, don't expect the bt for example 
to work). So this isn't to say that fedora people should be spending 
time on it, but rather a better long term solution for the rpi is to 
make something like that the default firmware for the rpi so we don't 
continue to have problems everytime the rpi foundation releases another 
vpu firmware that breaks some critical part of linux (and yes the pftf 
is frequently discovering regressions in the pi foundation firmware.)



https://rpi4-uefi.dev/
and
https://github.com/pftf/RPi4



___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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

[fedora-arm] Re: Hikey board (620) with Fedora 28 minimal cannot boot

[Jeremy Linton]

Hi,

Just a quick note here, per IRC this morning in case someone finds this 
but not that conversation.



On 05/18/2018 12:06 PM, Zamir SUN wrote:



On 05/17/2018 08:41 PM, Zamir SUN wrote:



On 05/16/2018 01:08 AM, Jeremy Linton wrote:

Hi,

On 05/14/2018 10:26 AM, Zamir SUN wrote:

Hi,

Today I am trying my HikeyBoard (620) with
Fedora-Minimal-28-1.1.aarch64.raw.xz. It simply cannot boot.


So, two quick questions. What firmware & version are you using, and have
you tried booting one of the installer images?

(I tend to use the server iso image, and have had a decent bit of luck
with it). 



Thanks for the suggestions.

I believe I haven't updated firmware after Fedora 27 released. I'll try
the installer way later when I have some time.



Hi Jeremy,

I updated to the newest firmware on Linaro website[1]. But boot still
stuck in "EFI stub: Exiting boot services and installing virtual address
map...". I flashed the firmware from your github[2] and the dracut
timeout error is still there. I am posting the console log from the UART
here[3].


That log looks suspiciously like the hi6220_reset driver being missing 
from the initrd. Regenerating it with dracut --add-drivers 
hi6220_reset.ko should may allow SD booting. I tested USB boot this 
weekend and it works, so the problem seems isolated to SD at the moment.




Addition note that might be useful:
1. The guide of flashing the firmware in[4] do not work for me. After
flashing l-loader.bin I cannot flash ptable-*.img(it just hang there
without any progress). When I see [5] I tried to flash the recovery.bin
first then it works.
2. I cannot type in anything using minicon after system boot to anaconda
text installer or dracut emergency shell. So I cannot install the system
myself or trying to get more logs. However I can edit the grub menu via
console, still not sure why.


This is likely an upstream edk2 bug. I've seen a couple patches for it, 
and integrated the one from the linaro edk2 repo, but i'm guessing its 
not working properly. To work around the problem pressing 'esc' during 
the "" boot, will exit to the UEFI BDS menus. From there simply 
booting the device should allow you to interact with grub/etc as normal. 
Starting the BDS seems to fix whatever is going wrong (although I didn't 
mention you should double check that your not using XON/XOFF flow control).




3. I did not see anything special with earlycon=pl011,0xf7113000 configured.

[1] https://releases.linaro.org/96boards/hikey/linaro/binaries/latest/
[2] https://github.com/jlinton/OpenPlatformPkg
[3] https://paste.fedoraproject.org/paste/cchgFYr~5R6YbjfGm4ZgNg
[4]
https://github.com/96boards/documentation/wiki/HiKeyUEFI#flash-binaries-to-emmc-
[5]
https://www.96boards.org/documentation/consumer/hikey/installation/board-recovery.md.html

So can you help with the second point (typing on console)? In that way I
can at least debug more myself.





I confirmed the xz image has the same hash as is shown on the mirror.
I. used the following command to write to my TF card.
xzcat Fedora-Minimal-28-1.1.aarch64.raw.xz | sudo dd status=progress
bs=4M of=/dev/mmcblk0

The system failed in dracut init queue timeout, with a warning "Warning:
/dev/disk/by-uuid/9a926ac9-5938-4539-bb79-72f87b36095f does not exist  "

However I confirmed the uuid is right for my partition.

Besides, I cannot type anything via minicon to it so I cannot really
debug more right now. I am posting the last block of message via UART.

So anyone have some hints for this? Thanks in advance!

(P.S. Fedora 27 works fine on my hikey board).


[  222.639468] dracut-initqueue[468]: Warning: dracut-initqueue timeout
- starts
[  222.639909] dracut-initqueue[468]: Warning: Could not boot.

   Starting Setup Virtual Console...

[  OK  [  222.716760] audit: type=1130 audit(1520288415.819:14): pid=1
uid=0 au'
] Started Setup [  222.738436] audit: type=1131
audit(1520288415.819:15): pid=1'
Virtual Console.

   Starting Dracut Emergency Shell...

[  222.825449] audit: type=1131 audit(1520288415.929:16): pid=1 uid=0
auid=4294'
Warning: /dev/disk/by-uuid/9a926ac9-5938-4539-bb79-72f87b36095f does not
exist


Generating "/run/initramfs/rdsosreport.txt"

[  222.897318] mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req
40H)
[  222.956555] mmc_host mmc0: Bus speed (slot 0) = 9920Hz (slot req
100)
[  222.967237] print_req_error: 6 callbacks suppressed

[  222.967243] print_req_error: I/O error, dev mmcblk0, sector 1

[  222.985808] print_req_error: I/O error, dev mmcblk0, sector 0

[  222.991640] print_req_error: I/O error, dev mmcblk0, sector 1

[  223.001405] Buffer I/O error on dev mmcblk0, logical block 0, async
page read
[  223.032457] mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req
40H)
[  223.089436] mmc_host mmc0: Bus speed (slot 0) = 9920Hz (slot req
100)
[  223.100132] print_req_error: I/O error, dev mmcblk0, sector 1

[  223.114

[fedora-arm] Re: Hikey board (620) with Fedora 28 minimal cannot boot

[Jeremy Linton]

Hi,

On 05/14/2018 10:26 AM, Zamir SUN wrote:

Hi,

Today I am trying my HikeyBoard (620) with
Fedora-Minimal-28-1.1.aarch64.raw.xz. It simply cannot boot.


So, two quick questions. What firmware & version are you using, and have 
you tried booting one of the installer images?


(I tend to use the server iso image, and have had a decent bit of luck 
with it).





I confirmed the xz image has the same hash as is shown on the mirror. I. 
used the following command to write to my TF card.

xzcat Fedora-Minimal-28-1.1.aarch64.raw.xz | sudo dd status=progress
bs=4M of=/dev/mmcblk0

The system failed in dracut init queue timeout, with a warning "Warning:
/dev/disk/by-uuid/9a926ac9-5938-4539-bb79-72f87b36095f does not exist  "

However I confirmed the uuid is right for my partition.

Besides, I cannot type anything via minicon to it so I cannot really
debug more right now. I am posting the last block of message via UART.

So anyone have some hints for this? Thanks in advance!

(P.S. Fedora 27 works fine on my hikey board).


[  222.639468] dracut-initqueue[468]: Warning: dracut-initqueue timeout
- starts
[  222.639909] dracut-initqueue[468]: Warning: Could not boot.

  Starting Setup Virtual Console...

[  OK  [  222.716760] audit: type=1130 audit(1520288415.819:14): pid=1
uid=0 au'
] Started Setup [  222.738436] audit: type=1131
audit(1520288415.819:15): pid=1'
Virtual Console.

  Starting Dracut Emergency Shell...

[  222.825449] audit: type=1131 audit(1520288415.929:16): pid=1 uid=0
auid=4294'
Warning: /dev/disk/by-uuid/9a926ac9-5938-4539-bb79-72f87b36095f does not
exist


Generating "/run/initramfs/rdsosreport.txt"

[  222.897318] mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req
40H)
[  222.956555] mmc_host mmc0: Bus speed (slot 0) = 9920Hz (slot req
100)
[  222.967237] print_req_error: 6 callbacks suppressed

[  222.967243] print_req_error: I/O error, dev mmcblk0, sector 1

[  222.985808] print_req_error: I/O error, dev mmcblk0, sector 0

[  222.991640] print_req_error: I/O error, dev mmcblk0, sector 1

[  223.001405] Buffer I/O error on dev mmcblk0, logical block 0, async
page read
[  223.032457] mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req
40H)
[  223.089436] mmc_host mmc0: Bus speed (slot 0) = 9920Hz (slot req
100)
[  223.100132] print_req_error: I/O error, dev mmcblk0, sector 1

[  223.114267] print_req_error: I/O error, dev mmcblk0, sector 0

[  223.120128] print_req_error: I/O error, dev mmcblk0, sector 1

[  223.129994] Buffer I/O error on dev mmcblk0, logical block 0, async
page read
[  223.176307] print_req_error: I/O error, dev mmcblk0, sector 0

[  223.182146] print_req_error: I/O error, dev mmcblk0, sector 1

[  223.211348] mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req
40H)
[  223.268935] mmc_host mmc0: Bus speed (slot 0) = 9920Hz (slot req
100)
[  223.279748] print_req_error: I/O error, dev mmcblk0, sector 1

[  223.285597] print_req_error: I/O error, dev mmcblk0, sector 2

[  223.313471] mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req
40H)
[  223.373025] mmc_host mmc0: Bus speed (slot 0) = 9920Hz (slot req
100)
[  223.442453] mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req
40H)
[  223.499139] mmc_host mmc0: Bus speed (slot 0) = 9920Hz (slot req
100)
[  223.533285] mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req
40H)
[  223.592543] mmc_host mmc0: Bus speed (slot 0) = 9920Hz (slot req
100)
[  223.663611] mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req
40H)
[  223.723301] mmc_host mmc0: Bus speed (slot 0) = 9920Hz (slot req
100)
[  223.757851] mmc_host mmc0: Bus speed (slot 0) = 2480Hz (slot req
40H)
[  223.817927] mmc_host mmc0: Bus speed (slot 0) = 9920Hz (slot req
100)


___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Docs on using Fedora-Everything-netinst-aarch64-27-20170912.n.0.iso with HiKey960?

[Jeremy Linton]

On 09/22/2017 07:41 AM, Konrad Rzeszutek Wilk wrote:

On Thu, Sep 21, 2017 at 03:19:12PM -0500, Jeremy Linton wrote:

Hi,

On 09/18/2017 02:18 PM, Konrad Rzeszutek Wilk wrote:

Hey,

The HiKey960 is one of the supported list of devices per 
(https://fedoraproject.org/wiki/Architectures/ARM?rd=Architectures/AArch64) 
where it mentions that the 96Boards.

But I am not finding any docs on how to install?


I don't have a 960, but I've been running fedora on the older hikey. My
suggestion is to use the prebuilt binaries install process to get a valid
uefi image running on the machine.

http://snapshots.linaro.org/reference-platform/embedded/morty/hikey960/latest/rpb/bootloader/

Really, you should only need to flash the ptable (emmc partition table),
xloader/iloader, and fip.bin (uefi/armtf image). Then from that you _SHOULD_
be able to download one of the fedora server/netboot images boot it and
install fedora like you would on any generic PC with uefi.


OK, so I think you are saying extract:
Fedora-Everything-netinst-aarch64-27-20170912.n.0.iso:
/TRANS.TBL
./Fedora-Legal-README.txt
./boot.catalog
./LICENSE
./EFI
./EFI/BOOT
./EFI/BOOT/BOOTAA64.EFI
./EFI/BOOT/grub.cfg
./EFI/BOOT/TRANS.TBL
./EFI/BOOT/mmaa64.efi
./EFI/BOOT/fonts
./EFI/BOOT/fonts/TRANS.TBL
./EFI/BOOT/fonts/unicode.pf2
./EFI/BOOT/grubaa64.efi
./images
./images/TRANS.TBL
./images/efiboot.img
./images/pxeboot
./images/pxeboot/TRANS.TBL
./images/pxeboot/initrd.img
./images/pxeboot/vmlinuz
./images/install.img



No, don't extraction anything. Just dd the entire .iso file (or as I now 
see Peter suggests gnome disk tool) to a USB disk, or burn it to a blank 
cd, or maybe if there isn't a USB driver in the UEFI firmware an SD 
card. Then plug the resulting disk into the hikey and reset the machine. 
What should happen is that since there isn't any bootable media on the 
hikey outside of that disk, it gets automatically started and you walk 
through the fedora installer.


(I'm assuming you have the 96boards serial mezzanine 
https://www.96boards.org/product/uartserial/)


More likely, you will either land in the BDS (boot device selector menu) 
or the UEFI command shell. From that you can either move around in the 
menus and select "Boot Manager" and pick the device you wrote, or look 
at the list of filesystems (FS0,FS1, etc) displayed by the UEFI shell, 
and type "FSx:", "cd EFI\BOOT" "grubaa64.efi" which will start grub and 
allow you to start the install. Its possible you might need to add 
"inst.text" to the grub command line if it starts up and complains about 
X and you don't see a graphical installer.


Just be prepared for various things to not work, if for example it 
appears the hikey can't see any USB devices you plug in from the 
BDS/Shell then try a SD card, if the network can't start from the fedora 
installer, try the server image, etc..






from 
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170912.n.0_Installation?rd=Test_Results:Current_Installation_Test

, then create an DOS partition image, put in the contents of that whole
thing in there (456M), modify the grub.cfg to use the serial console
(and VNC?), and then kick it off.

.. But that seems a bit silly - why not just have pre-created images
(boot and system.img) that could be loaded directly and have a basic
install?


That's basically what the .iso images are, they have a uEFI system 
partition and the artifacts necessarily to be auto-detected and started 
from a boot manager across a range of different aarch64 devices. Whether 
the linaro/hikey960 firmware is providing enough of the standard UEFI 
services for this to work is something I can't say.





The remainder of the images (boot/system/etc) would just be overwritten by
the fedora install anyway.

Will it work? No idea! The aarch64 fedora installers use basically upstream
grub/kernel/etc trees so linaro "workarounds" for machine/firmware problems
may not be in fedora. I intend to encourage more "standards" compliance with
regard to the UEFI images linaro ships when i'm at connect next week.

Sorry, not be be more helpful.




The Linaro images are rootfs ones that would be loaded using fastboot (after a 
lot of pain of changing the boot to UEFI) and loading the right Android type 
images on the box.
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org




___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Docs on using Fedora-Everything-netinst-aarch64-27-20170912.n.0.iso with HiKey960?

[Jeremy Linton]

Hi,

On 09/20/2017 10:27 AM, Konrad Rzeszutek Wilk wrote:

On Wed, Sep 20, 2017 at 04:14:04PM +0100, Peter Robinson wrote:

On Wed, Sep 20, 2017 at 4:07 PM, Konrad Rzeszutek Wilk
 wrote:

On Mon, Sep 18, 2017 at 8:18 PM, Konrad Rzeszutek Wilk

[fedora-arm] Re: Docs on using Fedora-Everything-netinst-aarch64-27-20170912.n.0.iso with HiKey960?

[Jeremy Linton]

Hi,

On 09/18/2017 02:18 PM, Konrad Rzeszutek Wilk wrote:

Hey,

The HiKey960 is one of the supported list of devices per 
(https://fedoraproject.org/wiki/Architectures/ARM?rd=Architectures/AArch64) 
where it mentions that the 96Boards.

But I am not finding any docs on how to install?


I don't have a 960, but I've been running fedora on the older hikey. My 
suggestion is to use the prebuilt binaries install process to get a 
valid uefi image running on the machine.


http://snapshots.linaro.org/reference-platform/embedded/morty/hikey960/latest/rpb/bootloader/

Really, you should only need to flash the ptable (emmc partition table), 
xloader/iloader, and fip.bin (uefi/armtf image). Then from that you 
_SHOULD_ be able to download one of the fedora server/netboot images 
boot it and install fedora like you would on any generic PC with uefi.


The remainder of the images (boot/system/etc) would just be overwritten 
by the fedora install anyway.


Will it work? No idea! The aarch64 fedora installers use basically 
upstream grub/kernel/etc trees so linaro "workarounds" for 
machine/firmware problems may not be in fedora. I intend to encourage 
more "standards" compliance with regard to the UEFI images linaro ships 
when i'm at connect next week.


Sorry, not be be more helpful.




The Linaro images are rootfs ones that would be loaded using fastboot (after a 
lot of pain of changing the boot to UEFI) and loading the right Android type 
images on the box.
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org


___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: 48-bit support in F26?

[Jeremy Linton]

On 10/19/2016 12:29 PM, Robert Richter wrote:

Jeremy,

On 21.09.16 14:57:45, Jon Masters wrote:

Going forward, I would /also/ like to be 52-bit VA tolerant.


are current fixes for 48 bits sufficient to later extend it to 52
bits? It would be good if userland can already support 52 bits to
avoid fixing it again.


Well, just to muddy the waters a bit. Its possible there will be further 
problems with 52-bit VA's. Its hard to predict what other latent 
applications are using tagged pointers in bits that aren't affected by 
the 48bit VA. Plus, the js 1.85 changes just bump the tags a little 
higher. So anything still using 1.85 with 52-bit VA's will have 
problems. That is part of the reason why i'm trying to move everything 
that is still on js185 to mozjs24/38.



___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: 48-bit support in F26?

[Jeremy Linton]

On 10/19/2016 12:29 PM, Robert Richter wrote:

Jeremy,

On 21.09.16 14:57:45, Jon Masters wrote:

Going forward, I would /also/ like to be 52-bit VA tolerant.


are current fixes for 48 bits sufficient to later extend it to 52
bits? It would be good if userland can already support 52 bits to
avoid fixing it again.


Hi,

Sorry about the delay, this got lost in the shuffle.

Yes, the existing mozjs fixes should work for 52-bit VA's as well. They 
are basically limiting the addresses that the the tagged JS objects are 
allocated at. This means that even if the addresses expand to 52-bit 
VA's the objects will continue to be allocated below 47-bits.


(or that is the theory).



___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: 48-bit support in F26?

[Jeremy Linton]

Hi,

On 09/22/2016 04:58 AM, Peter Lemenkov wrote:

2016-09-21 20:47 GMT+02:00 Jeremy Linton <jeremy.lin...@arm.com>:

On 09/15/2016 08:15 AM, Peter Lemenkov wrote:


Hello All!

2016-09-14 23:59 GMT+02:00 Jeremy Linton <jeremy.lin...@arm.com>:


js185:
couchdb-0:1.6.1-16.fc25.x86_64


...


erlang-js-0:1.3.0-7.fc25.x86_64



I've got patches (mostly untested) for building erlang-js with mozjs170.

https://github.com/basho/erlang_js/pull/44#issuecomment-247323892



Hi Peter,

I've been submitting patches to pull everything forward to at least mozjs24
which is where gnome/etc are. Would it be possible to push from 17 to 24,
because if erlang lands on mozjs17 when polkit gets moved to 24, then again
mozjs17 will have a single dependency in fedora.


Working on it. The main issue is that they switched to C++, as well as
API change. I've got a version which compiles but segfaults during the
unit-tests.


I don't see that in the github repo, but moving from 17->24 is 
straightforward once you get the C++ compile/link conversions 
straightend out. The one gocha, which i'm guessing is biting you, is any 
calls to JS_NewCompartmentAndGlobalObject() need to be converted to 
JS_NewGlobalObject() then you need to construct an JSAutoCompartment and 
track it for the lifetime of the GlobalObject (or go ahead and try to 
use RAII, but that likely requires higher level restructing of the old C 
code). The auto compartment stuff caused me some grief when I initially 
ported polkit.






That said, it looks like gnome are trying to move again, but they are too
moving to mozjs31, just as 0ad leaves it.


Mozjs versions zoo is a mess :)
Still better than v8 API as I was told :)



___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: 48-bit support in F26?

[Jeremy Linton]

On 09/15/2016 08:15 AM, Peter Lemenkov wrote:

Hello All!

2016-09-14 23:59 GMT+02:00 Jeremy Linton <jeremy.lin...@arm.com>:


js185:
couchdb-0:1.6.1-16.fc25.x86_64

...

erlang-js-0:1.3.0-7.fc25.x86_64


I've got patches (mostly untested) for building erlang-js with mozjs170.

https://github.com/basho/erlang_js/pull/44#issuecomment-247323892


Hi Peter,

I've been submitting patches to pull everything forward to at least 
mozjs24 which is where gnome/etc are. Would it be possible to push from 
17 to 24, because if erlang lands on mozjs17 when polkit gets moved to 
24, then again mozjs17 will have a single dependency in fedora.


That said, it looks like gnome are trying to move again, but they are 
too moving to mozjs31, just as 0ad leaves it.



___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: 48-bit support in F26?

[Jeremy Linton]

Hi,
On 09/14/2016 02:55 PM, Jon Masters wrote:

Hi Jeremy, all,


(trimming)


Perhaps Jeremy can update us on the status, and then he and others can
help drive this forward (someone should nominate themselves as the ring
leader too). I spoke with Cavium earlier today, and I know they'll be
keen to help. I know Qualcomm had expressed interest during our IRC
meetings in helping out. To that end, I'm copying at least those I know
so far who are interested here.


(this is the short version, even so, it got really long) 

Right now, there are posted patches for 1.8.5, 17, 24 and 38 in the 
fedora mozjs defects 1242326, 1375305, 1375547. The 17, 24 and 38 
versions are fairly straightforward backports of the upstream mmap patch 
which maintains the mozjs ABI. The dependent packages should not need to 
be rebuilt. The 1.8.5 is based on an earlier patch and moves the tagging 
bits higher in the word and will require a further work to go beyond 
48-bit. That means that all js185 packages will need to be rebuilt 
against it. Doing it this way helps to solve some problems with couchdb.


There are public patches to move polkit (fedora bug #1375368, polkit bug 
#74592) to mozjs24 
(https://lists.freedesktop.org/archives/polkit-devel/2016-August/000503.html). 
That removes the mozjs17 dependency in fedora.


There are also public patches for libproxy 
https://github.com/libproxy/libproxy/pull/36, and pacrunner 
https://lists.01.org/pipermail/connman/2016-September/020902.html. To 
get them off js185.


Further, there is another effort to move 0ad off mozjs31 to mozj38. 
http://trac.wildfiregames.com/ticket/3708


This leaves couchdb, elinks, erlang, freewrl/libEIA, mediatomb and 
plowshare on js185.


At the moment, as far as mozjs is concerned I think its mostly working. 
The remaining js185 projects should work, but should have further 
attention. Erlang and freewrl are not trivial, and while it appears that 
freewrl was moving towards duktape, it doesn't actually appear to be 
working at the moment.


There is also a similar mess for lua, for which upstream version 2.1 has 
patches, but those need investigation and backporting for nginx/etc on 
fedora. Frankly, I'm trying to clear off my small piece of mozjs  before 
jumping into the lua bucket. If someone wants to grab that portion they 
are welcome to it.


I can provide more detail about specifics in mozjs if anyone is 
interested. My general goal right now is to consolidate on mozjs24 and 
mozjs38. If once that happens I will consider it done. If anyone decides 
to grab one of the projects let me know, I have partial (not yet 100% 
functional) reworks for a couple of them. Further, it should be noted 
that at least mozjs24 has regression failures on fedora/aarch64 at the 
moment. Those failures are not dependent on 48-bit.




js185:
couchdb-0:1.6.1-16.fc25.x86_64
elinks-0:0.12-0.48.pre6.fc24.x86_64
erlang-js-0:1.3.0-7.fc25.x86_64
freewrl-0:3.0.0-1.fc25.x86_64
js-devel-1:1.8.5-25.fc25.i686
js-devel-1:1.8.5-25.fc25.x86_64
libEAI-0:3.0.0-1.fc25.x86_64
libproxy-mozjs-0:0.4.12-4.fc25.x86_64
mediatomb-0:0.12.1-38.fc25.20120403gitb66dc1.x86_64
pacrunner-0:0.7-7.fc24.x86_64
plowshare-0:2.0.1-3.fc24.noarch


mozjs17:
mozjs17-devel-0:17.0.0-15.fc25.i686
mozjs17-devel-0:17.0.0-15.fc25.x86_64
polkit-0:0.113-5.fc24.x86_64

mozjs24:
cinnamon-0:3.0.6-1.fc25.x86_64
cjs-1:3.0.1-1.fc25.i686
cjs-1:3.0.1-1.fc25.x86_64
cjs-tests-1:3.0.1-1.fc25.x86_64
gjs-0:1.45.4-1.fc25.i686
gjs-0:1.45.4-1.fc25.x86_64
gjs-tests-0:1.45.4-1.fc25.x86_64
gnome-shell-0:3.21.4-1.fc25.x86_64
mozjs24-devel-0:24.2.0-8.fc24.i686
mozjs24-devel-0:24.2.0-8.fc24.x86_64

mozjs31:
0ad-0:0.0.20-4.fc25.x86_64 (in progress to 38

mozjs38:
mongodb-0:3.2.7-1.fc25.x86_64
mongodb-server-0:3.2.7-1.fc25.x86_64
mozjs38-devel-0:38.2.1-8.fc25.i686
mozjs38-devel-0:38.2.1-8.fc25

mozjs45:
(nothing at the moment, just in rawhide)
___
arm mailing list
arm@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org