[opensuse-arm] Extremely slow boot of raspberry pi 4 images
I tried the newest XFCE Raspberry Pi 4 images for openSUSE Leap 15.2 and Tumbleweed. Both are extremely slow to start. I did not have enough patience for Leap 15.2 to see it finish with a log screen, so abandoned that test and continued with the test of Tumbleweed. There are several error messages during the boot process to explain why it takes so long, but even loading the final linux image takes minutes. Below is what I did catch during the start of the boot process: ------------------- U-Boot 2020.04 (Aug 09 2020 - 19:41:12 +0000) DRAM: 3.9 GiB RPI 4 Model B (0xc03112) MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 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... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:3... ** Invalid partition 4 ** ** Unrecognized filesystem type ** Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Card did not respond to voltage select! Scanning disk mmcnr@7e300000.blk... Disk mmcnr@7e300000.blk not ready Scanning disk emmc2@7e340000.blk... ** Unrecognized filesystem type ** Found 4 disks BootOrder not defined EFI boot manager: Cannot load any image 1382256 bytes read in 108 ms (12.2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Welcome to GRUB! Please press 't' to show the boot menu on this console error: file `/boot/grub2/locale/nl.gmo' not found. ------------------- This is the first reboot after the initial boot of the system and after making some configuration changes in that system. O.a. the default language to be nl_NL. I needed at least 30 minutes to get to the GRUB screen. It looks as if the clock is very slow. On the GRUB screen 10s appeared, which is the initial count down time, but this time is very slowly decreasing. About 5 minutes per second. The USB keyboard does nothing. I finally tried the keyboard on the serial port which started loading the openSUSE image. After 2 hours I got the login screen of XFCE. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
-----Original Message----- From: Freek de Kruijf <freek@opensuse.org> Sent: 27 October 2020 20:47 To: Mailinglist openSUSE ARM <opensuse-arm@opensuse.org> Subject: [opensuse-arm] Extremely slow boot of raspberry pi 4 images
I tried the newest XFCE Raspberry Pi 4 images for openSUSE Leap 15.2 and Tumbleweed. Both are extremely slow to start. I did not have enough patience for Leap 15.2 to see it finish with a log screen, so abandoned that test and continued with the test of Tumbleweed.
There are several error messages during the boot process to explain why it takes so long, but even loading the final linux image takes minutes.
RPi4 is now tested in openQA: https://openqa.opensuse.org/tests/1451651 And there is no such problem. Could you try another uSD card, and/or another RPi4, maybe? Cheers, Guillaume
Below is what I did catch during the start of the boot process:
------------------- U-Boot 2020.04 (Aug 09 2020 - 19:41:12 +0000)
DRAM: 3.9 GiB RPI 4 Model B (0xc03112) MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment
In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 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... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:3... ** Invalid partition 4 ** ** Unrecognized filesystem type ** Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Card did not respond to voltage select! Scanning disk mmcnr@7e300000.blk... Disk mmcnr@7e300000.blk not ready Scanning disk emmc2@7e340000.blk... ** Unrecognized filesystem type ** Found 4 disks BootOrder not defined EFI boot manager: Cannot load any image 1382256 bytes read in 108 ms (12.2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Welcome to GRUB!
Please press 't' to show the boot menu on this console error: file `/boot/grub2/locale/nl.gmo' not found. -------------------
This is the first reboot after the initial boot of the system and after making some configuration changes in that system. O.a. the default language to be nl_NL.
I needed at least 30 minutes to get to the GRUB screen. It looks as if the clock is very slow. On the GRUB screen 10s appeared, which is the initial count down time, but this time is very slowly decreasing. About 5 minutes per second. The USB keyboard does nothing. I finally tried the keyboard on the serial port which started loading the openSUSE image.
After 2 hours I got the login screen of XFCE.
-- fr.gr.
member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Op woensdag 28 oktober 2020 07:57:58 CET schreef Guillaume Gardet:
Hi,
RPi4 is now tested in openQA: https://openqa.opensuse.org/tests/1451651 And there is no such problem.
Could you try another uSD card, and/or another RPi4, maybe?
Once the system is up, it behaves normal/fast. I don't have another RPi4. I could try another uSD, but considering it is fast when it is up I have no hopes. The uSD i use now is a Sandisk Ultra with 128GB and an encircled 10. Also putting the image on it is fast.
Cheers, Guillaume
-- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Op woensdag 28 oktober 2020 16:02:44 CET schreef Freek de Kruijf:
Op woensdag 28 oktober 2020 07:57:58 CET schreef Guillaume Gardet:
Hi,
RPi4 is now tested in openQA: https://openqa.opensuse.org/tests/1451651 And there is no such problem.
Could you try another uSD card, and/or another RPi4, maybe?
Once the system is up, it behaves normal/fast. I don't have another RPi4. I could try another uSD, but considering it is fast when it is up I have no hopes. The uSD i use now is a Sandisk Ultra with 128GB and an encircled 10. Also putting the image on it is fast.
Cheers, Guillaume
Another observation is that another uSD with Raspbian is working normally. Boots in less than a minute. So it is NOT the RPi4. openSUSE shows a number of tests on different partitions, before it finds a bootable image and gives an error message that an image has not been found. Will try the uSD with Raspbian with openSUSE. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hello, I just downloaded the image for my Pi as well and I also recently watched Peter Chubb's from 2015 talk regarding his experience and with SD cards and Linux filesystems. https://www.youtube.com/watch?v=K3zb6p0thQU There he notes that most MCUs and firmwares work with a 4M alignment size. Hence the general recommendation appears to be to keep the MBR table in that first 4M block and align the first partition start to address 4096. This seems to be what the official formatting tool of the SD Association does. When I flashed the current Tumbleweed JeOS image to my SD card with dd I noticed that the partition starts at 2048. Other partition start addresses do not appear to fit into the physical 4M block size either. Swap starts at 133120 (divided by 4098 equals 32.5) and does not align, Root at 11571120 (divided by 4098 equals 2823.60...). So hence to improve performance the alignment of the partitions on the image should be fixed. The question is how. Best regards Tamara On 29/10/2020 09:51, Freek de Kruijf wrote:
Op woensdag 28 oktober 2020 16:02:44 CET schreef Freek de Kruijf:
Once the system is up, it behaves normal/fast. I don't have another RPi4. I could try another uSD, but considering it is fast when it is up I have no hopes. The uSD i use now is a Sandisk Ultra with 128GB and an encircled 10. Also putting the image on it is fast.
Cheers, Guillaume
Another observation is that another uSD with Raspbian is working normally. Boots in less than a minute. So it is NOT the RPi4.
openSUSE shows a number of tests on different partitions, before it finds a bootable image and gives an error message that an image has not been found.
Will try the uSD with Raspbian with openSUSE.
-- Tamara Schmitz SCC Team SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany HRB 36809, AG Nürnberg Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Op donderdag 29 oktober 2020 09:51:10 CET schreef Freek de Kruijf:
Op woensdag 28 oktober 2020 16:02:44 CET schreef Freek de Kruijf:
Op woensdag 28 oktober 2020 07:57:58 CET schreef Guillaume Gardet:
Hi,
RPi4 is now tested in openQA: https://openqa.opensuse.org/tests/1451651 And there is no such problem.
Could you try another uSD card, and/or another RPi4, maybe?
Once the system is up, it behaves normal/fast. I don't have another RPi4. I could try another uSD, but considering it is fast when it is up I have no hopes. The uSD i use now is a Sandisk Ultra with 128GB and an encircled 10. Also putting the image on it is fast.
Cheers, Guillaume
Another observation is that another uSD with Raspbian is working normally. Boots in less than a minute. So it is NOT the RPi4.
openSUSE shows a number of tests on different partitions, before it finds a bootable image and gives an error message that an image has not been found.
Will try the uSD with Raspbian with openSUSE.
I tried the uSD, which works good with Raspbian, with the Tumbleweed JeOS images from Snapshot20200918 and Snapshot20201022 and both show the same behavior as described earlier. Did put Raspbian back on the uSD; works OK. Started a bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1178293 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
30.10.2020 13:06, Tamara Schmitz пишет:
Hello,
I just downloaded the image for my Pi as well and I also recently watched Peter Chubb's from 2015 talk regarding his experience and with SD cards and Linux filesystems. https://www.youtube.com/watch?v=K3zb6p0thQU
There he notes that most MCUs and firmwares work with a 4M alignment size. Hence the general recommendation appears to be to keep the MBR table in that first 4M block and align the first partition start to address 4096. This seems to be what the official formatting tool of the SD Association does.
When I flashed the current Tumbleweed JeOS image to my SD card with dd I noticed that the partition starts at 2048. Other partition start addresses do not appear to fit into the physical 4M block size either. Swap starts at 133120 (divided by 4098 equals 32.5) and does not align, Root at 11571120 (divided by 4098 equals 2823.60...).
So hence to improve performance the alignment of the partitions on the image should be fixed. The question is how.
There is KIWI option <type image="oem" disk_start_sector="XXX" ... Though I am not sure you will see the considerable gain.
Best regards
Tamara
On 29/10/2020 09:51, Freek de Kruijf wrote:
Op woensdag 28 oktober 2020 16:02:44 CET schreef Freek de Kruijf:
Once the system is up, it behaves normal/fast. I don't have another RPi4. I could try another uSD, but considering it is fast when it is up I have no hopes. The uSD i use now is a Sandisk Ultra with 128GB and an encircled 10. Also putting the image on it is fast.
Cheers, Guillaume
Another observation is that another uSD with Raspbian is working normally. Boots in less than a minute. So it is NOT the RPi4.
openSUSE shows a number of tests on different partitions, before it finds a bootable image and gives an error message that an image has not been found.
Will try the uSD with Raspbian with openSUSE.
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (4)
-
Freek de Kruijf -
Guillaume Gardet -
Matwey V. Kornilov -
Tamara Schmitz