From: Josh Cartwright <josh.cartwright@ni.com>
To: Nick Bowler <nbowler@elliptictech.com>
Cc: arm@kernel.org, Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
John Linn <john.linn@xilinx.com>,
Michal Simek <michal.simek@xilinx.com>
Subject: Re: [PATCH v4 5/5] zynq: move static peripheral mappings
Date: Thu, 25 Oct 2012 16:29:02 -0500 [thread overview]
Message-ID: <20121025212902.GX20593@beefymiracle.amer.corp.natinst.com> (raw)
In-Reply-To: <20121025201701.GA18217@elliptictech.com>
[-- Attachment #1: Type: text/plain, Size: 3328 bytes --]
On Thu, Oct 25, 2012 at 04:17:01PM -0400, Nick Bowler wrote:
> Hi Josh,
>
> On 2012-10-24 15:04 -0500, Josh Cartwright wrote:
> > Shifting them up into the vmalloc region prevents the following warning,
> > when booting a zynq qemu target with more than 512mb of RAM:
> [...]
> > -/* For now, all mappings are flat (physical = virtual)
> > +/* Static peripheral mappings are mapped at the top of the
> > + * vmalloc region
> > */
> > -#define UART0_PHYS 0xE0000000
> > -#define UART0_VIRT UART0_PHYS
> > +#define UART0_PHYS 0xE0000000
> > +#define UART0_SIZE SZ_4K
> > +#define UART0_VIRT (VMALLOC_END - UART0_SIZE)
>
> Did you test this on any real hardware? I can't get the ZC702 to work
> with the UART mapped at this address (this ends up being mapped at
> 0xFEFFF000), although I can't for the life of me figure out why the
> virtual address even matters. Note that for the ZC702, the physical
> address of the "main" UART is 0xE0001000.
Ugh, not yet; My testing has been on a qemu model. I also
unfortunately neglected to mention I am carrying a qemu patch that
forces RX_EN/TX_EN of the uarts out of reset. There is an (incomplete)
thread on qemu-devel discussing whose responsibility it really is to
enable the uarts:
http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03779.html
Clearly, though, if you are seeing the "Uncompressing Linux..."
messages, then the uart is enabled, so I don't think that's the problem.
> All I end up seeing is "Uncompressing Linux... done, booting the
> kernel." with no further messages. With the UART mapped at
> 0xF0001000, all printouts make it to the console. I tried a couple
> different virtual addresses and I'm surprised at the results, since
> the behaviour seems to vary wildly. I saw three behaviours depending
> only on the virtual address of the static mapping; all results are 100%
> reproducible:
>
> "Works": all printouts make it to the console
> "Fails": no printouts make it to the console after decompression
> "Truncated": the first few lines of output do not make it to the
> console, but after that it "Works". The first line
> successfully printed is always
> "Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096"
Odd, I'm wondering the uart gets into a weird state, and some bits get
knocked loose at console_initcall() time, when the console driver comes
up (Assuming CONFIG_SERIAL_XILINX_PS_UART)?
> And here are the addresses I tested:
>
> Address Result
> -----------------------
> 0xf0000000 Truncated
> 0xf0001000 Works
> 0xf0007000 Truncated
> 0xf0008000 Fails
> 0xf0009000 Fails
> 0xf000e000 Truncated
> 0xf000f000 Fails
> 0xf8000000 Truncated
> 0xf8001000 Works
> 0xfef00000 Truncated
> 0xfef01000 Works
> 0xfef08000 Fails
> 0xfef0f000 Fails
> 0xfeff0000 Fails
> 0xfeff1000 Fails
> 0xfeffe000 Fails
> 0xfefff000 Fails
>
> Judging by the list, the console seems to only work properly if the
> defined virtual address is Fxxx1000 and xxx is not too big...
Very odd. Do you mind sending out your patch allowing the selection of
the secondary uart for DEBUG_LL?
Thanks,
Josh
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-10-25 21:29 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 20:02 [PATCH v4 0/5] zynq subarch cleanups Josh Cartwright
2012-10-24 20:03 ` [PATCH v4 1/5] zynq: use GIC device tree bindings Josh Cartwright
2012-10-27 13:39 ` Michal Simek
2012-10-27 14:00 ` Josh Cartwright
2012-10-27 14:06 ` Michal Simek
2012-10-27 14:42 ` Josh Cartwright
2012-10-27 15:20 ` Michal Simek
2012-11-05 18:35 ` Josh Cartwright
2012-11-07 12:05 ` Michal Simek
2012-11-07 14:17 ` Josh Cartwright
2012-11-08 0:38 ` John Linn
2012-10-24 20:03 ` [PATCH v4 2/5] zynq: use pl310 " Josh Cartwright
2012-10-27 13:40 ` Michal Simek
2012-10-24 20:04 ` [PATCH v4 3/5] zynq: remove use of CLKDEV_LOOKUP Josh Cartwright
2012-10-27 16:47 ` Michal Simek
2012-10-24 20:04 ` [PATCH v4 4/5] ARM: annotate VMALLOC_END definition with _AC Josh Cartwright
2012-10-27 13:59 ` Michal Simek
2012-10-30 22:22 ` Arnd Bergmann
2012-10-31 8:43 ` Michal Simek
2012-10-31 11:36 ` Josh Cartwright
2012-10-24 20:04 ` [PATCH v4 5/5] zynq: move static peripheral mappings Josh Cartwright
2012-10-25 20:17 ` Nick Bowler
2012-10-25 21:29 ` Josh Cartwright [this message]
2012-10-25 22:41 ` Nick Bowler
2012-10-25 22:47 ` [PATCH] ARM: zynq: Allow UART1 to be used as DEBUG_LL console Nick Bowler
2012-10-29 16:56 ` Josh Cartwright
2012-10-29 18:13 ` Nick Bowler
2012-10-26 1:03 ` [PATCH v4 5/5] zynq: move static peripheral mappings Josh Cartwright
2012-10-27 16:52 ` Michal Simek
2012-10-28 23:26 [PATCH v4 0/5] zynq subarch cleanups Josh Cartwright
2012-10-22 2:15 ` [PATCH v4 5/5] zynq: move static peripheral mappings Josh Cartwright
2012-10-29 8:00 ` Michal Simek
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=20121025212902.GX20593@beefymiracle.amer.corp.natinst.com \
--to=josh.cartwright@ni.com \
--cc=arm@kernel.org \
--cc=arnd@arndb.de \
--cc=john.linn@xilinx.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@xilinx.com \
--cc=nbowler@elliptictech.com \
/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).