[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@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