On Tue, Oct 8, 2019 at 6:51 AM Peter Robinson <pbrobin...@gmail.com> wrote: > > > > > > >>>>>> 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.
Apologizes to everyone. I pushed the patch [1] to revert this change. Thank you to everyone for allowing me the courtesy of undoing it. I also want to thank Stefano for bringing to my attention that we can override the standard settings by adding board_boot_order() [2] which actually let me default back to the serial down-loader in the event that something goes wrong. adam [1] - https://patchwork.ozlabs.org/patch/1173314/ [2] - https://patchwork.ozlabs.org/patch/1173316/ > > > 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
