This is a ticket to sum-up and link other tickets. I'm starting to dig into the Rpi problems, and here my findings: The used DTB are either from the Linux kernel project or Das U-Boot bootloader project, build from their respective DTS. But the Raspberry-pi project does not provide the DTS but only the DTB. The Raspberry-pi firmware (start.elf) starts by reading the config.txt file, then the dtb, do some manipulation with the overlayers and provide the result to U-Boot. U-Boot provides the dtb as it to Grub2 which provides also as it to the kernel. From u-boot channel, the use of dtb from uboot or kernel from retro-engineering is discouraged and leads to troubles. This is probably the root cause of many problems for the Rpi Iso, like usb keyboard not working. Using the upstream closed-source dtb from Rpi project provide a working usb stack to u-boot, but this dtb specify a restricted area that prevent u-boot from loading the .efi file (current size 29000h, it should be less than 25000h (151552 bytes)). Open question : - How to reduce the .efi file size? (I manage to light up one; but landed into grub rescue> not able to load the stage2.) - Should we rework the boot process (currently firmware -> u-boot -> grub2 -> kernel for the flexibility of kernel update, as the first stages would remain static) ?
Depends on: (none) => 32159
Depends on: (none) => 32160
Depends on: (none) => 30243
Depends on: (none) => 28572
Depends on: (none) => 26277, 29560
On Rpi4, wpa_supplicant could not connect to wifi : - bug https://bugs.mageia.org/show_bug.cgi?id=32160 On Rpi4, there is a long boot : - bug https://bugs.mageia.org/show_bug.cgi?id=26277 - https://bugs.mageia.org/show_bug.cgi?id=29560
The rpi devices do not use an iso. They use images that must be copied to the sd card, such as http://mirror.math.princeton.edu/pub/mageia/distrib/9/aarch64/install/images/ from last April. What have you been testing with? The best way to test them for now is to use an mga8 image and then upgrade it to m9. One way to upgrade is to use "killall mgaapplet" followed by "mgaapplet --testing".
CC: (none) => davidwhodgins
I've requested updated images be produced, on the sysadmin discuss ml.
So where do we assign this?
Hardware: All => aarch64CC: (none) => lewyssmith
Assigning to iso builders group, though aarch64 uses dd images, not iso images. It that's wrong, please reassign appropriately.
Assignee: bugsquad => isobuild
Just repeated my upgrade test on an rpi 4b. Copied a working m8 plasma install to a new sd card, booted that and used urpmi to upgrade. Zero bugs noticed. On reboot it's working perfectly so far.
OK but what are you supposed to do if you don't have a working Mga8 image? The one in the repo from Feb 2021 does not boot in a RPi4b. Error message says: ----snip start4.elf is not compatible This board requires newer software ----snip Is copying a newer start4.elf etc. from e.g. a working raspbian system likely to work any better than it does with the Mga9 image?
CC: (none) => zen25000
Short answer: no. I copied across 8 files: fixup4* start4*.elf Only output was: Net:eth0: ethernet@7d580000 PCIe BRCM: link up, 5Gbps x1 (SSC) starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device ERROR: memory not allocated The Mga9 version did get to a login albeit without keyboard.
Summary: Rpi ISO are not working => Rpi images are not working
Yes... Working on it. It is useless to generate new images right now as long as I did not solve the major issues. I assign it to me instead of isobuild team.
Assignee: isobuild => j.biernacki+mga
From lshw on my working rpi 4b, currently back to running m8. *-firmware description: BIOS vendor: U-Boot physical id: 0 version: 2020.10 date: 02/02/2021 I guess newer versions of the 4b are different enough not to work. The only part that doesn't work on mine in Mageia is sound via hdmi. It works in raspberian, but not in Mageia 8. I haven't tested the sound in m9 yet. The monitor I normally use for it doesn't have speakers, so have to hook it up to my tv to test sound.
CC: lewyssmith => (none)
CC: (none) => filip.komar
\o/ Il n'y a plus qu'à. I was able to boot Mageia with USB support, I was able to mount a USB key. When using proprietary DTB (B for blob, not open source), our u-boot refuses to load the efi as it will overwrite reserved sections. From u-boot, one can solve the issue by: > env save > env set kernel_addr_r 0x00001000 > env save loading from address 1000h instead of 80000h provide enough space to load the efi and boot grub, then grub the initrd and kernel... What needs to be done: On mageia4arm project; copy the bananapro lines which extract and save the default environment of uboot into the root of the FAT boot partition, set the path to the environment file in /etc then use the uboot tools to overwrite set kernel_addr_r with 0x00001000. (If I remember correctly) I will not do it tonight; good night
As we modify the environment variable, we might set the grub efi file to mageia's one as in x86_64 /efi/mageia/grubx64.efi instead of /efi/BOOT/bootaa64.efi
By the way; I don't know what I did wrong at the first time, I got this output, I'm not yet able to debug/understand. Loading Linux 6.4.8-desktop-4.mga9 ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... "Synchronous Abort" handler, esr 0x96000005 elr: 00000000000b5734 lr : 00000000000b564c (reloc) elr: 000000003df87734 lr : 000000003df8764c x0 : 0000000300905a4d x1 : 000000003db40124 x2 : 0000000000000004 x3 : 000000003df8761c x4 : 000000003db56430 x5 : 000000003db56430 x6 : 000000000000005f x7 : 000000003db40130 x8 : 000000000000003f x9 : 000000003804aa88 x10: 0000000000000004 x11: 000000000000dc00 x12: 0000000000001450 x13: 000000003c918e34 x14: 0000000000000001 x15: 000000003ca445c1 x16: 000000003df8761c x17: 0000000000000000 x18: 000000003db4dd70 x19: 0000000000000004 x20: 0000000000000000 x21: 0000000000000004 x22: 000000003db40124 x23: 0000000080000020 x24: 00000000ffffffff x25: 0000000000000000 x26: 0000000000000007 x27: 0000000000010000 x28: 0000000000000000 x29: 000000003db3ffd0 Code: 1400000a d2803e80 9400a696 f9400280 (b9401800) UEFI image [0x0000000036660000:0x0000000036688fff] '/\efi\BOOT\bootaa64.efi' Resetting CPU ... resetting ...
Back on this topic: Finally; the grub generates the efi file at the u-boot's default path. I only modify the preboot avoiding to spend time scanning usb devices and the kernel load address for uboot's environment variable. Current state: The boards loads and execute correctly the firmware (bootcode.bin + start*.elf) The firmware loads correctly the dtb and the u-boot.bin and executes it correctly u-boot.bin loads and executes correctly the first stage of grub (bootaa64.efi) grub loads and execute correctly grub second stage (printing the menu of the different mageia and edition of the kernel command line) grub loads correclty the kernel and the initrd and executes the initrd... The initrd fails to mount /proc and kernel-panic. The given hint : > mount: error while loading shared libraries: libmount.so.1: cannot open shared object file: No such file or directory > Cannot mount proc on /proc! Compile the kernel with CONFIG_PROC_FS! is misleading I think because : > grep CONFIG_PROC_FS /run/media/[...]/boot/config-6.4.9-desktop-4.mga9 > CONFIG_PROC_FS=y But I tried to regenerate an mga8 image and I've the same error, so I'm thinking about an error in the generation of the initrd on my machine and a bug in the mageia4arm project.
Depends on: (none) => 24084
Depends on: (none) => 28818
URL: (none) => https://wiki.mageia.org/en/Installing_Mageia_on_ARM_(Raspberry_PI)
Back after many trials. It seems that the generation of the initrd on a x86_64 machine with chroot+qemu fails. I took an old image with handmade workarround, git clone mageia4arm and generate an rpi-aarch64 image, burn the image on the sd card from the laptop. It boots ! When booted, first steps : - define a root password - regenerate an initrd (avoid 3minutes timeout) : dracut -f - fix wpa_supplicant (comment the line setting wrong frequency) - define wifi configuration : wpa_passphrase - connect to wifi: wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf & - get an ip address : dhclient - enlarge the root partition: -- install cloud-utils-growpart -- growpart /dev/mmcblk0 2 -- resize2fs /dev/mmcblk0p2 - install drakconf - set the network with drakconf, because it works better at reboot : mmc - define the firewall (on mmc, section firewall) - add a user (adduser) - add your ssh key to your user user friendly :D
So currently, for arm images, isobuild team needs to ensure the generation on aarch64 machine. Sorry
Depends on: (none) => 32526
(In reply to Jybz from comment #15) > Back after many trials. Sounds familiar. > It seems that the generation of the initrd on a x86_64 machine with > chroot+qemu fails. > > I took an old image with handmade workarround, git clone mageia4arm and > generate an rpi-aarch64 image, burn the image on the sd card from the laptop. > > It boots ! Nice! Can you be more specific: 1. on which board it works? 2. are any images somewhere online? is it on our mirrors like: http://mirrors.kernel.org/mageia/distrib/9/aarch64/install/images/ 3. did you fix mageia4arm or did you use another "handmade workarround"? What was it? I would like to test it ;). I have 3B, 4B and 5.
Hi, i've a 4B and 5B (waiting for uboot). No need for 3B, i can buy one on wednesday if required. I worked on mageia4arm. https://gitweb.mageia.org/software/mageia4arm/commit/?id=a3b81566b3b730e0a3bc3e768a40498b230bf524 I'm not sysadm, i can not re-generate the images from arm servers. Jybz
Hello, any success on rpi 3b? mine boots fine but the keyboard doesn´t work so I can´t do anything. Does somebody knows if openssh-server is activated? This would be great,
CC: (none) => ezequiel_partida
I pushed on master a fix, tested with Rpi3. There is still one thing to fix: the dracut generation of initrd that takes the build machine drives, thus there is a delay when the rpi start; not finding build machine drives...