From: Baruch Siach <baruch@tkos.co.il>
To: u-boot@lists.denx.de
Subject: [U-Boot] mx6cuboxi fails to load u-boot.img
Date: Sun, 06 Oct 2019 13:23:35 +0300 [thread overview]
Message-ID: <875zl2npeg.fsf@tarshish> (raw)
In-Reply-To: <CAHCN7xJP+PJTVrje=TPzE=bXRk46RZJ6kLLYBXcbXqjJR9DZeA@mail.gmail.com>
Hi Adam,
(Adding MMC and i.MX maintainers to Cc)
On Fri, Sep 27 2019, Adam Ford wrote:
> On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray <jsg@jsg.id.au> 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.
>>
> I am going to argue that making the board comply with DM_MMC is why I
> needed to make the patch, because when booting from MMC2, the function
> was returning MMC1 which was clearly not the boot source.
>
> If the boards that fail accept MMC2 as a response when booting from
> MMC2, that seems like a bug on the indvidual boards. Instead they
> should setup their boot sequence to configure MMC2 when MMC2 is the
> boot source. Instead, it seems like some boards are configuring MMC1
> with MMC2 info which only prolongs the conversion to DM_MMC.
>
> If we revert the patch, then boards like imx6_logic who rely solely on
> device tree and DM_MMC for booting will have to manually override the
> MMC driver in order to boot from MMC2, and that seems like a step
> backwards. I would argue that this board should migrate to DM_MMC and
> use the device tree to boot, and the problem should go away.
I started working on migration to DM_MMC as you suggested. Unfortunately
I can't see how this solves the problem for Cubox-i/Hummingboard, nor in
the general case.
The imx6_logic board happens to use only usdhc1 and usdhc2 for boot, and
both are always enabled. This matches perfectly to BOOT_DEVICE_MMC{1,2},
and their corresponding DT representation.
However, the 'index' parameter in uclass_get_device() that is set
according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with the
usdhcX sequence number. It simply returns the Nth probed SD/eMMC device
(see uclass_find_device()). In the case of Cubox-i/Hummingboard, usdhc1
is never used for boot, usdhc2 is always an SD card, and usdhc3 is an
optional eMMC. When booting from SD card, uclass_get_device(), returns
-ENODEV when eMMC is not available, or the eMMC device when it is
available. In both cases, boot fails.
In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?
How is all that intended to work?
Aren't other i.MX boards impacted by this commit?
Thanks,
baruch
>> 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>
>>
>> arch/arm/mach-imx/spl.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
next prev parent reply other threads:[~2019-10-06 10:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-26 19:16 [U-Boot] mx6cuboxi fails to load u-boot.img Vagrant Cascadian
2019-09-26 20:07 ` Fabio Estevam
2019-09-27 9:38 ` Jonathan Gray
2019-09-27 12:10 ` Adam Ford
2019-09-29 5:58 ` Baruch Siach
2019-09-29 12:34 ` Fabio Estevam
2019-10-06 10:23 ` Baruch Siach [this message]
2019-10-06 11:30 ` Adam Ford
2019-10-06 12:05 ` Adam Ford
2019-10-06 12:22 ` Baruch Siach
2019-10-06 12:30 ` Adam Ford
2019-10-06 12:38 ` Adam Ford
2019-10-06 12:48 ` Baruch Siach
2019-10-06 14:02 ` Adam Ford
2019-10-06 15:55 ` Baruch Siach
2019-10-06 16:18 ` Adam Ford
2019-10-08 10:03 ` Peter Robinson
2019-10-08 10:18 ` Stefano Babic
2019-10-08 10:42 ` Adam Ford
2019-10-08 11:04 ` Stefano Babic
2019-10-08 11:43 ` Adam Ford
2019-10-08 11:44 ` Peter Robinson
2019-10-08 11:46 ` Adam Ford
2019-10-08 11:51 ` Peter Robinson
2019-10-08 13:05 ` Adam Ford
2019-10-08 13:36 ` Stefano Babic
2019-10-06 11:22 ` Peter Robinson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875zl2npeg.fsf@tarshish \
--to=baruch@tkos.co.il \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.