[U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot

[Tom Rini]

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 <jjhiblot at ti.com>
> >>>>>---
> >>>>>
> >>>>>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170210/8f601746/attachment.sig>