[fedora-arm] Re: device tree on Pi4B

[Steven A. Falco]

On 8/4/22 02:46 AM, Peter Robinson wrote:

On Wed, Aug 3, 2022 at 8:04 PM Steven A. Falco  wrote:


On 8/3/22 02:24 PM, Peter Robinson wrote:

On Wed, Aug 3, 2022 at 4:17 PM Steven A. Falco  wrote:


I have a Pi4B that is working pretty well with the aarch64 version of Fedora 
Rawhide, but I have one issue that I haven't been able to find a solution to.

I have an Adafruit RTC connected via I2C 
(https://www.adafruit.com/product/3386).  If I use the kernel device tree, this 
device is not found.

I then tried switching to the firmware device tree via the instructions in 
https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi/HATs.  That works 
pretty well - I can now add an overlay for the RTC in /boot/efi/config.txt and 
the RTC is found during boot.  dtoverlay=i2c-rtc,pcf8523,addr=0x68

However, once I've switched to the firmware device tree, I no longer have /dev/vchiq, 
which means that I can no longer use vcgencmd.  Instead, vcgencmd gives me "VCHI 
initialization failed".


It should be the same as required in Raspbian. Have you checked the
details in /boot/efi/overlays/README? Out of interest what do you use
/dev/vchiq / vcgencmd for?


I've looked at the README, but it doesn't mention VCHI, so I'm not sure how to 
enable VCHI when using the firmware DT.  I'll look at the kernel DT source - 
perhaps that gives clues as to how to create an overlay that I could then use 
with the firmware DT.


I'll take a look when I get a few cycles.


Turns out the vchiq_probe code in vchiq_arm.c is looking for either "brcm,bcm2835-vchiq" or 
"brcm,bcm2836-vchiq", while the FW DT is supplying "brcm,bcm2711-vchiq".  I attached a 
patch that lets me insert the vchiq driver; the driver in turn creates the /dev/vchiq node, and I am then 
able to use vcgencmd.

I have to manually modprobe the driver when using the FW DT.  The driver is 
automatically inserted during boot when using the kernel DT.  I haven't tracked 
that part down yet...


One interesting thing is that the kernel DT shows the RTC on bus 3, but the 
firmware DT shows the RTC on bus 1.


Three's different "modes" (for want of a better description) where the
firmware steals buses for it's own use.


BTW, I'm using vcgencmd to measure the temperature and to check the 
"get_throttled" flag to detect voltage dips.


You can also use tmon in the kernel-tools package to monitor temp,
thermal trip points and the like.


Is there any way to get both the RTC and vcgencmd to work?  Which device tree 
would I choose?  Do I have to build a custom kernel or is there some other way 
to enable the RTC with the kernel device tree?


You don't need a custom kernel but you'd need to build your own DT as
obviously anything that is not default on the RPi devices themselves
is optional hence the requirement of overlays.


Understood.  I don't know which is better - the firmware DT or the kernel DT.  
I guess the FW DT has the advantage that it is easy to turn stuff on/off, but 
the kernel DT probably better matches the drivers.


For the later point, not really, they are slowly converging closer
together. Fedora as a whole is moving towards SystemReady IR style of
DT where it's provided by the firmware and I hope to stop shipping the
kernel ones all together.


And of course the last thing I want is to have to regenerate a custom DT each 
time the kernel is updated.


You shouldn't need to do that for each kernel.
--- test_kernel/builddir/kernel_build/BUILD/kernel-5.19/linux-5.19.0-65.local.fc37.aarch64/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c	2022-07-31 17:03:01.0 -0400
+++ /home/sfalco/vchiq_arm.c	2022-08-12 11:10:23.609220349 -0400
@@ -81,6 +81,10 @@
 	.cache_line_size = 64,
 };
 
+static struct vchiq_drvdata bcm2711_drvdata = {
+	.cache_line_size = 64,
+};
+
 struct vchiq_arm_state {
 	/* Keepalive-related data */
 	struct task_struct *ka_thread;
@@ -1761,6 +1765,7 @@
 static const struct of_device_id vchiq_of_match[] = {
 	{ .compatible = "brcm,bcm2835-vchiq", .data = _drvdata },
 	{ .compatible = "brcm,bcm2836-vchiq", .data = _drvdata },
+	{ .compatible = "brcm,bcm2711-vchiq", .data = _drvdata },
 	{},
 };
 MODULE_DEVICE_TABLE(of, vchiq_of_match);
___
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: device tree on Pi4B

[Steven A. Falco]

On 8/3/22 02:24 PM, Peter Robinson wrote:

On Wed, Aug 3, 2022 at 4:17 PM Steven A. Falco  wrote:


I have a Pi4B that is working pretty well with the aarch64 version of Fedora 
Rawhide, but I have one issue that I haven't been able to find a solution to.

I have an Adafruit RTC connected via I2C 
(https://www.adafruit.com/product/3386).  If I use the kernel device tree, this 
device is not found.

I then tried switching to the firmware device tree via the instructions in 
https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi/HATs.  That works 
pretty well - I can now add an overlay for the RTC in /boot/efi/config.txt and 
the RTC is found during boot.  dtoverlay=i2c-rtc,pcf8523,addr=0x68

However, once I've switched to the firmware device tree, I no longer have /dev/vchiq, 
which means that I can no longer use vcgencmd.  Instead, vcgencmd gives me "VCHI 
initialization failed".


It should be the same as required in Raspbian. Have you checked the
details in /boot/efi/overlays/README? Out of interest what do you use
/dev/vchiq / vcgencmd for?


I've looked at the README, but it doesn't mention VCHI, so I'm not sure how to 
enable VCHI when using the firmware DT.  I'll look at the kernel DT source - 
perhaps that gives clues as to how to create an overlay that I could then use 
with the firmware DT.

One interesting thing is that the kernel DT shows the RTC on bus 3, but the 
firmware DT shows the RTC on bus 1.

BTW, I'm using vcgencmd to measure the temperature and to check the 
"get_throttled" flag to detect voltage dips.


Is there any way to get both the RTC and vcgencmd to work?  Which device tree 
would I choose?  Do I have to build a custom kernel or is there some other way 
to enable the RTC with the kernel device tree?


You don't need a custom kernel but you'd need to build your own DT as
obviously anything that is not default on the RPi devices themselves
is optional hence the requirement of overlays.


Understood.  I don't know which is better - the firmware DT or the kernel DT.  
I guess the FW DT has the advantage that it is easy to turn stuff on/off, but 
the kernel DT probably better matches the drivers.

And of course the last thing I want is to have to regenerate a custom DT each 
time the kernel is updated.

Steve
___
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] device tree on Pi4B

[Steven A. Falco]

I have a Pi4B that is working pretty well with the aarch64 version of Fedora 
Rawhide, but I have one issue that I haven't been able to find a solution to.

I have an Adafruit RTC connected via I2C 
(https://www.adafruit.com/product/3386).  If I use the kernel device tree, this 
device is not found.

I then tried switching to the firmware device tree via the instructions in 
https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi/HATs.  That works 
pretty well - I can now add an overlay for the RTC in /boot/efi/config.txt and 
the RTC is found during boot.  dtoverlay=i2c-rtc,pcf8523,addr=0x68

However, once I've switched to the firmware device tree, I no longer have /dev/vchiq, 
which means that I can no longer use vcgencmd.  Instead, vcgencmd gives me "VCHI 
initialization failed".

Is there any way to get both the RTC and vcgencmd to work?  Which device tree 
would I choose?  Do I have to build a custom kernel or is there some other way 
to enable the RTC with the kernel device tree?

Steve
___
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: Failures booting on Pi4

[Steven A. Falco]

I haven't posted the following as a bug yet, but when I ssh into the unit as 
root I get an oops as shown in the attached file.  But if I ssh into the unit 
as a normal user, there is no oops.  The oops is non-fatal, as far as I can 
tell, but unsettling regardless.


The above is misleading.  Turns out the oops is generated by doing:

kbdrate -d 500

which I had added to my .bash_profile.  That command opens /dev/port, which 
only root can do.  So a normal user cannot trigger the oops but the root user 
can.

I opened bug https://bugzilla.redhat.com/show_bug.cgi?id=2108633 because while 
root can certainly crash a system in many ways, the kbdrate command really 
shouldn't cause an oops.

Steve
___
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: Failures booting on Pi4

[Steven A. Falco]

On 7/18/22 03:26 PM, Chris Adams wrote:

Once upon a time, Steven A. Falco  said:

So, there is something bizarre happening with uSD cards with most of the images I tested. 
 The only image that works for me on a uSD card is the Server image.  Note that I tried 
several different uSD cards - Samsung, SanDisk, and a "no name" card, and got 
consistent results, so I don't think the uSD cards are at fault.


If you take off "rhgb quiet" from the kernel command line, do you see
kernel error messages?  If I try to boot Fedora on a Pi 4B with any card
in the uSD slot, I get a loop of these from the kernel:

mmc0: error -22 whilst initialising SD card
mmc0: invalid bus width


Interesting.  I get an mmc0 error, but it looks different.  I get this in a 
loop:

[   51.973829] mmc0: ADMA error: 0x0200
[   51.982126] mmc0: sdhci:  SDHCI REGISTER DUMP ===
[   51.993799] mmc0: sdhci: Sys addr:  0x | Version:  0x1002
[   52.005088] mmc0: sdhci: Blk size:  0x7008 | Blk cnt:  0x0001
[   52.016654] mmc0: sdhci: Argument:  0x | Trn mode: 0x0013
[   52.028282] mmc0: sdhci: Present:   0x1fff0206 | Host ctl: 0x0011
[   52.039924] mmc0: sdhci: Power: 0x000f | Blk gap:  0x0080
[   52.051544] mmc0: sdhci: Wake-up:   0x | Clock:0xa707
[   52.063216] mmc0: sdhci: Timeout:   0x | Int stat: 0x
[   52.074896] mmc0: sdhci: Int enab:  0x03ff100b | Sig enab: 0x03ff100b
[   52.086568] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x
[   52.098224] mmc0: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
[   52.109936] mmc0: sdhci: Cmd:   0x333a | Max curr: 0x00080008
[   52.121629] mmc0: sdhci: Resp[0]:   0x0920 | Resp[1]:  0x00ee7f7f
[   52.133368] mmc0: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x00400e00
[   52.145037] mmc0: sdhci: Host ctl2: 0x0008
[   52.154607] mmc0: sdhci: ADMA Err:  0x0001 | ADMA Ptr: 0xe7000200
[   52.166233] mmc0: sdhci: 
[   52.177916] mmc0: sdhci: e7000200: DMA 0xf4802000, LEN 0x0008, Attr=0x21
[   52.189979] mmc0: sdhci: e7000208: DMA 0x, LEN 0x, Attr=0x03
[   52.203909] mmc0: error -5 whilst initialising SD card


I'm not sure how you'd get different behavior with different images
though, because they're all the same kernel/initrd setup AFAIK

They are mostly the same setup, but perhaps there are some race conditions that 
are triggered by the different filesystems that the different image types use?  
I know that Minimal uses ext4 for /, Workstation and KDE use btrfs, and Server 
uses lvm + xfs.

Since the USB flash sticks are well-behaved I'll use them for now.  But this is 
one quirky piece of hardware, and I'm not surprised it has taken so many people 
so many hours/years to get it to work at all.

I haven't posted the following as a bug yet, but when I ssh into the unit as 
root I get an oops as shown in the attached file.  But if I ssh into the unit 
as a normal user, there is no oops.  The oops is non-fatal, as far as I can 
tell, but unsettling regardless.

Steve
[root@fedora system]# [ 1907.572507] Unable to handle kernel paging request at 
virtual address fbfffe800064
[ 1907.581112] Mem abort info:
[ 1907.583955]   ESR = 0x9606
[ 1907.587763]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1907.593242]   SET = 0, FnV = 0
[ 1907.596347]   EA = 0, S1PTW = 0
[ 1907.599539]   FSC = 0x06: level 2 translation fault
[ 1907.604542] Data abort info:
[ 1907.607472]   ISV = 0, ISS = 0x0006
[ 1907.611410]   CM = 0, WnR = 0
[ 1907.614426] swapper pgtable: 4k pages, 48-bit VAs, pgdp=1d8d
[ 1907.621273] [fbfffe800064] pgd=1e6e1003, p4d=1e6e1003, 
pud=1e6e2003, pmd=
[ 1907.632326] Internal error: Oops: 9606 [#1] SMP
[ 1907.637279] Modules linked in: ufs hfsplus hfs minix msdos jfs xfs tls 
snd_seq_dummy snd_hrtimer snd_seq rfcomm snd_seq_device nft_objref 
nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 
nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject 
nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set 
nf_tables nfnetlink qrtr bnep bcm2835_v4l2(C) bcm2835_mmal_vchiq(C) 
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev 
snd_soc_hdmi_codec snd_bcm2835(C) mc cpufreq_dt btsdio brcmfmac brcmutil vfat 
joydev fat hci_uart cfg80211 raspberrypi_cpufreq btqca btrtl btbcm btintel 
bluetooth rfkill vchiq(C) iproc_rng200 vc4 bcm2711_thermal snd_soc_core 
snd_compress ac97_bus snd_pcm_dmaengine leds_gpio fuse zram uas usb_storage 
snd_pcm broadcom dwc2 snd_timer crct10dif_ce raspberrypi_hwmon 
gpio_raspberrypi_exp bcm_phy_lib clk_bcm2711_dvp snd udc_core pwm_bcm2835 
soundcore genet drm_display_helper bcm2835_wdt
[ 1907.637451]  i2c_bcm2835 pcie_brcmstb cec mdio_bcm_unimac bcm2835_dma 
sdhci_iproc sdhci_plt

[fedora-arm] Failures booting on Pi4

[Steven A. Falco]

Since there has been discussion about supporting Fedora on the Pi4, I decided 
to try a few rawhide images on a Pi4B with 2 GB of RAM.  Most of the 
experiments below used uSD cards.

The results are very strange.  To begin, I connected Ethernet, a mouse, 
keyboard, and an HDMI monitor, along with a serial port on pins 8 and 10 of the 
40-pin connector.

Fedora-Minimal-Rawhide-20220717.n.0.aarch64.raw.xz fails with the following on 
the serial port:

U-Boot 2022.07-rc6 (Jul 04 2022 - 00:00:00 +)

DRAM:  2 GiB
RPI 4 Model B (0xb03115)
Core:  211 devices, 17 uclasses, devicetree: board
MMC:   mmcnr@7e30: 1, mmc@7e34: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   eth0: ethernet@7d58
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... Unexpected XHCI event TRB, skipping... 
(3db5f620 0004 0100 01008401)
BUG at drivers/usb/host/xhci-ring.c:530/abort_td()!
BUG!
resetting ...

I tried disconnecting the mouse, keyboard, and Ethernet, but I got the same 
failure.

I then tried just disconnecting the HDMI monitor, while leaving everything else 
connected.  In that case I am able to get further, but then I start getting 
timeout messages from dracut:

[  OK  ] Started plymouth-start.ser…e - Show Plymouth Boot Screen.
[  OK  ] Started systemd-ask-passwo…uests to Plymouth Directory Watch.
[  OK  ] Reached target cryptsetup.…get - Local Encrypted Volumes.
[  OK  ] Reached target paths.target - Path Units.
[  OK  ] Finished systemd-udev-sett…To Complete Device Initialization.
 Starting multipathd.servic…per Multipath Device Controller...
[  OK  ] Started multipathd.service…apper Multipath Device Controller.
[  OK  ] Reached target local-fs-pr…reparation for Local File Systems.
[  OK  ] Reached target local-fs.target - Local File Systems.
 Starting systemd-tmpfiles-… Volatile Files and Directories...
[  OK  ] Finished systemd-tmpfiles-…te Volatile Files and Directories.
[  OK  ] Reached target sysinit.target - System Initialization.
[  OK  ] Reached target basic.target - Basic System.
[  368.423014] dracut-initqueue[441]: Warning: dracut-initqueue: timeout, still 
waiting for following initqueue hooks:
[  368.471849] dracut-initqueue[441]: Warning: 
/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f6c12ffc9-6ea9-457c-9acf-7a886798e99c.sh:
 "if ! grep -q After=remote-fs-pre.target 
/run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
[  368.472914] dracut-initqueue[441]: [ -e 
"/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ]
[  368.473753] dracut-initqueue[441]: fi"
[  368.545042] dracut-initqueue[441]: Warning: dracut-initqueue: starting 
timeout scripts
[  370.304891] dracut-initqueue[441]: Warning: dracut-initqueue: timeout, still 
waiting for following initqueue hooks:
[  370.353412] dracut-initqueue[441]: Warning: 
/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f6c12ffc9-6ea9-457c-9acf-7a886798e99c.sh:
 "if ! grep -q After=remote-fs-pre.target 
/run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
[  370.354565] dracut-initqueue[441]: [ -e 
"/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ]
[  370.355428] dracut-initqueue[441]: fi"
[  370.426159] dracut-initqueue[441]: Warning: dracut-initqueue: starting 
timeout scripts
[  371.795792] dracut-initqueue[441]: Warning: dracut-initqueue: timeout, still 
waiting for following initqueue hooks:
[  371.845592] dracut-initqueue[441]: Warning: 
/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f6c12ffc9-6ea9-457c-9acf-7a886798e99c.sh:
 "if ! grep -q After=remote-fs-pre.target 
/run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
[  371.846757] dracut-initqueue[441]: [ -e 
"/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ]
[  371.847604] dracut-initqueue[441]: fi"
[  371.922589] dracut-initqueue[441]: Warning: dracut-initqueue: starting 
timeout scripts

Next, I tried Fedora-KDE-Rawhide-20220717.n.0.aarch64.raw.xz and 
Fedora-Workstation-Rawhide-20220717.n.0.aarch64.raw.xz.  Amazingly, they are 
able to get past the XHCI error even with the HDMI monitor connected.  However, 
they still fail later in the startup process with the same dracut messages that 
I showed above.

I then tried Fedora-Server-Rawhide-20220717.n.0.aarch64.raw.xz.  It booted with 
everything connected.  It got to the initial configuration menu, let me set the 
root password, and booted to a login prompt, which worked perfectly.

As a final test, I tried the Fedora-Minimal-Rawhide-20220717.n.0.aarch64.raw.xz 
and Fedora-KDE-Rawhide-20220717.n.0.aarch64.raw.xz images on a USB flash stick 
instead of on a uSD card.  Both worked perfectly.

So, there is something bizarre happening with uSD cards with 

[fedora-arm] Re: Question: kernelopts on raspberry pi

[Steven A. Falco]

On 9/9/20 6:57 PM, Stuart D Gathman wrote:

On Wed, 9 Sep 2020, Steven A. Falco wrote:


But that doesn't seem to have any effect.  After booting, I still see:

# cat /proc/cmdline
BOOT_IMAGE=(hd1,msdos2)/vmlinuz-5.8.0-1.fc33.aarch64 
root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro

Where does the kernel get its command line on RPi?


I have an rPi3 and Pinebook.  Same place as Intel.

   grubby --info=DEFAULT

shows default boot

   grubby --info=ALL

to show all kernels

https://fedoramagazine.org/setting-kernel-command-line-arguments-with-fedora-30/

Here is Pinebook:

   # grubby --info=DEFAULT
   index=0
   kernel="/boot/vmlinuz-5.8.6-201.fc32.aarch64"
   args="ro"
   root="/dev/mapper/pinevg-f32"
   initrd="/boot/initramfs-5.8.6-201.fc32.aarch64.img"
   title="Fedora (5.8.6-201.fc32.aarch64) 32 (Thirty Two)"
   id="8814846c48db47e2bb50c252d4bc0a29-5.8.6-201.fc32.aarch64"

Note that root and args are defaulted to kernelopts in grubenv.

   # grub2-editenv list
   saved_entry=8814846c48db47e2bb50c252d4bc0a29-5.8.6-201.fc32.aarch64
   kernelopts=root=/dev/mapper/pinevg-f32 ro
   boot_success=1
   boot_indeterminate=0



Thanks.  I've learned a little more.  I have a Pi that is running F32.  It works 
correctly - if I add "selinux=0" to /etc/default/grub, then run grub2-mkconfig, 
then reboot, then I do see the selinux=0 parameter in /proc/cmdline.  However, on a 
second Pi that is running Rawhide, the exact same steps don't work.

One clue may be that when I run grub2-mkconfig on Rawhide, I get a warning:

pif# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
/etc/grub.d/30_uefi-firmware: line 34: warning: command substitution: ignored 
null byte in input
done

This warning is not present in F32.

One other bit of info: on the Rawhide system, if I edit 
/boot/loader/entries/1cba1c70b65f41128fb4b94953fc3741-5.8.0-1.fc33.aarch64.conf 
and put the selinux=0 setting in that file, then it works, i.e. I do see 
selinux=0 on /proc/cmdline after a reboot.

I'll have to try reloading the Rawhide system with a fresh image to see if that 
makes any difference.

Steve
___
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: Question: kernelopts on raspberry pi

[Steven A. Falco]

I tried adding:

GRUB_CMDLINE_LINUX="selinux=0"

to /etc/default/grub, then ran:

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

That successfully added the following to grub.cfg:

if [ -z "${kernelopts}" ]; then
  set kernelopts="root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro selinux=0 "
fi

However, /boot/efi/EFI/fedora/grubenv didn't contain "selinux=0".  So I 
manually added that via:

grub2-editenv - set "kernelopts=BOOT_IMAGE=(hd1,msdos2)/vmlinuz-5.8.0-1.fc33.aarch64 
root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro selinux=0 "

But that doesn't seem to have any effect.  After booting, I still see:

# cat /proc/cmdline
BOOT_IMAGE=(hd1,msdos2)/vmlinuz-5.8.0-1.fc33.aarch64 
root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro

Where does the kernel get its command line on RPi?

Steve

On 9/8/20 3:56 PM, Steven A. Falco wrote:

I'd like to add a kernel command line option (selinux=0) on a raspberry pi.

Normally, I'd edit /etc/default/grub and append that setting to the 
GRUB_CMDLINE_LINUX variable, then run grub2-mkconfig to regenerate the 
/boot/efi/EFI/fedora/grub.cfg file.

However, on the pi, /etc/default/grub doesn't have a GRUB_CMDLINE_LINUX 
variable defined.  Yet, I do see this line in /boot/efi/EFI/fedora/grub.cfg:

set kernelopts="root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro  "

To accomplish what I want, should I add a new GRUB_CMDLINE_LINUX variable to 
/etc/default/grub, for example:

GRUB_CMDLINE_LINUX="root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro selinux=0"

Or is there a more correct way to do this?

 Steve

___
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: i2c-tools & serial port

[Steven A. Falco]

The script is asking you to use apt-get, which is not a Fedora tool - Fedora uses dnf.  
You might try "dnf install python3-i2c-tools", to see if it helps with the I2C 
communications.

But really, the path of least resistance is to use the OS they wrote their 
tools for.

Steve

On 7/26/20 12:31 PM, ng0...@gmail.com wrote:

Good advice. I tried but adding the uart option didn't work. I suspect we have 
two problems overlaid. It coudl be a problem with the python version in 
addition?

$ sudo i2cset -y 1 0x60 0x08 0xbb && sleep 1 && sudo python 
PCF4_serial0_9600_FU1.0.py <http://PCF4_serial0_9600_FU1.0.py> -v -f PiCoolFAN_V1_4.hex
   File "PCF4_serial0_9600_FU1.0.py <http://PCF4_serial0_9600_FU1.0.py>", line 
120
     print 'WARNING: I2C support is missing. Please install smbus support for 
python to enable additional functionality! (sudo apt-get install python-smbus)'
           ^
SyntaxError: invalid syntax

On Sun, Jul 26, 2020 at 5:29 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

You can enable the serial port by adding this line:

enable_uart=1

in the file /boot/efi/config.txt and rebooting the Pi.  If that doesn't 
work for you, you might consider temporarily loading a copy of Raspbian on an 
SD card just to do the fan setup, since that is what the hardware manufacturer 
expects you to be using.

After configuring the fan, then put your Fedora SD card back in.  The 
manual you linked to says that the settings are stored in EEPROM, so they 
should be remembered when you switch back to Fedora.

         Steve


On 7/26/20 7:40 AM, ng0...@gmail.com <mailto:ng0...@gmail.com> wrote:
 > Sorry, I forgot - here is what we are talking about:
 >
 > https://pimodules.com/picoolfan4
 >
 > https://pimodules.com/download/picoolfan4-user-manual
 > see also attached.
 >
 > Yes, Raspian, although not mentioned explicitly in the manual.
 >
 > On Sun, Jul 26, 2020 at 12:12 PM Peter Robinson mailto:pbrobin...@gmail.com> <mailto:pbrobin...@gmail.com 
<mailto:pbrobin...@gmail.com>>> wrote:
 >
 >      > I need to update the firmware of a fan for the RPi4 and given the 
below instructions in Raspbian. I also installed
 >      >
 >      > sudo dnf -y install i2c-tools
 >      > sudo dnf -y install python3-i2c-tools
 >      >
 >      > but the firmware update fails. I guess, it is because of the 
serial port not being enabled. Any advice?
 >
 >     Can you actually link to the hardware and the instructions you're
 >     attempting to follow/convert, it saves people actually trying to
 >     guess/interpret what that may be.
 >
 >      > Thanks, Thomas
 >      >
 >      > In order to use bootloader, user need to have activated and free 
Serial Port on Raspberry Pi®. The below
 >      > procedure is showing how to make sure that Serial Port is free 
and available for Bootloader process.
 >      > sudo raspi-config
 >      > Select -> Interfacing Options
 >      > 1. IC Kernel ON
 >      > 2. Serial option to enable UART
 >      > Then it will ask for login shell to be accessible over Serial, 
select No shown as follows.
 >      > At the end, it will ask for enabling Hardware Serial port, select 
Yes,
 >      > Then, reboot the Raspberry Pi®!!
 >
 >     I take it they're the details for Raspbian?
 >
 >
 > ___
 > arm mailing list -- arm@lists.fedoraproject.org 
<mailto:arm@lists.fedoraproject.org>
 > To unsubscribe send an email to arm-le...@lists.fedoraproject.org 
<mailto: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 
<mailto:arm@lists.fedoraproject.org>
To unsubscribe send an email to arm-le...@lists.fedoraproject.org 
<mailto: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://d

[fedora-arm] Re: i2c-tools & serial port

[Steven A. Falco]

You can enable the serial port by adding this line:

enable_uart=1

in the file /boot/efi/config.txt and rebooting the Pi.  If that doesn't work 
for you, you might consider temporarily loading a copy of Raspbian on an SD 
card just to do the fan setup, since that is what the hardware manufacturer 
expects you to be using.

After configuring the fan, then put your Fedora SD card back in.  The manual 
you linked to says that the settings are stored in EEPROM, so they should be 
remembered when you switch back to Fedora.

Steve


On 7/26/20 7:40 AM, ng0...@gmail.com wrote:

Sorry, I forgot - here is what we are talking about:

https://pimodules.com/picoolfan4

https://pimodules.com/download/picoolfan4-user-manual
see also attached.

Yes, Raspian, although not mentioned explicitly in the manual.

On Sun, Jul 26, 2020 at 12:12 PM Peter Robinson mailto:pbrobin...@gmail.com>> wrote:

 > I need to update the firmware of a fan for the RPi4 and given the below 
instructions in Raspbian. I also installed
 >
 > sudo dnf -y install i2c-tools
 > sudo dnf -y install python3-i2c-tools
 >
 > but the firmware update fails. I guess, it is because of the serial port 
not being enabled. Any advice?

Can you actually link to the hardware and the instructions you're
attempting to follow/convert, it saves people actually trying to
guess/interpret what that may be.

 > Thanks, Thomas
 >
 > In order to use bootloader, user need to have activated and free Serial 
Port on Raspberry Pi®. The below
 > procedure is showing how to make sure that Serial Port is free and 
available for Bootloader process.
 > sudo raspi-config
 > Select -> Interfacing Options
 > 1. IC Kernel ON
 > 2. Serial option to enable UART
 > Then it will ask for login shell to be accessible over Serial, select No 
shown as follows.
 > At the end, it will ask for enabling Hardware Serial port, select Yes,
 > Then, reboot the Raspberry Pi®!!

I take it they're the details for Raspbian?


___
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: Raspberry Pi 4 / Fedora 32 / Kernel 5.6

[Steven A. Falco]

They change often.  Right now the latest is 
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Spins/aarch64/images/Fedora-Minimal-Rawhide-20200422.n.0.aarch64.raw.xz

Just take the latest Minimal and you should be ok.

Steve

On 4/22/20 6:06 AM, ng0...@gmail.com wrote:

@gnome-desktop-environment

seems not to be available on Fedora-Minimal-Rawhide-20200421.n.0.aarch64.raw.xz 
<https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Spins/aarch64/images/Fedora-Minimal-Rawhide-20200421.n.0.aarch64.raw.xz>
from 
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Spins/aarch64/images/

Any ideas? Much appreciate, Thomas

On Fri, Apr 17, 2020 at 8:47 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

On 4/17/20 12:23 PM, ng0...@gmail.com <mailto:ng0...@gmail.com> wrote:
 > Fedora-Workstation-32-20200416.n.0.aarch64.raw.xz
 >
 > I was not able to see the RPI 4 Model B (0x??) hex code, it scrolls 
too fast. How to find it on a running system?
 >
 > As recommended by other, I will go the minimal-first-way. But I do not 
know how to add a graphics package group e.g. Gnome?

This should install gnome:

dnf install @gnome-desktop-environment

A few other things that I found helpful:

1) I got lots of disconnects with 1 Gbps Ethernet, so I added the following 
to root's crontab (via crontab -e) to force the ethernet down to 100 Mbps:

@reboot sleep 10 ; /sbin/ethtool -s eth0 speed 100 duplex full

2) I was not able to login on the console serial port, because plymouth was 
interfering with agetty.  I removed plymouth via:

dnf remove plymouth

3) I had a problem with overscan - basically I had a black border all 
around the screen.  I fixed that by editing /boot/efi/config.txt and adding 
this line at the end of the file:

disable_overscan=1

         Steve

 >
 > Appreciate your help.
 >
 >
 > On Fri, Apr 17, 2020 at 1:17 PM Peter Robinson mailto:pbrobin...@gmail.com> <mailto:pbrobin...@gmail.com 
<mailto:pbrobin...@gmail.com>>> wrote:
 >
 >     On Fri, Apr 17, 2020 at 12:13 PM mailto:ng0...@gmail.com> 
<mailto:ng0...@gmail.com <mailto:ng0...@gmail.com>>> wrote:
 >      >
 >      > Thanks for that! In one of latest images it gets stuck at the 
point shown in the attached screenshot.
 >
 >     What image are you using, full file name please.
 >
 >     What revision of the hardware do you have? You should have a line at
 >     the early U-Boot phase that looks something like:
 >     RPI 4 Model B (0xc03111)
 >
 >     I'm interested in the hex values at the end.
 >
 >      > Good to have your clarification on RPi4 support in the Kernel.
 >      >
 >      > Thomas
 >      >
 >      > On Fri, Apr 17, 2020 at 12:01 PM Peter Robinson mailto:pbrobin...@gmail.com> <mailto:pbrobin...@gmail.com 
<mailto:pbrobin...@gmail.com>>> wrote:
 >      >>
 >      >> Hi Thomas,
 >      >>
 >      >> > Hi, testing of daily images from 
https://dl.fedoraproject.org/pub/fedora-secondary/development/32/Workstation/aarch64/images/
 >      >>
 >      >> > Raspberry Pi 4 defies the keyboard.
 >      >>
 >      >> I'm not sure what you mean by defies in this context? They 
keyboard
 >      >> doesn't work? At what point are you having issues. There is no 
support
 >      >> for USB (actually the PCIe), hence keyboards, in the U-Boot 
firmware
 >      >> which means it won't work in grub or the early boot process. 
Once it
 >      >> gets to Linux such as the login prompt they keyboard should work 
find
 >      >> as there is USB support.
 >      >>
 >      >> > I have been under the assumption that 5.6 has support 
built-in? Any ideas?
 >      >>
 >      >> Support for what exactly? Support for a device such as the RPi4 
is not
 >      >> a binary thing. There is initial support and enablement so it's 
useful
 >      >> for a number of situations but the support is far from complete 
and
 >      >> hence while for a it works for a lot of use cases we don't 
officially
 >      >> support the RPi4 yet because the HW enablement is incomplete.
 >      >>
 >      >> Peter
 >
 >
 > ___
 > arm mailing list -- arm@lists.fedoraproject.org 
<mailto:arm@lists.fedoraproject.org>
 > To unsubscribe send an email to arm-le...@lists.fedoraproject.org 
<mailto:arm-le...@l

[fedora-arm] Re: Raspberry Pi 4 / Fedora 32 / Kernel 5.6

[Steven A. Falco]

On 4/17/20 12:23 PM, ng0...@gmail.com wrote:

Fedora-Workstation-32-20200416.n.0.aarch64.raw.xz

I was not able to see the RPI 4 Model B (0x??) hex code, it scrolls too 
fast. How to find it on a running system?

As recommended by other, I will go the minimal-first-way. But I do not know how 
to add a graphics package group e.g. Gnome?


This should install gnome:

dnf install @gnome-desktop-environment

A few other things that I found helpful:

1) I got lots of disconnects with 1 Gbps Ethernet, so I added the following to 
root's crontab (via crontab -e) to force the ethernet down to 100 Mbps:

@reboot sleep 10 ; /sbin/ethtool -s eth0 speed 100 duplex full

2) I was not able to login on the console serial port, because plymouth was 
interfering with agetty.  I removed plymouth via:

dnf remove plymouth

3) I had a problem with overscan - basically I had a black border all around 
the screen.  I fixed that by editing /boot/efi/config.txt and adding this line 
at the end of the file:

disable_overscan=1

Steve



Appreciate your help.


On Fri, Apr 17, 2020 at 1:17 PM Peter Robinson mailto:pbrobin...@gmail.com>> wrote:

On Fri, Apr 17, 2020 at 12:13 PM mailto:ng0...@gmail.com>> wrote:
 >
 > Thanks for that! In one of latest images it gets stuck at the point 
shown in the attached screenshot.

What image are you using, full file name please.

What revision of the hardware do you have? You should have a line at
the early U-Boot phase that looks something like:
RPI 4 Model B (0xc03111)

I'm interested in the hex values at the end.

 > Good to have your clarification on RPi4 support in the Kernel.
 >
 > Thomas
 >
 > On Fri, Apr 17, 2020 at 12:01 PM Peter Robinson mailto:pbrobin...@gmail.com>> wrote:
 >>
 >> Hi Thomas,
 >>
 >> > Hi, testing of daily images from 
https://dl.fedoraproject.org/pub/fedora-secondary/development/32/Workstation/aarch64/images/
 >>
 >> > Raspberry Pi 4 defies the keyboard.
 >>
 >> I'm not sure what you mean by defies in this context? They keyboard
 >> doesn't work? At what point are you having issues. There is no support
 >> for USB (actually the PCIe), hence keyboards, in the U-Boot firmware
 >> which means it won't work in grub or the early boot process. Once it
 >> gets to Linux such as the login prompt they keyboard should work find
 >> as there is USB support.
 >>
 >> > I have been under the assumption that 5.6 has support built-in? Any 
ideas?
 >>
 >> Support for what exactly? Support for a device such as the RPi4 is not
 >> a binary thing. There is initial support and enablement so it's useful
 >> for a number of situations but the support is far from complete and
 >> hence while for a it works for a lot of use cases we don't officially
 >> support the RPi4 yet because the HW enablement is incomplete.
 >>
 >> Peter


___
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: Raspberry Pi 4 / Fedora 32 / Kernel 5.6

[Steven A. Falco]

On 4/17/20 7:34 AM, Frantisek Zatloukal wrote:

On Fri, Apr 17, 2020, 13:21 Michael Young mailto:m.a.yo...@durham.ac.uk>> wrote:

On Fri, 17 Apr 2020, ng0...@gmail.com  wrote:

 > Thanks for that! In one of latest images it gets stuck at the point 
shown in
 > the attached screenshot.
 > Good to have your clarification on RPi4 support in the Kernel.


I hit the same issue while trying to run F32 Workstation aarch64 (RC1.3) on my 
rpi4.

I'll add some more information once I get to the rpi4. One way to workaround 
this is to use Minimal aarch64 raw.xz and then install workstation package 
group...


I had that experience too.  Start with the Minimal image, which should install 
and boot just fine.  Then add a graphics package group of your choice.  I'm 
using KDE on my Pi 4.

Steve
___
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: What is the latest arm64 image that people have successfully run on the RPi4?

[Steven A. Falco]

On 3/4/20 10:17 AM, Peter Robinson wrote:

Thanks Paul.  I just tried Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz on 
my RPi4 but it behaves the same as I previously reported.  There is a 5 minute 
pause after the eth0 link becomes ready and I then wind up in the dracut 
emergency shell.


That's two different an unrelated problems. Is the pause with ethernet
before the grub2 prompt?


No - the pause is in the kernel.  In an earlier email in this chain, I attached a file 
"session.log".  Here is part of that file - note that the eth0 link comes up at 
around the 28 second mark.  Then there is a 5 minute pause where nothing appears to be 
happening, and then at the 321 second mark, dracut starts printing timeout messages.


I don't read attachments, much less compressed globs of information,
sorry it takes too much time to search for a needle in a haystack.

Ok - I provided the attachment because people often want the full details 
rather than a summary.  Next time I'll be sure to provide both.


[   23.467681] raspberrypi-firmware soc:firmware: Request 0x00028001 returned 
status 0x
[   23.969125] bcmgenet fd58.ethernet: configuring instance for external 
RGMII (RX delay)
[   23.986485] bcmgenet fd58.ethernet eth0: Link is Down
[   27.394605] systemd-udevd (515) used greatest stack depth: 11696 bytes left
[   28.172043] bcmgenet fd58.ethernet eth0: Link is Up - 1Gbps/Full - flow 
control rx/tx
[   28.186922] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   28.241941] NetworkManager (549) used greatest stack depth: 10272 bytes left
[  234.092146] random: crng init done
[  234.101385] random: 6 urandom warning(s) missed due to ratelimiting
[  321.541094] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  322.921646] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts

The "Warning: dracut-initqueue timeout" messages repeat for a quite a while, 
then at the 466 second mark we get the following:

[  464.979853] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  466.181960] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  466.183175] dracut-initqueue[522]: Warning: Could not boot.
Starting Setup Virtual Console...
[  OK  ] Started Setup Virtual Console.
[  466.475450] audit: type=1130 audit(1580894910.719:14): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  466.475689] audit: type=1131 audit(1580894910.719:15): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Starting Dracut Emergency Shell...
[  466.661153] audit: type=1131 audit(1580894910.899:16): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Warning: /dev/disk/by-uuid/369ee56a-5038-4040-b16e-f127f8a81ba0 does not exist


What storage/medium are you booting off? Unless it's a network style
of storage it's actually unlikely to be an issue here with the network
side of things. More likely storage.


I have a 4 GB RPi4 with an SD card.  I think you are correct that it looks more 
like a storage issue.

Also what rev of the RPi4 hardware do you have? If it's one of the
refresh versions there may be an issue around a firmware <-> kernel
interaction. I should have a new rev 2Gb version in the next day or
so, there's a proposed patch under review upstream but I think it
might need a newer firmware as well. I'll be testing once I have all
the pieces available.


Great.  Thanks for checking.  Here is the hardware data for my board:

Hardware: BCM2835
Revision: c03112
Serial  : 10004463a5a7
Model   : Raspberry Pi 4 Model B Rev 1.2

Based on the revision-codes page [1], this would be the latest revision of the 
4 GB RPi4 board.


Yes, looks like a rev 1.2 and that could possibly have this problem.

Could you file a bug with the following link and let me know what the RHBZ # is?
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=32=kernel



The bug number is 1810134 [1].  I have to run to an appointment right now, but 
I'll add the logs to the bug report when I return.

Steve

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1810134
___
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: What is the latest arm64 image that people have successfully run on the RPi4?

[Steven A. Falco]

On 3/4/20 8:34 AM, Peter Robinson wrote:

Thanks Paul.  I just tried Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz on 
my RPi4 but it behaves the same as I previously reported.  There is a 5 minute 
pause after the eth0 link becomes ready and I then wind up in the dracut 
emergency shell.


That's two different an unrelated problems. Is the pause with ethernet
before the grub2 prompt?


No - the pause is in the kernel.  In an earlier email in this chain, I attached a file 
"session.log".  Here is part of that file - note that the eth0 link comes up at 
around the 28 second mark.  Then there is a 5 minute pause where nothing appears to be 
happening, and then at the 321 second mark, dracut starts printing timeout messages.


I don't read attachments, much less compressed globs of information,
sorry it takes too much time to search for a needle in a haystack.

Ok - I provided the attachment because people often want the full details 
rather than a summary.  Next time I'll be sure to provide both.


[   23.467681] raspberrypi-firmware soc:firmware: Request 0x00028001 returned 
status 0x
[   23.969125] bcmgenet fd58.ethernet: configuring instance for external 
RGMII (RX delay)
[   23.986485] bcmgenet fd58.ethernet eth0: Link is Down
[   27.394605] systemd-udevd (515) used greatest stack depth: 11696 bytes left
[   28.172043] bcmgenet fd58.ethernet eth0: Link is Up - 1Gbps/Full - flow 
control rx/tx
[   28.186922] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   28.241941] NetworkManager (549) used greatest stack depth: 10272 bytes left
[  234.092146] random: crng init done
[  234.101385] random: 6 urandom warning(s) missed due to ratelimiting
[  321.541094] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  322.921646] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts

The "Warning: dracut-initqueue timeout" messages repeat for a quite a while, 
then at the 466 second mark we get the following:

[  464.979853] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  466.181960] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  466.183175] dracut-initqueue[522]: Warning: Could not boot.
   Starting Setup Virtual Console...
[  OK  ] Started Setup Virtual Console.
[  466.475450] audit: type=1130 audit(1580894910.719:14): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  466.475689] audit: type=1131 audit(1580894910.719:15): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
   Starting Dracut Emergency Shell...
[  466.661153] audit: type=1131 audit(1580894910.899:16): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Warning: /dev/disk/by-uuid/369ee56a-5038-4040-b16e-f127f8a81ba0 does not exist


What storage/medium are you booting off? Unless it's a network style
of storage it's actually unlikely to be an issue here with the network
side of things. More likely storage.


I have a 4 GB RPi4 with an SD card.  I think you are correct that it looks more 
like a storage issue.

Also what rev of the RPi4 hardware do you have? If it's one of the
refresh versions there may be an issue around a firmware <-> kernel
interaction. I should have a new rev 2Gb version in the next day or
so, there's a proposed patch under review upstream but I think it
might need a newer firmware as well. I'll be testing once I have all
the pieces available.


Great.  Thanks for checking.  Here is the hardware data for my board:

Hardware: BCM2835
Revision: c03112
Serial  : 10004463a5a7
Model   : Raspberry Pi 4 Model B Rev 1.2

Based on the revision-codes page [1], this would be the latest revision of the 
4 GB RPi4 board.

Steve

[1] 
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
___
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: What is the latest arm64 image that people have successfully run on the RPi4?

[Steven A. Falco]

On 3/3/20 5:09 PM, Peter Robinson wrote:

I just tried Fedora-Minimal-Rawhide-20200302.n.1.aarch64.raw.xz and it worked
properly.  However, Fedora-Workstation-Rawhide-20200302.n.1.aarch64.raw.xz
has a problem, as shown by the attached session.log file.  I let it run for
a long period of time, and after 5 or 10 minutes it wound up at a dracut
emergency prompt.  Please note that this was a fresh install - the only
thing I changed was to enable the console uart in config.txt so I could log
the output.


We're a few weeks out from Fedora 32 Beta, so Rawhide is getting very little
attention right now. Both of these are pre-release as well, so issues are
somewhat expected until GA.

The last nominated nightly was 20200225.n.0, I tested both Minimal and
Workstation images for AArch64 and they should boot as expected.


Thanks Paul.  I just tried Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz on 
my RPi4 but it behaves the same as I previously reported.  There is a 5 minute 
pause after the eth0 link becomes ready and I then wind up in the dracut 
emergency shell.


That's two different an unrelated problems. Is the pause with ethernet
before the grub2 prompt?


No - the pause is in the kernel.  In an earlier email in this chain, I attached a file 
"session.log".  Here is part of that file - note that the eth0 link comes up at 
around the 28 second mark.  Then there is a 5 minute pause where nothing appears to be 
happening, and then at the 321 second mark, dracut starts printing timeout messages.

[   23.467681] raspberrypi-firmware soc:firmware: Request 0x00028001 returned 
status 0x
[   23.969125] bcmgenet fd58.ethernet: configuring instance for external 
RGMII (RX delay)
[   23.986485] bcmgenet fd58.ethernet eth0: Link is Down
[   27.394605] systemd-udevd (515) used greatest stack depth: 11696 bytes left
[   28.172043] bcmgenet fd58.ethernet eth0: Link is Up - 1Gbps/Full - flow 
control rx/tx
[   28.186922] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   28.241941] NetworkManager (549) used greatest stack depth: 10272 bytes left
[  234.092146] random: crng init done
[  234.101385] random: 6 urandom warning(s) missed due to ratelimiting
[  321.541094] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  322.921646] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts

The "Warning: dracut-initqueue timeout" messages repeat for a quite a while, 
then at the 466 second mark we get the following:

[  464.979853] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  466.181960] dracut-initqueue[522]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  466.183175] dracut-initqueue[522]: Warning: Could not boot.
 Starting Setup Virtual Console...
[  OK  ] Started Setup Virtual Console.
[  466.475450] audit: type=1130 audit(1580894910.719:14): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  466.475689] audit: type=1131 audit(1580894910.719:15): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
 Starting Dracut Emergency Shell...
[  466.661153] audit: type=1131 audit(1580894910.899:16): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Warning: /dev/disk/by-uuid/369ee56a-5038-4040-b16e-f127f8a81ba0 does not exist

Generating "/run/initramfs/rdsosreport.txt"


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.


dracut:/#

Steve
___
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: What is the latest arm64 image that people have successfully run on the RPi4?

[Steven A. Falco]

On 3/3/20 3:12 PM, Paul Whalen wrote:


Hi Steve,


I just tried Fedora-Minimal-Rawhide-20200302.n.1.aarch64.raw.xz and it worked
properly.  However, Fedora-Workstation-Rawhide-20200302.n.1.aarch64.raw.xz
has a problem, as shown by the attached session.log file.  I let it run for
a long period of time, and after 5 or 10 minutes it wound up at a dracut
emergency prompt.  Please note that this was a fresh install - the only
thing I changed was to enable the console uart in config.txt so I could log
the output.


We're a few weeks out from Fedora 32 Beta, so Rawhide is getting very little
attention right now. Both of these are pre-release as well, so issues are
somewhat expected until GA.

The last nominated nightly was 20200225.n.0, I tested both Minimal and
Workstation images for AArch64 and they should boot as expected.


Thanks Paul.  I just tried Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz on 
my RPi4 but it behaves the same as I previously reported.  There is a 5 minute 
pause after the eth0 link becomes ready and I then wind up in the dracut 
emergency shell.

No matter - I have a running setup that started out as Rawhide-20200127.  I was 
just trying a later version to see how it behaved.  And I know it isn't ready 
for prime-time yet.  I pasted the last few console message below for reference.

Steve

[  317.658740] dracut-initqueue[520]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  318.517540] dracut-initqueue[520]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  318.518353] dracut-initqueue[520]: Warning: Could not boot.
 Starting Setup Virtual Console...
[  OK  ] Star[  318.628289] kauditd_printk_skb: 2 callbacks suppressed
ted   318.628297] audit: type=1130 audit(1580894767.719:14): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
1;39mSet[  318.628417] audit: type=1131 audit(1580894767.729:15): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
up Virtual Console.
 Starting Dracut Emergency Shell...
[  318.753718] audit: type=1131 audit(1580894767.849:16): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Warning: /dev/disk/by-uuid/eecf14ed-eb46-4b72-acd6-ef009a3e4f30 does not exist

Generating "/run/initramfs/rdsosreport.txt"


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.


dracut:/# uname -a
Linux localhost 5.6.0-0.rc3.git0.1.fc32.aarch64 #1 SMP Mon Feb 24 21:17:09 UTC 
2020 aarch64 aarch64 aarch64 GNU/Linux
dracut:/# cat /etc/os-release
NAME="dracut"
VERSION="32 (Workstation Edition) dracut-049-27.git20181204.fc32.2"
ID=dracut
VERSION_ID=049-27.git20181204.fc32.2
PRETTY_NAME="Fedora 32 (Workstation Edition) dracut-049-27.git20181204.fc32.2 
(Initramfs)"
ANSI_COLOR="0;34"
dracut:/#
___
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: What is the latest arm64 image that people have successfully run on the RPi4?

[Steven A. Falco]

On 3/3/20 1:12 PM, Peter Robinson wrote:

On Tue, Mar 3, 2020 at 5:56 PM Steven A. Falco  wrote:


On 3/3/20 9:38 AM, Paul Kennedy wrote:

I've just tried the latest F32 and Rawhide workstation images, but neither 
successfully booted for me. Both hung after eth0 came up, then sat for several 
minutes before logging about dracut timeouts and then a recovery shell (mouse 
and keyboard never worked). I've seen that someone had success with a 
Fedora-Workstation-Rawhide-20200110.n.0.aarch64.raw.xz image - has anyone 
successfully booted from anything newer?


The new images do seem to be broken.  I just tried the latest one, and as you 
have seen, the boot process hangs at the Ethernet initialization point.


Kernel or firmware stage? The firmware stage is slow but it does go through.


I just tried Fedora-Minimal-Rawhide-20200302.n.1.aarch64.raw.xz and it worked 
properly.  However, Fedora-Workstation-Rawhide-20200302.n.1.aarch64.raw.xz has 
a problem, as shown by the attached session.log file.  I let it run for a long 
period of time, and after 5 or 10 minutes it wound up at a dracut emergency 
prompt.  Please note that this was a fresh install - the only thing I changed 
was to enable the console uart in config.txt so I could log the output.


I also tried Fedora-Minimal-Rawhide-20200214.n.1.aarch64.raw.xz, which is the 
latest one that I have saved, and it boots, but it won't let me log in on the 
console.  I think that is because plymouth is fighting with agetty.

I do have an RPi4 running 64-bit Fedora pretty well, including a KDE desktop.  
But I started with an earlier image, and it took a lot of fiddling around to 
get there.

I have another RPi4 running Manjaro, and it provides a good 64-bit experience right out 
of the box.  You might want to try that until "Fedora on RPi4" matures.


Other distros are off topic for the list, please keep discussion to
topic, if you wish to discuss them there's other forums.


Sorry - I'll use private email in future.

Steve




U-Boot 2020.04-rc3 (Feb 26 2020 - 00:00:00 +)

DRAM:  3.9 GiB
RPI 4 Model B (0xc03112)
MMC:   emmc2@7e34: 0, mmcnr@7e30: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

In:serial
Out:   vidconsole
Err:   vidconsole
Net:   eth0: genet@7d58
Hit any key to stop autoboot:  2  1  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/fedora/grubaa64.efi
Found DTB mmc 0:2 /dtb/broadcom/bcm2711-rpi-4-b.dtb
22650 bytes read in 24 ms (920.9 KiB/s)
Scanning disk em...@7e34.blk...
Card did not respond to voltage select!
Scanning disk mm...@7e30.blk...
Disk mm...@7e30.blk not ready
Found 4 disks
BootOrder not defined
EFI boot manager: Cannot load any image
2620152 bytes read in 194 ms (12.9 MiB/s)
genet@7d58 Waiting for PHY auto negotiation to complete. done
Use the ▲ and ▼ keys to change the selection.   
  Press 'e' to edit the selected item, or 'c' for a command prompt.  Fedora (5.6.0-0.rc3.git3.1.fc33.aarch64) 33 (Rawhide)  Sy

[fedora-arm] Re: What is the latest arm64 image that people have successfully run on the RPi4?

[Steven A. Falco]

On 3/3/20 9:38 AM, Paul Kennedy wrote:

I've just tried the latest F32 and Rawhide workstation images, but neither 
successfully booted for me. Both hung after eth0 came up, then sat for several 
minutes before logging about dracut timeouts and then a recovery shell (mouse 
and keyboard never worked). I've seen that someone had success with a 
Fedora-Workstation-Rawhide-20200110.n.0.aarch64.raw.xz image - has anyone 
successfully booted from anything newer?


The new images do seem to be broken.  I just tried the latest one, and as you 
have seen, the boot process hangs at the Ethernet initialization point.

I also tried Fedora-Minimal-Rawhide-20200214.n.1.aarch64.raw.xz, which is the 
latest one that I have saved, and it boots, but it won't let me log in on the 
console.  I think that is because plymouth is fighting with agetty.

I do have an RPi4 running 64-bit Fedora pretty well, including a KDE desktop.  
But I started with an earlier image, and it took a lot of fiddling around to 
get there.

I have another RPi4 running Manjaro, and it provides a good 64-bit experience right out 
of the box.  You might want to try that until "Fedora on RPi4" matures.

Steve


__
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] Question: u-boot 2020.04 on RPi4

[Steven A. Falco]

I noticed that there was a new u-boot image for the RPi4: 
uboot-images-armv8-2020.04-0.2.rc1.fc32.noarch.rpm so I gave it a try.  With 
that u-boot image, once Linux booted, ethernet was not functional.  It appeared 
to come up, but it couldn't do dhcp to get an address.  I tried applying an 
address manually, but that didn't work either.

I reverted to the uboot-images-armv8-2020.01-1.fc32.noarch.rpm version and 
ethernet worked properly.

I then tried rebuilding u-boot 2020.04-0.2.rc1 from source, but without the 
"Ethernet-support-for-Raspberry-Pi-4.patch" file and ethernet worked.

Has anyone else observed this behavior?

Steve
___
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: [PATCH] kernel build of dtc tool

[Steven A. Falco]

On 1/30/20 3:39 AM, Peter Robinson wrote:

On Wed, Jan 29, 2020 at 4:45 PM Steven A. Falco  wrote:


On 1/29/20 7:40 AM, Peter Robinson wrote:

I ran into a problem with multiple definition of yylloc in the dtc tool when 
trying to compile the kernel in rawhide via mock, because of a change in gcc10.

The attached patch allows me to build the dtc tool.

Where is the best place to submit this?  It should go into the upstream kernel, 
but Fedora may want the patch before then.  I'm not sure how to proceed.


I'm planning on pulling in the upstream patch shortly, I'm just
awaiting the review from upstream and I'm traveling ATM.


Just to be clear, are you saying that there is already an upstream patch, 
similar to the one I proposed?


A quick look on the list gave me the following:
https://www.spinics.net/lists/devicetree-compiler/msg02959.html


Interesting.  I didn't get the error Dirk had with adding "extern".  But since 
his patch was applied, I naturally won't submit mine.

Steve
___
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: [PATCH] kernel build of dtc tool

[Steven A. Falco]

On 1/29/20 7:40 AM, Peter Robinson wrote:

I ran into a problem with multiple definition of yylloc in the dtc tool when 
trying to compile the kernel in rawhide via mock, because of a change in gcc10.

The attached patch allows me to build the dtc tool.

Where is the best place to submit this?  It should go into the upstream kernel, 
but Fedora may want the patch before then.  I'm not sure how to proceed.


I'm planning on pulling in the upstream patch shortly, I'm just
awaiting the review from upstream and I'm traveling ATM.


Just to be clear, are you saying that there is already an upstream patch, 
similar to the one I proposed?

If so, then I don't need to submit mine upstream.

Steve
___
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] [PATCH] kernel build of dtc tool

[Steven A. Falco]

I ran into a problem with multiple definition of yylloc in the dtc tool when 
trying to compile the kernel in rawhide via mock, because of a change in gcc10.

The attached patch allows me to build the dtc tool.

Where is the best place to submit this?  It should go into the upstream kernel, 
but Fedora may want the patch before then.  I'm not sure how to proceed.

Steve
>From 2f98758ecbcb1fe2ae76167f45f27df202e7a455 Mon Sep 17 00:00:00 2001
From: "Steven A. Falco" 
Date: Tue, 28 Jan 2020 14:19:29 -0500
Subject: [PATCH] Correct multiple definition of yylloc

---
 scripts/dtc/dtc-lexer.l | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
index 5c6c3fd557d7..3f942ce7f26d 100644
--- a/scripts/dtc/dtc-lexer.l
+++ b/scripts/dtc/dtc-lexer.l
@@ -23,7 +23,7 @@ LINECOMMENT	"//".*\n
 #include "srcpos.h"
 #include "dtc-parser.tab.h"
 
-YYLTYPE yylloc;
+extern YYLTYPE yylloc;
 extern bool treesource_error;
 
 /* CAUTION: this will stop working if we ever use yyless() or yyunput() */
-- 
2.24.1

___
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: Adding an RTC module

[Steven A. Falco]

On 1/28/20 9:39 AM, Peter Robinson wrote:

On Tue, Jan 28, 2020 at 1:59 PM Steven A. Falco  wrote:


I'd like to add an RTC module to a Raspberry Pi.  I see that uboot has some 
support for device tree overlays, but if I'm reading the code correctly, it 
doesn't seem to be enabled for the Pi.

Is it possible to use device tree overlays at this point, or am I better off 
building a custom kernel?


Yes, mostly, but there's still a whole bunch of corner cases, for
Raspberry Pi we use the Firmware provided DT and not the kernel DT.
It's only really clean on aarch64 and completely doesn't work on RPi4
(yet another reason there's been no announcement around RPi4 support).


I see.  U-boot says it is using 0:2 /dtb/broadcom/bcm2711-rpi-4-b.dtb, and I've 
confirmed that:  If I hand-edit that dtb file to add the RTC (pcf8523@68) to 
the I2C bus (i2c@7e804000) it works - the RTC is reported as being managed by 
the kernel.  So it looks like the RPi4 is using the kernel device tree rather 
than the firmware one.

I have not been entirely successful rebuilding the kernel yet (using mock on 
the RPi4 itself).  The dtc portion of the build fails because of the gcc10 
change from -fcommon to -fno-common.  I need to tweak the kernel spec file to 
work around that, but my first attempt was a little too heavy-handed.  Seems 
that a lot of stuff needs -fno-common, but dtc needs -fcommon.

Steve
___
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] Adding an RTC module

[Steven A. Falco]

I'd like to add an RTC module to a Raspberry Pi.  I see that uboot has some 
support for device tree overlays, but if I'm reading the code correctly, it 
doesn't seem to be enabled for the Pi.

Is it possible to use device tree overlays at this point, or am I better off 
building a custom kernel?

Steve

___
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: RPi 4

[Steven A. Falco]

On 1/27/20 2:54 PM, Steven A. Falco wrote:

On 1/27/20 2:26 PM, YOUNG, MICHAEL A. wrote:

On Mon, 27 Jan 2020, Steven A. Falco wrote:


On 1/27/20 4:10 AM, M A Young wrote:


  On Sun, 26 Jan 2020, Dirk Streubel wrote:


  why is RPi 4 supported on Ubuntu early than in Fedora? Is there any
  different in kernel in Ubuntu?
  Yes, they use random vendor forks.

  Can you say something about the timetable? Would it be possible to use
  the
  PI4 with Fedora32, i mean official?

  Or it this to early?

  I have tested at at Friday with Rawhide at it has not worked. It always
  stop
  at the same point of the Installation.


  I was playing with my Pi4 running rawhide this at the weekend (though not
  necessarily expecting it to work) and I don't think it was reading the SD
  card after the boot started, and the keyboard and serial port didn't work
  either. The network card seemed to work (ie. lights flashing on the port)
  so I am guessing it might be possible to boot it with a network root disk
  and a remote login though I didn't try that.


Are you running 32-bit or 64-bit rawhide?  I am running 64-bit rawhide
(Fedora-Workstation-Rawhide-20200110.n.0.aarch64.raw.xz) on my RPi4.


I was trying with Fedora-Server-Rawhide-20200123.n.0.aarch64.raw.xz both
directly and having got it to boot on my Pi3 first (I rather doubt that
image is functional without some adjustment).


I suppose it is possible that something has been broken since I grabbed the 
20200110 build.  That image did work.

In my case, I see the grub menu, but it is badly messed up, because the escape 
codes are apparently not recognized.  There is then a several second pause, 
before the kernel starts loading.  The whole boot process takes about 2 minutes 
in my setup.

How far does it get when you try it?


I got curious, so I just downloaded 
Fedora-Xfce-Rawhide-20200127.n.0.aarch64.raw.xz and tried it.  It booted 
properly on my RPi4 (with 4 GB of ram).  I have a working desktop, and this 
time, I tried using wifi - it works too.

Steve
___
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: RPi 4

[Steven A. Falco]

On 1/27/20 2:26 PM, YOUNG, MICHAEL A. wrote:

On Mon, 27 Jan 2020, Steven A. Falco wrote:


On 1/27/20 4:10 AM, M A Young wrote:


  On Sun, 26 Jan 2020, Dirk Streubel wrote:


  why is RPi 4 supported on Ubuntu early than in Fedora? Is there any
  different in kernel in Ubuntu?
  Yes, they use random vendor forks.

  Can you say something about the timetable? Would it be possible to use
  the
  PI4 with Fedora32, i mean official?

  Or it this to early?

  I have tested at at Friday with Rawhide at it has not worked. It always
  stop
  at the same point of the Installation.


  I was playing with my Pi4 running rawhide this at the weekend (though not
  necessarily expecting it to work) and I don't think it was reading the SD
  card after the boot started, and the keyboard and serial port didn't work
  either. The network card seemed to work (ie. lights flashing on the port)
  so I am guessing it might be possible to boot it with a network root disk
  and a remote login though I didn't try that.


Are you running 32-bit or 64-bit rawhide?  I am running 64-bit rawhide
(Fedora-Workstation-Rawhide-20200110.n.0.aarch64.raw.xz) on my RPi4.


I was trying with Fedora-Server-Rawhide-20200123.n.0.aarch64.raw.xz both
directly and having got it to boot on my Pi3 first (I rather doubt that
image is functional without some adjustment).


I suppose it is possible that something has been broken since I grabbed the 
20200110 build.  That image did work.

In my case, I see the grub menu, but it is badly messed up, because the escape 
codes are apparently not recognized.  There is then a several second pause, 
before the kernel starts loading.  The whole boot process takes about 2 minutes 
in my setup.

How far does it get when you try it?

Steve
___
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: RPi 4

[Steven A. Falco]

On 1/27/20 10:56 AM, Fred van Zwieten wrote:

On Mon, Jan 27, 2020 at 4:33 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

On 1/27/20 4:10 AM, M A Young wrote:
 >
 > On Sun, 26 Jan 2020, Dirk Streubel wrote:
 >
 >> why is RPi 4 supported on Ubuntu early than in Fedora? Is there any
 >> different in kernel in Ubuntu?
 >> Yes, they use random vendor forks.
 >>
 >> Can you say something about the timetable? Would it be possible to use 
the
 >> PI4 with Fedora32, i mean official?
 >>
 >> Or it this to early?
 >>
 >> I have tested at at Friday with Rawhide at it has not worked. It always 
stop
 >> at the same point of the Installation.
 >
 > I was playing with my Pi4 running rawhide this at the weekend (though not
 > necessarily expecting it to work) and I don't think it was reading the SD
 > card after the boot started, and the keyboard and serial port didn't work
 > either. The network card seemed to work (ie. lights flashing on the port)
 > so I am guessing it might be possible to boot it with a network root disk
 > and a remote login though I didn't try that.

Are you running 32-bit or 64-bit rawhide?  I am running 64-bit rawhide 
(Fedora-Workstation-Rawhide-20200110.n.0.aarch64.raw.xz) on my RPi4.

It works well - mouse, keyboard, sd card, ethernet, basic HDMI are all 
good.  I did have to add one line to /boot/efi/config.txt:

disable_overscan=1

Without that, I had a black border on my monitor.  Once I added the above 
line and rebooted, the display looked good.  No accelerated graphics, but that 
is ok for me right now.


I only want to use the RPI4 as a server with UBI (and this aarch). Are you 
having 4 GB of usable memory (as a lot of people only get 3 GB)?

I also just read RPI4 HW support is in the just released 5.5 kernel. Wonder if 
5.5 will be in rawhide..


Rawhide already has kernel 5.5:

pif# uname -a
Linux pif.optonline.net 5.5.0-0.rc6.git2.1.fc32.aarch64 #1 SMP Wed Jan 15 
20:23:38 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

I have very close to the full 4 GB of ram available.  According to dmesg, 256K 
of ram is not available - it might be assigned to the video core:

Memory: 3833660K/4096000K available (12924K kernel code, 5450K rwdata, 6272K 
rodata, 6272K init, 26849K bss, 229572K reserved, 32768K cma-reserved)

Steve
___
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: RPi 4

[Steven A. Falco]

On 1/27/20 4:10 AM, M A Young wrote:


On Sun, 26 Jan 2020, Dirk Streubel wrote:


why is RPi 4 supported on Ubuntu early than in Fedora? Is there any
different in kernel in Ubuntu?
Yes, they use random vendor forks.

Can you say something about the timetable? Would it be possible to use the
PI4 with Fedora32, i mean official?

Or it this to early?

I have tested at at Friday with Rawhide at it has not worked. It always stop
at the same point of the Installation.


I was playing with my Pi4 running rawhide this at the weekend (though not
necessarily expecting it to work) and I don't think it was reading the SD
card after the boot started, and the keyboard and serial port didn't work
either. The network card seemed to work (ie. lights flashing on the port)
so I am guessing it might be possible to boot it with a network root disk
and a remote login though I didn't try that.


Are you running 32-bit or 64-bit rawhide?  I am running 64-bit rawhide 
(Fedora-Workstation-Rawhide-20200110.n.0.aarch64.raw.xz) on my RPi4.

It works well - mouse, keyboard, sd card, ethernet, basic HDMI are all good.  I 
did have to add one line to /boot/efi/config.txt:

disable_overscan=1

Without that, I had a black border on my monitor.  Once I added the above line 
and rebooted, the display looked good.  No accelerated graphics, but that is ok 
for me right now.

Steve
___
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: RPi 4 overscan

[Steven A. Falco]

On 1/22/20 12:13 AM, Peter Robinson wrote:

I'm running Fedora Rawhide on an RPi 4, and noticed that the video wasn't quite 
filling the monitor.  Looking at Xorg.0.log, I saw:


I need more context. What architecture, what image etc, what desktop
environment. Custom builds etc, as we've not yet announced anything
official around RPi4 and there's no accelerated graphics upstream yet
and on older gens this problem had never been reported.

I suspect you're using FB graphics.


You are correct that I am using FB graphics, but I don't think that is the problem.  I 
see the exact same behavior with both the Raspian and Manjaro operating systems on my 
RPi4.  In all cases, I have a large black border unless I put 
"disable_overscan=1" into /boot/config.txt.  I've also tried two different 
monitors, and two different HDMI cables.  It is always the same problem.

Perhaps this behavior is new to the RPi4, but I learned about this fix from 
[1], which is from 2013, so some people at least have had the issue on older 
hardware.

Here are the details of my Fedora setup:

Architecture: aarch64
Image: Fedora-Workstation-Rawhide-20200110.n.0.aarch64.raw.xz
Desktop: KDE (but problem shows up even on the login screen)

According to dmesg (copy attached), the system starts out on simple-framebuffer, then I 
see a message: "switching to EFI VGA from simple".  But like I said above, I 
don't think that is the issue.

I understand that there is no official RPi4 support in Fedora yet, and maybe 
the problem will go away when the accelerated graphics driver becomes 
available.  But since Raspian and Manjaro behave the same, I suspect the 
accelerated graphics driver will have the same problem.

[1] https://www.raspberrypi.org/forums/viewtopic.php?t=47152

Steve




Virtual size is 1824x984 (pitch 1824)

I fixed that by adding a line to /boot/efi/config.txt:

disable_overscan=1

Now, the video fits the monitor perfectly, and Xorg.0.log shows:

Virtual size is 1920x1080 (pitch 1920)

as expected.  /boot/efi/config.txt is owned by bcm283x-firmware.  Should I 
write a bug against bcm283x-firmware to add this line?

 Steve
___
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


[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
[0.00] Linux version 5.5.0-0.rc6.git2.1.fc32.aarch64 
(mockbu...@buildvm-aarch64-05.arm.fedoraproject.org) (gcc version 9.2.1 
20190827 (Red Hat 9.2.1-1) (GCC)) #1 SMP Wed Jan 15 20:23:38 UTC 2020
[0.00] Machine model: Raspberry Pi 4 Model B
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.80 by Das U-Boot
[0.00] efi:  SMBIOS=0x3cb51000  MEMRESERVE=0x3c8c2040 
[0.00] Reserved memory: created CMA memory pool at 0x3a00, 
size 32 MiB
[0.00] OF: reserved mem: initialized node linux,cma, compatible id 
shared-dma-pool
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x-0xfbff]
[0.00] NUMA: NODE_DATA [mem 0xfb7b0d00-0xfb7c2fff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x3fff]
[0.00]   DMA32[mem 0x4000-0xfbff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x0fff]
[0.00]   node   0: [mem 0x1000-0x3cb47fff]
[0.00]   node   0: [mem 0x3cb48000-0x3cb4cfff]
[0.00]   node   0: [mem 0x3cb4d000-0x3cb4dfff]
[0.00]   node   0: [mem 0x3cb4e000-0x3cb52fff]
[0.00]   node   0: [mem 0x3cb53000-0x3cb54fff]
[0.00]   node   0: [mem 0x3cb55000-0x3cb58fff]
[0.00]   node   0: [mem 0x3cb59000-0x3df5]
[0.00]   node   0: [mem 0x3df6-0x3df6]
[0.00]   node   0: [mem 0x3df7-0x3dff]
[0.00]   node   0: [mem 0x4000-0xfbff]
[0.00] Zeroed struct page in unavailable ranges: 30 pages
[0.00] Initmem setup node 0 [mem 0x-0xfbff]
[0.00] On node 0 totalpages: 1024000
[0.00]   DMA zone: 4096 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 253952 pages, LIFO batch:63
[0.00]   DMA32 zone: 12032 pages used for memmap
[0.00]   DMA32 zone: 770048 pages, LIFO batch:63
[0.00] percpu: Embedded 32 

[fedora-arm] Re: RPi 4 overscan

[Steven A. Falco]

On 1/19/20 1:06 PM, Benson Muite wrote:
> 
> On 1/18/20 6:56 PM, Steven A. Falco wrote:
>> I'm running Fedora Rawhide on an RPi 4, and noticed that the video wasn't 
>> quite filling the monitor.  Looking at Xorg.0.log, I saw:
>>
>> Virtual size is 1824x984 (pitch 1824)
>>
>> I fixed that by adding a line to /boot/efi/config.txt:
>>
>> disable_overscan=1
>>
>> Now, the video fits the monitor perfectly, and Xorg.0.log shows:
>>
>> Virtual size is 1920x1080 (pitch 1920)
>>
>> as expected.  /boot/efi/config.txt is owned by bcm283x-firmware.  Should I 
>> write a bug against bcm283x-firmware to add this line?
> 
> Hi Steve,
> 
> Are you also able to make a pull request here:
> 
> https://src.fedoraproject.org/rpms/bcm283x-firmware/blob/master/f/config.txt

Yes - I just did that.  I added the line to both the 32-bit and 64-bit versions 
of config.txt.

Steve
___
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] RPi 4 overscan

[Steven A. Falco]

I'm running Fedora Rawhide on an RPi 4, and noticed that the video wasn't quite 
filling the monitor.  Looking at Xorg.0.log, I saw:

Virtual size is 1824x984 (pitch 1824)

I fixed that by adding a line to /boot/efi/config.txt:

disable_overscan=1

Now, the video fits the monitor perfectly, and Xorg.0.log shows:

Virtual size is 1920x1080 (pitch 1920)

as expected.  /boot/efi/config.txt is owned by bcm283x-firmware.  Should I 
write a bug against bcm283x-firmware to add this line?

Steve
___
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: RPi 4

[Steven A. Falco]

On 1/9/20 10:56 AM, Peter Robinson wrote:
>> I know that the RPi 4 is not currently supported in Fedora, while we wait 
>> for upstream kernel support for the new Broadcom BCM2711 SOC.
>>
>> However, I now see that there is some support for the BCM2711 in kernel 5.5, 
>> and I also see that kernel 5.5 is in rawhide.
> 
> It's been worked on.
> 
>> Thus, I'm wondering if that is sufficient to start talking about Fedora on 
>> the RPi 4.
> 
> It's being worked upon. Ultimately I don't tend to talk about it
> widely because most Raspberry Pi users complain if it's not perfect
> with accelerated graphics and a whole bunch of other features and I
> end up with more support requests than I can cope with.

I understand - I recognize that this is a new chip, and it will take some time 
for full support to make it into the upstream kernel.  I certainly don't want 
to add any work or hassle for anyone.

>> I'm currently running Manjaro on my RPi 4, because they have an aarch64 
>> version, and I wanted an aarch64 machine to experiment with.
>>
>> I'm not sure if the Fedora ARM team plans to support both 32-bit and 64-bit 
>> mode on the RPi 4, so any information about that would be appreciated.
> 
> Well I do most of the RPi enablement, and yes, it's intended to
> support it in similar ways to the way we support the RPi 2/3 devices.
> 
>> I'm interested in helping out.  If there is something I can do, please let 
>> me know.
> 
> What are your capabilities to help out? Are you a kernel developer,
> user space developer etc?

In the past I had done some kernel driver and u-boot work, mostly for Freescale 
PowerPC chips on proprietary boards.  I currently have a few Wandboards with 
some custom hardware added, running yocto (an ntp clock and a weather station 
project), so I am familiar with device trees on ARM.

I don't have access to anything beyond the public documentation for the RPi 4.

I'm not sure how the Fedora ARM images are generated, but in the past I used 
lorax and pungi to generate respins of CentOS 7.

Steve

___
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] RPi 4

[Steven A. Falco]

I know that the RPi 4 is not currently supported in Fedora, while we wait for 
upstream kernel support for the new Broadcom BCM2711 SOC.

However, I now see that there is some support for the BCM2711 in kernel 5.5, 
and I also see that kernel 5.5 is in rawhide.

Thus, I'm wondering if that is sufficient to start talking about Fedora on the 
RPi 4.

I'm currently running Manjaro on my RPi 4, because they have an aarch64 
version, and I wanted an aarch64 machine to experiment with.

I'm not sure if the Fedora ARM team plans to support both 32-bit and 64-bit 
mode on the RPi 4, so any information about that would be appreciated.

I'm interested in helping out.  If there is something I can do, please let me 
know.

Steve
___
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: Moving root fs to sata

[Steven A. Falco]

On 7/6/19 3:35 AM, Damian Wrobel wrote:
>> On 7/4/19 9:30 AM, Steven A. Falco wrote:
>> Therefore, I need to add a delay in U-Boot.
> 
> There seems to be U-Boot equivalent of 'rootdelay' called: 'bootdelay'[1].
> 
> [1] http://processors.wiki.ti.com/index.php/Change_U-Boot_bootdelay_setting

And that one works.  I set it to 10 seconds, and the board booted properly.  I 
could hear the disk spin up, and the heads loaded prior to U-Boot querying the 
drive.

Thanks very much for the assistance.

Steve
___
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: Moving root fs to sata

[Steven A. Falco]

On 7/4/19 9:30 AM, Steven A. Falco wrote:
> On 7/4/19 3:52 AM, Damian Wrobel wrote:
>>> On 6/8/19 5:58 AM, Peter Robinson wrote:
>>>
>>> I find that on a cold boot, it usually fails, because U-Boot is faster than
>>> the disk can spin up. :-)  However, if I then hit the reset button it boots 
>>> fine.  Others
>>> might want to know that.
>>
>> I'm using the following kernel options in case where the SATA disk needs to 
>> spin up first to become usable:
>>   rootwait rootdelay=5
> 
> Thanks for the tip!  I'll give that a try.

Unfortunately, it turns out that rootwait/delay doesn't help.  The problem 
occurs even earlier: U-Boot cannot find any bootable devices.  Therefore, I 
need to add a delay in U-Boot.

But it is not a big deal - I very rarely power-cycle my Wandboard.  It is on a 
UPS, and runs 24/7.  It is only power-cycled if I have to replace hardware.

Steve
___
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: Moving root fs to sata

[Steven A. Falco]

On 7/4/19 3:52 AM, Damian Wrobel wrote:
>> On 6/8/19 5:58 AM, Peter Robinson wrote:
>>
>> I find that on a cold boot, it usually fails, because U-Boot is faster than
>> the disk can spin up. :-)  However, if I then hit the reset button it boots 
>> fine.  Others
>> might want to know that.
> 
> I'm using the following kernel options in case where the SATA disk needs to 
> spin up first to become usable:
>   rootwait rootdelay=5

Thanks for the tip!  I'll give that a try.

Steve
___
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: Moving root fs to sata

[Steven A. Falco]

On 6/8/19 5:58 AM, Peter Robinson wrote:
> On Fri, Jun 7, 2019 at 10:58 PM Steven A. Falco  wrote:
>>
>> On 6/7/19 2:38 PM, Steven A. Falco wrote:
>>> On 6/7/19 2:32 PM, Peter Robinson wrote:
>>>> On Fri, Jun 7, 2019 at 7:28 PM Steven A. Falco  
>>>> wrote:
>>>>>
>>>>> On 6/7/19 2:26 PM, Peter Robinson wrote:
>>>>>>> I have a wandboard quad, and I'd like to move the root filesystem to a 
>>>>>>> sata drive.  I have the drive connected and formatted, and I copied all 
>>>>>>> of "/" to a partition on the sata drive.
>>>>>>
>>>>>> For the wandboard you can actually have the entire OS on SATA. The
>>>>>> only thing that needs to be on a SD card is U-Boot.
>>>>>>
>>>>>> So if you take a new image and DD it out to the sata device, then just
>>>>>> dd out the U-Boot to a mSD card it should just all boot.
>>>>>
>>>>> That is very interesting.  So I think you are saying that the initramfs 
>>>>> that is part of the Fedora 30 image already has the necessary drivers.  
>>>>> Do I have that right?
>>>>
>>>> Sort of. The pre generated images that we ship have "generic"
>>>> initramfs which have a LOT of drivers so the images will boot on the
>>>> vast majority of Arm devices, once the first kernel update is applied
>>>> it automatically moves to a host specific initramfs so will then be a
>>>> lot smaller, and hence much quicker to boot, but will not be a generic
>>>> initramfs.
>>>
>>> Excellent!  That is a good design.
>>
>> I am happy to report that it worked perfectly.  My Wandboard is now running 
>> entirely from a SATA drive, with the tiny exception of U-Boot.
> 
> Excellent news, feel free to suggest any improvements that could be
> done to improve the process.

Is there a page where I could contribute some information, or is this already 
written up?  In particular, I find that on a cold boot, it usually fails, 
because U-Boot is faster than the disk can spin up. :-)  However, if I then hit 
the reset button it boots fine.  Others might want to know that.

Steve
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Re: Moving root fs to sata

[Steven A. Falco]

On 6/7/19 2:38 PM, Steven A. Falco wrote:
> On 6/7/19 2:32 PM, Peter Robinson wrote:
>> On Fri, Jun 7, 2019 at 7:28 PM Steven A. Falco  wrote:
>>>
>>> On 6/7/19 2:26 PM, Peter Robinson wrote:
>>>>> I have a wandboard quad, and I'd like to move the root filesystem to a 
>>>>> sata drive.  I have the drive connected and formatted, and I copied all 
>>>>> of "/" to a partition on the sata drive.
>>>>
>>>> For the wandboard you can actually have the entire OS on SATA. The
>>>> only thing that needs to be on a SD card is U-Boot.
>>>>
>>>> So if you take a new image and DD it out to the sata device, then just
>>>> dd out the U-Boot to a mSD card it should just all boot.
>>>
>>> That is very interesting.  So I think you are saying that the initramfs 
>>> that is part of the Fedora 30 image already has the necessary drivers.  Do 
>>> I have that right?
>>
>> Sort of. The pre generated images that we ship have "generic"
>> initramfs which have a LOT of drivers so the images will boot on the
>> vast majority of Arm devices, once the first kernel update is applied
>> it automatically moves to a host specific initramfs so will then be a
>> lot smaller, and hence much quicker to boot, but will not be a generic
>> initramfs.
> 
> Excellent!  That is a good design.

I am happy to report that it worked perfectly.  My Wandboard is now running 
entirely from a SATA drive, with the tiny exception of U-Boot.

Steve
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Re: Moving root fs to sata

[Steven A. Falco]

On 6/7/19 2:32 PM, Peter Robinson wrote:
> On Fri, Jun 7, 2019 at 7:28 PM Steven A. Falco  wrote:
>>
>> On 6/7/19 2:26 PM, Peter Robinson wrote:
>>>> I have a wandboard quad, and I'd like to move the root filesystem to a 
>>>> sata drive.  I have the drive connected and formatted, and I copied all of 
>>>> "/" to a partition on the sata drive.
>>>
>>> For the wandboard you can actually have the entire OS on SATA. The
>>> only thing that needs to be on a SD card is U-Boot.
>>>
>>> So if you take a new image and DD it out to the sata device, then just
>>> dd out the U-Boot to a mSD card it should just all boot.
>>
>> That is very interesting.  So I think you are saying that the initramfs that 
>> is part of the Fedora 30 image already has the necessary drivers.  Do I have 
>> that right?
> 
> Sort of. The pre generated images that we ship have "generic"
> initramfs which have a LOT of drivers so the images will boot on the
> vast majority of Arm devices, once the first kernel update is applied
> it automatically moves to a host specific initramfs so will then be a
> lot smaller, and hence much quicker to boot, but will not be a generic
> initramfs.

Excellent!  That is a good design.

Steve
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Re: Moving root fs to sata

[Steven A. Falco]

On 6/7/19 2:26 PM, Peter Robinson wrote:
>> I have a wandboard quad, and I'd like to move the root filesystem to a sata 
>> drive.  I have the drive connected and formatted, and I copied all of "/" to 
>> a partition on the sata drive.
> 
> For the wandboard you can actually have the entire OS on SATA. The
> only thing that needs to be on a SD card is U-Boot.
> 
> So if you take a new image and DD it out to the sata device, then just
> dd out the U-Boot to a mSD card it should just all boot.

That is very interesting.  So I think you are saying that the initramfs that is 
part of the Fedora 30 image already has the necessary drivers.  Do I have that 
right?

Steve

___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Moving root fs to sata

[Steven A. Falco]

I have a wandboard quad, and I'd like to move the root filesystem to a sata 
drive.  I have the drive connected and formatted, and I copied all of "/" to a 
partition on the sata drive.

Now the question is "where do I need to change the UUID to match that of the 
new partition".

I know I need to change /etc/fstab, /boot/extlinux/extlinux.conf and perhaps 
/boot/grub/grub.conf, but do I also have to regenerate the initramfs images, 
and if so, what command would I use so they contain the correct UUID and 
drivers?

If I need to rebuild the initramfs, that would be a bit of a chicken and egg 
problem, because I would not be able to boot from the sata drive until I 
rebuilt it, but if I rebuilt it while running from the SD card, I'd guess the 
rebuilt initramfs would still reference the SD card.

Steve
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Bug 1628209

[Steven A. Falco]

Roughly a month ago I upgraded the kernel on my wandboard quad.  The quad had 
been running kernel 4.17.19-200.fc28.armv7hl and was working properly.

However, when I upgraded to kernel 4.18.5-200.fc28.armv7hl I found that 
ethernet no longer worked.  I reverted to kernel 4.17.19-200.fc28.armv7hl and 
ethernet was fine again.

I've tried several kernels since then, including the latest 
(4.18.13-200.fc28.armv7hl), with the same negative result.

When running kernel 4.18.13-200.fc28.armv7hl the console messages say that the 
link is up, however I am not able to ping anything on the local subnet. 

I filed a bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1628209

Does anyone know of any driver changes that might account for this bug?

Steve

___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] [PATCH] Increase offset for Wandboard environment

[Steven A. Falco]

U-Boot has grown beyond the allocated size, such that the enviromnent
was overlapping the code.  This patch corrects that.

Signed-off-by: Steven A. Falco stevenfa...@gmail.com
---
 include/configs/wandboard.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 4950ed7..a7e2261 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -285,7 +285,7 @@
 #define CONFIG_ENV_SIZE(8 * 1024)
 
 #define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_OFFSET  (6 * 64 * 1024)
+#define CONFIG_ENV_OFFSET  (7 * 64 * 1024)
 #define CONFIG_SYS_MMC_ENV_DEV 0
 
 #ifndef CONFIG_SYS_DCACHE_OFF
-- 
2.4.3

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Announcing Fedora 19 (Schrödinger's cat) for the 2012 Samsung Chromebook

[Steven A. Falco]

On 07/04/2013 11:16 AM, Jon wrote:

Thanks Steven,

Fixed the wiki.

Hopefully the image was not corrupted on download, and my apologies
for not providing a checksum before.
Here you go:

sha256sumf19-chromebook-MATE.img.xz
723647155e51f94d0c9a20f0f1f44d6c375cb06d23c459241d38508b252e48f9
f19-chromebook-MATE.img.xz


The checksum verified as correct.


Beyond that you might try to fix the sdcard from inside ChromeOS.

1. boot into ChromeOS.
2. type: CTRL + ALT + T to open a shell.
3. Inside the shell type: shell and sudo su - to reach a
privileged bash prompt
4. Run the setup script on the sdcard:
 # bash /media/removable/rootfs/root/setup.bash


I ran the script manually.  I got one failure message about not
being able to access /dev/mmcblk1 (error code = 2, ENOENT).

This appears to be caused by the device node not being present
in /media/removable/rootfs.

If I do:

mknod /media/removable/rootfs/dev/mmcblk1 b 179 48
chmod ugo+rw /media/removable/rootfs/dev/mmcblk1

then the script gives error 13 instead (EACCES).  I also get a
message that I need to be root.  However, id shows that I am
root.  So something about the chroot appears to be dropping the
permissions.

Regardless, the script continues to run, and at the end I am
able to boot into F19 via ^U.  So the error is not fatal.

Steve


This will copy over the ChromeOS 3.4 kernel plus modules to the sdcard.

Hopefully that works.
If not, well... try to find me on IRC and I'll walk you through some
more comprehensive troubleshooting.

Thanks,
-Jon Disnard
fas: parasense
irc: masta



On Thu, Jul 4, 2013 at 10:49 AM, Steven A. Falco stevenfa...@gmail.com wrote:

On 07/03/2013 12:59 PM, Jon wrote:


I'm pleased to announce the availability of Fedora 19 for the 2012
Samsung Chromebook featuring ARM Exynos dual core A15 processor.



Thanks for doing that!



The initial release is based on MATE desktop environment.
Expect to see KDE, XFCE, LXDE, and SUGAR to land in the next few days.


Exact steps:
(assume the sdcard is /dev/sdz)

# fetch the remix image
wget http://parasense.fedorapeople.org/f19-chromebook-MATE.img.xz

# write the image to sdcard
sudo xzcat f19-chromebook-MATE.img.xz  /dev/sdz



The web page at:

https://fedoraproject.org/wiki/Architectures/ARM/F19/Remixes

has a typo in the above command - it is missing the .xz in the
source file name.  The web page is also missing the 'sudo' on
the various commands.



# resize the rootfs partition
sudo sgdisk -p -a8192 -e -d5 -n5:0:0 -t5:8300 -c5:'ROOTFS' -p /dev/sdz

# resize the rootfs ext4 filesystem
sudo e2fsck -f /dev/sdz5
sudo resize2fs /dev/sdz5

#THE END


For more details please visit our REMIX site at:
https://fedoraproject.org/wiki/Architectures/ARM/F19/Remixes


Please note this is an unofficial REMIX image.
For support, you can find me (masta) in #fedora-arm on IRC



I tried this with two different SD cards.  In both cases, when
I type ^U, I hear a double beep from uboot and it refuses to
boot from the SD card.

I am able to enter ^D and get into developer mode, so I don't
think there is anything wrong with my chromebook.

 Steve





Thanks,
-Jon Disnard
fas: parasense
irc: masta








___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Fedora 18 on ARM based Samsung Chromebook class

[Steven A. Falco]

On 02/25/2013 03:05 AM, Dan Horák wrote:
 John Dulaney píše v Čt 21. 02. 2013 v 15:52 -0500: 
 On Feb 22 at 20:00 UTC in #fedora-arm-talks I will be discussing how to 
 install
 Fedora on the arm based Samsung Chromebook.

 Things you will need prior to the talk:
 A Chromebook
 A second machine for extracting images, etc.
 8 GB SD card (4 *may* work, but I have not tested this)
 The Fedora 18 armv7hfp image here:
 http://scotland.proximity.on.ca/arm-nightlies/vault/f18/Images/armhfp/Fedora-18-armhfp-rootfs.tar.xz

 I will be teaching three stages.  The first stage is to get Fedora working 
 on the SD card
 using the Chrome OS kernel.  Stage Two will be installing Fedora on the 
 internal SSD,
 once again using the Chrome OS kernel.  Stage three will be about hints on 
 building
 your own kernel.
 
 do you have the IRC log uploaded somewhere? I did stage 1 some time ago
 and now I'm interested in stage 2, the SD card protrudes from the
 Chromebook badly :-)
 

http://meetbot.fedoraproject.org/fedora-arm-talks/2013-02-22/fedora_on_the_arm_based_samsung_chromebook.2013-02-22-20.01.log.html

Steve

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?

[Steven A. Falco]

On 08/08/2012 11:38 PM, Scott Sullivan wrote:
 On 08/08/2012 09:57 PM, Steven A. Falco wrote:
 On 08/08/2012 09:14 PM, Scott Sullivan wrote:
 On 08/08/2012 02:44 PM, Steven A. Falco wrote:
 On 08/07/2012 12:09 PM, Scott Sullivan wrote:
 [...]
 # Needs to be Modified to support Fedora .zx tar archive and /lib 
 symbolic link. Working on a patch.

 Here is a patch that fixes both the xz and symbolic link:

 --- /home/sfalco/a1x-media-create.sh2012-08-08 14:10:38.323150167 -0400
 +++ ./a1x-media-create.sh2012-08-08 14:38:29.609848573 -0400
 @@ -107,6 +107,8 @@
sudo tar xzf ../$1
elif [ ${fileext} == 7z ] | [ ${fileext} == lzma ]; then
sudo 7z x ../$1
 +elif [ ${fileext} == xz ]; then
 +sudo tar xJf ../$1
else
echo Unknown file extension: ${fileext}
popd
 @@ -217,6 +219,14 @@
cleanup
fi
echo Copy hwpack rootfs files
 +# Fedora uses a softlink for lib.  Adjust, if needed.
 +if [ -L mntSDrootfs/lib ]; then
 +# Find where it points.  For Fedora, we expect usr/lib.
 +DEST=`/bin/ls -l mntSDrootfs/lib | sed -e 's,.* ,,'`
 +if [ $DEST = usr/lib ]; then
 +mv hwpack/rootfs/lib hwpack/rootfs/usr
 +fi
 +fi
sudo cp -a hwpack/rootfs/* mntSDrootfs  ${logfile}
if [ $? -ne 0 ]; then
echo Failed to copy rootfs hwpack files to SD Card


 Thanks Steven. My time got busy and this got pushed to my back burner, 
 greatly appreciated.

 Have you tired getting this applied to the upstream yet?


 I created a fork on github, put in my changes, and made a pull
 request.  My version is here:

 git://github.com/stevefalco/a10-tools.git

 Please give it a try and feed me any comments.

 Steve
 
 I snagged it and ran up a fresh SD card. It booted as expected and so far 
 networking is working. Now to just to find some time to get the VGA working 
 under Fedora.
 

Thanks for the confirmation.  The pull was accepted, so it is now in the
mainline.

Steve


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?

[Steven A. Falco]

On 08/08/2012 08:45 AM, Fernando Cassia wrote:
 On Wed, Aug 8, 2012 at 9:02 AM, Steven A. Falco safa...@optonline.net wrote:
 The problem is that you will need a USB/ethernet dongle right now, and
 that means you have to build your own kernel.  So a single image is not
 really possible at the moment.

 Steve
 
 OK I see. Thanks.
 
 Let me guess... the Ethernet port in the device is handled by the cpu
 (DSP microcode) rather than being based on a real Ethernet controller
 on the system board?. Or is there an Ethernet chip in there, just
 unsupported by Linux drivers?.
 
 If the former case, then it reminds me of the Neuros OSD...

It uses something called WEMAC which is part of the chip.  I have not
attempted to see what is wrong.  Might just be a gpio that is not
turned on, or might be something major.  Sadly I don't have time to
dig into it.

But since Olimex is looking at building a hacker board with this CPU,
I imagine it will get sorted out by them, if not before...

Steve

 
 FC
 ___
 arm mailing list
 arm@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/arm
 

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?

[Steven A. Falco]

On 08/07/2012 12:09 PM, Scott Sullivan wrote:
 On 08/06/2012 11:59 PM, Jon wrote:
 On Mon, Aug 6, 2012 at 8:52 PM, Steven A. Falco safa...@optonline.net 
 wrote:
 On 08/03/2012 06:12 AM, Peter Robinson wrote:
 [...]

 Ok - I have Fedora 17 running on the Mele.  It is quite a hack, but it
 is usable (yum merrily installing the dev tools as we speak).

 Here is the recipe:

 1) grab and cross-compile a copy of the kernel from:
  git://github.com/amery/linux-allwinner.git
 (use branch allwinner-v3.0-android-v2 with sun4i_defconfig)
 2) grab http://hands.com/~lkcl/mele-ubuntu-lucid.img.lzma and write it
 to an SD card (don't forget to decompress it).  Afterwards, use
 gparted to expand the ext partition to fill the SD card.

 3) Mount the various partitions of the SD card on a host machine.  On
 the fat partition, replace uImage with the one you just built.  On
 the ext partition, blow everything away, and replace with an untar of:

 http://download.fedoraproject.org/pub/fedora-secondary/releases/17/Images/armhfp/Fedora-17-armhfp-console.tar.xz

 4) Install the modules that go with the kernel you built to the ext
 partition (into /lib/modules/3.0.38+).

 5) Stick the SD card in the Mele, and it should boot.
 
 Alternatively and Cleaner:
 
 1) Download A1000 hardware pack from nightly builds. This is a Kernel and 
 Uboot pre-built.
 
 http://rhombus-tech.net/allwinner_a10/nightly_build_images/
 
 2) Grab the a1x-media-create.sh Script.
 
 # Needs to be Modified to support Fedora .zx tar archive and /lib symbolic 
 link. Working on a patch.

The following is all that is needed for the .xz stuff.  I have
not looked at the /lib part.

--- /home/sfalco/a1x-media-create.sh2012-08-08 14:10:38.323150167 -0400
+++ ./a1x-media-create.sh   2012-08-08 14:08:26.021655286 -0400
@@ -107,6 +107,8 @@
 sudo tar xzf ../$1
 elif [ ${fileext} == 7z ] | [ ${fileext} == lzma ]; then 
 sudo 7z x ../$1
+elif [ ${fileext} == xz ]; then 
+sudo tar xJf ../$1
 else
echo Unknown file extension: ${fileext}
 popd

 
 3) Download the Fedora Root FS.
 
 4) Run media build script.
 
 5) Stick SD card in the Mele and it will boot.
 
 This removes the dependence on the ubuntu image and automatically makes the 
 partitions the correct size for the media.
 
 
 One big issue is that the built-in eth0 is not functional.  That is true
 of the ubuntu build as well.  To get around that, I plugged in a 
 USB/ethernet
 adapter (and built the kernel module for it).  That gave me a usable eth1.
 
 I got it to boot on Saturday using the method I outlined. I ran out of time 
 to verify what did and didn't work.
 
 This clearly needs a ton of work to be a proper Fedora installation,
 but at least it is a start...
 
 Yes, certainly getting easier.
 
 Sounds like a good start.

 We could probably just use the resize script in our image to expand
 partition and resize ext on firstboot?
 
 No need with the creation script from the nightly builds. Otherwise we could 
 re-purpose the scripts form the Raspberry Pi remix.
 
 We might also consider making a wiki page for this device, ensure to
 mention this is unsupported.
 
 Where do you want it?
 

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?

[Steven A. Falco]

On 08/07/2012 12:09 PM, Scott Sullivan wrote:
 On 08/06/2012 11:59 PM, Jon wrote:
 On Mon, Aug 6, 2012 at 8:52 PM, Steven A. Falco safa...@optonline.net 
 wrote:
 On 08/03/2012 06:12 AM, Peter Robinson wrote:
 [...]

 Ok - I have Fedora 17 running on the Mele.  It is quite a hack, but it
 is usable (yum merrily installing the dev tools as we speak).

 Here is the recipe:

 1) grab and cross-compile a copy of the kernel from:
  git://github.com/amery/linux-allwinner.git
 (use branch allwinner-v3.0-android-v2 with sun4i_defconfig)
 2) grab http://hands.com/~lkcl/mele-ubuntu-lucid.img.lzma and write it
 to an SD card (don't forget to decompress it).  Afterwards, use
 gparted to expand the ext partition to fill the SD card.

 3) Mount the various partitions of the SD card on a host machine.  On
 the fat partition, replace uImage with the one you just built.  On
 the ext partition, blow everything away, and replace with an untar of:

 http://download.fedoraproject.org/pub/fedora-secondary/releases/17/Images/armhfp/Fedora-17-armhfp-console.tar.xz

 4) Install the modules that go with the kernel you built to the ext
 partition (into /lib/modules/3.0.38+).

 5) Stick the SD card in the Mele, and it should boot.
 
 Alternatively and Cleaner:
 
 1) Download A1000 hardware pack from nightly builds. This is a Kernel and 
 Uboot pre-built.
 
 http://rhombus-tech.net/allwinner_a10/nightly_build_images/
 
 2) Grab the a1x-media-create.sh Script.
 
 # Needs to be Modified to support Fedora .zx tar archive and /lib symbolic 
 link. Working on a patch.

Here is a patch that fixes both the xz and symbolic link:

--- /home/sfalco/a1x-media-create.sh2012-08-08 14:10:38.323150167 -0400
+++ ./a1x-media-create.sh   2012-08-08 14:38:29.609848573 -0400
@@ -107,6 +107,8 @@
 sudo tar xzf ../$1
 elif [ ${fileext} == 7z ] | [ ${fileext} == lzma ]; then 
 sudo 7z x ../$1
+elif [ ${fileext} == xz ]; then 
+sudo tar xJf ../$1
 else
echo Unknown file extension: ${fileext}
 popd
@@ -217,6 +219,14 @@
cleanup
fi 
 echo Copy hwpack rootfs files
+   # Fedora uses a softlink for lib.  Adjust, if needed.
+   if [ -L mntSDrootfs/lib ]; then
+   # Find where it points.  For Fedora, we expect usr/lib.
+   DEST=`/bin/ls -l mntSDrootfs/lib | sed -e 's,.* ,,'`
+   if [ $DEST = usr/lib ]; then
+   mv hwpack/rootfs/lib hwpack/rootfs/usr
+   fi
+   fi
 sudo cp -a hwpack/rootfs/* mntSDrootfs  ${logfile}
if [ $? -ne 0 ]; then
echo Failed to copy rootfs hwpack files to SD Card

 
 3) Download the Fedora Root FS.
 
 4) Run media build script.
 
 5) Stick SD card in the Mele and it will boot.
 
 This removes the dependence on the ubuntu image and automatically makes the 
 partitions the correct size for the media.
 
 
 One big issue is that the built-in eth0 is not functional.  That is true
 of the ubuntu build as well.  To get around that, I plugged in a 
 USB/ethernet
 adapter (and built the kernel module for it).  That gave me a usable eth1.
 
 I got it to boot on Saturday using the method I outlined. I ran out of time 
 to verify what did and didn't work.
 
 This clearly needs a ton of work to be a proper Fedora installation,
 but at least it is a start...
 
 Yes, certainly getting easier.
 
 Sounds like a good start.

 We could probably just use the resize script in our image to expand
 partition and resize ext on firstboot?
 
 No need with the creation script from the nightly builds. Otherwise we could 
 re-purpose the scripts form the Raspberry Pi remix.
 
 We might also consider making a wiki page for this device, ensure to
 mention this is unsupported.
 
 Where do you want it?
 

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?

[Steven A. Falco]

On 08/08/2012 09:14 PM, Scott Sullivan wrote:
 On 08/08/2012 02:44 PM, Steven A. Falco wrote:
 On 08/07/2012 12:09 PM, Scott Sullivan wrote:
 [...]
 # Needs to be Modified to support Fedora .zx tar archive and /lib symbolic 
 link. Working on a patch.

 Here is a patch that fixes both the xz and symbolic link:

 --- /home/sfalco/a1x-media-create.sh2012-08-08 14:10:38.323150167 -0400
 +++ ./a1x-media-create.sh2012-08-08 14:38:29.609848573 -0400
 @@ -107,6 +107,8 @@
   sudo tar xzf ../$1
   elif [ ${fileext} == 7z ] | [ ${fileext} == lzma ]; then
   sudo 7z x ../$1
 +elif [ ${fileext} == xz ]; then
 +sudo tar xJf ../$1
   else
   echo Unknown file extension: ${fileext}
   popd
 @@ -217,6 +219,14 @@
   cleanup
   fi
   echo Copy hwpack rootfs files
 +# Fedora uses a softlink for lib.  Adjust, if needed.
 +if [ -L mntSDrootfs/lib ]; then
 +# Find where it points.  For Fedora, we expect usr/lib.
 +DEST=`/bin/ls -l mntSDrootfs/lib | sed -e 's,.* ,,'`
 +if [ $DEST = usr/lib ]; then
 +mv hwpack/rootfs/lib hwpack/rootfs/usr
 +fi
 +fi
   sudo cp -a hwpack/rootfs/* mntSDrootfs  ${logfile}
   if [ $? -ne 0 ]; then
   echo Failed to copy rootfs hwpack files to SD Card
 
 
 Thanks Steven. My time got busy and this got pushed to my back burner, 
 greatly appreciated.
 
 Have you tired getting this applied to the upstream yet?
 

No, but I have tested it, and it is working very well.  It even solves
the wired-ethernet bug that I was having.  So I'm happy with it.  I'll
look at trying to get it upstream a bit later.

Steve
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?

[Steven A. Falco]

On 08/08/2012 09:14 PM, Scott Sullivan wrote:
 On 08/08/2012 02:44 PM, Steven A. Falco wrote:
 On 08/07/2012 12:09 PM, Scott Sullivan wrote:
 [...]
 # Needs to be Modified to support Fedora .zx tar archive and /lib symbolic 
 link. Working on a patch.

 Here is a patch that fixes both the xz and symbolic link:

 --- /home/sfalco/a1x-media-create.sh2012-08-08 14:10:38.323150167 -0400
 +++ ./a1x-media-create.sh2012-08-08 14:38:29.609848573 -0400
 @@ -107,6 +107,8 @@
   sudo tar xzf ../$1
   elif [ ${fileext} == 7z ] | [ ${fileext} == lzma ]; then
   sudo 7z x ../$1
 +elif [ ${fileext} == xz ]; then
 +sudo tar xJf ../$1
   else
   echo Unknown file extension: ${fileext}
   popd
 @@ -217,6 +219,14 @@
   cleanup
   fi
   echo Copy hwpack rootfs files
 +# Fedora uses a softlink for lib.  Adjust, if needed.
 +if [ -L mntSDrootfs/lib ]; then
 +# Find where it points.  For Fedora, we expect usr/lib.
 +DEST=`/bin/ls -l mntSDrootfs/lib | sed -e 's,.* ,,'`
 +if [ $DEST = usr/lib ]; then
 +mv hwpack/rootfs/lib hwpack/rootfs/usr
 +fi
 +fi
   sudo cp -a hwpack/rootfs/* mntSDrootfs  ${logfile}
   if [ $? -ne 0 ]; then
   echo Failed to copy rootfs hwpack files to SD Card
 
 
 Thanks Steven. My time got busy and this got pushed to my back burner, 
 greatly appreciated.
 
 Have you tired getting this applied to the upstream yet?
 

I created a fork on github, put in my changes, and made a pull
request.  My version is here:

git://github.com/stevefalco/a10-tools.git

Please give it a try and feed me any comments.

Steve


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?

[Steven A. Falco]

On 08/07/2012 12:02 AM, Itamar Reis Peixoto wrote:
 On Tue, Aug 7, 2012 at 12:59 AM, Jon jdisn...@gmail.com wrote:
 

 Sounds like a good start.

 We could probably just use the resize script in our image to expand
 partition and resize ext on firstboot?

 We might also consider making a wiki page for this device, ensure to
 mention this is unsupported.

 -Jon
 
 Please do that, I got one, its very fast with android, if I replace
 android with fedora I can use it as my desktop.


If I have access, I'll start working up a page tonight.  One thing
about a desktop - I have not tried any graphics yet.  It is strictly
an ssh text-mode thing right now, as that is all I need to do my
initial performance measurements.  I'm trying to assess the viability
of the chip for an embedded project rather than as a general-purpose
box.

But of course others in the community would be encouraged to look
the graphics side.  Once you have it booted, the rest of the code can
follow.

Steve

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?

[Steven A. Falco]

On 08/03/2012 06:12 AM, Peter Robinson wrote:
 On Fri, Aug 3, 2012 at 1:00 AM, Steven A. Falco safa...@optonline.net wrote:
 I've picked up a Mele A1000 set top, which uses the Allwinner A10 CPU.
 I don't see a Fedora port for this one yet, so I might take a shot at
 it.  But first I wanted to ask if anyone else has already started this?

 The CPU is a Cortex A8, and there is an Ubuntu port, as well as its
 native Android OS.
 
 None of the A10 kernel source code is upstream. It's something I would
 like to support at some point in time as there's a lot of cheap and
 interesting devices coming out with the chip from Netbook form factor
 through to stick PCs. It should be doable as it's only kernel stuff
 that's needed and it should run fine with the standard hardfp builds
 but your milarge may vary.
 
 Peter
 

Ok - I have Fedora 17 running on the Mele.  It is quite a hack, but it
is usable (yum merrily installing the dev tools as we speak).

Here is the recipe:

1) grab and cross-compile a copy of the kernel from:
git://github.com/amery/linux-allwinner.git
   (use branch allwinner-v3.0-android-v2 with sun4i_defconfig)

2) grab http://hands.com/~lkcl/mele-ubuntu-lucid.img.lzma and write it
   to an SD card (don't forget to decompress it).  Afterwards, use
   gparted to expand the ext partition to fill the SD card.

3) Mount the various partitions of the SD card on a host machine.  On
   the fat partition, replace uImage with the one you just built.  On
   the ext partition, blow everything away, and replace with an untar of:

http://download.fedoraproject.org/pub/fedora-secondary/releases/17/Images/armhfp/Fedora-17-armhfp-console.tar.xz

4) Install the modules that go with the kernel you built to the ext
   partition (into /lib/modules/3.0.38+).

5) Stick the SD card in the Mele, and it should boot.

One big issue is that the built-in eth0 is not functional.  That is true
of the ubuntu build as well.  To get around that, I plugged in a USB/ethernet
adapter (and built the kernel module for it).  That gave me a usable eth1.

This clearly needs a ton of work to be a proper Fedora installation,
but at least it is a start...

Steve

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?

[Steven A. Falco]

On 08/03/2012 09:37 AM, Jon wrote:
 Have tried to get the kernel to build, and I remember these sites were 
 helpful.
 
 https://github.com/amery/linux-allwinner
 http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/Building_Debian_From_Source_Code_for_Mele/
 
 Make sure that cgroups are enabled in your kernel.
 Once you have the kernel build you can integrate with the latest userland 
 image.
 
 Somebody on IRC suggested that the Allwinner patches may need
 improvement before they could be accepted upstream?
 It would be great if that happened, as Fedora only digests upstream kernel.
 
 Otherwise this could be a 3rd party spin like raspi?

I'll take a close look at the kernel patches over the next day
or two.  I am set up to cross-compile that, so it is mostly a
question of the required settings for Fedora.  Is there a minimum
allowed kernel version?  As in, nothing older than 3.xxx?  I ask
because I tried a 2.6.34.9 kernel with F17 on my Ionics, and got
lots of errors from udev and systemd.

Also, is there a preferred procedure for bootstrapping initramfs?
I assume the best way is to unpack an existing one, replace any
kernel modules, and repack.  I don't see a way to run dracut in
a cross-environment (i.e. from an x86).

Steve

 
 -Jon
 
 On Fri, Aug 3, 2012 at 8:23 AM, Itamar Reis Peixoto
 ita...@ispbrasil.com.br wrote:
 On Fri, Aug 3, 2012 at 7:12 AM, Peter Robinson pbrobin...@gmail.com wrote:
 On Fri, Aug 3, 2012 at 1:00 AM, Steven A. Falco safa...@optonline.net 
 wrote:
 I've picked up a Mele A1000 set top, which uses the Allwinner A10 CPU.
 I don't see a Fedora port for this one yet, so I might take a shot at
 it.  But first I wanted to ask if anyone else has already started this?

 The CPU is a Cortex A8, and there is an Ubuntu port, as well as its
 native Android OS.

 None of the A10 kernel source code is upstream. It's something I would
 like to support at some point in time as there's a lot of cheap and
 interesting devices coming out with the chip from Netbook form factor
 through to stick PCs. It should be doable as it's only kernel stuff
 that's needed and it should run fine with the standard hardfp builds
 but your milarge may vary.

 Peter

 I have one, if you build the kernel I am able to try it.

 --
 

 Itamar Reis Peixoto
 msn, google talk: ita...@ispbrasil.com.br
 +55 11 4063 5033 (FIXO SP)
 +55 34 9158 9329 (TIM)
 +55 34 8806 3989 (OI)
 +55 34 3221 8599 (FIXO MG)
 ___
 arm mailing list
 arm@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/arm
 
 
 

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Soft lockup on Ionics Stratus

[Steven A. Falco]

On 08/02/2012 04:31 AM, Peter Robinson wrote:
 On Thu, Aug 2, 2012 at 1:28 AM, Steven A. Falco safa...@optonline.net wrote:
 I just filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=845143 
 relating
 to a soft lockup that I am seeing when attempting to run a maven build on an
 Ionics Stratus plug computer.

 I've only had this machine for a short time, but it has been quite reliable 
 up
 to this point.  I've been able to do yum updates, etc, without problems.

 However, my attempted maven build of Apache ActiveMQ (java app) causes a 100%
 reproducible lockup of the machine.
 
 It's quite possible it's a general problem but I suspect there's not
 many people running large amounts of java let alone ActiveMQ. Does it
 happen if you run other java things?

I'll have to do more tests.  Right now I am trying to port a suite of existing
code from x86 to arm, and this component was the first one I chose to try.

The thing is, it is 100% reproducible.  I don't always see the kernel messages,
but the machine always locks up - all ssh sessions are frozen, as is the 
console.
Application code shouldn't be able to do that. :-)

 I'd like to ask if other folks have had any stability issues with the 
 Stratus.
 
 It's not a device I've ever heard of, I presume it's a kirkwood based
 device using the standard Fedora kernel.

Correct - kirkwood plug computer: http://www.ionicsplug.com/stratus.html

Steve
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Anyone working on Mele A1000 or Allwinner A10 CPU?

[Steven A. Falco]

I've picked up a Mele A1000 set top, which uses the Allwinner A10 CPU.
I don't see a Fedora port for this one yet, so I might take a shot at
it.  But first I wanted to ask if anyone else has already started this?

The CPU is a Cortex A8, and there is an Ubuntu port, as well as its
native Android OS.

Steve
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm