Hi Tim, On Tue, May 19, 2015 at 10:26 AM, Tim Harvey <thar...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
