On Fri, Feb 10, 2017 at 06:24:18PM +0100, Jean-Jacques Hiblot wrote: > > > On 06/02/2017 22:13, Jean-Jacques Hiblot wrote: > > > > > >On 06/02/2017 13:49, Tom Rini wrote: > >>On Mon, Feb 06, 2017 at 12:25:19PM +0100, Jean-Jacques Hiblot wrote: > >>> > >>>On 03/02/2017 17:52, Tom Rini wrote: > >>>>On Wed, Feb 01, 2017 at 11:39:14AM +0100, Jean-Jacques Hiblot wrote: > >>>>>To keep a consistent MMC device mapping in SPL and in u-boot, let's > >>>>>register the MMC controllers the same way in u-boot and in the SPL. > >>>>>In terms of boot time, it doesn't hurt to register more > >>>>>controllers than > >>>>>needed because the MMC device is initialized only prior > >>>>>being accessed for > >>>>>the first time. > >>>>>Having the same device mapping in SPL and u-boot allows us to use the > >>>>>environment in SPL whatever the MMC boot device. > >>>>> > >>>>>Signed-off-by: Jean-Jacques Hiblot <[email protected]> > >>>>>--- > >>>>> > >>>>>This has been tested on DRA7 platforms, AM437x Starter Kit > >>>>>and Beaglebone Black. > >>>>>I also checked that building the TI-based platforms was > >>>>>okay using buildman: > >>>>>tools/buildman/buildman -d -e -l omap am33 davinci > >>>>Did you test this around falcon mode and bootcount as well? Thanks! > >>>I tested the falcon boot on beaglebone, DRA7 and am437x. Note that > >>>more changes are required to make it work properly: FDT memory nodes > >>>fixup + support for spl_start_uboot() for the am437x SK. They'll be > >>>submitted later. > >>Er, SK being broken is confusing since 'spl export' should prepare the > >>whole DTB. > >I didn't write the FDT memory fixup patch so I'm not 100% > >confident in what my following comment: This patch adjusts > >dynamically the memory nodes in the DTB. I guess that's required > >because the amount of memory is read from an on-board EEPROM. > > After a bit of research here is the explanation, the patch adds a > call to arch_fixup_fdt() so that the memory banks are properly > described in the dtb. > This is required in our case because of the way the dtb is > programmed in the flash/mmc: we don't use "spl export", instead we > write the dtb as-is (though we do customize it on dev station with > fdtput).
So, yes. If you don't use the built-in mechanism to prepare a DTB for use with falcon you do have to set all of the values required via fdtput/similar (I've suggested as much for customers wanting to productize falcon mode, "spl export" doesn't fit as well into upgrade paths when run via Linux for example). -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
