You are not logged in.
Ok, to fix the wrong UUIDs in the grub configuation, it is necessary to go into the chroot environment, mount the sd card partitions, run update-initramfs and update-grub. Make sure you mounted dev, proc and sys in the directories of your chroot environment before running the following commands on it:
First mount the SD card partitions in place of the rootfs in the chroot environment:
mount /dev/SDCARDp2 /
mount /dev/SDCARDp1 /bootThen update the initial ramdisk:
update-initramfs -uThen finally update-grub:
update-grubAfter that, unmount the sd card partitions:
umount /boot
umount /With these steps I was able to get a working grub configuration that is able to load the kernel and the inital ramdisk.
However, the kernel won't boot because it cannot allocate memory for uncompressing itself. The messages seen on the screen for just a few miliseconds before returning to grub were:
EFI stub: ERROR: Unable to allocate memory for uncompressed kernel
EFI stub: ERROR: Failed to relocate kernelSomething is definetly missing. U-boot is acting as EFI (at least when loading grub), so maybe a module for memory management needs to be compiled into it, if u-boot is still the part that is responsible for EFI stuff after loading grub.
Another error corrected: Do not provide any configuration file to grub-mkimage since it is executed before grub enters normal mode, as described here:
https://www.gnu.org/software/grub/manua … ation.html
Current grub-mkimage command line:
grub-mkimage -p '(hd0,msdos1)/grub/' -O arm-efi -o /boot/efi/boot/bootarm.efi fat ext2 probe terminal scsi ls linux elf part_msdos search normal help echo loadenv parttool boot configfile disk fdt file fshelp gfxmenu halt jpeg lsefi msdospart png reboot search_fs_file search_fs_uuid testCurrent status: Grub can read partitions now but the boot entries for the Linux kernel probably have the wrong uuids. Running update-grub in a chroot environment on the SD card with a mounted boot partition could fix this.
I found out why Grub is so "incomplete": I included the wrong configuration file. It isn't /etc/default/grub, it's /boot/grub/grub.cfg, the config file you're no supposed to edit Now Grub is showing me the standard boot screen, bit it cannot find the kernel, probably because the UUID of the partition in the chroot environment differs from the uuid of the real partition.
I'm stuck at getting Grub working:
- Grub is loading with the minimal configuration (text mod with a few commands)
- Grub detects the SD card (hd0), but cannot find any partitions on it
- The driver for hd0 is "efidisk"
- The probe command of Grub cannot detect the partition map type or a filesystem type.
- I have a grub.cfg in /boot/grub.
- /boot/grub/grubenv exists and is filled with hash characters.
I am building the grub image using this grub-mkimage command now:
grub-mkimage -p '(hd0)/boot/grub' -c /etc/default/grub -O arm-efi -o /boot/efi/bootarm.efi fat ext2 probe terminal scsi ls linux elf part_msdos search normal help echo loadenv parttool boot configfile disk fdt file fshelp gfxmenu halt jpeg lsefi msdospart png reboot search_fs_file search_fs_uuidAm I missing a grub module?
Ok, for all others in this forum:
Grub can be loaded from u-boot using the automatic efi boot functionality of u-boot. After you installed the grub-efi-arm package in your RootFS (either a chroot environment or a real one), you can build a grub image almost the same way as described in the section "GRUB for ARM" in the following source:
https://www.hellion.org.uk/blog/posts/g … t-on-qemu/
The difference is that you use arm-efi instead of arm-uboot as the value for the O parameter of grub-mkimage to build the grub image. Modified example from the source above:
grub-mkimage -p /boot/ -c $CONFIGFILE -O arm-efi -o /boot/efi-img fat ext2 probe terminal scsi ls linux elf msdospart normal help echoAfter you built it, place it in the folder efi/boot/ of your boot partition and rename the grub image to "bootarm.efi". If you still have any u-boot configuration file (boot.scr.uimg) on the boot partition, remove it.
With these steps you should be able to boot into grub. This is as far as I have come so far. Once the grub configuration is present, it should be possible to boot a standard vmlinuz kernel image.
From all the research, it seems that Grub is necessary between the Linux kernel and u-boot.
Or is there a way to load a vmlinuz binary direcly from u-boot?
I did some more research: objcopy cannot read the file since vmlinuz files are compressed using zlib. Furthermore, they are self-extracting. There is a vmlinuz-extract script in the Linux kernel sources but it doesn't work for ARM vmlinuz images.
Sources:
- https://unix.stackexchange.com/question … mlinux-vml
- https://unix.stackexchange.com/question … -arm-image
In the meantime, I found these instruction in the u-boot manual to convert a vmlinuz image to an uImage:
https://www.denx.de/wiki/view/DULG/HowC … omAELFFile
The problem is that objcopy says that it doesn't recognise the file format. I tried objcopy, arm-none-eabi-objcopy and arm-linux-gnueabihf-objcopy. All three give the same message. I called objcopy like this:
objcopy -O binary vmlinuz-4.19.0-9-armmp vmlinuz-4.19.0-9-armmp.binThe response is:
objcopy:vmlinuz-4.19.0-9-armmp: file format not recognizedWhy does objcopy not recognise the format?
you can download my binary image, mount it on the main host and see how uboot config done and do something like it for yourself:
Your image is compressed using rar. I do not have tools to extract such exotic compression formats.
Could you instead please just post the u-boot boot script from your image here?
How did you convert the Devuan vmlinuz kernel image to the zImage that u-boot from the Arch linux images boots?
TL;DR: Use the EFI variant of Grub between U-Boot and the kernel. It probably won't work on the Raspberry Pi, but on other ARM boards.
Original post below:
------------
Hello
I'm trying to start the vmlinuz-...-armmp-Kernel from the armhf package repository on a Raspberry Pi 2 using u-boot. The goal is to boot the standard Devuan Kernel that is updated via the package management to avoid recompiling the kernel by myself every time a security issue is fixed. U-boot is used to be able to use the free (libre) Raspberry Pi firmware from https://github.com/christinaa/rpi-open-firmware .
Currently I'm stuck at the point where u-boot tries to load the kernel. If I use the configuration file from the following source, the system freezes when u-boot tries to start the kernel (the "Starting kernel ...“ line):
https://elinux.org/RPi_U-Boot#Booting_from_an_SD_card
I looked into the u-boot boot script from the Devuan ascii image for the sunxi platform and switched to hard coded addresses to load the vmlinuz-...-armmp image. However, the same message appeared.
This following is the current state of the u-boot boot script. The device tree file is from u-boot.
setenv fdtfile bcm-2836-rpi-2-b.dtb
load mmc 0:1 0x4200000 vmlinuz-4.19.0-9-armmp
load mmc 0:1 0x4300000 ${fdtfile}
setenv bootargs earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
bootz 0x4200000Do I have to load the vmlinuz-...-armmp image to a special address or do I miss something in the u-boot boot script?
Regards
Moritz
Hello
I'm currently attempting to fork the SLiM desktop manager. The fork is called "Schlimm" (Simple configurable human login management module) and its source code is available at codeberg.org:
https://codeberg.org/ncc1988/schlimm
The initial motivation for the fork was that SLiM or its themes don't work well on HiDPI displays and I wanted to fix that. Since the original project is unmaintained with no commit since 2013 [1], I started to look at the source code to figure out how HiDPI support may be added. That in turn lead to code refactorisation that is still in progress. The code gets rewritten in a unified coding style (PSR-1 and PSR-2, as far as applicable) and standalone functions are moved into classes. Another part of the refactorisation is translating the C++03 code to modern C++ (C++20, as far as I know it).
During refactorisation, I started thinking that an unmaintained project like SLiM could in the future be removed from GNU/Linux repositories because external dependencies may be replaced: X11 -> Wayland, PAM -> elogind/logind, etc. So it might be necessary to prepare for these new libraries without removing support for established libraries which is why I think about adding interfaces between Schlimm and external dependencies so that they can be replaced more easily.
Are there features you miss in SLiM? Do you have ideas for features that shall be included in the fork?
I'm currently collecting ideas that could improve Schlimm, so feel free to tell me about them :-)
Regards
Moritz