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

[Tom Rini]

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 check bootcount because I didn't know about it. I don't
> think it could have broken since it's not used in SPL and I checked
> that the env was working in u-boot: I'm setting the variable
> 'boot_os' from the u-boot prompt to activate/deactivate the falcon
> boot.

Ah yes, nevermind, that never made it into mainline, nevermind.

-- 
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/20170206/68537792/attachment.sig>