[U-Boot] mx6cuboxi fails to load u-boot.img
Stefano Babic
sbabic at denx.de
Tue Oct 8 13:36:08 UTC 2019
On 08/10/19 15:05, Adam Ford wrote:
> On Tue, Oct 8, 2019 at 6:51 AM Peter Robinson <pbrobinson at 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 <aford173 at 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 <aford173 at 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 <aford173 at 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 <aford173 at gmail.com>
>>>>>>
>>>>>> commit 0749bbb5c75d2b35eaf6acd438750cf08df314ef
>>>>>> Author: Adam Ford <aford173 at 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 <aford173 at gmail.com>
>>>>>>
>>>>>> commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a
>>>>>> Author: Adam Ford <aford173 at 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 <aford173 at 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: sbabic at 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: sbabic at denx.de
=====================================================================
More information about the U-Boot
mailing list