configs: keystone2: env: Fix burn_uboot_spi command
PATCH 1/1 configs: keystone2: env: Fix burn_uboot_spi command
Now the u-boot spi image is greater than 0x90000, increase the same in env during spi erase.
--- include/configs/ti_armv7_keystone2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/ti_armv7_keystone2.h +1 -1
@@ -266,7 +266,7 @@"${bootdir}/${fit_bootfile}\0" \"get_uboot_net=dhcp ${loadaddr} ${tftp_root}/${name_uboot}\0" \"get_uboot_nfs=nfs ${loadaddr} ${nfs_root}/boot/${name_uboot}\0" \ -"burn_uboot_spi=sf probe; sf erase 0 0x90000; " \ +"burn_uboot_spi=sf probe; sf erase 0 0x100000; " \"sf write ${loadaddr} 0 ${filesize}\0" \"burn_uboot_nand=nand erase 0 0x100000; " \"nand write ${loadaddr} 0 ${filesize}\0" \
Signature · 1 line
2.7.4
PATCH 1/1 configs: keystone2: env: Fix burn_uboot_spi command
Quoted 13 lines · Faiz Abbas
Now the u-boot spi image is greater than
0x90000, increase the same in env during spi erase.Signed-off-by Faiz Abbas <[email protected]>--- include/configs/ti_armv7_keystone2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)include/configs/ti_armv7_keystone2.h +0
-0
include/configs/ti_armv7_keystone2.h line 272
Quoted 8 lines
include/configs/ti_armv7_keystone2.h +1
-1@@ -266,7 +266,7 @@"${bootdir}/${fit_bootfile}\0" \"get_uboot_net=dhcp ${loadaddr} ${tftp_root}/${name_uboot}\0" \"get_uboot_nfs=nfs ${loadaddr} ${nfs_root}/boot/${name_uboot}\0" \ -"burn_uboot_spi=sf probe; sf erase 0 0x90000; " \ +"burn_uboot_spi=sf probe; sf erase 0 0x100000; " \"sf write ${loadaddr} 0 ${filesize}\0" \"burn_uboot_nand=nand erase 0 0x100000; " \"nand write ${loadaddr} 0 ${filesize}\0" \
Can we future proof this? Where is the next bit of content located in the SPI flash? We should erase up to that instead I think. Thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180116/b48f4a6f/attachment.sig>
PATCH 1/1 configs: keystone2: env: Fix burn_uboot_spi command
Hi,
+Vignesh
Quoted 9 lines · Tom Rini
Quoted 8 lines · Faiz Abbas
Now the u-boot spi image is greater than
0x90000, increase the same in env during spi erase.Signed-off-by Faiz Abbas <[email protected]>--- include/configs/ti_armv7_keystone2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Quoted 17 lines
include/configs/ti_armv7_keystone2.h line 272
Quoted 13 lines
include/configs/ti_armv7_keystone2.h +1
-1@@ -266,7 +266,7 @@"${bootdir}/${fit_bootfile}\0" \"get_uboot_net=dhcp ${loadaddr} ${tftp_root}/${name_uboot}\0" \"get_uboot_nfs=nfs ${loadaddr} ${nfs_root}/boot/${name_uboot}\0" \ -"burn_uboot_spi=sf probe; sf erase 0 0x90000; " \ +"burn_uboot_spi=sf probe; sf erase 0 0x100000; " \"sf write ${loadaddr} 0 ${filesize}\0" \"burn_uboot_nand=nand erase 0 0x100000; " \"nand write ${loadaddr} 0 ${filesize}\0" \Can we future proof this? Where is the next bit of content located in the SPI flash? We should erase up to that instead I think. Thanks!
Currently it is limited to 1M by the parameter we pass to kernel in include/environment/ti/spi.h
#define KEYSTONE_SPI0_MTD_PARTS "spi0.0:1m(u-boot-spl)ro,-(misc);\0" #define KEYSTONE_SPI1_MTD_PARTS "spi1.0:1m(u-boot-spl)ro,-(misc);\0"
This was added by 3f18ff0 ("ARM: keystone: Pass SPI MTD partition table via kernel command line")
So this is the maximum limit right now.
Thanks,
Faiz
PATCH 1/1 configs: keystone2: env: Fix burn_uboot_spi command
Quoted 36 lines · Faiz Abbas
Hi,
+Vignesh
Quoted 9 lines · Tom Rini
Quoted 8 lines · Faiz Abbas
Now the u-boot spi image is greater than
0x90000, increase the same in env during spi erase.Signed-off-by Faiz Abbas <[email protected]>--- include/configs/ti_armv7_keystone2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Quoted 17 lines
include/configs/ti_armv7_keystone2.h line 272
Quoted 13 lines
include/configs/ti_armv7_keystone2.h +1
-1@@ -266,7 +266,7 @@"${bootdir}/${fit_bootfile}\0" \"get_uboot_net=dhcp ${loadaddr} ${tftp_root}/${name_uboot}\0" \"get_uboot_nfs=nfs ${loadaddr} ${nfs_root}/boot/${name_uboot}\0" \ -"burn_uboot_spi=sf probe; sf erase 0 0x90000; " \ +"burn_uboot_spi=sf probe; sf erase 0 0x100000; " \"sf write ${loadaddr} 0 ${filesize}\0" \"burn_uboot_nand=nand erase 0 0x100000; " \"nand write ${loadaddr} 0 ${filesize}\0" \Can we future proof this? Where is the next bit of content located in the SPI flash? We should erase up to that instead I think. Thanks!
Currently it is limited to 1M by the parameter we pass to kernel in
include/environment/ti/spi.h
Quoted 8 lines
#define
KEYSTONE_SPI0_MTD_PARTS"spi0.0:1m(u-boot-spl)ro,-(misc);\0" #defineKEYSTONE_SPI1_MTD_PARTS"spi1.0:1m(u-boot-spl)ro,-(misc);\0"This was added by 3f18ff0 ("ARM: keystone: Pass SPI MTD partition table via kernel command line")
So this is the maximum limit right now.
OK, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180117/a2ea1775/attachment.sig>
Quoted 5 lines · Faiz Abbas
Now the u-boot spi image is greater than
0x90000, increase the same in env during spi erase.Signed-off-by Faiz Abbas <[email protected]>Reviewed-by Tom Rini <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180119/c86854d8/attachment.sig>