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

Marek Vasut
2016-04-28T00:02:05Z

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