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.

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

https://lkml.org/lkml/2019/8/2/57
https://github.com/raspberrypi/firmware/issues/1199

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.

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.

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?

- 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?

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

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.

Or is there a way to load a vmlinuz binary direcly from u-boot?

Sources:

- https://unix.stackexchange.com/question … mlinux-vml
- https://unix.stackexchange.com/question … -arm-image

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?

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?

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.