[U-Boot] RFC: Alternative boot_jump_linux() function

Sun May 27 13:01:52 UTC 2018

Ramon, Tom,

On Sat, May 26, 2018 at 7:58 AM, Ramon Fried <ramon.fried at gmail.com> wrote:

> On Sat, May 26, 2018 at 5:18 AM, Tom Rini <trini at konsulko.com> wrote:
> > On Fri, May 25, 2018 at 05:41:31PM +0300, Ramon Fried wrote:
> >> On Fri, May 25, 2018 at 3:11 PM, Tom Rini <trini at konsulko.com> wrote:
> >> > On Thu, May 17, 2018 at 07:48:45PM +0300, Ramon Fried wrote:
> >> >> On Thu, May 17, 2018 at 5:22 PM, Tom Rini <trini at konsulko.com>
> wrote:
> >> >> > On Thu, May 17, 2018 at 02:01:55PM +0300, Ramon Fried wrote:
> >> >> >
> >> >> >> Hi.
> >> >> >> I'm currently working on snapdragon bootloader support and in the
> >> >> >> particular case where U-boot is running in Aarch32 and the kernel
> is
> >> >> >> Aarch64 the specific implementation is to jump to Linux through
> SCM
> >> >> >> call.
> >> >> >>
> >> >> >> I try to find the best possible way to provide an alternative
> boot function.
> >> >> >> Adding #ifdef ARCH_SNAPDRAGON will just be too specific in
> >> >> >> arm/lib/bootm.c in my opinion and I'm thinking of introducing
> kind of
> >> >> >> a callback function in gd. that if exists will jump there instead
> of
> >> >> >> executing boot_jump_linux().
> >> >> >>
> >> >> >> What do you think ?
> >> >> >
> >> >> > So, to be clear, we're on an aarch64 SoC, but U-Boot has been
> entered in
> >> >> > 32bit mode.  And we need to boot a 64bit Linux Kernel.  What else,
> if
> >> >> > anything, is also loaded/still in residence/etc?  Can you explain
> the
> >> >> > overall usecase a bit more and why we're in 32bit mode?  Thanks!
> >> >> >
> >> >> OK.
> >> >> Basically, Qualcomm has the following boot flow:
> >> >>
> >> >> PBL -> SBL -> LK -> Linux Kernel
> >> >>
> >> >> PBL - 32bit Primary boot loader(ROM) loads the SBL from eMMC.
> >> >>
> >> >> SBL - 32bit Secondary boot loader(eMMC/UFS), proprietary closed
> source,
> >> >> Initializes the DDR, starts the trustzone and can load either a 32bit
> >> >> or a 64bit (1)
> >> >> ELF bootloader, given that it's signed.
> >> >>
> >> >> LK - Little kernel, 32bit. Qualcomm maintains a downstream version,
> open source.
> >> >> Loads 64bit Android boot image from eMMC and jumps to it using SMC
> >> >> call made to Trustzone.
> >> >>
> >> >> This was used primarily for Android, but when Dragonboards boards
> came
> >> >> out, Qualcomm and Linaro started
> >> >> distributing 64bit Linux OE & Debian builds that were booted by LK.
> >> >> Because U-boot is much more useful than LK, the first U-boot
> >> >> contribution was made by Mateusz Kulikowski.
> >> >>
> >> >> Basically, Mateusz port is wrapping U-boot to appear as a kernel so
> LK
> >> >> boots it, then it boots Linux.
> >> >> So basically, LK did the 32 -> 64 transition.
> >> >>
> >> >> Now, here where I appear in the story... :)
> >> >
> >> > Thanks for the detailed background.
> >> >
> >> >> I'm trying to get rid of LK and use U-boot as the real bootloader
> for Linux.
> >> >> I succeeded in that, and I have all the patches ready for submission,
> >> >> I just need to add a dedicated boot function
> >> >> that does the SMC call, hence this discussion.
> >> >>
> >> >> (1) - It implies that we can in practice just use 64bit U-boot for
> Snapdragon.
> >> >> The only problem I have right now is that there's isn't any
> >> >> open-source tool to sign the Bootloader that supports ELF64
> >> >> executable.
> >> >
> >> > Is it possible to just write that tool, or update an existing tool to
> do
> >> > that signature?
> >> Yes. It should be possible.
> >>
> >> Actually, when I did have access to qcom internal tool for doing so I
> >> was able to run U-boot
> >> on 64bit mode. I had problems booting the kernel, as after the boot
> >> weird things were happening,
> >> like other cpu weren't responding, eMMC driver wasn't working etc.
> >> I suspect it's related to low level initialization that was lacking,
> >> or something similar.
> >>
> >> I ended up working on the 32bit mode because I no longer have access
> >> to the internal tool.
> >> I believe that in the end we will end up with a working 64bit version.
> >> I'm just thinking that meanwhile It maybe worthwhile to also have the
> >> 32bit version.
> >>
> >> What do you think ?
> >
> > How long might we be in this interim odd spot?  It sounds like we need
> > some odd hoops to go and be able to boot a 64bit Linux when we're in
> > 32bit mode.  If this is just for a short period of time, maybe we just
> > accept that the Linaro tree will have to hold a patch or two for now
> > until we can just be a good and clean 64bit binary?
>
> I added Nicolas from Linaro to the thread so he can comment regarding
> the signing tool.
>

thanks Ramon, for the very good and information data above!

>
> I agree with you that the jump through SCM call is very specific.
> I didn't send any of the 32bit patches yet, I was waiting to see if
> the required supported
> changes will get accepted.
> It's up to you to decide if you're willing to accept that as in
> intermediate solution until we get
> a working 64bit version.
> I do know that there is high demand in the community for such support.
>
> The 32bit potentially waiting to be upstreamed is in my github repo here:
> https://github.com/mellowcandle/u-boot/tree/upstream

I have looked at the QCOM signing scripts, and I think they are now fixed
and should work for ELF32 and ELF64. So we should be good to go with uboot
built for aarch64!

>
>
> Thanks,
> Ramon.
>
> >
> > --
> > Tom
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>