From: Grant Grundler <grundler@parisc-linux.org>
To: linux-parisc@vger.kernel.org
Cc: Helge Deller <deller@gmx.de>
Subject: Re: pci 0000:01:04.0: BAR 0: no parent found for of device
Date: Fri, 6 Nov 2009 16:55:25 -0700 [thread overview]
Message-ID: <20091106235525.GD5262@lackof.org> (raw)
In-Reply-To: <20091106235405.GC5262@lackof.org>
[ sorry - didn't realize I hit "reply" instead of "reply-all" ]
On Fri, Nov 06, 2009 at 04:54:05PM -0700, Grant Grundler wrote:
> On Fri, Nov 06, 2009 at 09:37:31PM +0100, Helge Deller wrote:
> > Hi Grant,
> >
> > Thanks for your answers!!!
> ...
> >> IIRC, the graphics frame buffers are routed by every Elroy ELMMIO register
> >> on all 4 Elroys. If you can get the machine to NOT HPMC,
> >> ELMMIO resources should be listed in /proc/iomem for workstations.
> >
> > Ok, the good thing is, that it doesn't HPMCs.
> > But sadly I have no clue about what you write above :-(
>
> Heh...Here is a short and probably inadequate explanation.
>
> Elroy has 3 MMIO range registers that determine which physical
> addresses will get routed down to the PCI bus:
> LMMIO 32-bit MMIO address range
> ELMMIO "Extra" 32-bit MMIO address range
> GMMIO 64-bit MMIO address range
>
> The Astro that is upstream (via ropes) is also programmed to route
> specific addresses to specific Elroy devices. Including the ELMMIO
> and GMMIO ranges.
>
> The upstream routing is essentially the negative decoding of the
> downstream routing. So if f9000000-f9ffffff is routed down to
> elroy with PCI01, then any addresses generated by the PCI devices
> OUTSIDE of that range will get routed upstream since Elroy
> is designed to believe there is no device on that bus that will
> respond to addresses outside that range.
>
> It might be easiest to think of each MMIO transaction (read or write)
> as a network packet traversing a fabric and the MMIO address is
> the equivalent to an IP address. Each component in the path has
> a "routing table" (one or more MMIO range registers) to decide
> what to do with the packet.
>
> >
> > Syslog says:
> > SBA found Astro 2.1 at 0xfed00000
> > Elroy version TR4.0 (0x5) found at 0xfed30000
> > PCI: Enabled native mode for NS87415 (pif=0x8f)
> > Elroy version TR4.0 (0x5) found at 0xfed32000
> > pci 0000:01:04.0: BAR 0: no parent found for of device [0xfa000000-0xfbffffff]
> > iosapic: hpa not registered for 0000:01:04.0
> > iosapic: hpa not registered for 0000:01:05.0
> > Elroy version TR4.0 (0x5) found at 0xfed38000
> > Elroy version TR4.0 (0x5) found at 0xfed3c000
> > iosapic: hpa not registered for 0000:03:02.0
> > powersw: Soft power switch at 0xf0400804 enabled.
> >
> >
> > Maybe it's important, that 2 Elroys are detected before the BAR0 message and 2 afterwards?
>
> Yes, I think it is. There are two ELMMIO ranges being routed to PCI01 and
> PCI03. Need to determine if those are the right PCI busses (ergo Elroy)
> for those devices and that the same resources are available in the kernel
> that is failing to boot. Just hack lba_pci.c to dump more info about
> the address routing while it's booting.
>
>
> >
> > and here is /proc/iomem:
> > root@c3000:~# cat /proc/iomem
> > 00000000-7fffffff : System RAM
> > 00000000-000009ff : PDC data (Page Zero)
> > 00100000-00602fff : Kernel code
> > 00603000-0073bfff : Kernel data
> > f05d0000-f05d0000 : lcd_data
> > f05d0008-f05d0008 : lcd_cmd
> > f2000000-f23fffff : PCI00 LMMIO
> > f2000000-f2001fff : 0000:00:0f.1
> > f2000000-f2001fff : sym53c8xx
> > f2002000-f2003fff : 0000:00:0f.0
> > f2002000-f2003fff : sym53c8xx
> > f2004000-f20043ff : 0000:00:0f.1
> > f2004000-f20043ff : sym53c8xx
> > f2005000-f20053ff : 0000:00:0f.0
> > f2005000-f20053ff : sym53c8xx
> > f2006000-f2006fff : 0000:00:0e.2
> > f2007000-f2007fff : 0000:00:0e.2
> > f2007000-f2007fff : ohci_hcd
> > f2008000-f20083ff : 0000:00:0c.0
> > f2008000-f20083ff : tulip
> > f2009000-f200900f : 0000:00:0d.0
> > f200a000-f200a00f : 0000:00:0d.0
> > f200b000-f200b00f : 0000:00:0d.0
> > f200c000-f200c1ff : 0000:00:0d.0
> > f2040000-f207ffff : 0000:00:0c.0
> > f2400000-f27fffff : PCI01 LMMIO
> > f2400000-f240ffff : 0000:01:04.0
> > f3000000-f33fffff : PCI02 LMMIO
> > f3000000-f3003fff : 0000:02:01.0
> > f3004000-f300407f : 0000:02:03.0
> > f3004000-f300407f : tulip
> > f3040000-f307ffff : 0000:02:03.0
> > f3800000-f3bfffff : PCI03 LMMIO
> > f3800000-f39fffff : 0000:03:02.0
> > f6000000-f7ffffff : PCI03 ELMMIO
> > f6000000-f7ffffff : 0000:03:02.0
> > f9000000-f9ffffff : PCI01 ELMMIO
> > f9000000-f9ffffff : 0000:01:05.0
>
> I suspect how these are parented has changed.
> IIRC, Astro already "owns" this resource - but they aren't PCI devices.
> I don't recall offhand how the resource is (if at all) advertised and
> which Elroy's can even claim specific MMIO ranges.
>
> If the "fb at f6000000 (32 MB)" is coming from the PCI03 Elroy, then
> you can be sure the MMIO resource is not being advertised correctly.
> But the output below suggests its from PCI bus 1 (== PCI01 ? need to check).
>
> hth,
> grant
>
> > fed00000-fed00fff : 10
> > fed30000-fed30fff : 10:0
> > fed32000-fed32fff : 10:1
> > fed38000-fed38fff : 10:4
> > fed3c000-fed3cfff : 10:6
> > fef00000-feffffff : Astro Intr Ack
> > fff80000-fffaffff : Central Bus
> > fffa0000-fffa0fff : 32
> > fffb0000-fffdffff : Local Broadcast
> > fffe0000-ffffffff : Global Broadcast
> >
> >
> >
> >>> ...
> >>> STI GSC/PCI core graphics driver Version 0.9a
> >>> sti 0000:01:04.0: device not available because of BAR 0 [0xfa000000-0xfbffffff] collisions
> >>> sti 0000:01:04.0: Cannot enable PCI device
> >>> ^^^ HERE
> >>> sti: probe of 0000:01:04.0 failed with error -22
> >>> STI PCI graphic ROM found at f3800000 (2048 kB), fb at f6000000 (32 MB)
> >>> id 35acda30-9a02587, conforms to spec rev. 8.0d
> >>> graphics card name: A1262A
> >>> sticon: Initializing STI text console.
> >>> Console: switching to colour STI console 128x48
> >>> stifb: 'A1262A' (id: 0x35acda30) not supported.
> >>> Linux agpgart interface v0.103
> >>> ....
> >>>
> >>> Hopefully someone of you has an idea what caused this change?
> >>
> >> The automatic resource parenting code has changed a few times back
> >> and forth over the last 2-3 major releases. I've lost track
> >> but suspect it's probably easier to just look at what the
> >> LBA range registers say (set up by PDC) and then get the PCI subsystem
> >> to advertise those resources in a reasonable way.
> >
> > How can I see/check the LBA range registers?
> > Where is the advertising done?
> > Sorry, but I have no clue about PCI/LBA/Elroy/... ?
> >
> >> TBH, I'd rather spent a few hours this weekend debugging the PCI-PCI bridge
> >> support on PAT machines.
> >
> > Understood.
> > Any hints or untested patches would be great though...
> >
> >> hth,
> >> grant
> >
> > Thanks,
> > Helge
> >
> >
> >>
> >>>
> >>> lspci reports:
> >>> 01:04.0 Display controller: Hewlett-Packard Company A4977A Visualize EG (rev 03)
> >>> Flags: 66MHz, medium devsel
> >>> Memory at fa000000 (32-bit, non-prefetchable) [size=32M]
> >>> Expansion ROM at f2400000 [disabled] [size=64K]
next prev parent reply other threads:[~2009-11-06 23:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-03 21:00 pci 0000:01:04.0: BAR 0: no parent found for of device Helge Deller
[not found] ` <20091106062234.GC4574@lackof.org>
[not found] ` <4AF4890B.4050700@gmx.de>
[not found] ` <20091106235405.GC5262@lackof.org>
2009-11-06 23:55 ` Grant Grundler [this message]
2009-11-10 21:55 ` Helge Deller
2009-11-10 16:56 ` Domenico Andreoli
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=20091106235525.GD5262@lackof.org \
--to=grundler@parisc-linux.org \
--cc=deller@gmx.de \
--cc=linux-parisc@vger.kernel.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).