linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Russell McGuire" <rmcguire@videopresence.com>
To: "'Kumar Gala'" <galak@kernel.crashing.org>
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: MPC8360 : PCI resource allocate error
Date: Mon, 5 Feb 2007 16:51:19 -0800	[thread overview]
Message-ID: <000001c74988$ea7d7960$6405a8c0@absolut> (raw)
In-Reply-To: <A755B15B-9C78-40E1-998D-FE9E68E74805@kernel.crashing.org>


I think I might be getting someplace on this debugging of the PCI slots.

I solved the erratic SLOT 3 issue, it was a hardware problem. A net was
unconnected, I should shoot the designer. Anyway, this was fixed that so all
slots are 100% consistent.

I think general issue is probably a setup problem with the PCI bridge chip.
Though I do not know how U-boot and Linux set up the bridge.

But after reading through the Bridge documentation, I have learned that each
bus must have the memory map declared in it, for all three memory spaces.
I.e. the base and the upper limit for each mem, mmio, and IO space.

When I boot into Linux, with PCI cards plugged in, and I read these
registers it looks as if the base address is correct, but the upper limit is
actually set one byte below the base address. To me this effectively
prevents all access to the memory region, halting it at the bridge chip.
Would explain why the only region I can seem to read is the configuration
space. 

I guess the question is, does Linux only enable these ranges if a card is
actively using them. Or is BIOS supposed to have these enabled before the OS
gets access to the bridge?

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, February 02, 2007 8:07 AM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC8360 : PCI resource allocate error
> 
> 
> On Feb 2, 2007, at 10:01 AM, Russell McGuire wrote:
> 
> > Here is the current .dts mapping, though I am beginning to suspect the
> > hardware or a possible U-boot bug on this.
> >
> > U-boot can't see the PCI USB card in SLOT 3, but it can see the all
> > of the
> > other various PCI cards I have <ATI video card, sound card, ATA card,
> > network card>
> 
> Are any cards detected in SLOT 3 with u-boot?  If not, I'd think HW
> as well.
> 
> > All the cards that are seen by U-boot have the IO resource problem.
> > Only
> > when in Slot 3.
> >
> > I probably need to direct this at the U-boot crowd, but what about
> > these
> > defines in U-boot? Would they have any bearing? I forgot to publish
> > these
> > when I originally had asked the question bout PCI IO space, but
> > they are the
> > only ALL zero's in the mapping.
> 
> They shouldn't on just seeing the device.  Since PCI config cycles
> are used and U-boot will scan all busses you should at least see the
> device.
> 
> - k

  parent reply	other threads:[~2007-02-06  0:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-02 15:04 MPC8360 : PCI resource allocate error Russell McGuire
2007-02-02 15:27 ` Kumar Gala
2007-02-02 16:01   ` Russell McGuire
2007-02-02 16:07     ` Kumar Gala
2007-02-03  5:32       ` Russell McGuire
2007-02-05 16:16         ` Timur Tabi
2007-02-05 16:19         ` Kumar Gala
2007-02-06  0:51       ` Russell McGuire [this message]
2007-02-06 14:51         ` Kumar Gala

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='000001c74988$ea7d7960$6405a8c0@absolut' \
    --to=rmcguire@videopresence.com \
    --cc=galak@kernel.crashing.org \
    --cc=linuxppc-embedded@ozlabs.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).