[U-Boot] spl_mmc: allow to load raw image

Mon May 2 13:21:44 CEST 2016

On 05/02/2016 11:45 AM, Guillaume Gardet wrote:
>
>
> Le 02/05/2016 11:12, Alexander Graf a écrit :
>> On 05/02/2016 10:58 AM, Guillaume Gardet wrote:
>>>
>>>
>>> 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 at gmail.com>:
>>>>>>>>>> On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini <trini at 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 at 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?
>>
>> I can't find any patch that removes such a check. Hrm.
>
> Beaglebone black does not boot either with u-boot on FS. So, I did a 
> git bisect and it returns the following patch as the problem:
> **********************************************************************
> commit 4976f4827546154bb296dd0fb33b2cdff94be0c1
> Author: Masahiro Yamada <yamada.masahiro at socionext.com>
> Date:   Wed Mar 16 12:10:00 2016 +0900
>
>     spl_mmc: allow to load raw image
>
>     The function spl_parse_image_header() falls back to a raw image
>     if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE
>     is undefined.  While, mmc_load_image_raw_sector() only accepts a
>     U-Boot legacy image or an FIT image, preventing us from loading a
>     raw image.
>
>     Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
>     Reviewed-by: Tom Rini <trini at konsulko.com>
> **********************************************************************
>

Thanks a lot for the bisect! I guess we could also revert that patch and 
break socio support. Hrm :). Tom?

Alex