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

[Fabio Estevam]

Hi Tim,

On Tue, May 19, 2015 at 10:26 AM, Tim Harvey <tharvey at gateworks.com> wrote:

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

Thanks for your work on this and for your detailed reply! I will give
Falcon mode a try.

Thanks,

Fabio Estevam