[U-Boot] [PATCH 19/19] imx: ventana: config: enable Falcon mode

[Tim Harvey]

On Mon, May 18, 2015 at 4:25 PM, Fabio Estevam <festevam at gmail.com> wrote:
> Hi Tim,
>
> On Fri, May 8, 2015 at 10:28 PM, Tim Harvey <tharvey at gateworks.com> wrote:
>> Falcon mode entails the SPL booting the OS directly instead of U-Boot.
>
> I would like to give this a try, but I am not sure where the dtb
> should be placed in the SD card.
>
> Or are you combining the dtb and zImage into a single binary?
>
> Do you have a small README that shows how the user should use Falcon mode?
>
> Thanks!

Fabio,

I will be posting a README in the next day or so to document Falcon
mode usage on the Gateworks Ventana boards. In general the
documentation will be the same for any board using it but I'll provide
some detail about where things are stored in flash/mmc and what
#defines control that.

As a general rule though, when using Falcon mode for a device-tree
kernel the dtb must get loaded and processed via the 'spl export fdt'
command which you provide the kernel and dtb address in RAM you've
loaded them to because U-Boot will tweak the dtb then allow you to
store it back.

This is documented pretty well currently in doc/README.falcon. You
have to understand that the steps normally taken by U-Boot will be
skipped in Falcon mode as you go straight from SPL to OS. In the
general case this means your SPL must do anything that U-Boot
typically does for fixups including GPIO configuration (pinmux,
padctl, output/direction) for things the kernel may not be supporting
(hence my recent patches that move or replicate some of Ventana U-Boot
capability in the SPL). For the Linux OS case the SPL must do what the
bootm U-Boot command would have done which is to load the dtb, make
adjustments (enet macs, mtdparts, memsize, console args, anything in
ft_board_setup(), etc) and it does this by using the spl export
command which goes through all the steps that bootm does 'except' for
jumping to the kernel. Then you take the mem area that spl export left
the 'args' typically passed to the kernel and store that to your
non-volatile storage so that when the SPL boots in 'OS mode' it loads
the kernel, loads the pre-prepared args and jumps.

Note that Falcon mode also requires you have a function in the SPL
that decides to boot U-Boot or to skip it and boot the OS directly. In
the Gateworks Ventana case I didn't want to make this completely
dependent on a GPIO/Button because this bootloader supports about 8
different PCB designs in the Ventana family - some of which do not
have buttons or may not have buttons loaded on the board. Instead, I
pulled env support into the SPL and use 'boot_os' env var to decide as
other boards do (see spl_start_uboot()). I also have the Ventana
config build in support for both NAND and MMC so that in general the
same SPL/U-Boot can be used on Ventana boards with or without NAND.
U-Boot however currently does not support multiple environment backing
stores, so only NAND env is defined meaning Falcon mode for Ventana on
a nand-less board won't really work right as it will try to read env
from NAND. I have a downstream patch that adds multiple env support
which reads env from whatever the boot device was, however I have not
posted this patch yet and I don't expect it will be accepted because
it was desired for me to re-write env support instead which was a
large undertaking I don't have time for. Until then, mainline U-Boot
only supports Falcon mode on NAND for Ventana (which is the vast
majority of the Ventana boards).

Regards,

Tim