public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Alex G. <mr.nuke.me@gmail.com>
To: u-boot@lists.denx.de
Subject: Getting rid of falcon mode
Date: Mon, 12 Apr 2021 16:32:49 -0500	[thread overview]
Message-ID: <ffbc81fd-496d-96bd-d67b-5237b26d9011@gmail.com> (raw)

## 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?

Alex

             reply	other threads:[~2021-04-12 21:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12 21:32 Alex G. [this message]
2021-04-12 22:21 ` Getting rid of falcon mode Tom Rini
2021-04-13  8:56 ` Maxime Ripard
2021-04-13 14:08   ` Alex G.
2021-04-13 14:13     ` Tom Rini
2021-04-13 14:28       ` Maxime Ripard
2021-04-13 14:26     ` Maxime Ripard
2021-04-14 19:37 ` Simon Glass
2021-04-14 20:05   ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ffbc81fd-496d-96bd-d67b-5237b26d9011@gmail.com \
    --to=mr.nuke.me@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox