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.
]]>