> On Sat, Mar 13, 2010 at 11:12:05PM +0200, Alex RAY wrote:
> > On Fri, 12 Mar 2010 15:13:34 -0800
> > Weongyo Jeong <weongyo.jeong@gmail.com> wrote:
> >
> > >
> > > I thought that your opinion was right and if mem is
> > > 0xf4000000-0xf4003fff (16 Kb) I thought the device has 4 cores. However
> > > it looks this was wrong according to the below document:
> > >
> > >
http://voodoowarez.com/bcm5365p.pdf
> > >
> > > Please see Section 3: PCI Core, PCI Bus (Page 34) that it indicates that
> > > 16Kb, maybe 8 Kb in the old devices is core register region.
> > >
> > > "Accesses to the lower half of the core register region are translated
> > > into system backplane accesses using the PCIBAR0Window register"
> > > "Accesses to offsets 0x1000 to 0x17FF of this region initiate a direct
> > > access to the external SPROM"
> > >
> > > If we just access memory using offset + core and bus_space_read_x
> > > interfaces it would actually not access core register region.
> > >
> > > So without solving this problem it looks it could not remove coreswitch
> > > routines.
> > >
> > > regards,
> > > Weongyo Jeong
> > >
> >
> > Hi,
> >
> > this document about SoC BCM5365P, not about PCI device with PCI to SSB
> > bridge.
>
> Yes it's about SoC BCM5365P but I think the basic concept of Silicon
> Backplane would be same at a PCI device with PCI to SSB bridge.
>
> > I know in SoC`s like BSM5365 (I test it in BCM5354 and BCM5836) core
> > switching is not required.
> >
> > BCM5354 -
http://lists.freebsd.org/pipermail/freebsd-mips/2009-June/000421.html
> > BCM5836 -
http://lists.freebsd.org/pipermail/freebsd-mips/2010-February/000635.html
>
> The above URLs you mentioned indicates that
>
> siba0: <Sonics SiliconBackplane rev 0x0> at mem 0x18000000-0x18006fff on nexus0
> siba_cc0: <ChipCommon core> at mem 0x18000000-0x18000fff irq 0 on siba0
> bfe0: <Broadcom 44xx Ethernet Chip> at mem 0x18001000-0x18001fff irq 1 on siba0
> siba_mips0: <MIPS 3302 processor> at mem 0x18002000-0x18002fff on siba0
> ohci0: <SiBa integrated USB controller> at mem 0x18003000-0x18003fff irq 4 on siba0
>
> siba0 used memory region at starting 0x18000000 that I think this is a
> reason why it doesn't require core switching and each cores have their
> own memory region at starting 0x1800xxxx.
>
> But in a case of PCI device with PCI to SSB bridge, it normally used
> 0xf4000000, 0xfe200000 or other address which reserved by parent PCI
> bridge.
>
> > With PCI device, when device report memory window
> > 0xf4000000-0xf4003fff, why we can`t use full window?
>
> Because I'm not a Silicon Backplane expert I could not answer this
> question. But I'd like to make sure that memory window at 0xf4000000
> (size 16 Kbytes) comes from PCI BAR0 when pci(4) attached device.
> Moreover I believe size of memory window also comes from PCI BAR0 size
> testing of pci(4).
>
> Of course I think we can try to remap full memory window after
> calculating numbers of core but it looks meaning would be little bit
> different.
>
> > May be You can test your code without core switching?
>
> I tried to remove core switching code in siba_bwn bridge but after
> moment I got stuck to go forward. For example,
>
> I have 1 device which attached with bwn(4) and it has 4 cores:
>
> 0x18000000-0x18000fff ChipCommon
> 0x18001000-0x18001fff EMAC
> 0x18002000-0x18002fff PCI
> 0x18003000-0x18003fff PCMCIA
>
> When it attached at siba_bwn it shows its memory region at 0xfe2fe000 -
> 0xfe2fffff (8 Kbytes). Initial PCI BAR0 value was 0x18002000.
