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

Ramon Fried ramon.fried at gmail.com
Sat May 26 05:58:01 UTC 2018


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.

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

Thanks,
Ramon.

>
> --
> Tom


More information about the U-Boot mailing list