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

[Marek Vasut <marex@denx.de>]

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