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.