Getting rid of falcon mode

[Tom Rini <trini@konsulko.com>]

On Wed, Apr 14, 2021 at 08:37:07PM +0100, Simon Glass wrote:
> Hi,
> 
> On Tue, 13 Apr 2021 at 09:32, Alex G. <mr.nuke.me@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.

I'm curious where the end of that 800ms is, and I think we might need to
post grabserial logs so everyone is on the same page about where / when
we're at in booting.

-- 
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/20210414/17369cba/attachment.sig>