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
signature.asc
Description: PGP signature
