From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support
Date: Wed, 27 Apr 2016 20:54:11 -0400 [thread overview]
Message-ID: <20160428005411.GG19598@bill-the-cat> (raw)
In-Reply-To: <572152FD.1020101@denx.de>
On Thu, Apr 28, 2016 at 02:02:05AM +0200, Marek Vasut wrote:
> On 04/28/2016 01:49 AM, Robert Nelson wrote:
[snip]
> > 1:
> >
> > Yeap, end users like to delete "MLO/u-boot.img" that was in the "fat"
> > boot partition in our production beaglebone images specifically
> > "2014-05-14" which was shipped by default on rev C. Thus
> > soft-bricking/etc boards..
>
> OK, so because hypothetical user is an idiot, we should use sub-par
> solution ? User can also be an idiot and generate U-Boot which is over 1
> MiB, in which case I will turn your argument around against you. Sorry,
> I am not buying this.
No, real users. Lots of them. From nearly every "community" oriented
board ever. Which is why the distros also go for this method, point #2.
> > http://beagleboard.org/latest-images
> >
> > Moving it under the 1MB location, has solved that problem.
>
> Until u-boot grows over 1 MiB. This only postponed the problem.
> Since there is filesystem support in the SPL, we should use that
> as a superior solution which doesn't suffer from this problem.
I thought people were supposed to be aligning their first partitions
much higher these days, 4MiB? as the general case for being safe
regardless of the actual flash in the SD card. Setting aside sandbox
which I hope grows extremely large for testing purposes, I really hope
U-Boot + SPL can always stay under 1MiB. Our job is to boot the next
stage. If we get so large in our design of implementing things that we
forget this, we have a problem.
--
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/20160427/3fd4dc42/attachment.sig>
next prev parent reply other threads:[~2016-04-28 0:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-27 23:06 [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support Marek Vasut
2016-04-27 23:16 ` Tom Rini
2016-04-27 23:28 ` Marek Vasut
2016-04-27 23:32 ` Robert Nelson
2016-04-27 23:41 ` Marek Vasut
2016-04-27 23:49 ` Robert Nelson
2016-04-28 0:02 ` Marek Vasut
2016-04-28 0:54 ` Tom Rini [this message]
2016-04-28 1:06 ` Robert Nelson
2016-04-28 12:02 ` Tom Rini
2016-04-28 2:24 ` Peng Fan
2016-04-28 5:59 ` Stefano Babic
2016-04-28 11:03 ` Marek Vasut
2016-04-28 13:36 ` Stefano Babic
2016-04-28 13:40 ` Marek Vasut
2016-04-28 18:06 ` Tom Rini
2016-04-28 18:29 ` Marek Vasut
2016-04-28 19:02 ` Tom Rini
2016-04-28 22:37 ` Marek Vasut
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=20160428005411.GG19598@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