On Mon, May 18, 2015 at 4:25 PM, Fabio Estevam <feste...@gmail.com> wrote: > Hi Tim, > > On Fri, May 8, 2015 at 10:28 PM, Tim Harvey <thar...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
