[U-Boot] [PATCH] 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.
Signed-off-by: Faiz Abbas faiz_abbas@ti.com --- include/configs/ti_armv7_keystone2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index 562bb65..7fb3aaf 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -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" \
On Tue, Jan 16, 2018 at 01:43:40PM +0530, Faiz Abbas wrote:
Now the u-boot spi image is greater than 0x90000, increase the same in env during spi erase.
Signed-off-by: Faiz Abbas faiz_abbas@ti.com
include/configs/ti_armv7_keystone2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index 562bb65..7fb3aaf 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -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!
Hi,
+Vignesh
On Tuesday 16 January 2018 08:55 PM, Tom Rini wrote:
On Tue, Jan 16, 2018 at 01:43:40PM +0530, Faiz Abbas wrote:
Now the u-boot spi image is greater than 0x90000, increase the same in env during spi erase.
Signed-off-by: Faiz Abbas faiz_abbas@ti.com
include/configs/ti_armv7_keystone2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index 562bb65..7fb3aaf 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -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
On Wed, Jan 17, 2018 at 01:08:19PM +0530, Faiz Abbas wrote:
Hi,
+Vignesh
On Tuesday 16 January 2018 08:55 PM, Tom Rini wrote:
On Tue, Jan 16, 2018 at 01:43:40PM +0530, Faiz Abbas wrote:
Now the u-boot spi image is greater than 0x90000, increase the same in env during spi erase.
Signed-off-by: Faiz Abbas faiz_abbas@ti.com
include/configs/ti_armv7_keystone2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index 562bb65..7fb3aaf 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -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.
OK, thanks!
Reviewed-by: Tom Rini trini@konsulko.com
On Tue, Jan 16, 2018 at 01:43:40PM +0530, Faiz Abbas wrote:
Now the u-boot spi image is greater than 0x90000, increase the same in env during spi erase.
Signed-off-by: Faiz Abbas faiz_abbas@ti.com Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
participants (2)
-
Faiz Abbas -
Tom Rini