public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Guillaume Gardet <guillaume.gardet@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] spl_mmc: allow to load raw image
Date: Mon, 2 May 2016 10:58:00 +0200	[thread overview]
Message-ID: <57271698.8090302@free.fr> (raw)
In-Reply-To: <3c04eb68-0f7d-1927-ad53-8bc8e9c60f1f@suse.de>



Le 02/05/2016 09:35, Alexander Graf a ?crit :
>
> On 02.05.16 04:29, Derald D. Woods wrote:
>> On 05/01/2016 09:17 PM, Derald D. Woods wrote:
>>> On 05/01/2016 08:57 PM, Tom Rini wrote:
>>>> On Sun, May 01, 2016 at 08:32:48PM -0500, Derald D. Woods wrote:
>>>>> On 05/01/2016 03:37 AM, Masahiro Yamada wrote:
>>>>>> Hi Adam,
>>>>>>
>>>>>>
>>>>>> 2016-04-30 3:06 GMT+09:00 Adam Ford <aford173@gmail.com>:
>>>>>>> On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini <trini@konsulko.com>
>>>>>>> wrote:
>>>>>>>> On Fri, Apr 29, 2016 at 09:59:00AM -0500, Adam Ford wrote:
>>>>>>>>
>>>>>>>>> Does anyone with an OMAP3 board have any issues with this patch?  I
>>>>>>>>> will admit I haven't stayed on top of stuff due to moving, and
>>>>>>>>> other
>>>>>>>>> issues at home, but I pulled down the master to reviews some on
>>>>>>>>> related stuff, and found that master doesn't boot.  I used git
>>>>>>>>> bisect
>>>>>>>>> this morning and it narrowed down a problem with booting to this
>>>>>>>>> patch.
>>>>>>>>>
>>>>>>>>> With the patch, I get:
>>>>>>>>>
>>>>>>>>> U-Boot SPL 2016.03-00378-g4976f48 (Apr 29 2016 - 09:25:27)
>>>>>>>>> Trying to boot from MMC
>>>>>>>> OK.  Do you have u-boot.bin or u-boot.img (which?) written to the
>>>>>>>> raw
>>>>>>>> offset in MMC or from filesystem?  Based on the log it looks like
>>>>>>>> filesystem.
>>>>>>> I have u-boot.img copied to the fatfs on the card, but I didn't
>>>>>>> put it
>>>>>>> in a specific location.
>>>>>>>
>>>>>>> I never used to have to do that.  Is this a new behavior and is it
>>>>>>> documented somewhere?
>>>>>>>
>>>>>>> adam
>>>>>> You are expecting to boot it from FAT,
>>>>>> but I think spl_boot_mode() on your board returns MMCSD_MODE_RAW.
>>>>>>
>>>>>> Can you fix the function to return MMCSD_MODE_FS?
>>>>>>
>>>>>>
>>>>>>
>>>>>> This commit changed to allow to load raw U-Boot image,
>>>>>> so MMCSD_MODE_RAW never fails.
>>>>>>
>>>>>> So, you can no longer rely on the former behavior
>>>>>> "try MMCSD_MODE_RAW first, and fallback to MMCSD_MODE_FS".
>>>>>>
>>>>> So everyone loading MLO from the FAT filesystem is now wrong? I am
>>>>> trying to understand how this came into being the default.
>>>> ... yes, we can't break the case of SPL+U-Boot being on FS on MMC1.  I
>>>> wonder if:
>>>> commit 22d90d560a2b01c47f180e196e6c6485eb8e65db
>>>> Author: Alexander Graf <agraf@suse.de>
>>>> Date:   Tue Mar 1 09:56:34 2016 +0100
>>>>
>>>>       omap3: Use raw SPL by default for mmc1
>>>>
>>>> Isn't part of what's going wrong now.
>>>>
>>> Reverting that commit worked for me!
>>>
>>> ---8<----------------------------------------------
>>>
>>> U-Boot SPL 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05)
>>> Trying to boot from MMC1
>>> reading args
>>> spl_load_image_fat_os: error reading image args, err - -1
>>> reading u-boot.img
>>> reading u-boot.img
>>>
>>>
>>> U-Boot 2016.05-rc3-00012-gfccdb28-dirty (May 01 2016 - 21:10:05 -0500)
>>>
>>> OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz
>>> Logic DM37x/OMAP35x reference board + LPDDR/NAND
>>>
>>> ---8<----------------------------------------------
>>>
>>> Derald
>>>
>>>
>> I should also mention that I have Tom's patch from this mailing list
>> thread:
>>
>> "[U-Boot] [PATCH] omap3: Reduce logic/overo SPL max image size"
>>
>> So with the reversion and patch I can boot master on 'omap3_logic' again.
> Ok, so I'm puzzled. The raw boot path can basically never fail, since
> all it does is to verify whether we could read the sectors - and that
> usually works:
>
> http://git.denx.de/?p=u-boot.git;a=blob;f=common/spl/spl.c;h=82e7f58e80f028f7517ec52bd0d73566dae82d28;hb=HEAD#l115
>
> So how could we ever fall back from raw to fs mode? I can see how we
> could fall back from fs loading to raw loading, but the other way around?
>
> Guillaume, you posted a patch a while back to handle exactly that case.
> How did you get there?

I think there is (was?) a signature or a header check or something like this.

I did not check latest git version. Maybe a patch removed a check?



Guillaume

>
> The only real "fix" to this I can think of is to reverse the fallback
> path. Load from fs, fall back to raw. Because with file systems we know
> whether something failed.
>
>
> Alex
>

  reply	other threads:[~2016-05-02  8:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-29 11:31 [U-Boot] [PATCH] spl_mmc: allow to load raw image Masahiro Yamada
2016-03-01  1:58 ` Tom Rini
2016-03-15 19:23 ` [U-Boot] " Tom Rini
2016-03-16  3:10   ` Masahiro Yamada
2016-03-17  2:04 ` Tom Rini
2016-03-17 16:07   ` Masahiro Yamada
2016-03-17 16:12     ` Tom Rini
2016-04-29 14:59       ` Adam Ford
2016-04-29 17:53         ` Tom Rini
2016-04-29 18:06           ` Adam Ford
2016-04-29 18:06             ` Tom Rini
2016-05-01  8:37             ` Masahiro Yamada
2016-05-01 13:46               ` Tom Rini
2016-05-02  1:32               ` Derald D. Woods
2016-05-02  1:57                 ` Tom Rini
2016-05-02  2:04                   ` Masahiro Yamada
2016-05-02  2:17                   ` Derald D. Woods
2016-05-02  2:29                     ` Derald D. Woods
2016-05-02  7:08                       ` Alexander Graf
2016-05-02 12:44                         ` Tom Rini
2016-05-02  7:35                       ` Alexander Graf
2016-05-02  8:58                         ` Guillaume Gardet [this message]
2016-05-02  9:12                           ` Alexander Graf
2016-05-02  9:45                             ` Guillaume Gardet
2016-05-02 11:21                               ` Alexander Graf
2016-05-02 16:14                             ` Tom Rini
2016-05-02 21:19                               ` Alexander Graf

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=57271698.8090302@free.fr \
    --to=guillaume.gardet@free.fr \
    --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