On Wed, Apr 14, 2021 at 08:37:07PM +0100, Simon Glass wrote: > Hi, > > On Tue, 13 Apr 2021 at 09:32, Alex G. <mr.nuke...@gmail.com> wrote: > > > > ## Introduction > > > > Today we use "falcon mode" to mean "boot linux straight from SPL". This > > designation makes sense, since falcons "fly at high speed and change > > direction rapidly" according to Wikipedia. > > > > The way we implement falcon mode is to reserve two areas of storage: > > * kernel area/partition > > * dtb area/partition > > By using some "special cases", and "spl export", SPL can more or less > > figure out how to skip u-boot. > > > > > > ## The plot twist > > > > People familiar with FIT, will have recognized that the above is > > achievable with a very basic FIT image. With some advantages: > > > > - No "special cases" in SPL code > > - Signed kernel images > > - Signed kernel devicetree > > - Devicetree overlays > > - Automatic selection of correct devicetree > > > > > > ## The problems > > > > The advantages of FIT are not obvious by looking at SPL code. A > > noticeable amount of SPL code is hidden under #ifdef CONFIG_SPL_OS_BOOT, > > leading one to believe that SPL_OS_BOOT is very important. It must be > > since it takes up so much code. > > > > Enabling falcon mode is not well documented, and requires a lot of trial > > and error. I've had to define 7 macros, and one new function to get it > > working on my board -- and vividly remember the grief. This is an > > antiquated way of doing things, and completely ignores the u-boot > > devicetree -- we could just as well have defined those seven values in > > the dtb. > > > > SPL assumes that it must load u-boot, unless in instances under > > CONFIG_SPL_OS_BOOT. This has cause me a huge amount of grief and > > confusion over the past several months. I have no less than three patch > > series trying to address shortfalls there. It's awful. > > > > > > ## The proposal > > > > I propose we drop falcon mode support for legacy images. > > > > - Drop CONFIG_SPL_OS_BOOT. Support for this is implied by SPL_FIT > > - Drop the "dtb area/partition". The dtb is derived from the FIT > > - Drop "spl export" > > > > > > How do we deal with devicetrees in the FIT then? The options are to use > > a modified devicetree which has the desired "/chosen" node, or use DTB > > overlays. > > > > What are the reasons why we shouldn't go this route? > > I think this makes sense, on the basis that it is a legacy image and > people can always use the U-Boot path if needed. > > I believe Falcon boot made a lot more sense when the cache was off. > But at least in my experience, we were able to get through two SPLs > and two U-Boots and boot a kernel about 800ms on a Cortex-A15, so > Falcon mode might not be so relevant anymore, and supporting a legacy > image seems like unnecessary complexity.
I'm curious where the end of that 800ms is, and I think we might need to post grabserial logs so everyone is on the same page about where / when we're at in booting. -- Tom
signature.asc
Description: PGP signature