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@denx.de <mailto:marex@denx.de> > <mailto:marex@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/