On Mon, 26 Feb 2018 19:59:46 +0530 Faiz Abbas faiz_abbas@ti.com wrote:
Hi,
On Sunday 25 February 2018 07:18 PM, Tom Rini wrote:
On Sun, Feb 25, 2018 at 09:53:10AM +0100, Wolfgang Denk wrote:
Dear Tom Rini,
In message 20180224215325.GQ4311@bill-the-cat you wrote:
Why do you ignore this NAK, and why do you add this patch so late in the release cycle anyway?
Sorry, didn't v2 address your concerns? We don't initialize the device because maybe we'll have env there, we initalize mmc because we need to check that it is there. Thanks!
No, it does not. As is, we initialize MMC in the EXT4 code (in env_ext4_load()). If we go that route, we would have to add similar init calls to all other file systemn load routines as well.
This does not make sense to me. This pollutes the code with unrelated things - file system code should not depend on any underlaying driver suport. It increases code size, makes the code harder to maintain (if you need to change this, there is good chances to forget the same change in other file systems), and there is a good chance that in the end you will initialzie MMC even if you don't use it.
We should keep the code clean and orthogonal. Driver init code has no place in file system code.
If needed, the drivers have to make sure to auto--initialize on first access.
I hold my NAK on this patch. It is the wrong thing to do.
I think you have this a little bit wrong. But, it's also where we are with the DM conversion. This _is_ the first place we're trying to access the MMC. And it's not in the filesystem code, it's in the environment code.
That said, Faiz, what exactly is the failure sequence (and hardware)? Thanks!
The failure happens in SPL when booting from a non-MMC device (say NAND) and environment is in MMC. I have seen it in am335x_evm (with NAND and ethernet boot mode) and in dra7xx_evm (with qspi boot mode).
The failure sequence is as follows:
- spl_start_uboot() in the appropriate board file calls env_load().
Just out of curiosity - is the env_load() preceded with env_init() ?
Maybe env_init() is the place to resolve the issue with eMMC init (to call board_mmc_init() for SPL) ?
- Since ENV_IS_IN_FAT and CONFIG_ENV_FAT_INTERFACE=mmc,
env_fat_load() eventually leads to a call to find_mmc_device() in drivers/mmc/mmc_legacy.c or mmc-uclass.c
- Since the mmc devices have not been probed (by a call to
mmc_initialize()), SPL is not able to get the environment and I get this warning message:
*** Warning - No MMC card found, using default environment
Note: In case of legacy mode (CONFIG_BLK is not enabled), SPL crashes because of dereferencing a NULL pointer (mmc_devices) in find_mmc_device().
Thanks, Faiz _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de