* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support @ 2016-04-27 23:06 Marek Vasut 2016-04-27 23:16 ` Tom Rini 2016-04-28 2:24 ` Peng Fan 0 siblings, 2 replies; 19+ messages in thread From: Marek Vasut @ 2016-04-27 23:06 UTC (permalink / raw) To: u-boot 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 Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de> --- include/configs/wandboard.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index 99f5c0c..fbce730 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -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 -- 2.7.0 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-27 23:06 [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support Marek Vasut @ 2016-04-27 23:16 ` Tom Rini 2016-04-27 23:28 ` Marek Vasut 2016-04-28 2:24 ` Peng Fan 1 sibling, 1 reply; 19+ messages in thread From: Tom Rini @ 2016-04-27 23:16 UTC (permalink / raw) To: u-boot 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? -- 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-27 23:16 ` Tom Rini @ 2016-04-27 23:28 ` Marek Vasut 2016-04-27 23:32 ` Robert Nelson 0 siblings, 1 reply; 19+ messages in thread From: Marek Vasut @ 2016-04-27 23:28 UTC (permalink / raw) To: u-boot 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. -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-27 23:28 ` Marek Vasut @ 2016-04-27 23:32 ` Robert Nelson 2016-04-27 23:41 ` Marek Vasut 0 siblings, 1 reply; 19+ messages in thread From: Robert Nelson @ 2016-04-27 23:32 UTC (permalink / raw) To: u-boot On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <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". Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img as that works for ti/imx/sunxi... Regards, -- Robert Nelson https://rcn-ee.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-27 23:32 ` Robert Nelson @ 2016-04-27 23:41 ` Marek Vasut 2016-04-27 23:49 ` Robert Nelson 0 siblings, 1 reply; 19+ messages in thread From: Marek Vasut @ 2016-04-27 23:41 UTC (permalink / raw) To: u-boot 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>> 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. > 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 ? > Regards, > > -- > Robert Nelson > https://rcn-ee.com/ -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-27 23:41 ` Marek Vasut @ 2016-04-27 23:49 ` Robert Nelson 2016-04-28 0:02 ` Marek Vasut 0 siblings, 1 reply; 19+ messages in thread From: Robert Nelson @ 2016-04-27 23:49 UTC (permalink / raw) To: u-boot On Wed, Apr 27, 2016 at 6:41 PM, Marek Vasut <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>> 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? Otherwise, keep like the other i.mx6's.. Or throw it under a "kconfig" so you can easily enable either mode. > > > 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.. 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, -- Robert Nelson https://rcn-ee.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-27 23:49 ` Robert Nelson @ 2016-04-28 0:02 ` Marek Vasut 2016-04-28 0:54 ` Tom Rini 0 siblings, 1 reply; 19+ messages in thread From: Marek Vasut @ 2016-04-28 0:02 UTC (permalink / raw) To: u-boot 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 at denx.de <mailto:marex@denx.de> > > <mailto:marex at 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/ -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 0:02 ` Marek Vasut @ 2016-04-28 0:54 ` Tom Rini 2016-04-28 1:06 ` Robert Nelson 0 siblings, 1 reply; 19+ messages in thread From: Tom Rini @ 2016-04-28 0:54 UTC (permalink / raw) To: u-boot On Thu, Apr 28, 2016 at 02:02:05AM +0200, Marek Vasut wrote: > On 04/28/2016 01:49 AM, Robert Nelson wrote: [snip] > > 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. > > 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. -- 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 0:54 ` Tom Rini @ 2016-04-28 1:06 ` Robert Nelson 2016-04-28 12:02 ` Tom Rini 0 siblings, 1 reply; 19+ messages in thread From: Robert Nelson @ 2016-04-28 1:06 UTC (permalink / raw) To: u-boot On Wed, Apr 27, 2016 at 7:54 PM, Tom Rini <trini@konsulko.com> wrote: > On Thu, Apr 28, 2016 at 02:02:05AM +0200, Marek Vasut wrote: > > On 04/28/2016 01:49 AM, Robert Nelson wrote: > [snip] > > > 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. > > > > 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. > 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, -- Robert Nelson https://rcn-ee.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 1:06 ` Robert Nelson @ 2016-04-28 12:02 ` Tom Rini 0 siblings, 0 replies; 19+ messages in thread From: Tom Rini @ 2016-04-28 12:02 UTC (permalink / raw) To: u-boot On Wed, Apr 27, 2016 at 08:06:24PM -0500, Robert Nelson wrote: > On Wed, Apr 27, 2016 at 7:54 PM, Tom Rini <trini@konsulko.com> wrote: > > > On Thu, Apr 28, 2016 at 02:02:05AM +0200, Marek Vasut wrote: > > > On 04/28/2016 01:49 AM, Robert Nelson wrote: > > [snip] > > > > 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. > > > > > > 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. > > > > 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 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... -- 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-27 23:06 [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support Marek Vasut 2016-04-27 23:16 ` Tom Rini @ 2016-04-28 2:24 ` Peng Fan 2016-04-28 5:59 ` Stefano Babic 1 sibling, 1 reply; 19+ messages in thread From: Peng Fan @ 2016-04-28 2:24 UTC (permalink / raw) To: u-boot 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. > >Signed-off-by: Marek Vasut <marex@denx.de> >Cc: Stefano Babic <sbabic@denx.de> Acked-by: Peng Fan <van.freenix@gmail.com> Regards, Peng. >--- > include/configs/wandboard.h | 2 ++ > 1 file changed, 2 insertions(+) > >diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h >index 99f5c0c..fbce730 100644 >--- a/include/configs/wandboard.h >+++ b/include/configs/wandboard.h >@@ -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 >-- >2.7.0 > >_______________________________________________ >U-Boot mailing list >U-Boot at lists.denx.de >http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 2:24 ` Peng Fan @ 2016-04-28 5:59 ` Stefano Babic 2016-04-28 11:03 ` Marek Vasut 0 siblings, 1 reply; 19+ messages in thread From: Stefano Babic @ 2016-04-28 5:59 UTC (permalink / raw) To: u-boot 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 Best regards, Stefano Babic -- ===================================================================== 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 ===================================================================== ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 5:59 ` Stefano Babic @ 2016-04-28 11:03 ` Marek Vasut 2016-04-28 13:36 ` Stefano Babic 0 siblings, 1 reply; 19+ messages in thread From: Marek Vasut @ 2016-04-28 11:03 UTC (permalink / raw) To: u-boot 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 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 ... -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 11:03 ` Marek Vasut @ 2016-04-28 13:36 ` Stefano Babic 2016-04-28 13:40 ` Marek Vasut 0 siblings, 1 reply; 19+ messages in thread From: Stefano Babic @ 2016-04-28 13:36 UTC (permalink / raw) To: u-boot 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. Best regards, Stefano Babic -- ===================================================================== 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 ===================================================================== ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 13:36 ` Stefano Babic @ 2016-04-28 13:40 ` Marek Vasut 2016-04-28 18:06 ` Tom Rini 0 siblings, 1 reply; 19+ messages in thread From: Marek Vasut @ 2016-04-28 13:40 UTC (permalink / raw) To: u-boot 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? -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 13:40 ` Marek Vasut @ 2016-04-28 18:06 ` Tom Rini 2016-04-28 18:29 ` Marek Vasut 0 siblings, 1 reply; 19+ messages in thread From: Tom Rini @ 2016-04-28 18:06 UTC (permalink / raw) To: u-boot 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. -- 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 18:06 ` Tom Rini @ 2016-04-28 18:29 ` Marek Vasut 2016-04-28 19:02 ` Tom Rini 0 siblings, 1 reply; 19+ messages in thread From: Marek Vasut @ 2016-04-28 18:29 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 18:29 ` Marek Vasut @ 2016-04-28 19:02 ` Tom Rini 2016-04-28 22:37 ` Marek Vasut 0 siblings, 1 reply; 19+ messages in thread From: Tom Rini @ 2016-04-28 19:02 UTC (permalink / raw) To: u-boot On Thu, Apr 28, 2016 at 08:29:47PM +0200, Marek Vasut wrote: > 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. 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. -- 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support 2016-04-28 19:02 ` Tom Rini @ 2016-04-28 22:37 ` Marek Vasut 0 siblings, 0 replies; 19+ messages in thread From: Marek Vasut @ 2016-04-28 22:37 UTC (permalink / raw) To: u-boot On 04/28/2016 09:02 PM, Tom Rini wrote: > On Thu, Apr 28, 2016 at 08:29:47PM +0200, Marek Vasut wrote: >> 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. > > 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 ... -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2016-04-28 22:37 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-04-27 23:06 [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support Marek Vasut 2016-04-27 23:16 ` Tom Rini 2016-04-27 23:28 ` Marek Vasut 2016-04-27 23:32 ` Robert Nelson 2016-04-27 23:41 ` Marek Vasut 2016-04-27 23:49 ` Robert Nelson 2016-04-28 0:02 ` Marek Vasut 2016-04-28 0:54 ` Tom Rini 2016-04-28 1:06 ` Robert Nelson 2016-04-28 12:02 ` Tom Rini 2016-04-28 2:24 ` Peng Fan 2016-04-28 5:59 ` Stefano Babic 2016-04-28 11:03 ` Marek Vasut 2016-04-28 13:36 ` Stefano Babic 2016-04-28 13:40 ` Marek Vasut 2016-04-28 18:06 ` Tom Rini 2016-04-28 18:29 ` Marek Vasut 2016-04-28 19:02 ` Tom Rini 2016-04-28 22:37 ` Marek Vasut
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox