From mboxrd@z Thu Jan 1 00:00:00 1970 From: Derald D. Woods Date: Sun, 1 May 2016 21:29:53 -0500 Subject: [U-Boot] spl_mmc: allow to load raw image In-Reply-To: References: <1456745517-19797-1-git-send-email-yamada.masahiro@socionext.com> <20160317020452.GX23166@bill-the-cat> <20160317161210.GB23166@bill-the-cat> <20160429175350.GZ19598@bill-the-cat> <20160502015758.GI7884@bill-the-cat> Message-ID: <1ecbd1aa-7176-1240-dd50-56f4a5141c88@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. Derald