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

[Tom Rini]

On Mon, May 02, 2016 at 09:08:27AM +0200, Alexander Graf wrote:
> 
> 
> 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've tried to see why things don't work and dug out my beagle xm
> from the shelf. Unfortunately, I don't even get it to boot at all with
> current master. Bisecting points me to the commit below which makes
> sense - we simply change the raw offset on SD for all OMAP systems.
> 
> Is that a good idea? It probably breaks pretty much every user that uses
> raw boot right now.

No, see the other thread about this one (The -rc release email), it's
going to be reverted since I thought it was doing something more clever
than it was, oops.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160502/8bd73f77/attachment.sig>