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

[Jean-Jacques Hiblot]

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


JJ

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