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

Tom Rini trini at konsulko.com
Mon May 2 18:14:05 CEST 2016


On Mon, May 02, 2016 at 11:12:11AM +0200, Alexander Graf wrote:

[snip]
> So Tom, how would you like to roll this? We can either
> 
>   1) Check raw after fs, default to fs and revert my patch or
>   2) Leave fs boot broken (regression) or
>   3) Leave raw boot broken (same as 2016.03)
> 
> Given that release is in 1 week, I'm wary on option 1. I also don't
> like regressions. So how about we revert my patch and fix it up with
> fs-before-raw boot for 2016.07?

So, we need to revert ef5ebe951bec72 which is what changed the raw
offset.  I think we also need to revert 22d90d560a2b which yes, will go
back to breaking raw MLO + FS U-Boot.  The problem here is that we have
the fallback case of "load hard-coded size from MMC, assume u-boot.bin
is raw".  So raw will never fail.  Marek posted a series late last week
that would address this by letting us say that we want to call an
invalid signature for U-Boot bad and continue on to other methods.  I'm
wondering if this doesn't go far enough actually and we should say that
unless specifically set (like CONFIG_SPL_NAND_RAW_ONLY does), we don't
assume it's good.  It's been a long time since we didn't default to
making a u-boot.img and SPL has "always" supported both.  It was mainly
legacy code for letting people mix-and-match SPL + X-Loader (and go back
and forth).  I'm leaning towards making this an opt-in thing and
introduce CONFIG_SPL_MMC_BIN_ONLY (and rename the NAND one) as the logic
is getting really really convoluted now.

-- 
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/e0077641/attachment.sig>


More information about the U-Boot mailing list