From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 28 Apr 2016 02:02:05 +0200 Subject: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support In-Reply-To: References: <1461798367-9723-1-git-send-email-marex@denx.de> <20160427231647.GF19598@bill-the-cat> <57214B34.6040005@denx.de> <57214E46.1050208@denx.de> Message-ID: <572152FD.1020101@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 01:49 AM, Robert Nelson wrote: > > > On Wed, Apr 27, 2016 at 6:41 PM, Marek Vasut > wrote: > > On 04/28/2016 01:32 AM, Robert Nelson wrote: > > > > > > On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut > > >> 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