ARM: mx6: Enable MMC FS boot support
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
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
--- include/configs/wandboard.h | 2 ++ 1 file changed, 2 insertions(+)
include/configs/wandboard.h +2 -0
@@ -14,6 +14,8 @@#define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_MMC_SUPPORT +#define CONFIG_SPL_FAT_SUPPORT +#define CONFIG_SPL_EXT_SUPPORT #include "imx6_spl.h" #define MACH_TYPE_WANDBOARD 4412
Signature · 1 line
2.7.0
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 4 lines · Marek Vasut
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?
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160427/0037eb51/attachment.sig>
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 10 lines · Tom Rini
Quoted 4 lines · Marek Vasut
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=512Wait, 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.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 18 lines · Marek Vasut
Quoted 5 lines · Tom Rini
Quoted 3 lines · Marek Vasut
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:
Quoted 5 lines
Quoted 1 line
$ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512Wait, 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.
Quoted 5 lines
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".
Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img as that works for ti/imx/sunxi...
Regards,
Signature · 2 lines
Robert Nelson https://rcn-ee.com/
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 28 lines · Robert Nelson
On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <[email protected] <mailto:[email protected]>> 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.
Quoted 6 lines
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.
Quoted 2 lines
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 ?
Quoted 5 lines
Regards,
Signature · 2 lines
Robert Nelson https://rcn-ee.com/
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 36 lines · Marek Vasut
Quoted 9 lines · Robert Nelson
On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <[email protected] <mailto:[email protected]>> 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 insteadof some
Quoted 1 line
Quoted 1 line
Quoted 1 line
random offset on the SD card. This makes the board usable by
putting the
Quoted 1 line
Quoted 1 line
Quoted 1 line
u-boot.img to first partition of the SD card and writing the SPL
this way:
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
$ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512Wait, you're still writing u-boot + SPL to the device and not just
SPL,
Quoted 9 lines
Quoted 2 lines
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
Quoted 7 lines
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...
Quoted 8 lines
Quoted 4 lines
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?
Otherwise, keep like the other i.mx6's..
Or throw it under a "kconfig" so you can easily enable either mode.
Quoted 11 lines
Quoted 3 lines
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.
Quoted 3 lines
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..
http://beagleboard.org/latest-images
Moving it under the 1MB location, has solved that problem.
2:
fedora/debian/ubuntu/yocto all expect this board to have these settings..
Regards,
Signature · 2 lines
Robert Nelson https://rcn-ee.com/
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 45 lines · Robert Nelson
On Wed, Apr 27, 2016 at 6:41 PM, Marek Vasut <[email protected] <mailto:[email protected]>> wrote:
On 04/28/2016 01:32 AM, Robert Nelson wrote: > > > On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <marex at denx.de <mailto:[email protected]> > <mailto:marex at denx.de <mailto:[email protected]>>> 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.
Quoted 4 lines
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.
Quoted 1 line
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.
Quoted 1 line
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.
Quoted 14 lines
Quoted 2 lines
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 ?
Quoted 6 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
Regards,
Signature · 2 lines
Robert Nelson https://rcn-ee.com/
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 1 line · Marek Vasut
On 04/28/2016 01:49 AM, Robert Nelson wrote:
[snip]
Quoted 11 lines
Quoted 6 lines
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.
No, real users. Lots of them. From nearly every "community" oriented board ever. Which is why the distros also go for this method, point #2.
Quoted 7 lines
Quoted 3 lines
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.
I thought people were supposed to be aligning their first partitions much higher these days, 4MiB? as the general case for being safe regardless of the actual flash in the SD card. Setting aside sandbox which I hope grows extremely large for testing purposes, I really hope U-Boot + SPL can always stay under 1MiB. Our job is to boot the next stage. If we get so large in our design of implementing things that we forget this, we have a problem.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160427/3fd4dc42/attachment.sig>
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 26 lines · Tom Rini
Quoted 1 line · Marek Vasut
On 04/28/2016 01:49 AM, Robert Nelson wrote:
[snip]
Quoted 11 lines
Quoted 6 lines
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.
No, real users. Lots of them. From nearly every "community" oriented board ever. Which is why the distros also go for this method, point #2.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 8 lines
I thought people were supposed to be aligning their first partitions much higher these days, 4MiB? as the general case for being safe regardless of the actual flash in the SD card. Setting aside sandbox which I hope grows extremely large for testing purposes, I really hope U-Boot + SPL can always stay under 1MiB. Our job is to boot the next stage. If we get so large in our design of implementing things that we forget this, we have a problem.
I've followed the 4kb convention and fdisk defaults to 1MB offset: (even thou we aren't dealing spinning disks)
https://www.ibm.com/developerworks/library/l-linux-on-4kb-sector-disks/
I haven't looked at the latest eMMC spec, but the eMMC 'boot' sections on current silicon is only 1MB (x2)
mmcblk1boot0 179:16 0 1M 1 disk mmcblk1boot1 179:24 0 1M 1 disk mmcblk1 179:8 0 1.8G 0 disk
Regards,
Signature · 2 lines
Robert Nelson https://rcn-ee.com/
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 40 lines · Robert Nelson
Quoted 26 lines · Tom Rini
Quoted 1 line · Marek Vasut
On 04/28/2016 01:49 AM, Robert Nelson wrote:
[snip]
Quoted 11 lines
Quoted 6 lines
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.
No, real users. Lots of them. From nearly every "community" oriented board ever. Which is why the distros also go for this method, point #2.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 8 lines
I thought people were supposed to be aligning their first partitions much higher these days, 4MiB? as the general case for being safe regardless of the actual flash in the SD card. Setting aside sandbox which I hope grows extremely large for testing purposes, I really hope U-Boot + SPL can always stay under 1MiB. Our job is to boot the next stage. If we get so large in our design of implementing things that we forget this, we have a problem.
I've followed the 4kb convention and fdisk defaults to 1MB offset: (even thou we aren't dealing spinning disks)
Quoted 8 lines
https://www.ibm.com/developerworks/library/l-linux-on-4kb-sector-disks/
I haven't looked at the latest eMMC spec, but the eMMC 'boot' sections on current silicon is only 1MB (x2)
mmcblk1boot0 179:16 0 1M 1 disk mmcblk1boot1 179:24 0 1M 1 disk mmcblk1 179:8 0 1.8G 0 disk
eMMC is "different" since you don't partition the boot sections usually, so offset of 0 is good. But for the eMMC itself when you do partition it I'd have sworn 4MiB was what to align on. I haven't thrown flashbench on something in a while however...
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160428/91e3c170/attachment.sig>
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
In reply to Marek VasutHi Marek,
Quoted 4 lines · Marek Vasut
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.
Quoted 3 lines
Signed-off-by Marek Vasut <[email protected]>Cc Stefano Babic <[email protected]>
Regards,
Peng.
Quoted 24 lines
---
include/configs/wandboard.h| 2 ++1 file changed, 2 insertions(+)include/configs/wandboard.h +2
-0@@ -14,6 +14,8 @@#define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_MMC_SUPPORT +#define CONFIG_SPL_FAT_SUPPORT +#define CONFIG_SPL_EXT_SUPPORT #include "imx6_spl.h" #define MACH_TYPE_WANDBOARD 4412Signature · 6 lines
2.7.0 _______________________________________________ U-Boot mailing list U-Boot at lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Hi Marek,
Quoted 11 lines · Peng Fan
Hi Marek,
Quoted 4 lines · Marek Vasut
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=512I 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
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 11 lines · Stefano Babic
Hi Marek,
Quoted 8 lines · Peng Fan
Hi Marek,
Quoted 4 lines · Marek Vasut
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
Quoted 8 lines
Quoted 3 lines
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 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 ...
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Hi Marek,
Quoted 16 lines · Marek Vasut
Quoted 15 lines · Stefano Babic
Hi Marek,
Quoted 11 lines · Peng Fan
Hi Marek,
Quoted 4 lines · Marek Vasut
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=512I once want to enable this for i.MX6UL, but was rejected. Anyway I prefer load u-boot.img from filesystem.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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.
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 38 lines · Stefano Babic
Hi Marek,
Quoted 16 lines · Marek Vasut
Quoted 15 lines · Stefano Babic
Hi Marek,
Quoted 11 lines · Peng Fan
Hi Marek,
Quoted 4 lines · Marek Vasut
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=512I once want to enable this for i.MX6UL, but was rejected. Anyway I prefer load u-boot.img from filesystem.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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 ...
Quoted 2 lines
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?
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 39 lines · Marek Vasut
Quoted 38 lines · Stefano Babic
Hi Marek,
Quoted 16 lines · Marek Vasut
Quoted 15 lines · Stefano Babic
Hi Marek,
Quoted 11 lines · Peng Fan
Hi Marek,
Quoted 4 lines · Marek Vasut
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=512I once want to enable this for i.MX6UL, but was rejected. Anyway I prefer load u-boot.img from filesystem.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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 ...
Quoted 5 lines
Quoted 2 lines
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.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160428/00bcd6bf/attachment.sig>
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 43 lines · Tom Rini
Quoted 42 lines · Marek Vasut
Quoted 40 lines · Stefano Babic
Hi Marek,
Quoted 16 lines · Marek Vasut
Quoted 15 lines · Stefano Babic
Hi Marek,
Quoted 11 lines · Peng Fan
Hi Marek,
Quoted 4 lines · Marek Vasut
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=512I once want to enable this for i.MX6UL, but was rejected. Anyway I prefer load u-boot.img from filesystem.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 47 lines · Marek Vasut
Quoted 46 lines · Tom Rini
Quoted 44 lines · Marek Vasut
Quoted 38 lines · Stefano Babic
Hi Marek,
Quoted 16 lines · Marek Vasut
Quoted 15 lines · Stefano Babic
Hi Marek,
Quoted 11 lines · Peng Fan
Hi Marek,
Quoted 4 lines · Marek Vasut
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=512I once want to enable this for i.MX6UL, but was rejected. Anyway I prefer load u-boot.img from filesystem.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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 ...Quoted 2 lines
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?
Quoted 7 lines
Quoted 4 lines
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.
Good. Then you need to shove this up and over to the right common location since all of the offsets are, or better be (or we have a problem here..) the same for all imx6 and probably falling back a while too. I know on TI parts the "magic" locations go back farther than U-Boot still supports. And I know that might take a little time which is fine, this isn't a patch that needs to be in for v2016.05.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160428/d3ad2645/attachment.sig>
PATCH 1/1 ARM: mx6: Enable MMC FS boot support
Quoted 56 lines · Tom Rini
Quoted 47 lines · Marek Vasut
Quoted 46 lines · Tom Rini
Quoted 44 lines · Marek Vasut
Quoted 38 lines · Stefano Babic
Hi Marek,
Quoted 16 lines · Marek Vasut
Quoted 15 lines · Stefano Babic
Hi Marek,
Quoted 11 lines · Peng Fan
Hi Marek,
Quoted 4 lines · Marek Vasut
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=512I once want to enable this for i.MX6UL, but was rejected. Anyway I prefer load u-boot.img from filesystem.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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 ...Quoted 2 lines
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?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
Good. Then you need to shove this up and over to the right common location since all of the offsets are, or better be (or we have a problem here..) the same for all imx6 and probably falling back a while too. I know on TI parts the "magic" locations go back farther than U-Boot still supports. And I know that might take a little time which is fine, this isn't a patch that needs to be in for v2016.05.
Hm, grumble, the thing is falling apart the more I drill into it. There will be a few more patches needed to deal with this raw legacy. Sigh ...
Signature · 2 lines
Best regards, Marek Vasut