From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: PATCH: Fix MMC boot in OMAP4 xload configurations
Date: Mon, 27 Feb 2012 20:32:47 +0100 [thread overview]
Message-ID: <20120227193247.GI12248@game.jcrosoft.org> (raw)
In-Reply-To: <20120224072308.GS3852@pengutronix.de>
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
next prev parent reply other threads:[~2012-02-27 19:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
2012-02-28 8:57 ` Sascha Hauer
[not found] <5E5BF80D-E268-4688-8E16-5BF26FBD7D4D@yamaha.co.uk>
2012-02-24 15:57 ` Mark Olleson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120227193247.GI12248@game.jcrosoft.org \
--to=plagnioj@jcrosoft.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox