[U-Boot] mx6cuboxi fails to load u-boot.img

[Stefano Babic]

On 08/10/19 12:42, Adam Ford wrote:
> On Tue, Oct 8, 2019 at 5:19 AM Stefano Babic <sbabic at denx.de> wrote:
>>
>> Hi everybody,
>>
>> thanks for deep analyses (I just jump at the end):
>>
>> On 08/10/19 12:03, Peter Robinson wrote:
>>>> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
>>>>> Hi Vagrant,
>>>>>
>>>>> On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian <vagrant at debian.org> 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 ?

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
=====================================================================