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).
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.
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
