public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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 -

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox