From: Scott Wood <scottwood@freescale.com>
To: wolfking <wolfking2000@msn.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: can't access PCIe card under sbc8548
Date: Thu, 30 May 2013 11:29:25 -0500 [thread overview]
Message-ID: <1369931365.14679.7@snotra> (raw)
In-Reply-To: <1369885321567-71775.post@n7.nabble.com> (from wolfking2000@msn.com on Wed May 29 22:42:01 2013)
On 05/29/2013 10:42:01 PM, wolfking wrote:
> hi, all
> I'm doing some developing on the windriver's sbc8548 board. The =20
> kernel I
> use
> is 3.6.10 and the u-boot version is 2012-10. I changed the board's
> configuration:
> the board now boot from the 64MB SODIMM Flash (not the default 8MB =20
> on-board
> Flash
> memory), and the PCI clock rate is changed to 33MHZ.
> Now the trouble I am in is that: the PCI card (a NIC card rtl8139) =20
> can be
> accessed OK, while the PCIe card can't work, that is, the kernel can't
> access
> its internal register. The kernel can correctly probe the PCIe card. =20
> its
> BAR0
> is a I/O mapped register, I use ioport_map to map the BAR0 to kernel's
> address
> space, then use ioread8/iowrite8 to access its internal register, it =20
> doesn't
> work.
In what specific way does it not work?
> I analyse the ioport_map function and find it just add the input =20
> parameter
> to
> a fixed _IO_BASE value, below is the function:
> void __iomem *ioport_map(unsigned long port, unsigned int len)
> {
> return (void __iomem *) (port + _IO_BASE);
> }
> the _IO_BASE value under sbc8548 is 0xfd7fd000, the value of =20
> ioport_map
> paramenter
> "port" is 0xfefff000. Obviously the add overflows, so the follow-up
> operations
> can't succeed.
Why can't it succeed? Is there nothing mapped at 0xfc7fc000?
> The value of "port" is got from the function
> pci_resource_start.
> So I guess the kernel allocate a bad address to this PCIe card. How =20
> can I
> fix this?
> I also plug this PCIe card into a freescale's board mpc8641-hpcn, =20
> try the
> same driver,
> I noticed ioport_map also meet overflow, but it does work fine.
So don't focus on the overflow, but rather on the actual breakage.
-Scott=
next prev parent reply other threads:[~2013-05-30 16:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-30 3:42 can't access PCIe card under sbc8548 wolfking
2013-05-30 5:56 ` tiejun.chen
2013-05-30 7:19 ` wolfking
2013-05-30 8:47 ` tiejun.chen
2013-05-30 9:15 ` wolfking
2013-05-30 9:30 ` tiejun.chen
2013-05-30 7:32 ` wolfking
2013-05-30 10:42 ` tiejun.chen
2013-05-30 12:49 ` wolfking
2013-05-30 16:24 ` Scott Wood
2013-05-31 1:34 ` tiejun.chen
2013-05-31 2:27 ` wolfking
2013-05-31 10:00 ` Benjamin Herrenschmidt
2013-05-30 10:02 ` wolfking
2013-05-30 10:08 ` tiejun.chen
2013-05-30 12:45 ` wolfking
2013-05-30 16:29 ` Scott Wood [this message]
2013-05-31 0:40 ` wolfking
2013-05-31 10:01 ` Benjamin Herrenschmidt
2013-05-31 12:46 ` wolfking
2013-06-08 7:00 ` wolfking
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=1369931365.14679.7@snotra \
--to=scottwood@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=wolfking2000@msn.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).