On Tue, Apr 13, 2021 at 10:13:50AM -0400, Tom Rini wrote: > 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.
Another issue with sunxi is that it implements PSCI in U-Boot, so you'll need in the SPL as well if you want to do falcon boot. This is doable on the later SoCs that have a bigger SRAM, but for that kind of test you'll want to test on the A10 or A13 Maxime
signature.asc
Description: PGP signature
