From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 28 Apr 2016 20:29:47 +0200 Subject: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support In-Reply-To: <20160428180635.GO19598@bill-the-cat> References: <1461798367-9723-1-git-send-email-marex@denx.de> <20160428021647.GA31323@linux-7smt.suse> <5721A6B7.202@denx.de> <5721EE0B.80907@denx.de> <572211C3.5040601@denx.de> <572212DD.6060607@denx.de> <20160428180635.GO19598@bill-the-cat> Message-ID: <5722569B.6070808@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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