| Message ID | 1516090420-26502-1-git-send-email-faiz_abbas@ti.com |
|---|---|
| State | Accepted |
| Commit | e8b9fdced641bbc6edb0a2c85f6000edaedf8b2e |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | [U-Boot] configs: keystone2: env: Fix burn_uboot_spi command | expand |
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!
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" \
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(-)