From: Steve Sakoman <steve@sakoman.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
Date: Mon, 25 Oct 2010 08:07:32 -0700 [thread overview]
Message-ID: <1288019252.2342.21.camel@quadra> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593023461B195@dbde02.ent.ti.com>
On Mon, 2010-10-25 at 20:10 +0530, Premi, Sanjeev wrote:
> > -----Original Message-----
> > From: Steve Sakoman [mailto:steve at sakoman.com]
> > Sent: Monday, October 25, 2010 6:52 PM
> > To: Premi, Sanjeev
> > Cc: u-boot at lists.denx.de
> > Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
> >
> > On Mon, 2010-10-25 at 15:28 +0530, Premi, Sanjeev wrote:
> > > > -----Original Message-----
> > > > From: u-boot-bounces at lists.denx.de
> > > > [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Steve Sakoman
> > > > Sent: Saturday, October 23, 2010 2:20 AM
> > > > To: u-boot at lists.denx.de
> > > > Subject: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
> > > >
> > > > Commit c3d3a54 uses CONFIG_ARMV7 to determine whether to call the
> > > > v7_flush_cache_all function. This breaks the build for
> > all non-OMAP3
> > > > boards (like Panda and OMAP4430SDP) since there is only a
> > > > v7_flush_cache_all
> > > > implementation for OMAP3.
> > > >
> > > > This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so
> > > > that only boards
> > > > with a v7_flush_cache_all will make the call.
> > >
> > > [sp] Is this call board specific?
> >
> > No, it is not.
>
> [sp] I asked because I can see omap3/cache.S but not under omap-common/
> (as I was expecting) - neither in omap4/
>
> Doesn't this patch works-around the problem by using CONFIG_OMAP34XX?
Yes, this is a hopefully temporary fix to allow non-OMAP3 ARMV7 boards
to build.
> Wouldn't change in cache.S (or Makefile) be better solution/ or
> workaround. At least workaround will be visible to more eyes.
Ideally we would have a generic ARMV7 implementation that would work for
even non-OMAP ARMV7 processors. Someone who is familiar with the
differences in ARMV7 cache implementations from the various silicon
vendors would need to do this. This beyond my knowledge.
A "second best" solution would be to have a cache.S that worked for both
OMAP3 and OMAP4 in omap-common/
If this isn't possible, then we should add an OMAP4 specific cache.S in
omap4/
But until we settle on the proper long term strategy this patch should
be applied so that non-OMAP3 ARMV7 boards will build.
Steve
next prev parent reply other threads:[~2010-10-25 15:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-22 20:50 [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards Steve Sakoman
2010-10-25 9:58 ` Premi, Sanjeev
2010-10-25 13:21 ` Steve Sakoman
2010-10-25 14:40 ` Premi, Sanjeev
2010-10-25 15:07 ` Steve Sakoman [this message]
2010-10-26 13:59 ` Premi, Sanjeev
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=1288019252.2342.21.camel@quadra \
--to=steve@sakoman.com \
--cc=u-boot@lists.denx.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