<div dir="ltr">The grub in buster already has all of the fixes like Ubuntu 18.04. It properly loads device tree from systab passed from firmware. This is a pretty important issue for simply booting arm systems so I don't know if it is worth it to backport the capability into the current grub or just not use stretch for any arm systems. We hacked around this but I would imagine it would save a lot of time for others to backport the arm64/armhf bits I mentioned.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 26, 2019 at 2:32 PM Colin Watson <<a href="mailto:cjwatson@debian.org">cjwatson@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Feb 12, 2019 at 01:59:23AM +0000, Da Xue wrote:<br>
> Package: grub-efi-arm<br>
> Version: 2.02~beta3-5+deb9u1<br>
> Severity: important<br>
> <br>
> Dear Maintainer,<br>
> <br>
> <br>
>    * What led up to the situation?<br>
>    Install grub (bootarm.efi) and update-grub on armhf system.<br>
> <br>
>    * What exactly did you do (or not do) that was effective (or<br>
>      ineffective)?<br>
>    We pass the device tree from u-boot to GRUB2 via UEFI systab. It is<br>
>    not automatically used by the current version of grub so we have to<br>
>    manually execute "devicetree" and point it to a device tree binary <br>
>    file. However even with this manual intervention, the kernel still <br>
>    hangs. The problem does not occur on arm64 systems or the GRUB2 <br>
>    version in Ubuntu 18.04.<br>
<br>
Could you try version 2.02+dfsg1-9 or newer, from buster?  It has a very<br>
substantial reworking of the Linux loader on arm, so it'd be good to<br>
determine whether it suffers from the same problem.<br>
<br>
Thanks,<br>
<br>
-- <br>
Colin Watson                                       [<a href="mailto:cjwatson@debian.org" target="_blank">cjwatson@debian.org</a>]<br>
</blockquote></div>