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@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.
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.