Getting rid of falcon mode

[Tom Rini]

On Tue, Apr 13, 2021 at 09:08:01AM -0500, Alex G. wrote:
> 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.

sunxi is both modern and small, so a good thing to benchmark.

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

Since you have this working on some platforms, can you show some logs?
Sample configurations?  Thanks.

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