From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 2 May 2016 08:44:34 -0400 Subject: [U-Boot] spl_mmc: allow to load raw image In-Reply-To: References: <20160317161210.GB23166@bill-the-cat> <20160429175350.GZ19598@bill-the-cat> <20160502015758.GI7884@bill-the-cat> <1ecbd1aa-7176-1240-dd50-56f4a5141c88@gmail.com> Message-ID: <20160502124434.GJ7884@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 : > >>>>>> On Fri, Apr 29, 2016 at 12:53 PM, Tom Rini > >>>>>> 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 > >>> 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: