Getting rid of falcon mode

[Maxime Ripard]

Hi,

On Mon, Apr 12, 2021 at 04:32:49PM -0500, Alex G. 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 can see at least two, that are mainly due to a FIT image being
essentially a compiled device tree:

  - Not all platforms have enough head-space in their SPL to have libfdt
    in addition to what is already there.

  - Parsing a DT is fairly slow too. Last time I checked booting a FIT
    image took around 150ms more than a legacy image on a Cortex-A7. If
    one is using the Falcon mode in the first place chances are it's to
    improve the boot-time, so this seems like a step backward.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210413/3d7d280f/attachment.sig>