Ramon, Tom, On Sat, May 26, 2018 at 7:58 AM, Ramon Fried <ramon.fr...@gmail.com> wrote:
> On Sat, May 26, 2018 at 5:18 AM, Tom Rini <tr...@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 <tr...@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 <tr...@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@lists.denx.de > https://lists.denx.de/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
