[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

Enable support for booting U-Boot image from filesystem instead of some
random offset on the SD card. This makes the board usable by putting the
u-boot.img to first partition of the SD card and writing the SPL this way:
$ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
---
 include/configs/wandboard.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 99f5c0c..fbce730 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -14,6 +14,8 @@
 
 #define CONFIG_SPL_LIBCOMMON_SUPPORT
 #define CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SPL_FAT_SUPPORT
+#define CONFIG_SPL_EXT_SUPPORT
 #include "imx6_spl.h"
 
 #define MACH_TYPE_WANDBOARD		4412
-- 
2.7.0

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Tom Rini]

On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:

> Enable support for booting U-Boot image from filesystem instead of some
> random offset on the SD card. This makes the board usable by putting the
> u-boot.img to first partition of the SD card and writing the SPL this way:
> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512

Wait, you're still writing u-boot + SPL to the device and not just SPL,
but it's still preferring the filesystem one over the appended one?

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

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

On 04/28/2016 01:16 AM, Tom Rini wrote:
> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
> 
>> Enable support for booting U-Boot image from filesystem instead of some
>> random offset on the SD card. This makes the board usable by putting the
>> u-boot.img to first partition of the SD card and writing the SPL this way:
>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> 
> Wait, you're still writing u-boot + SPL to the device and not just SPL,
> but it's still preferring the filesystem one over the appended one?
> 

Ha, good point. I should've written the 'SPL' file instead, which is
just the SPL without U-Boot. I don't want to install U-Boot to random
offset on the SD card as it has the potential to corrupt data if the
u-boot binary changes in size.

If I install u-boot image to random offset 138 blocks from the start of
SD card, it will boot that, otherwise it will load from FS.

I will update the commit message with the correct info, sorry.

-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Robert Nelson]

On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <marex@denx.de> wrote:

> On 04/28/2016 01:16 AM, Tom Rini wrote:
> > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
> >
> >> Enable support for booting U-Boot image from filesystem instead of some
> >> random offset on the SD card. This makes the board usable by putting the
> >> u-boot.img to first partition of the SD card and writing the SPL this
> way:
> >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> >
> > Wait, you're still writing u-boot + SPL to the device and not just SPL,
> > but it's still preferring the filesystem one over the appended one?
> >
>
> Ha, good point. I should've written the 'SPL' file instead, which is
> just the SPL without U-Boot. I don't want to install U-Boot to random
> offset on the SD card as it has the potential to corrupt data if the
> u-boot binary changes in size.
>
> If I install u-boot image to random offset 138 blocks from the start of
> SD card, it will boot that, otherwise it will load from FS.
>
> I will update the commit message with the correct info, sorry.
>

Oh, we went thru this last year...

http://lists.denx.de/pipermail/u-boot/2015-August/222061.html

If your serious about changing "one" i.mx6 board, you need to change them
"all".

Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img as
that works for ti/imx/sunxi...

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

On 04/28/2016 01:32 AM, Robert Nelson wrote:
> 
> 
> On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <marex@denx.de
> <mailto:marex@denx.de>> wrote:
> 
>     On 04/28/2016 01:16 AM, Tom Rini wrote:
>     > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>     >
>     >> Enable support for booting U-Boot image from filesystem instead of some
>     >> random offset on the SD card. This makes the board usable by putting the
>     >> u-boot.img to first partition of the SD card and writing the SPL this way:
>     >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
>     >
>     > Wait, you're still writing u-boot + SPL to the device and not just SPL,
>     > but it's still preferring the filesystem one over the appended one?
>     >
> 
>     Ha, good point. I should've written the 'SPL' file instead, which is
>     just the SPL without U-Boot. I don't want to install U-Boot to random
>     offset on the SD card as it has the potential to corrupt data if the
>     u-boot binary changes in size.
> 
>     If I install u-boot image to random offset 138 blocks from the start of
>     SD card, it will boot that, otherwise it will load from FS.
> 
>     I will update the commit message with the correct info, sorry.
> 
> 
> Oh, we went thru this last year...
> 
> http://lists.denx.de/pipermail/u-boot/2015-August/222061.html
> 
> If your serious about changing "one" i.mx6 board, you need to change
> them "all".

No, I do not have to change and will not change any other boards I
cannot test.

> Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img
> as that works for ti/imx/sunxi...

No, this design is utterly broken. If U-Boot grows beyond 1 MiB, it will
corrupt my data, silently. I will not have this. I would much rather see
these broken designs go away and have everyone move to
SPL in random location as mandated by BootROM (unfortunately) and
u-boot.img on a filesystem. That way, u-boot.img can grow and shrink
either way, without endangering any surrounding data.

Can you give me any argument why writing u-boot.img to random location
on the SD card is better than storing it on a filesystem ?

> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/


-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Robert Nelson]

On Wed, Apr 27, 2016 at 6:41 PM, Marek Vasut <marex@denx.de> wrote:

> On 04/28/2016 01:32 AM, Robert Nelson wrote:
> >
> >
> > On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <marex@denx.de
> > <mailto:marex@denx.de>> wrote:
> >
> >     On 04/28/2016 01:16 AM, Tom Rini wrote:
> >     > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
> >     >
> >     >> Enable support for booting U-Boot image from filesystem instead
> of some
> >     >> random offset on the SD card. This makes the board usable by
> putting the
> >     >> u-boot.img to first partition of the SD card and writing the SPL
> this way:
> >     >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> >     >
> >     > Wait, you're still writing u-boot + SPL to the device and not just
> SPL,
> >     > but it's still preferring the filesystem one over the appended one?
> >     >
> >
> >     Ha, good point. I should've written the 'SPL' file instead, which is
> >     just the SPL without U-Boot. I don't want to install U-Boot to random
> >     offset on the SD card as it has the potential to corrupt data if the
> >     u-boot binary changes in size.
> >
> >     If I install u-boot image to random offset 138 blocks from the start
> of
> >     SD card, it will boot that, otherwise it will load from FS.
> >
> >     I will update the commit message with the correct info, sorry.
> >
> >
> > Oh, we went thru this last year...
> >
> > http://lists.denx.de/pipermail/u-boot/2015-August/222061.html
> >
> > If your serious about changing "one" i.mx6 board, you need to change
> > them "all".
>
> No, I do not have to change and will not change any other boards I
> cannot test.
>

Okay, so if you can't test, are you going to keep an updated database:

boardx = boots this way?
boardy = boots that way?

Otherwise, keep like the other i.mx6's..

Or throw it under a "kconfig" so you can easily enable either mode.


>
> > Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img
> > as that works for ti/imx/sunxi...
>
> No, this design is utterly broken. If U-Boot grows beyond 1 MiB, it will
> corrupt my data, silently. I will not have this. I would much rather see
> these broken designs go away and have everyone move to
> SPL in random location as mandated by BootROM (unfortunately) and
> u-boot.img on a filesystem. That way, u-boot.img can grow and shrink
> either way, without endangering any surrounding data.
>
> Can you give me any argument why writing u-boot.img to random location
> on the SD card is better than storing it on a filesystem ?
>

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..

http://beagleboard.org/latest-images

Moving it under the 1MB location, has solved that problem.

2:

fedora/debian/ubuntu/yocto all expect this board to have these settings..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

On 04/28/2016 01:49 AM, Robert Nelson wrote:
> 
> 
> On Wed, Apr 27, 2016 at 6:41 PM, Marek Vasut <marex@denx.de
> <mailto:marex@denx.de>> wrote:
> 
>     On 04/28/2016 01:32 AM, Robert Nelson wrote:
>     >
>     >
>     > On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <marex at denx.de <mailto:marex@denx.de>
>     > <mailto:marex at denx.de <mailto:marex@denx.de>>> wrote:
>     >
>     >     On 04/28/2016 01:16 AM, Tom Rini wrote:
>     >     > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>     >     >
>     >     >> Enable support for booting U-Boot image from filesystem instead of some
>     >     >> random offset on the SD card. This makes the board usable by putting the
>     >     >> u-boot.img to first partition of the SD card and writing the SPL this way:
>     >     >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
>     >     >
>     >     > Wait, you're still writing u-boot + SPL to the device and not just SPL,
>     >     > but it's still preferring the filesystem one over the appended one?
>     >     >
>     >
>     >     Ha, good point. I should've written the 'SPL' file instead, which is
>     >     just the SPL without U-Boot. I don't want to install U-Boot to random
>     >     offset on the SD card as it has the potential to corrupt data if the
>     >     u-boot binary changes in size.
>     >
>     >     If I install u-boot image to random offset 138 blocks from the start of
>     >     SD card, it will boot that, otherwise it will load from FS.
>     >
>     >     I will update the commit message with the correct info, sorry.
>     >
>     >
>     > Oh, we went thru this last year...
>     >
>     > http://lists.denx.de/pipermail/u-boot/2015-August/222061.html
>     >
>     > If your serious about changing "one" i.mx6 board, you need to change
>     > them "all".
> 
>     No, I do not have to change and will not change any other boards I
>     cannot test.
> 
> 
> Okay, so if you can't test, are you going to keep an updated database:
> 
> boardx = boots this way?
> boardy = boots that way?

I fail to see why should I do any sort of database, this patch supports
both behaviors -- the old (broken) and the new (booting from FS). All
new boards should load u-boot from filesystem and old boards should be
updated as people have time.

> Otherwise, keep like the other i.mx6's..

I can pick "other mx6s" which boot from filesystem, like Novena, and I
will never allow that board to boot from ad-hoc offset.

> Or throw it under a "kconfig" so you can easily enable either mode.

Both modes are enabled, which should allow seamless conversion.
If there is another problem, it should be addressed.

>     > Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img
>     > as that works for ti/imx/sunxi...
> 
>     No, this design is utterly broken. If U-Boot grows beyond 1 MiB, it will
>     corrupt my data, silently. I will not have this. I would much rather see
>     these broken designs go away and have everyone move to
>     SPL in random location as mandated by BootROM (unfortunately) and
>     u-boot.img on a filesystem. That way, u-boot.img can grow and shrink
>     either way, without endangering any surrounding data.
> 
>     Can you give me any argument why writing u-boot.img to random location
>     on the SD card is better than storing it on a filesystem ?
> 
> 
> 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.

> 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.

> 2:
> 
> fedora/debian/ubuntu/yocto all expect this board to have these settings..

Sadly, they are all broken and need fixing, but they are broken because
historically, there was no filesystem support in SPL. I have had this
discussion with debian guys already about fixing it.

> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/


-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Tom Rini]

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>

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Robert Nelson]

On Wed, Apr 27, 2016 at 7:54 PM, Tom Rini <trini@konsulko.com> wrote:

> 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.
>

I've followed the 4kb convention and fdisk defaults to 1MB offset: (even
thou we aren't dealing spinning disks)

https://www.ibm.com/developerworks/library/l-linux-on-4kb-sector-disks/

I haven't looked at the latest eMMC spec, but the eMMC 'boot' sections on
current silicon is only 1MB (x2)

mmcblk1boot0 179:16   0    1M  1 disk
mmcblk1boot1 179:24   0    1M  1 disk
mmcblk1      179:8    0  1.8G  0 disk

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Peng Fan]

Hi Marek,

On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>Enable support for booting U-Boot image from filesystem instead of some
>random offset on the SD card. This makes the board usable by putting the
>u-boot.img to first partition of the SD card and writing the SPL this way:
>$ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512

I once want to enable this for i.MX6UL, but was rejected.
Anyway I prefer load u-boot.img from filesystem.

>
>Signed-off-by: Marek Vasut <marex@denx.de>
>Cc: Stefano Babic <sbabic@denx.de>

Acked-by: Peng Fan <van.freenix@gmail.com>

Regards,
Peng.
>---
> include/configs/wandboard.h | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
>index 99f5c0c..fbce730 100644
>--- a/include/configs/wandboard.h
>+++ b/include/configs/wandboard.h
>@@ -14,6 +14,8 @@
> 
> #define CONFIG_SPL_LIBCOMMON_SUPPORT
> #define CONFIG_SPL_MMC_SUPPORT
>+#define CONFIG_SPL_FAT_SUPPORT
>+#define CONFIG_SPL_EXT_SUPPORT
> #include "imx6_spl.h"
> 
> #define MACH_TYPE_WANDBOARD		4412
>-- 
>2.7.0
>
>_______________________________________________
>U-Boot mailing list
>U-Boot at lists.denx.de
>http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Stefano Babic]

Hi Marek,

On 28/04/2016 04:24, Peng Fan wrote:
> Hi Marek,
> 
> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>> Enable support for booting U-Boot image from filesystem instead of some
>> random offset on the SD card. This makes the board usable by putting the
>> u-boot.img to first partition of the SD card and writing the SPL this way:
>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> 
> I once want to enable this for i.MX6UL, but was rejected.
> Anyway I prefer load u-boot.img from filesystem.
> 

Right - we have this discussion some times ago. The agreement we reach
was to maintain SPL loading only from a raw image.

https://www.mail-archive.com/u-boot at lists.denx.de/msg185432.html

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

On 04/28/2016 07:59 AM, Stefano Babic wrote:
> Hi Marek,
> 
> On 28/04/2016 04:24, Peng Fan wrote:
>> Hi Marek,
>>
>> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>>> Enable support for booting U-Boot image from filesystem instead of some
>>> random offset on the SD card. This makes the board usable by putting the
>>> u-boot.img to first partition of the SD card and writing the SPL this way:
>>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
>>
>> I once want to enable this for i.MX6UL, but was rejected.
>> Anyway I prefer load u-boot.img from filesystem.
>>
> 
> Right - we have this discussion some times ago. The agreement we reach
> was to maintain SPL loading only from a raw image.
> 
> https://www.mail-archive.com/u-boot at lists.denx.de/msg185432.html

The feeling I get from the discussion you linked above and the
discussion here is that because user can be an idiot and delete
files at random, we should move back to the 80s and store files
like on the casette tapes, at random offset. User can also delete
kernel image and yet, we store it on the filesystem. Maybe we should
also store the kernel image at another raw offset ... and hey, maybe
we should ditch filesystem altogether, just tar everything up and
store it at yet another offset, since user might delete files at
random, just imaging he'd delete libc ...

-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Tom Rini]

On Wed, Apr 27, 2016 at 08:06:24PM -0500, Robert Nelson wrote:
> On Wed, Apr 27, 2016 at 7:54 PM, Tom Rini <trini@konsulko.com> wrote:
> 
> > 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.
> >
> 
> I've followed the 4kb convention and fdisk defaults to 1MB offset: (even
> thou we aren't dealing spinning disks)
> 
> https://www.ibm.com/developerworks/library/l-linux-on-4kb-sector-disks/
> 
> I haven't looked at the latest eMMC spec, but the eMMC 'boot' sections on
> current silicon is only 1MB (x2)
> 
> mmcblk1boot0 179:16   0    1M  1 disk
> mmcblk1boot1 179:24   0    1M  1 disk
> mmcblk1      179:8    0  1.8G  0 disk

eMMC is "different" since you don't partition the boot sections usually,
so offset of 0 is good.  But for the eMMC itself when you do partition
it I'd have sworn 4MiB was what to align on.  I haven't thrown
flashbench on something in a while however...

-- 
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/20160428/91e3c170/attachment.sig>

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Stefano Babic]

Hi Marek,

On 28/04/2016 13:03, Marek Vasut wrote:
> On 04/28/2016 07:59 AM, Stefano Babic wrote:
>> Hi Marek,
>>
>> On 28/04/2016 04:24, Peng Fan wrote:
>>> Hi Marek,
>>>
>>> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>>>> Enable support for booting U-Boot image from filesystem instead of some
>>>> random offset on the SD card. This makes the board usable by putting the
>>>> u-boot.img to first partition of the SD card and writing the SPL this way:
>>>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
>>>
>>> I once want to enable this for i.MX6UL, but was rejected.
>>> Anyway I prefer load u-boot.img from filesystem.
>>>
>>
>> Right - we have this discussion some times ago. The agreement we reach
>> was to maintain SPL loading only from a raw image.
>>
>> https://www.mail-archive.com/u-boot at lists.denx.de/msg185432.html
> 
> The feeling I get from the discussion you linked above and the
> discussion here is that because user can be an idiot and delete
> files at random, we should move back to the 80s 

No U-Boot in the 80s.

> and store files
> like on the casette tapes, at random offset. User can also delete
> kernel image and yet, we store it on the filesystem. Maybe we should
> also store the kernel image at another raw offset ... and hey, maybe
> we should ditch filesystem altogether, just tar everything up and
> store it at yet another offset, since user might delete files at
> random, just imaging he'd delete libc ...

wandboard has a market quite similar to the Raspi and yes, there is a
lot of inexperienced people using it.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

On 04/28/2016 03:36 PM, Stefano Babic wrote:
> Hi Marek,
> 
> On 28/04/2016 13:03, Marek Vasut wrote:
>> On 04/28/2016 07:59 AM, Stefano Babic wrote:
>>> Hi Marek,
>>>
>>> On 28/04/2016 04:24, Peng Fan wrote:
>>>> Hi Marek,
>>>>
>>>> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>>>>> Enable support for booting U-Boot image from filesystem instead of some
>>>>> random offset on the SD card. This makes the board usable by putting the
>>>>> u-boot.img to first partition of the SD card and writing the SPL this way:
>>>>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
>>>>
>>>> I once want to enable this for i.MX6UL, but was rejected.
>>>> Anyway I prefer load u-boot.img from filesystem.
>>>>
>>>
>>> Right - we have this discussion some times ago. The agreement we reach
>>> was to maintain SPL loading only from a raw image.
>>>
>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg185432.html
>>
>> The feeling I get from the discussion you linked above and the
>> discussion here is that because user can be an idiot and delete
>> files at random, we should move back to the 80s 
> 
> No U-Boot in the 80s.
> 
>> and store files
>> like on the casette tapes, at random offset. User can also delete
>> kernel image and yet, we store it on the filesystem. Maybe we should
>> also store the kernel image at another raw offset ... and hey, maybe
>> we should ditch filesystem altogether, just tar everything up and
>> store it at yet another offset, since user might delete files at
>> random, just imaging he'd delete libc ...
> 
> wandboard has a market quite similar to the Raspi and yes, there is a
> lot of inexperienced people using it.

Shall I prepare a patch which places kernel to yet another ad-hoc
location on the SD card then and tweak bootargs to use cramfs then?

-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Tom Rini]

On Thu, Apr 28, 2016 at 03:40:45PM +0200, Marek Vasut wrote:
> On 04/28/2016 03:36 PM, Stefano Babic wrote:
> > Hi Marek,
> > 
> > On 28/04/2016 13:03, Marek Vasut wrote:
> >> On 04/28/2016 07:59 AM, Stefano Babic wrote:
> >>> Hi Marek,
> >>>
> >>> On 28/04/2016 04:24, Peng Fan wrote:
> >>>> Hi Marek,
> >>>>
> >>>> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
> >>>>> Enable support for booting U-Boot image from filesystem instead of some
> >>>>> random offset on the SD card. This makes the board usable by putting the
> >>>>> u-boot.img to first partition of the SD card and writing the SPL this way:
> >>>>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> >>>>
> >>>> I once want to enable this for i.MX6UL, but was rejected.
> >>>> Anyway I prefer load u-boot.img from filesystem.
> >>>>
> >>>
> >>> Right - we have this discussion some times ago. The agreement we reach
> >>> was to maintain SPL loading only from a raw image.
> >>>
> >>> https://www.mail-archive.com/u-boot at lists.denx.de/msg185432.html
> >>
> >> The feeling I get from the discussion you linked above and the
> >> discussion here is that because user can be an idiot and delete
> >> files at random, we should move back to the 80s 
> > 
> > No U-Boot in the 80s.
> > 
> >> and store files
> >> like on the casette tapes, at random offset. User can also delete
> >> kernel image and yet, we store it on the filesystem. Maybe we should
> >> also store the kernel image at another raw offset ... and hey, maybe
> >> we should ditch filesystem altogether, just tar everything up and
> >> store it at yet another offset, since user might delete files at
> >> random, just imaging he'd delete libc ...
> > 
> > wandboard has a market quite similar to the Raspi and yes, there is a
> > lot of inexperienced people using it.
> 
> Shall I prepare a patch which places kernel to yet another ad-hoc
> location on the SD card then and tweak bootargs to use cramfs then?

Users bricking their devices is a real problem.  I don't object to
adding support for many ways of doing things (we have it on TI boards
today) enabled, but saying there's no use case nor reason to do non-FS
installs is also missing the mark.

-- 
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/20160428/00bcd6bf/attachment.sig>

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

On 04/28/2016 08:06 PM, Tom Rini wrote:
> On Thu, Apr 28, 2016 at 03:40:45PM +0200, Marek Vasut wrote:
>> On 04/28/2016 03:36 PM, Stefano Babic wrote:
>>> Hi Marek,
>>>
>>> On 28/04/2016 13:03, Marek Vasut wrote:
>>>> On 04/28/2016 07:59 AM, Stefano Babic wrote:
>>>>> Hi Marek,
>>>>>
>>>>> On 28/04/2016 04:24, Peng Fan wrote:
>>>>>> Hi Marek,
>>>>>>
>>>>>> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>>>>>>> Enable support for booting U-Boot image from filesystem instead of some
>>>>>>> random offset on the SD card. This makes the board usable by putting the
>>>>>>> u-boot.img to first partition of the SD card and writing the SPL this way:
>>>>>>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
>>>>>>
>>>>>> I once want to enable this for i.MX6UL, but was rejected.
>>>>>> Anyway I prefer load u-boot.img from filesystem.
>>>>>>
>>>>>
>>>>> Right - we have this discussion some times ago. The agreement we reach
>>>>> was to maintain SPL loading only from a raw image.
>>>>>
>>>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg185432.html
>>>>
>>>> The feeling I get from the discussion you linked above and the
>>>> discussion here is that because user can be an idiot and delete
>>>> files at random, we should move back to the 80s 
>>>
>>> No U-Boot in the 80s.
>>>
>>>> and store files
>>>> like on the casette tapes, at random offset. User can also delete
>>>> kernel image and yet, we store it on the filesystem. Maybe we should
>>>> also store the kernel image at another raw offset ... and hey, maybe
>>>> we should ditch filesystem altogether, just tar everything up and
>>>> store it at yet another offset, since user might delete files at
>>>> random, just imaging he'd delete libc ...
>>>
>>> wandboard has a market quite similar to the Raspi and yes, there is a
>>> lot of inexperienced people using it.
>>
>> Shall I prepare a patch which places kernel to yet another ad-hoc
>> location on the SD card then and tweak bootargs to use cramfs then?
> 
> Users bricking their devices is a real problem.  I don't object to
> adding support for many ways of doing things (we have it on TI boards
> today) enabled, but saying there's no use case nor reason to do non-FS
> installs is also missing the mark.
> 
I am convinced this patch does not remove the "fallback to legacy
behavior" though.

-- 
Best regards,
Marek Vasut

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Tom Rini]

On Thu, Apr 28, 2016 at 08:29:47PM +0200, Marek Vasut wrote:
> On 04/28/2016 08:06 PM, Tom Rini wrote:
> > On Thu, Apr 28, 2016 at 03:40:45PM +0200, Marek Vasut wrote:
> >> On 04/28/2016 03:36 PM, Stefano Babic wrote:
> >>> Hi Marek,
> >>>
> >>> On 28/04/2016 13:03, Marek Vasut wrote:
> >>>> On 04/28/2016 07:59 AM, Stefano Babic wrote:
> >>>>> Hi Marek,
> >>>>>
> >>>>> On 28/04/2016 04:24, Peng Fan wrote:
> >>>>>> Hi Marek,
> >>>>>>
> >>>>>> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
> >>>>>>> Enable support for booting U-Boot image from filesystem instead of some
> >>>>>>> random offset on the SD card. This makes the board usable by putting the
> >>>>>>> u-boot.img to first partition of the SD card and writing the SPL this way:
> >>>>>>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
> >>>>>>
> >>>>>> I once want to enable this for i.MX6UL, but was rejected.
> >>>>>> Anyway I prefer load u-boot.img from filesystem.
> >>>>>>
> >>>>>
> >>>>> Right - we have this discussion some times ago. The agreement we reach
> >>>>> was to maintain SPL loading only from a raw image.
> >>>>>
> >>>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg185432.html
> >>>>
> >>>> The feeling I get from the discussion you linked above and the
> >>>> discussion here is that because user can be an idiot and delete
> >>>> files at random, we should move back to the 80s 
> >>>
> >>> No U-Boot in the 80s.
> >>>
> >>>> and store files
> >>>> like on the casette tapes, at random offset. User can also delete
> >>>> kernel image and yet, we store it on the filesystem. Maybe we should
> >>>> also store the kernel image at another raw offset ... and hey, maybe
> >>>> we should ditch filesystem altogether, just tar everything up and
> >>>> store it at yet another offset, since user might delete files at
> >>>> random, just imaging he'd delete libc ...
> >>>
> >>> wandboard has a market quite similar to the Raspi and yes, there is a
> >>> lot of inexperienced people using it.
> >>
> >> Shall I prepare a patch which places kernel to yet another ad-hoc
> >> location on the SD card then and tweak bootargs to use cramfs then?
> > 
> > Users bricking their devices is a real problem.  I don't object to
> > adding support for many ways of doing things (we have it on TI boards
> > today) enabled, but saying there's no use case nor reason to do non-FS
> > installs is also missing the mark.
> 
> I am convinced this patch does not remove the "fallback to legacy
> behavior" though.

Good.  Then you need to shove this up and over to the right common
location since all of the offsets are, or better be (or we have a
problem here..) the same for all imx6 and probably falling back a while
too.  I know on TI parts the "magic" locations go back farther than
U-Boot still supports.  And I know that might take a little time which
is fine, this isn't a patch that needs to be in for v2016.05.

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

[U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support

[Marek Vasut]

On 04/28/2016 09:02 PM, Tom Rini wrote:
> On Thu, Apr 28, 2016 at 08:29:47PM +0200, Marek Vasut wrote:
>> On 04/28/2016 08:06 PM, Tom Rini wrote:
>>> On Thu, Apr 28, 2016 at 03:40:45PM +0200, Marek Vasut wrote:
>>>> On 04/28/2016 03:36 PM, Stefano Babic wrote:
>>>>> Hi Marek,
>>>>>
>>>>> On 28/04/2016 13:03, Marek Vasut wrote:
>>>>>> On 04/28/2016 07:59 AM, Stefano Babic wrote:
>>>>>>> Hi Marek,
>>>>>>>
>>>>>>> On 28/04/2016 04:24, Peng Fan wrote:
>>>>>>>> Hi Marek,
>>>>>>>>
>>>>>>>> On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote:
>>>>>>>>> Enable support for booting U-Boot image from filesystem instead of some
>>>>>>>>> random offset on the SD card. This makes the board usable by putting the
>>>>>>>>> u-boot.img to first partition of the SD card and writing the SPL this way:
>>>>>>>>> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512
>>>>>>>>
>>>>>>>> I once want to enable this for i.MX6UL, but was rejected.
>>>>>>>> Anyway I prefer load u-boot.img from filesystem.
>>>>>>>>
>>>>>>>
>>>>>>> Right - we have this discussion some times ago. The agreement we reach
>>>>>>> was to maintain SPL loading only from a raw image.
>>>>>>>
>>>>>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg185432.html
>>>>>>
>>>>>> The feeling I get from the discussion you linked above and the
>>>>>> discussion here is that because user can be an idiot and delete
>>>>>> files at random, we should move back to the 80s 
>>>>>
>>>>> No U-Boot in the 80s.
>>>>>
>>>>>> and store files
>>>>>> like on the casette tapes, at random offset. User can also delete
>>>>>> kernel image and yet, we store it on the filesystem. Maybe we should
>>>>>> also store the kernel image at another raw offset ... and hey, maybe
>>>>>> we should ditch filesystem altogether, just tar everything up and
>>>>>> store it at yet another offset, since user might delete files at
>>>>>> random, just imaging he'd delete libc ...
>>>>>
>>>>> wandboard has a market quite similar to the Raspi and yes, there is a
>>>>> lot of inexperienced people using it.
>>>>
>>>> Shall I prepare a patch which places kernel to yet another ad-hoc
>>>> location on the SD card then and tweak bootargs to use cramfs then?
>>>
>>> Users bricking their devices is a real problem.  I don't object to
>>> adding support for many ways of doing things (we have it on TI boards
>>> today) enabled, but saying there's no use case nor reason to do non-FS
>>> installs is also missing the mark.
>>
>> I am convinced this patch does not remove the "fallback to legacy
>> behavior" though.
> 
> Good.  Then you need to shove this up and over to the right common
> location since all of the offsets are, or better be (or we have a
> problem here..) the same for all imx6 and probably falling back a while
> too.  I know on TI parts the "magic" locations go back farther than
> U-Boot still supports.  And I know that might take a little time which
> is fine, this isn't a patch that needs to be in for v2016.05.
> 
Hm, grumble, the thing is falling apart the more I drill into it. There
will be a few more patches needed to deal with this raw legacy. Sigh ...

-- 
Best regards,
Marek Vasut