[U-Boot] spl_mmc: allow to load raw image
Alexander Graf
agraf at suse.de
Mon May 2 23:19:50 CEST 2016
On 02.05.16 18:14, Tom Rini wrote:
> 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.
I agree with the plan :)
Alex
More information about the U-Boot
mailing list