Boot arm SBC's - Das Uboot

This forum is dedicated to testing early releases and cauldron : Howtos, tips, tricks and user global feedback and thoughts...

Helpful tip :
For bugs tracking we use : https://bugs.mageia.org = The Mageia Bug Tracker
In this bug tracker you'll find already reported bugs and you'll be able to report those you have found....

Boot arm SBC's - Das Uboot

Postby markvnl » May 30th, '20, 21:02

Playing a bit with my experimental RPI4 mageia-cauldron. Put it to work and compiled uboot-tools and it's odd dependencies (vboot-tools, arm-trusted-firmware) and a few uboot binaries,
among them the (Rockchip) rk3399 which needs a cross compiler because it has an (arm)cortex-m0 on board.

All went well (just a minor dependency name change glib-static > glib-satic-devel) which is nice because the rpi4 is preforming well,
this also means it wouldn't be to hard booting every SBC compatible with mainline-{uboot kernel}

As said before my preference goes out to let uboot load the grub2-efi stub, unfortunately the location where uboot looks for the stub is hard coded;
it would need a patch like this (1) specific for mageia.

My primary question is: can uboot be sure to find grub<arch>.efi in (/boot/EFI/)EFI/mageia/ ?

Do not find "shim" or any fallback xxx.efi on my x86_64 test vm
Secondary question: Is my assumption correct all it needs to porgess booting is loading the grub(2)-efi stub?

**EDIT** update url to proposed mageia specific patch
1) https://github.com/markVnl/rpms-uboot-tools/blob/wip_mga8/uefi-use-Mageia-specific-path-name.patch
Last edited by isadora on May 30th, '20, 21:57, edited 1 time in total.
Reason: Topic moved into appropriate sub-forum.
markvnl
 
Posts: 16
Joined: May 27th, '20, 17:50

Re: Boot arm SBC's - Das Uboot

Postby markvnl » Jun 1st, '20, 22:39

markvnl wrote:My primary question is: can uboot be sure to find grub<arch>.efi in (/boot/EFI/)EFI/mageia/ ?

Secondary question: Is my assumption correct all it needs to porgess booting is loading the grub(2)-efi stub?


Can answers myself: (primary) seems like it, (secondary) yes

Third question:

An attempt to create the stub in a chroot fails: (1)
Code: Select all
grub2-install --target=arm64-efi --efi-directory=/boot/EFI --bootloader-id=mageia --no-bootsector --no-nvram


How can you create the stub in a chroot?

1) https://github.com/markVnl/Mageia_SBC/b ... ga.ks#L119
markvnl
 
Posts: 16
Joined: May 27th, '20, 17:50

Re: Boot arm SBC's - Das Uboot

Postby doktor5000 » Jun 2nd, '20, 17:02

markvnl wrote:Third question:

An attempt to create the stub in a chroot fails: (1)
Code: Select all
grub2-install --target=arm64-efi --efi-directory=/boot/EFI --bootloader-id=mageia --no-bootsector --no-nvram

Could you post the full output of grub2-install please ?
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
----
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
doktor5000
 
Posts: 17630
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: Boot arm SBC's - Das Uboot

Postby markvnl » Jun 2nd, '20, 17:56

doktor5000 wrote:Could you post the full output of grub2-install please ?



Code: Select all
grub2-install: error: failed to get canonical path of `/dev/mapper/loop0p1'.


Its probably because {dev proc sys} are not mounted by the appliance creator (EDIT: part off appliance-tools).
(full log off events) https://gist.github.com/markVnl/a2335b1 ... a-log-L274

I"v mitigated it by remounting the new created image including {dev proc sys} of the host system on a loop device and ran the command again:
chroot ${tmp} /bin/bash -c "/usr/sbin/grub2-install --target=arm64-efi --efi-directory=/boot/EFI --bootloader-id=mageia --no-bootsector --no-nvram"
https://github.com/markVnl/Mageia_SBC/b ... img.sh#L40

In other words it is a kind of solved.

Unfortunately something of same seems to happen installing the kernel, the kernel scriplet fails with:

Code: Select all
Undefined subroutine &main::SYS_mknod called at /usr/share/perl5/vendor_perl/MDK/Common/System.pm line 357.

https://gist.github.com/markVnl/a2335b1 ... a-log-L172
Hense initrd is created manualy..


Nevertheless;
A uboot-based install is running the default magiea cauldron aarch64 kernel-desktop on a Raspberry PI 3+.
Not on my odroid-c2 though, only one driver seems to be missing: :oops:
https://gist.github.com/markVnl/a2335b1 ... ktop-L8612
markvnl
 
Posts: 16
Joined: May 27th, '20, 17:50

Re: Boot arm SBC's - Das Uboot

Postby markvnl » Jun 9th, '20, 19:41

markvnl wrote:A uboot-based install is running the default magiea cauldron aarch64 kernel-desktop on a Raspberry PI 3+.
Not on my odroid-c2 though, only one driver seems to be missing


Actually for the odroid-c2 the issue is much simpler :D not so easy to mitigate though: :cry:

Uboot-autoboot on aarch64 (arm64) expects the device tree in a different location as packaged in /usr/lib64/linux<kernel_version>.
In this folder all the dtb's are packaged in the root of this folder,. On aarch64 however it is custom to place them in <manufacturer>/...dtb,
For instance for the odroid-c2 uboot looks for (dtb)/amlogic/meson-gxbb-odroidc2.dtb , this location more-or-less corresponds with the kernel source:
https://github.com/torvalds/linux/tree/ ... ts/amlogic

Note the difference between arm and arm64, on arm it's custom to place the dtb's in the root...
(Again) more-or-less the location corresponding with the kernel source:
https://github.com/torvalds/linux/tree/ ... m/boot/dts

After moving meson-gxbb-odroidc2.dtb to dtb/amlogic/ the odroid it boots and you can (ssh) login..

My question:
What was the rationale to deviate from the the kernel-source proposed default location in the Mageia (cauldron) kernel-package?

(hope it's clean what I mean..)
Grtz mark
Last edited by doktor5000 on Jun 10th, '20, 23:31, edited 1 time in total.
Reason: fixed quote
markvnl
 
Posts: 16
Joined: May 27th, '20, 17:50

Re: Boot arm SBC's - Das Uboot

Postby markvnl » Jun 12th, '20, 15:01

Also took a shot at amr7hl to find out the kernel is not compiled with the efi-stub. To my understanding is is possible to build a zImage with the efi stub included and it should not intervene with other loading methods.
A further look into the arm kernel config learned it is (from a arm perspective) not explicitly generic; quite a lot "CONFIG_ARCH-xxxx" are not set. At the first glance from the wellknown/used SOC's just Broadcom's rpi (BCM2835) and the Allwiner family (SUNXI) are set.

This makes it not feasible to pursue a generic-image which boots a lot of boards once taken care of a recent (mainline) uboot.

As said on the aarch64 side of this the packaging of the dtb's does not match; (strange enough this kernel seems to be more generic)

IMHO the make target dtbs_install of the kernel's makefile should be invoked rather than "find" *.dtb.

Not being familiar with Mageia packaging (nor knowing the difference between %{make}, %smake or %kmake) it could look something like this (L1141):
Code: Select all
%ifarch %{arm} aarch64
    install -d %{temp_root}%{_libdir}/linux-$KernelVer/
    %smake ARCH=%{target_arch} dtbs_install INSTALL_DTBS_PATH=%{temp_root}%{_libdir}/linux-$KernelVer
    find arch/%{target_arch}/boot/dts -name '*.dtb' -type f -delete
%endif

(And a adaption in the %files section)


In the end;

Most worrying and hard to mitigate is the behavior of the kernel install-scriplets installkernel and bootloader-config.

In my experience so far they act quite unpredictable in a chroot moreover
it seem to be impossible to hook in this procedure to (as an example) move the devicetree directory to a location U-boot autoboot will find them.
Correct me if I'm wrong,
Under the impression the scripts ignore /lib/kernel/install.d and cannot see any other method calling an kernel_add.d or kernel_remove.d elsewhere.



Grtz mark
markvnl
 
Posts: 16
Joined: May 27th, '20, 17:50

Re: Boot arm SBC's - Das Uboot

Postby markvnl » Jun 20th, '20, 22:43

There is a prove of concept for uboot > grub2-efi on armv7hl too (1);

However just can not get it done with the grub-efi (armv7hl) from the cauldron repository.
This is no surprise as it does not work for me on Fedora and CentOS 8 too, and the build of that package is so opaque I can't figure out why..

* It runs a test kernel build with the efi-stub enabled;
* It has an (close to upstream) minimal grub2, (as said) can not get it up with grub2 of the main repository's;
* It has Raspberry PI's bcm28XX firmware and uboot for RPI{2,3,3+} pre installed; just flash and boot;
* It proved to boot an OrgangePI plus 2E too, but that's about it.;

All custom build packages are included in local repository found in /home/repository/mageia


NOTE: this pre-release might be short-lived as it is just a prove of concept

1) https://github.com/markVnl/Mageia_SBC/r ... hl-efi-poc
markvnl
 
Posts: 16
Joined: May 27th, '20, 17:50


Return to Testing : Alpha, Beta, RC and Cauldron

Who is online

Users browsing this forum: No registered users and 1 guest