PATCH: Fix MMC boot in OMAP4 xload configurations

PATCH: Fix MMC boot in OMAP4 xload configurations

[Mark Olleson]

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

Fwd: PATCH: Fix MMC boot in OMAP4 xload configurations

[Mark Olleson]

> 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

Re: PATCH: Fix MMC boot in OMAP4 xload configurations

[Sascha Hauer]

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

Re: PATCH: Fix MMC boot in OMAP4 xload configurations

[Jean-Christophe PLAGNIOL-VILLARD]

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

Re: PATCH: Fix MMC boot in OMAP4 xload configurations

[Sascha Hauer]

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

PATCH: Fix MMC boot in OMAP4 xload configurations

[Mark Olleson]

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