| Summary: | sabresd boot failure with preferred provider linux-fslc | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Nick Lewis <nick.lewis> | ||||
| Component: | bsps-meta-fsl-arm | Assignee: | Daiane <angolini> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | angolini, otavio | ||||
| Version: | 1.4.1 | ||||||
| Target Milestone: | 1.7 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | New (Never tested) | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
|
Description
Nick Lewis
2013-09-13 08:33:16 UTC
Thanks for reporting this issue. Do you know when we fixed this in mainline kernel? I think it'd be good to backport it to Dylan kernel branch. Not sure but it might be 0001-mx6qsabre_common-uEnv.txt-bootz-n-fixes.patch Sorry - scrub all that - the bug does seem to affect Master too Steps to reproduce - repo init with the master of fsl-community-bsp-platform and setup environment - add PREFERRED_PROVIDER_virtual/kernel = "linux-fslc" and PREFERRED_PROVIDER_virtual/bootloader = "u-boot-fslc" to the local.conf - bitbake core-image-minimal - dd onto an sdcard - boot in an mx6sabresd board This temporary patch resolved the problem for me: --- tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-fslc/v2013.10-r0/git/include/configs/mx6sabresd.h.bak 2013-09-16 16:56:13.106857912 +0100 +++ tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-fslc/v2013.10-r0/git/include/configs/mx6sabresd.h 2013-09-17 11:51:17.963975426 +0100 @@ -15,7 +15,7 @@ #define CONFIG_MACH_TYPE 3980 #define CONFIG_MXC_UART_BASE UART1_BASE #define CONFIG_CONSOLE_DEV "ttymxc0" -#define CONFIG_MMCROOT "/dev/mmcblk1p2" +#define CONFIG_MMCROOT "/dev/mmcblk0p2" #define CONFIG_DEFAULT_FDT_FILE "imx6q-sabresd.dtb" #define PHYS_SDRAM_SIZE (1u * 1024 * 1024 * 1024) Using this patch, most probably break FSL kernel usage. Can you confirm it? Fabio has been able to reproduce it. Setting it for him. By 'FSL kernel' do you mean with PREFERRED_PROVIDER_virtual/kernel="linux-imx"? A workaround is to insert another sd card containing anything into SD2. This SD card is ignored by uboot and early kernel boot but is loaded first by the SDHCI controllers at mmcblk0 meaning that the card in SD3 does become mmcblk1 as currently configured for the mmcroot This thread discusses a similar problem and includes solutions Devicetree: Initialization order of mmc block devices Nick, thanks for the link. Could you please try the suggestion from: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html ? Ok, I managed to manually apply Dirk's proposal patch and it seems that this is the way to fix this issue. Now I can mount the rootfs with the original U-boot. I will start a thread in the linux-mmc list about this. I also think that we should fix this in the mmc core instead of sdhc-imx driver. Created attachment 1516 [details]
Ported Patch
I have also tried the ported patch and it works for me both with and without SD cards in other slots It would be nice if aliases could be defined only for those sd slots that need a fixed device id e.g. containing rootfs. Could the driver first probe for those requiring fixed aliases and then probe again for the rest? At the moment the find_next_zero_bit would silently allocate the wrong device index in these cases leading to unexpected and possibly insecure behaviour (e.g. using malicious rootfs) Part of your patch at linux-mmc looks a bit dangerous + if (ret >= 0) + host->mmc->devidx = ret; How about instead using + host->mmc->devidx = ret ? ret : 0; Nope I am an idiot + if (ret >= 0) + host->mmc->devidx = ret; + else + host->mmc->devidx = 0; Nick, what do you think about this approach? http://marc.info/?l=linux-mmc&m=134423822729031 I worry that there may be cases where a host supports more than one device. It would need in depth checking to fully understand the implications Also this change may obsolete all the md->name_idx stuff which I guess would need to be removed in any final version of the patch. I am unclear about the impact or otherwise of subname Aparently the alias approach is used for serial ports so may be best to be consistent With the two patches below we should be able to run both 3.0.35 and 3.11 with no issues: From 584ee6fb95edc73b1e16ad02e4d86a444376d688 Mon Sep 17 00:00:00 2001 From: Fabio Estevam <fabio.estevam@freescale.com> Date: Sat, 28 Sep 2013 18:46:18 -0300 Subject: [PATCH] ARM: mach-mx6: board-mx6q_sabresd: Register SDHC3 first On sabresd boards we boot from SDHC3, so let's register it as mmc0. Currently eMMC is mmc0 and mmc1 can be SDHC3 or SDHC2 (if present). Registering SDHC3 is safer as we can always find the rootfs. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> --- arch/arm/mach-mx6/board-mx6q_sabresd.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/arm/mach-mx6/board-mx6q_sabresd.c b/arch/arm/mach-mx6/board-mx6q_sabresd.c index 3f9a845..4e6b323 100644 --- a/arch/arm/mach-mx6/board-mx6q_sabresd.c +++ b/arch/arm/mach-mx6/board-mx6q_sabresd.c @@ -1847,12 +1847,9 @@ static void __init mx6_sabresd_board_init(void) imx6q_add_pm_imx(0, &mx6q_sabresd_pm_data); - /* Move sd4 to first because sd4 connect to emmc. - Mfgtools want emmc is mmcblk0 and other sd card is mmcblk1. - */ + imx6q_add_sdhci_usdhc_imx(2, &mx6q_sabresd_sd3_data); imx6q_add_sdhci_usdhc_imx(3, &mx6q_sabresd_sd4_data); imx6q_add_sdhci_usdhc_imx(1, &mx6q_sabresd_sd2_data); - imx6q_add_sdhci_usdhc_imx(2, &mx6q_sabresd_sd3_data); imx_add_viv_gpu(&imx6_gpu_data, &imx6q_gpu_pdata); imx6q_sabresd_init_usb(); /* SATA is not supported by MX6DL/Solo */ -- 1.8.1.2 From b180194e61c4a2eab83cff00b501d7c5cff7eeba Mon Sep 17 00:00:00 2001 From: Fabio Estevam <fabio.estevam@freescale.com> Date: Sat, 28 Sep 2013 18:52:40 -0300 Subject: [PATCH] mx6sabresd: Use mmcblk0 for CONFIG_MMCROOT Using mmcblk0 for CONFIG_MMCROOT, so that the rootfs can be found on both FSL 3.0.35 as well as in mainline kernel. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> --- include/configs/mx6sabresd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h index a3dd74a..c740986 100644 --- a/include/configs/mx6sabresd.h +++ b/include/configs/mx6sabresd.h @@ -15,7 +15,7 @@ #define CONFIG_MACH_TYPE 3980 #define CONFIG_MXC_UART_BASE UART1_BASE #define CONFIG_CONSOLE_DEV "ttymxc0" -#define CONFIG_MMCROOT "/dev/mmcblk1p2" +#define CONFIG_MMCROOT "/dev/mmcblk0p2" #define CONFIG_DEFAULT_FDT_FILE "imx6q-sabresd.dtb" #define PHYS_SDRAM_SIZE (1u * 1024 * 1024 * 1024) -- 1.8.1.2 Applied following changes: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=eda8fb05ad0edcd831dab6c59f75962fcc7bae02 http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=e2feee421e3c4050649edf0c44693e62e6c68d2e Does there also need to be -#define CONFIG_MMCROOT "/dev/mmcblk1p2" +#define CONFIG_MMCROOT "/dev/mmcblk0p2" in u-boot-fslc? Yes; this is part of the fix. It also changed the linux-imx recipe to use same order as mainline kernel. I am a bit confused why there is no change to the u-boot-imx recipe Will the following local conf work? PREFERRED_PROVIDER_virtual/kernel = "linux-imx" PREFERRED_PROVIDER_virtual/bootloader = "u-boot-imx" You're right. u-boot-imx should need same fix. Can you make a patch for it Nick? Otavio I am out of my depth here. u-boot-imx already seems to have a patch mx69_sabresd-Change-default-environment-to-work-eith.patch with the line + "mmcroot=/dev/mmcblk0p2 rw\0" \ but running the u-boot-imx/linux-imx sdcard image i see on the console Waiting for root device /dev/mmcblk1p2... Nick Just tested with daisy |