Getting rid of falcon mode

[Simon Glass]

Hi,

On Tue, 13 Apr 2021 at 09:32, Alex G. <mr.nuke.me at 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.

Regards,
Simon