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

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180525/dfb1e7e4/attachment.sig>