[U-Boot] [PATCH] 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
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
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?
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.
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,
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/
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 insteadof some
>> random offset on the SD card. This makes the board usable byputting the
>> u-boot.img to first partition of the SD card and writing the SPLthis 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 justSPL,
> 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 startof
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,
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/
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.
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,
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...
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@lists.denx.de http://lists.denx.de/mailman/listinfo/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@lists.denx.de/msg185432.html
Best regards, Stefano Babic
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@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 ...
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@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
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@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?
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@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.
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@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.
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@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.
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@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 ...
participants (5)
-
Marek Vasut -
Peng Fan -
Robert Nelson -
Stefano Babic -
Tom Rini