From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from metis.ext.pengutronix.de ([2001:6f8:1178:4:290:27ff:fe1d:cc33]) by casper.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1S0pUp-0005Rt-1d for barebox@lists.infradead.org; Fri, 24 Feb 2012 07:23:16 +0000 Date: Fri, 24 Feb 2012 08:23:08 +0100 From: Sascha Hauer Message-ID: <20120224072308.GS3852@pengutronix.de> References: <35246B69-4D16-4459-9E1E-0C79C4350EFF@yamaha.co.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: barebox-bounces@lists.infradead.org Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org Subject: Re: PATCH: Fix MMC boot in OMAP4 xload configurations To: Mark Olleson Cc: barebox@lists.infradead.org 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