Getting rid of falcon mode

[Alex G. <mr.nuke.me@gmail.com>]

Hi Maxime,

On 4/13/21 3:56 AM, Maxime Ripard wrote:
> 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.

Do we know which platforms fall in this category? We can investigate if 
it might be possible to disable just enough of the legacy support to 
make room for libfdt.


>    - 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.

I'm skeptical of the 150ms delta, as I also did heavy measurements on 
this a few months back. But maybe there's something that causes certain 
platforms to bog down, (caching issues ?).

I've used grabserial (e.g. "grabserial -d /dev/ttyACM0 -b 2000000 
-m"U-Boot SPL" -t") to time the boot. If you have similar logs, maybe 
there's something there that tells us why parsing the FIT bogs down.

Alex