From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] spl_mmc: allow to load raw image
Date: Mon, 2 May 2016 12:14:05 -0400 [thread overview]
Message-ID: <20160502161405.GK7884@bill-the-cat> (raw)
In-Reply-To: <572719EB.6090306@suse.de>
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>
next prev parent reply other threads:[~2016-05-02 16:14 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-29 11:31 [U-Boot] [PATCH] spl_mmc: allow to load raw image Masahiro Yamada
2016-03-01 1:58 ` Tom Rini
2016-03-15 19:23 ` [U-Boot] " Tom Rini
2016-03-16 3:10 ` Masahiro Yamada
2016-03-17 2:04 ` Tom Rini
2016-03-17 16:07 ` Masahiro Yamada
2016-03-17 16:12 ` Tom Rini
2016-04-29 14:59 ` Adam Ford
2016-04-29 17:53 ` Tom Rini
2016-04-29 18:06 ` Adam Ford
2016-04-29 18:06 ` Tom Rini
2016-05-01 8:37 ` Masahiro Yamada
2016-05-01 13:46 ` Tom Rini
2016-05-02 1:32 ` Derald D. Woods
2016-05-02 1:57 ` Tom Rini
2016-05-02 2:04 ` Masahiro Yamada
2016-05-02 2:17 ` Derald D. Woods
2016-05-02 2:29 ` Derald D. Woods
2016-05-02 7:08 ` Alexander Graf
2016-05-02 12:44 ` Tom Rini
2016-05-02 7:35 ` Alexander Graf
2016-05-02 8:58 ` Guillaume Gardet
2016-05-02 9:12 ` Alexander Graf
2016-05-02 9:45 ` Guillaume Gardet
2016-05-02 11:21 ` Alexander Graf
2016-05-02 16:14 ` Tom Rini [this message]
2016-05-02 21:19 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160502161405.GK7884@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox