On 24/01/2017 20:11, Tom Rini wrote:
On Tue, Jan 24, 2017 at 06:04:47PM +0100, Jean-Jacques Hiblot wrote:
On 24/01/2017 16:46, Tom Rini wrote:
I had noticed that it's quite old indeed. I didn't mean that it's a
regression. I'm just puzzled by the commit. what is its purpose ?
why is SPL not using CONFIG_SYS_MMC_ENV_DEV ?
Because in SPL we do not have both MMC devices initialized.
That is not always the case. Actually in spl_mmc.c the code requires
us to register more than one MMC device to work properly when
multiple MMC boot devices can be used (see
spl_mmc_get_device_index())
I did the test of registering only MMC2 when booting from eMMC, the
SPL fails because it can't find device 1:
Trying to boot from MMC2_2
MMC Device 1 not found
spl: could not find mmc device. error: -19
We register
the one we booted from and thus it is device 0 to U-Boot in this case.
I suspect the rest of the issues stem from this quirk, or something
having broken around this quirk. Thanks!
Right. So I suspect the problem is that some level of the env_mmc.c
code needs to be adapted again for the change in how SPL now works with
the possibility of multiple devices. It's possible that the change you
found is the right fix, please investigate a bit more and confirm
things before submitting a proper patch, thanks!
I did more tests and it turns out that there I find no real benefit of
registering only the controller for the boot device.
The initialization of the MMC/SD/eMMC is done only prior accessing it,
not when it's registered. So in terms of boot time the impact of
registering many controllers is not significant.
By registering the same controllers in SPL and in u-boot, we would get
the same mapping for the MMC devices in SPL and u-boot. It would remove
a source of confusion and of #ifdef CONFIG_SPL_BUILD
The catch is that many boards register only one MMC controller in the
SPL, depending on what the boot source is (ex: board_mmc_init() in
board/freescale/mx6slevk/mx6slevk.c)
To reduce the risk of regression, we could deal with those boards in 2
steps:
1) Don't change the code of the board except to override the weak
function mmc_get_env_dev() and make it return 0. This is not likely to
introduce a regression
2) One by one, change the code of the boards to register all the
controllers in SPL as done in u-boot. Also we need to adapt
spl_boot_device() to return the right boot device. There has been a
partial attempt at this ""ARM: mx6: add MMC2 boot device detection
support in SPL" but had to be reverted probably because it was not
coherent with the registration of the controllers.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
