| Message ID | 1420737505-32119-1-git-send-email-stefan@agner.ch |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
On 8 Jan 2015, stefan@agner.ch wrote: > Boot from SD-card (and probably also from NAND) was broken since > commit d6d07a9bec ("arm: vf610: add NAND support for vf610twr"). > It looks like the increased size of U-Boot lead to a situation > where the boot ROM overwrote its own stack/heap while loading > U-Boot from the SD-card to the SRAM. However, U-Boot worked fine > when loaded through USB serial loader directly into SRAM. It > looks like loading from SD-card uses other stack/heap location > then the serial loader (or maybe no stack or heap at all). > This fix moves U-Boot to gfxRAM, which is 512kB in size and is not > used by the boot ROM nor the SD-card loader of it. > > Signed-off-by: Stefan Agner <stefan@agner.ch> > --- > We use U-Boot from gfxRAM on Vybrid since quite a while for the > Colibri VF50/VF61 modules in our downstream U-Boot branch. Hence > this is quite well tested. > > Just today I discovered that this is broken on the Tower module. > Back then, when I made the offending change, I only tested on the > Tower board using the serial loader, since I thought the behaviour > should be exactly the same. But now, I know better... :-) > > If still possible, it would be great to get this into v2015.01... > > include/configs/vf610twr.h | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h > index 6fd0b17..bd79e81 100644 > --- a/include/configs/vf610twr.h > +++ b/include/configs/vf610twr.h > @@ -125,7 +125,10 @@ > #define CONFIG_BOOTDELAY 3 > > #define CONFIG_LOADADDR 0x82000000 > -#define CONFIG_SYS_TEXT_BASE 0x3f008000 > + > +/* We boot from the gfxRAM area of the OCRAM. */ > +#define CONFIG_SYS_TEXT_BASE 0x3f408000 > +#define CONFIG_BOARD_SIZE_LIMIT 524288 > > #define CONFIG_EXTRA_ENV_SETTINGS \ > "script=boot.scr\0" \ Acked-by: Bill Pringlemeir <bpringlemeir@nbsps.com> See also: http://lists.denx.de/pipermail/u-boot/2014-December/197641.html It seems since v2014.04 u-boot on the Vybrid Tower SD card has not booted. Most users will probably boot this way. https://community.freescale.com/docs/DOC-95248 Thanks, Bill Pringlemeir.
On 8 Jan 2015, stefan@agner.ch wrote: > Boot from SD-card (and probably also from NAND) was broken since > commit d6d07a9bec ("arm: vf610: add NAND support for vf610twr"). It was broke before that when fsl_qspi was added? Or at least that also added a lot of code. It maybe dependant on the compiler (and hence binary size). > It looks like the increased size of U-Boot lead to a situation where > the boot ROM overwrote its own stack/heap while loading U-Boot from > the SD-card to the SRAM. I didn't think of this. That is a possibility. > However, U-Boot worked fine when loaded through USB serial loader > directly into SRAM. It looks like loading from SD-card uses other > stack/heap location then the serial loader (or maybe no stack or heap > at all). I have tried various u-boot images with git-bisect. For instance when the QSPI was added, I had issues. It seems that an image near 220k was a threshold. The offset in the On-chip SRAM is 0x8000 (from the 'ld' file) and the imximage prints '3f008000'. So, I think that the offset takes the breaking point to where we cross from OC-SRAM0 to OC-SRAM1; I guess a stack maybe located here but it must be fairly small. I thought that maybe the HAB has a mapping of device memory start/size and didn't like it when we crossed the boundary. > This fix moves U-Boot to gfxRAM, which is 512kB in size and is not > used by the boot ROM nor the SD-card loader of it. Whatever the issue is, this fixes it for me as well. I would guess that NAND boot is also not possible or probably anything but serial-download modes. Thanks, Bill Pringlemeir.
Hi Bill, On 2015-01-08 18:32, Bill Pringlemeir wrote: > On 8 Jan 2015, stefan@agner.ch wrote: > >> Boot from SD-card (and probably also from NAND) was broken since >> commit d6d07a9bec ("arm: vf610: add NAND support for vf610twr"). >> It looks like the increased size of U-Boot lead to a situation >> where the boot ROM overwrote its own stack/heap while loading >> U-Boot from the SD-card to the SRAM. However, U-Boot worked fine >> when loaded through USB serial loader directly into SRAM. It >> looks like loading from SD-card uses other stack/heap location >> then the serial loader (or maybe no stack or heap at all). >> This fix moves U-Boot to gfxRAM, which is 512kB in size and is not >> used by the boot ROM nor the SD-card loader of it. >> >> Signed-off-by: Stefan Agner <stefan@agner.ch> >> --- >> We use U-Boot from gfxRAM on Vybrid since quite a while for the >> Colibri VF50/VF61 modules in our downstream U-Boot branch. Hence >> this is quite well tested. >> >> Just today I discovered that this is broken on the Tower module. >> Back then, when I made the offending change, I only tested on the >> Tower board using the serial loader, since I thought the behaviour >> should be exactly the same. But now, I know better... :-) >> >> If still possible, it would be great to get this into v2015.01... >> >> include/configs/vf610twr.h | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h >> index 6fd0b17..bd79e81 100644 >> --- a/include/configs/vf610twr.h >> +++ b/include/configs/vf610twr.h >> @@ -125,7 +125,10 @@ >> #define CONFIG_BOOTDELAY 3 >> >> #define CONFIG_LOADADDR 0x82000000 >> -#define CONFIG_SYS_TEXT_BASE 0x3f008000 >> + >> +/* We boot from the gfxRAM area of the OCRAM. */ >> +#define CONFIG_SYS_TEXT_BASE 0x3f408000 >> +#define CONFIG_BOARD_SIZE_LIMIT 524288 >> >> #define CONFIG_EXTRA_ENV_SETTINGS \ >> "script=boot.scr\0" \ > > Acked-by: Bill Pringlemeir <bpringlemeir@nbsps.com> Thx! > > See also: > http://lists.denx.de/pipermail/u-boot/2014-December/197641.html Oh, I even gave my Ack for that, but I did not remember it! Oh dear! > It seems since v2014.04 u-boot on the Vybrid Tower SD card has not > booted. Most users will probably boot this way. > > https://community.freescale.com/docs/DOC-95248 Yes I agree, hence it would be nice to have that working again in 2015.1... I also think that meta-fsl-arm creates a SD-card boot-able image by default, but not sure whether mainline U-boot is in use there or not. Added Otavio for that matter... Albert, any chance that can make it into 2015.1 too? -- Stefan
On Fri, Jan 9, 2015 at 12:13 PM, Stefan Agner <stefan@agner.ch> wrote: ... > I also think that meta-fsl-arm creates a SD-card boot-able image by > default, but not sure whether mainline U-boot is in use there or not. > Added Otavio for that matter... Yes we generate and use U-Boot mainline. So I think we ought to backport this fix for 2014.10 there as well.
Hi Tom, hi Stefan, On 09/01/2015 15:13, Stefan Agner wrote: > Hi Bill, > > On 2015-01-08 18:32, Bill Pringlemeir wrote: >> On 8 Jan 2015, stefan@agner.ch wrote: >> >>> Boot from SD-card (and probably also from NAND) was broken since >>> commit d6d07a9bec ("arm: vf610: add NAND support for vf610twr"). >>> It looks like the increased size of U-Boot lead to a situation >>> where the boot ROM overwrote its own stack/heap while loading >>> U-Boot from the SD-card to the SRAM. However, U-Boot worked fine >>> when loaded through USB serial loader directly into SRAM. It >>> looks like loading from SD-card uses other stack/heap location >>> then the serial loader (or maybe no stack or heap at all). >>> This fix moves U-Boot to gfxRAM, which is 512kB in size and is not >>> used by the boot ROM nor the SD-card loader of it. >>> >>> Signed-off-by: Stefan Agner <stefan@agner.ch> >>> --- >>> We use U-Boot from gfxRAM on Vybrid since quite a while for the >>> Colibri VF50/VF61 modules in our downstream U-Boot branch. Hence >>> this is quite well tested. >>> >>> Just today I discovered that this is broken on the Tower module. >>> Back then, when I made the offending change, I only tested on the >>> Tower board using the serial loader, since I thought the behaviour >>> should be exactly the same. But now, I know better... :-) >>> >>> If still possible, it would be great to get this into v2015.01... >>> >>> include/configs/vf610twr.h | 5 ++++- >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h >>> index 6fd0b17..bd79e81 100644 >>> --- a/include/configs/vf610twr.h >>> +++ b/include/configs/vf610twr.h >>> @@ -125,7 +125,10 @@ >>> #define CONFIG_BOOTDELAY 3 >>> >>> #define CONFIG_LOADADDR 0x82000000 >>> -#define CONFIG_SYS_TEXT_BASE 0x3f008000 >>> + >>> +/* We boot from the gfxRAM area of the OCRAM. */ >>> +#define CONFIG_SYS_TEXT_BASE 0x3f408000 >>> +#define CONFIG_BOARD_SIZE_LIMIT 524288 >>> >>> #define CONFIG_EXTRA_ENV_SETTINGS \ >>> "script=boot.scr\0" \ >> >> Acked-by: Bill Pringlemeir <bpringlemeir@nbsps.com> > > Thx! > >> >> See also: >> http://lists.denx.de/pipermail/u-boot/2014-December/197641.html > > Oh, I even gave my Ack for that, but I did not remember it! Oh dear! > >> It seems since v2014.04 u-boot on the Vybrid Tower SD card has not >> booted. Most users will probably boot this way. >> >> https://community.freescale.com/docs/DOC-95248 > > Yes I agree, hence it would be nice to have that working again in > 2015.1... > > I also think that meta-fsl-arm creates a SD-card boot-able image by > default, but not sure whether mainline U-boot is in use there or not. > Added Otavio for that matter... > > Albert, any chance that can make it into 2015.1 too? > Maybe it is better if Tom can pick it up directly into his tree, avoiding to go through custodian's tree. Release is coming soon :-). Regards, Stefano
On Thu, Jan 08, 2015 at 06:18:25PM +0100, Stefan Agner wrote: > Boot from SD-card (and probably also from NAND) was broken since > commit d6d07a9bec ("arm: vf610: add NAND support for vf610twr"). > It looks like the increased size of U-Boot lead to a situation > where the boot ROM overwrote its own stack/heap while loading > U-Boot from the SD-card to the SRAM. However, U-Boot worked fine > when loaded through USB serial loader directly into SRAM. It > looks like loading from SD-card uses other stack/heap location > then the serial loader (or maybe no stack or heap at all). > This fix moves U-Boot to gfxRAM, which is 512kB in size and is not > used by the boot ROM nor the SD-card loader of it. > > Signed-off-by: Stefan Agner <stefan@agner.ch> > Acked-by: Bill Pringlemeir <bpringlemeir@nbsps.com> Applied to u-boot/master, thanks!
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h index 6fd0b17..bd79e81 100644 --- a/include/configs/vf610twr.h +++ b/include/configs/vf610twr.h @@ -125,7 +125,10 @@ #define CONFIG_BOOTDELAY 3 #define CONFIG_LOADADDR 0x82000000 -#define CONFIG_SYS_TEXT_BASE 0x3f008000 + +/* We boot from the gfxRAM area of the OCRAM. */ +#define CONFIG_SYS_TEXT_BASE 0x3f408000 +#define CONFIG_BOARD_SIZE_LIMIT 524288 #define CONFIG_EXTRA_ENV_SETTINGS \ "script=boot.scr\0" \
Boot from SD-card (and probably also from NAND) was broken since commit d6d07a9bec ("arm: vf610: add NAND support for vf610twr"). It looks like the increased size of U-Boot lead to a situation where the boot ROM overwrote its own stack/heap while loading U-Boot from the SD-card to the SRAM. However, U-Boot worked fine when loaded through USB serial loader directly into SRAM. It looks like loading from SD-card uses other stack/heap location then the serial loader (or maybe no stack or heap at all). This fix moves U-Boot to gfxRAM, which is 512kB in size and is not used by the boot ROM nor the SD-card loader of it. Signed-off-by: Stefan Agner <stefan@agner.ch> --- We use U-Boot from gfxRAM on Vybrid since quite a while for the Colibri VF50/VF61 modules in our downstream U-Boot branch. Hence this is quite well tested. Just today I discovered that this is broken on the Tower module. Back then, when I made the offending change, I only tested on the Tower board using the serial loader, since I thought the behaviour should be exactly the same. But now, I know better... :-) If still possible, it would be great to get this into v2015.01... include/configs/vf610twr.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)