You are not logged in.
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 0x4200000
Do 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
Last edited by mstrohm (2020-09-06 10:33:56)
Offline
I have found https://archlinuxarm.org/ the most useful to get a working uboot and its config file for any popular ARM device.
Then I have just replaced root dir to Devuan debootstrap done on X86 Devuan and then configured in a X86 chroot with ARM qemu-guest, replaced the kernel to a generic ARM from Devuan and it worked fine for me at least on Cubietruck.
Last edited by bimon (2020-05-14 05:39:20)
Offline
How did you convert the Devuan vmlinuz kernel image to the zImage that u-boot from the Arch linux images boots?
Last edited by mstrohm (2020-05-16 08:37:33)
Offline
I already do not remember which kernel exactly I have used last time, I do not use ARM board right now to look at it, 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:
https://dev1galaxy.org/viewtopic.php?id=3081
May be this thread could be moved to ARM builds?
It shall contain about two partitions, you can mount binary as a loop device or dd it to a zvol, then do partprobe on that device and then you can mount its specific partition, most likely the first one which is boot.
Last edited by bimon (2020-05-16 09:19:00)
Offline
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?
Offline
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.bin
The response is:
objcopy:vmlinuz-4.19.0-9-armmp: file format not recognized
Why does objcopy not recognise the format?
Last edited by mstrohm (2020-05-16 09:49:10)
Offline
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
Offline
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?
Last edited by mstrohm (2020-05-16 12:23:59)
Offline
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 echo
After 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.
Last edited by mstrohm (2020-05-16 13:06:12)
Offline
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?
I do not have it right now on my host computer and Cubietruck is far in a boxroom.
To uncrompress rar archive you can just do following:
apt-get install rar
rar x archive.rar
It is in the package:
https://packages.debian.org/stretch/rar
Offline
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_uuid
Am I missing a grub module?
Offline
I did not try GRUB on ARM,
btw. may be Uboot can do menus somehow? May be some forked version exists?
I would prefer to run kernel directly from Uboot, but having a menu with kernel/settings choices.
Or may be an easier boot loader exists like grub4dos for ARM?
Offline
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.
Offline
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 test
Current 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.
Last edited by mstrohm (2020-05-17 13:25:25)
Offline
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 /boot
Then update the initial ramdisk:
update-initramfs -u
Then finally update-grub:
update-grub
After 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 kernel
Something 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.
Offline
After reading the following thread on the Linux Kernel mailing list and reading the thread of the GitHub issue mentioned there, it seems that the memory allocation problem is specific to the Raspberry Pi.
https://lkml.org/lkml/2019/8/2/57
https://github.com/raspberrypi/firmware/issues/1199
Offline
my experiences with raspberry 1 and using u-boot:
1. Get https://files.devuan.org/devuan_ascii/e … pi1.img.xz
or from
https://files.devuan.org/devuan_ascii.torrent
2. on raspi 1:
sudo apt-get install u-boot u-boot-rpi linux-image
sudo cp /usr/lib/u-boot/rpi/u-boot.bin /boot/
echo kernel u-boot.bin >> /boot/config.txt
sudo apt-get install u-boot-menu
sudo mkdir /boot/extlinux/; sudo touch /boot/extlinux/extlinux.conf
edit /etc/default/u-boot, especially U_BOOT_PARAMETERS whitch corresponds to /boot/cmdline.txt
finally:
sudo u-boot-update
Key fingerprint = 90B5 1002 CAD8 3943 AFD9 3F91 88EF A14F 0F5A FA96
Offline
@florine:
I think, we have different approaches here. I try to build my Devuan system "from scratch" using multistrap. Regarding the boot process, I'm attempting to start my ARM boards just like x86 hardware by letting U-Boot load Grub first so that no extra steps after upgrading the kernel will be required.
Offline