On 08/10/19 12:42, Adam Ford wrote:
On Tue, Oct 8, 2019 at 5:19 AM Stefano Babic sbabic@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@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@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@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@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@gmail.com
commit 0749bbb5c75d2b35eaf6acd438750cf08df314ef Author: Adam Ford aford173@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@gmail.com
commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a Author: Adam Ford aford173@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@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