> > > > >>>>>> I just tested mx6cuboxi with 2019.10-rc4, and it fails to load > > > > >>>>>> u-boot.img from MMC: > > > > >>>>>> > > > > >>>>>> 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep > > > > >>>>>> 24 2019 - > > > > >>>>>> 08:03:23 +0000) > > > > >>>>>> 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 > > > > >>>>>> 3 2019-09-26_17:31:27.63095 MMC Device 1 not found > > > > >>>>>> 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. > > > > >>>>>> error: -19 > > > > >>>>>> 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot > > > > >>>>>> devices > > > > >>>>>> 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board > > > > >>>>>> ### > > > > >>>>> > > > > >>>>> Thanks for reporting this issue. > > > > >>>>> > > > > >>>>> Unfortunately, I don't have access to my Cuboxi, so I am adding > > > > >>>>> Jon > > > > >>>>> and Baruch on Cc. > > > > >>>> > > > > >>>> Works after reverting the following commit. > > > > >>> > > > > >>> For reference reverting this on 2019.10 fixed my issues with the > > > > >>> udoo_neo board. > > > > >>> > > > > >>>> 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit > > > > >>>> commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > > > > >>>> Author: Adam Ford <aford...@gmail.com> > > > > >>>> Date: Thu May 23 14:11:30 2019 -0500 > > > > >>>> > > > > >>>> spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > > > >>>> > > > > >>>> Currently, when the spl_boot_device checks the boot device, it > > > > >>>> will only return MMC1 when it's either sd or eMMC regardless > > > > >>>> of whether or not it's MMC1 or MMC2. This is a problem when > > > > >>>> booting from MMC2 if MMC isn't being manually configured like > > > > >>>> in > > > > >>>> the DM_SPL case with SPL_OF_CONTROL. > > > > >>>> > > > > >>>> This patch will check the register and return either MMC1 or > > > > >>>> MMC2. > > > > >>>> > > > > >>>> Signed-off-by: Adam Ford <aford...@gmail.com> > > > > >>>> > > > > >> > > > > >> I tend to revert the pathc and let the "standard" case working. A > > > > >> board > > > > >> maintainer coould add a board_boot_order() function to still > > > > >> overwrite > > > > >> the behavior of spl_boot_device(). > > > > > > > > > > I will revert this and the rest of the series that goes with it. > > > > > > > > The series is merged since a very long time - do you propose to revert > > > > all of them ? > > > > > > I just got into my office. I'm looking into it now. I should have > > > something shortly. for sure, I'll revert the offending patch, but I > > > want to look into options on how to best approach keeping my board > > > booting without adding a bunch of extra layers. > > > I know time is of the essence if we want to get it into the final > > > release for 2019.10 > > > > That ship sailed yesterday! > > Sorry. > :-(
It happens > Either way, I'll have a revert patch series sent today. Probably better off getting it fixed properly now, if that involved reverting it sure, if it involves patches on top fixing the situation and moving things forward do that. > adam > > > > > > > > adam > > > > > > > > commit 8f4691e31a18254d225524a4b018b8cbcddc70b1 > > > > Author: Adam Ford <aford...@gmail.com> > > > > Date: Thu May 23 14:11:32 2019 -0500 > > > > > > > > ARM: imx6q_logic: With SPL_OF_CONTROL enabled, remove MMC init > > > > > > > > Since the board uses SPL_OF_CONTROL now, we don't need to > > > > explicitly initialize the MMC driver, but we still need to > > > > pinmux the corresponding pins. This patch removes the > > > > initialization code and leave just the muxing behind. > > > > > > > > Signed-off-by: Adam Ford <aford...@gmail.com> > > > > > > > > commit 0749bbb5c75d2b35eaf6acd438750cf08df314ef > > > > Author: Adam Ford <aford...@gmail.com> > > > > Date: Thu May 23 14:11:31 2019 -0500 > > > > > > > > ARM: imx6q_logic: Enable SPL_DM with SPL_OF_CONTROL > > > > > > > > With the spl code correctly returning either MMC1 or MMC2, > > > > this board can not boot either from internal eMMC (MMC1) or > > > > the uSD card on the baseboard (MMC2) using the device tree. > > > > > > > > Signed-off-by: Adam Ford <aford...@gmail.com> > > > > > > > > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > > > > Author: Adam Ford <aford...@gmail.com> > > > > Date: Thu May 23 14:11:30 2019 -0500 > > > > > > > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > > > > > > > Currently, when the spl_boot_device checks the boot device, it > > > > will only return MMC1 when it's either sd or eMMC regardless > > > > of whether or not it's MMC1 or MMC2. This is a problem when > > > > booting from MMC2 if MMC isn't being manually configured like in > > > > the DM_SPL case with SPL_OF_CONTROL. > > > > > > > > This patch will check the register and return either MMC1 or MMC2. > > > > > > > > Signed-off-by: Adam Ford <aford...@gmail.com> > > > > > > > > Two of them affects just imx6q_logic, the only one with more > > > > side-effects is the one we discuss here. Of course, I can revert all > > > > three of them if you prefer to go on this way (I am happy with follow up > > > > pathces,too, after reverting just 14d319b1856). > > > > > > > > Regards, > > > > Stefano > > > > > > > > -- > > > > ===================================================================== > > > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > > > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > > > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > > > > ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
