* PATCH: Fix MMC boot in OMAP4 xload configurations [not found] <5E5BF80D-E268-4688-8E16-5BF26FBD7D4D@yamaha.co.uk> @ 2012-02-24 15:57 ` Mark Olleson 2012-02-24 16:18 ` Fwd: " Mark Olleson 0 siblings, 1 reply; 6+ messages in thread From: Mark Olleson @ 2012-02-24 15:57 UTC (permalink / raw) To: barebox Sascha, On 24 Feb 2012, at 07:23, Sascha Hauer wrote: > Hi Mark, > > On Thu, Feb 23, 2012 at 04:53:28PM +0000, Mark Olleson wrote: >> omap4_bootsrc() always returns OMAP_BOOTSRC_UNKNOWN when an OMAP4 >> xload image is built with pcm049_xload_defconfig. This is likely to >> be the case for all OMAP4 xload configurations. >> >> This means that when the CPU is configured to boot from MMC1 with >> boot[5:0], xload will load the second stage boot loader from NAND >> flash (if present) rather than MMC1 as intended. >> >> omap4_bootsrc() reads data left behind towards the top of the SRAM by >> the ROM-based boot-loader. This is the same SRAM into which the xload >> image is loaded. The xload image is of a sufficient size that it >> overwrites these locations, and OMAP4_TRACING_VECTOR3 always contains >> 0. >> >> These locations are in fact trampled by data in the BSS section of the >> image. The single largest item in there is FILE files[MAX_FILES]. >> This patch reduces the size of files[] considerably. The image now >> JUST fits. > > Sorry, this is not even a short term solution, it will probably break > very soon again. I totally agree - this fixed me in the very short term, but we're sailing so close to the wind here that changes in the any (few) modules that are used in these configurations will break it again. My patch was really a heads-up that we have an issue. > >> >> Long term, a better solution would be to not rely on >> OMAP4_TRACING_VECTOR3, and instead use the structure passed into the >> xload by the ROM-based boot loader - which also indicates the boot >> device. This wold allow us another 4kB of code before we overflow >> the SRAM completely. > > That sounds interesting. I wasn't aware that the ROM passes a structure > into the boot loader. Cue quick check that this is actually in the public TRM! it is - at §27.4.8.4 - Image Execution. The ROM boot-loader passes a pointer to a structure containing the data in a register at entry - what is not so obvious is where the structure is located. I think it's likely that it's on the ROM-loader's stack - which is also in SRAM, and also getting overwritten. Clearly the ROM loader doesn't have much in the way of functional decomposition if it still successfully boots after having its stack obliterated. The TRM is quite explicit that the xload image shouldn't be any larger than 48KB in order to avoid the stack, tracing vector - and a set of exception vectors also located in-between - as it stands, we're coming in at about 52.5kB once the bss sections of image are accounted for. > Another thing is that I still have the Thumb2 patches pending which are > currently blocked by Jean-Christophe. That will help a lot. Otherwise we're going to need to start the messy task of economising on space throughout the code-base. Another solution that might work would be to configure SYSBOOT[5:0] as GPIO and determine the boot method that way. Not ideal as this will tell us the boot order and not the device that was actually used, but would mean that we could use the entire 56kB of SRAM and not have to worry about the tracing vectors. Mark Mark Olleson - Senior R&D Engineer Technology Research & Development Group Yamaha R&D Centre London mark.olleson@yamaha.co.uk Direct Line: +44 20 8987 0870 Switchboard: +44 20 8987 9595 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 6+ messages in thread
* Fwd: PATCH: Fix MMC boot in OMAP4 xload configurations 2012-02-24 15:57 ` PATCH: Fix MMC boot in OMAP4 xload configurations Mark Olleson @ 2012-02-24 16:18 ` Mark Olleson 0 siblings, 0 replies; 6+ messages in thread From: Mark Olleson @ 2012-02-24 16:18 UTC (permalink / raw) To: barebox > Sascha, > On 24 Feb 2012, at 07:23, Sascha Hauer wrote: > >> Hi Mark, >> >> On Thu, Feb 23, 2012 at 04:53:28PM +0000, Mark Olleson wrote: >>> omap4_bootsrc() always returns OMAP_BOOTSRC_UNKNOWN when an OMAP4 >>> xload image is built with pcm049_xload_defconfig. This is likely to >>> be the case for all OMAP4 xload configurations. >>> >>> This means that when the CPU is configured to boot from MMC1 with >>> boot[5:0], xload will load the second stage boot loader from NAND >>> flash (if present) rather than MMC1 as intended. >>> >>> omap4_bootsrc() reads data left behind towards the top of the SRAM by >>> the ROM-based boot-loader. This is the same SRAM into which the xload >>> image is loaded. The xload image is of a sufficient size that it >>> overwrites these locations, and OMAP4_TRACING_VECTOR3 always contains >>> 0. >>> >>> These locations are in fact trampled by data in the BSS section of the >>> image. The single largest item in there is FILE files[MAX_FILES]. >>> This patch reduces the size of files[] considerably. The image now >>> JUST fits. >> >> Sorry, this is not even a short term solution, it will probably break >> very soon again. > > I totally agree - this fixed me in the very short term, but we're sailing so close > to the wind here that changes in the any (few) modules that are used in these > configurations will break it again. > > My patch was really a heads-up that we have an issue. > >> On further digging, this gets even worse: Barebox's initial stack is in the same area of SRAM as the ROM-loader's - overwriting the area where bss section of the image is getting loaded, containing various areas of static storage. Here, these addresses were falling somewhere in the middles of: static FILE files[MAX_FILES] Thankfully, there isn't a great deal of function call depth before the stack is then set up in SDRAM, and tramples here don't matter too much. Anyway, be warned - some interesting failure modes lie ahead should some of the other bits of static data or even program code fall at this location! Mark --- Mark Olleson - Senior R&D Engineer Technology Research & Development Group Yamaha R&D Centre London mark.olleson@yamaha.co.uk _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <35246B69-4D16-4459-9E1E-0C79C4350EFF@yamaha.co.uk>]
* PATCH: Fix MMC boot in OMAP4 xload configurations [not found] <35246B69-4D16-4459-9E1E-0C79C4350EFF@yamaha.co.uk> @ 2012-02-23 16:53 ` Mark Olleson 2012-02-24 7:23 ` Sascha Hauer 0 siblings, 1 reply; 6+ messages in thread From: Mark Olleson @ 2012-02-23 16:53 UTC (permalink / raw) To: barebox omap4_bootsrc() always returns OMAP_BOOTSRC_UNKNOWN when an OMAP4 xload image is built with pcm049_xload_defconfig. This is likely to be the case for all OMAP4 xload configurations. This means that when the CPU is configured to boot from MMC1 with boot[5:0], xload will load the second stage boot loader from NAND flash (if present) rather than MMC1 as intended. omap4_bootsrc() reads data left behind towards the top of the SRAM by the ROM-based boot-loader. This is the same SRAM into which the xload image is loaded. The xload image is of a sufficient size that it overwrites these locations, and OMAP4_TRACING_VECTOR3 always contains 0. These locations are in fact trampled by data in the BSS section of the image. The single largest item in there is FILE files[MAX_FILES]. This patch reduces the size of files[] considerably. The image now JUST fits. Long term, a better solution would be to not rely on OMAP4_TRACING_VECTOR3, and instead use the structure passed into the xload by the ROM-based boot loader - which also indicates the boot device. This wold allow us another 4kB of code before we overflow the SRAM completely. Signed-off-by: Mark Olleson <mark@yamaha.co.uk> --- diff --git a/include/stdio.h b/include/stdio.h index 4901bc7..98a4639 100644 --- a/include/stdio.h +++ b/include/stdio.h @@ -52,8 +52,21 @@ int vscnprintf(char *buf, size_t size, const char *fmt, va_list args); #define stdin 0 #define stdout 1 #define stderr 2 + +#if defined (CONFIG_SHELL_NONE) && defined (CONFIG_ARCH_OMAP4) + +// OMAP4 XLOAD configuations are very tight on RAM. If MAX_FILES is any +// larger, FILE files[MAX_FILES] (fs.c) tramples over data left for us by +// ROM-based bootloader and breaks boot from mmc. + +#define MAX_FILES 16 + +#else + + #define MAX_FILES 128 +#endif int fprintf(int file, const char *fmt, ...) __attribute__ ((format(__printf__, 2, 3))); int fputs(int file, const char *s); int fputc(int file, const char c); _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Fix MMC boot in OMAP4 xload configurations 2012-02-23 16:53 ` Mark Olleson @ 2012-02-24 7:23 ` Sascha Hauer 2012-02-27 19:32 ` Jean-Christophe PLAGNIOL-VILLARD 0 siblings, 1 reply; 6+ messages in thread From: Sascha Hauer @ 2012-02-24 7:23 UTC (permalink / raw) To: Mark Olleson; +Cc: barebox Hi Mark, On Thu, Feb 23, 2012 at 04:53:28PM +0000, Mark Olleson wrote: > omap4_bootsrc() always returns OMAP_BOOTSRC_UNKNOWN when an OMAP4 > xload image is built with pcm049_xload_defconfig. This is likely to > be the case for all OMAP4 xload configurations. > > This means that when the CPU is configured to boot from MMC1 with > boot[5:0], xload will load the second stage boot loader from NAND > flash (if present) rather than MMC1 as intended. > > omap4_bootsrc() reads data left behind towards the top of the SRAM by > the ROM-based boot-loader. This is the same SRAM into which the xload > image is loaded. The xload image is of a sufficient size that it > overwrites these locations, and OMAP4_TRACING_VECTOR3 always contains > 0. > > These locations are in fact trampled by data in the BSS section of the > image. The single largest item in there is FILE files[MAX_FILES]. > This patch reduces the size of files[] considerably. The image now > JUST fits. Sorry, this is not even a short term solution, it will probably break very soon again. > > Long term, a better solution would be to not rely on > OMAP4_TRACING_VECTOR3, and instead use the structure passed into the > xload by the ROM-based boot loader - which also indicates the boot > device. This wold allow us another 4kB of code before we overflow > the SRAM completely. That sounds interesting. I wasn't aware that the ROM passes a structure into the bootloader. Another thing is that I still have the Thumb2 patches pending which are currently blocked by Jean-Christophe. Jean-Christophe, please please have a look on these patches again or at least say *what* is wrong with them so that I have a chance to rework them. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Fix MMC boot in OMAP4 xload configurations 2012-02-24 7:23 ` Sascha Hauer @ 2012-02-27 19:32 ` Jean-Christophe PLAGNIOL-VILLARD 2012-02-28 8:57 ` Sascha Hauer 0 siblings, 1 reply; 6+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-02-27 19:32 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox On 08:23 Fri 24 Feb , Sascha Hauer wrote: > Hi Mark, > > On Thu, Feb 23, 2012 at 04:53:28PM +0000, Mark Olleson wrote: > > omap4_bootsrc() always returns OMAP_BOOTSRC_UNKNOWN when an OMAP4 > > xload image is built with pcm049_xload_defconfig. This is likely to > > be the case for all OMAP4 xload configurations. > > > > This means that when the CPU is configured to boot from MMC1 with > > boot[5:0], xload will load the second stage boot loader from NAND > > flash (if present) rather than MMC1 as intended. > > > > omap4_bootsrc() reads data left behind towards the top of the SRAM by > > the ROM-based boot-loader. This is the same SRAM into which the xload > > image is loaded. The xload image is of a sufficient size that it > > overwrites these locations, and OMAP4_TRACING_VECTOR3 always contains > > 0. > > > > These locations are in fact trampled by data in the BSS section of the > > image. The single largest item in there is FILE files[MAX_FILES]. > > This patch reduces the size of files[] considerably. The image now > > JUST fits. > > Sorry, this is not even a short term solution, it will probably break > very soon again. > > > > > Long term, a better solution would be to not rely on > > OMAP4_TRACING_VECTOR3, and instead use the structure passed into the > > xload by the ROM-based boot loader - which also indicates the boot > > device. This wold allow us another 4kB of code before we overflow > > the SRAM completely. > > That sounds interesting. I wasn't aware that the ROM passes a structure > into the bootloader. > > Another thing is that I still have the Thumb2 patches pending which are > currently blocked by Jean-Christophe. > > Jean-Christophe, please please have a look on these patches again or at > least say *what* is wrong with them so that I have a chance to rework > them. sorry need to finish some work on the kernel and the support of sam9x5 series on AT91 we must have the vector at the begeniing of the binary and the only valid instruction are ldr and branch so with your patch the rom code cannot boot barebox Best Regards, J. _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Fix MMC boot in OMAP4 xload configurations 2012-02-27 19:32 ` Jean-Christophe PLAGNIOL-VILLARD @ 2012-02-28 8:57 ` Sascha Hauer 0 siblings, 0 replies; 6+ messages in thread From: Sascha Hauer @ 2012-02-28 8:57 UTC (permalink / raw) To: Jean-Christophe PLAGNIOL-VILLARD; +Cc: barebox On Mon, Feb 27, 2012 at 08:32:47PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 08:23 Fri 24 Feb , Sascha Hauer wrote: > > Hi Mark, > > > > On Thu, Feb 23, 2012 at 04:53:28PM +0000, Mark Olleson wrote: > > > omap4_bootsrc() always returns OMAP_BOOTSRC_UNKNOWN when an OMAP4 > > > xload image is built with pcm049_xload_defconfig. This is likely to > > > be the case for all OMAP4 xload configurations. > > > > > > This means that when the CPU is configured to boot from MMC1 with > > > boot[5:0], xload will load the second stage boot loader from NAND > > > flash (if present) rather than MMC1 as intended. > > > > > > omap4_bootsrc() reads data left behind towards the top of the SRAM by > > > the ROM-based boot-loader. This is the same SRAM into which the xload > > > image is loaded. The xload image is of a sufficient size that it > > > overwrites these locations, and OMAP4_TRACING_VECTOR3 always contains > > > 0. > > > > > > These locations are in fact trampled by data in the BSS section of the > > > image. The single largest item in there is FILE files[MAX_FILES]. > > > This patch reduces the size of files[] considerably. The image now > > > JUST fits. > > > > Sorry, this is not even a short term solution, it will probably break > > very soon again. > > > > > > > > Long term, a better solution would be to not rely on > > > OMAP4_TRACING_VECTOR3, and instead use the structure passed into the > > > xload by the ROM-based boot loader - which also indicates the boot > > > device. This wold allow us another 4kB of code before we overflow > > > the SRAM completely. > > > > That sounds interesting. I wasn't aware that the ROM passes a structure > > into the bootloader. > > > > Another thing is that I still have the Thumb2 patches pending which are > > currently blocked by Jean-Christophe. > > > > Jean-Christophe, please please have a look on these patches again or at > > least say *what* is wrong with them so that I have a chance to rework > > them. > sorry need to finish some work on the kernel and the support of sam9x5 series > > on AT91 we must have the vector at the begeniing of the binary and the only > valid instruction are ldr and branch > > so with your patch the rom code cannot boot barebox Please check the series I just sent. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-02-28 8:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <5E5BF80D-E268-4688-8E16-5BF26FBD7D4D@yamaha.co.uk>
2012-02-24 15:57 ` PATCH: Fix MMC boot in OMAP4 xload configurations Mark Olleson
2012-02-24 16:18 ` Fwd: " Mark Olleson
[not found] <35246B69-4D16-4459-9E1E-0C79C4350EFF@yamaha.co.uk>
2012-02-23 16:53 ` Mark Olleson
2012-02-24 7:23 ` Sascha Hauer
2012-02-27 19:32 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-28 8:57 ` Sascha Hauer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox