On 08/10/19 15:05, Adam Ford wrote: > 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. > >
Thanks Adam - I have already merged your two patches into my -next branch (it will become u-boot-imx, -master after Travis will finish). Best regards, Stefano > 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 >>>>>> ===================================================================== -- ===================================================================== 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