From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] omap: Fix DEBUG_LL uart to access phys addr when MMU isn't enable
Date: Tue, 3 Aug 2010 09:57:10 +0300 [thread overview]
Message-ID: <20100803065709.GP12293@atomide.com> (raw)
In-Reply-To: <AANLkTi=ocZPDi5eU_F8VdAzJzYRCEp+B7MZ2q3DAesa3@mail.gmail.com>
* Eric Miao <eric.y.miao@gmail.com> [100803 07:29]:
> On Tue, Aug 3, 2010 at 11:44 AM, Jason Wang <jason77.wang@gmail.com> wrote:
> > Now we use a memory address to store the debug port info, So we need
> > to read/write this address when we choose DEBUG_LL. When MMU isn't
> > enable(I.E. the begining part of init stage of the linux kernel boot),
> > we need to access physical address instead of virtual address,
> > otherwise the kernel will crash.
> >
> > Signed-off-by: Jason Wang <jason77.wang@gmail.com>
> > ---
> > ?arch/arm/mach-omap1/include/mach/debug-macro.S | ? 10 +++++--
> > ?arch/arm/mach-omap2/include/mach/debug-macro.S | ? 29 +++++++++++++++++------
> > ?2 files changed, 28 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap1/include/mach/debug-macro.S b/arch/arm/mach-omap1/include/mach/debug-macro.S
> > index e8a8cf3..671408e 100644
> > --- a/arch/arm/mach-omap1/include/mach/debug-macro.S
> > +++ b/arch/arm/mach-omap1/include/mach/debug-macro.S
> > @@ -33,7 +33,7 @@ omap_uart_virt: ? ? ? .word ? 0x0
> > ? ? ? ? ? ? ? ?/* Use omap_uart_phys/virt if already configured */
> > ?9: ? ? ? ? ? ? mrc ? ? p15, 0, \rx, c1, c0
> > ? ? ? ? ? ? ? ?tst ? ? \rx, #1 ? ? ? ? ? ? ? ? @ MMU enabled?
> > - ? ? ? ? ? ? ? ldreq ? \rx, =omap_uart_phys ? ?@ physical base address
> > + ? ? ? ? ? ? ? ldreq ? \rx, =__virt_to_phys(omap_uart_phys) ? ?@ physical base address
>
> Along with introduction of run-time phys_offset, I'm afraid this
> macro won't work in assembly any longer.
/me scratches head wondering how this has been working so far on the
systems tested.. Looks like we've been lucky and the omap_uart_virt
and phys have been initialized twice to different memory addresses,
first with MMU off then on.
For the run-time phys_offset, can we use the same logic here and
set it based on the PC?
> And having a variable version of debugging uart base, in my POV,
> may not be generic enough to handle the fundamental issue. Tho
> I'm not sure if it will feasible to have a generic debug function in
> 'struct machine_desc' and make that structure available as early
> as possible.
That might cover the most typical debug cases, but is not available
right from the start.
What if we initialize the low level debug functions in some static
memory location already in uncompress.h? That would help sorting
out the debug-macro.S issue from compiling in multile ARM archs
point of view.
Regards,
Tony
next prev parent reply other threads:[~2010-08-03 6:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-03 3:44 [PATCH] omap: Fix DEBUG_LL uart to access phys addr when MMU isn't enable Jason Wang
2010-08-03 4:36 ` Eric Miao
2010-08-03 6:57 ` Tony Lindgren [this message]
2010-08-03 7:11 ` Eric Miao
2010-08-03 7:25 ` Russell King - ARM Linux
2010-08-03 12:38 ` Tony Lindgren
2010-08-03 19:47 ` Russell King - ARM Linux
2010-08-04 5:28 ` Tony Lindgren
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=20100803065709.GP12293@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).