Date: Tue, 16 Mar 2010 15:51:13 -0700 From: Weongyo Jeong <weongyo.jeong@gmail.com> To: Alex RAY <ray@ddteam.net> Cc: Alexandr Rybalko <ray@dlink.ua>, current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver Message-ID: <20100316225113.GF88159@weongyo> In-Reply-To: <20100315004357.fca53c7f.ray@ddteam.net> References: <20100226005115.GP14937@weongyo> <20100227011535.ed3f2486.ray@ddteam.net> <20100228095259.GB3536@weongyo> <20100301103240.3a4aac8a.ray@dlink.ua> <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <20100313231205.5e68a89a.ray@ddteam.net> <20100314005558.GB88159@weongyo> <20100315004357.fca53c7f.ray@ddteam.net>
index | next in thread | previous in thread | raw e-mail
On Mon, Mar 15, 2010 at 12:43:57AM +0200, Alex RAY wrote: > On Sat, 13 Mar 2010 16:55:58 -0800 > Weongyo Jeong <weongyo.jeong@gmail.com> wrote: > > > 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. > > Yes, You're right. I found another way. > We can use SBtoPCITranslation2 (Offset 0x108) register, in that way we > can access to SSB without coreswitching. > (Page 42) > > Initial access for copy SPROM and preconfigure make via BAR0, then > setup SBtoPCITranslation2 and access to SSB direct. According to the specification, as you mentioned SBtoPCITranslation2 has a field UpperAddress but on field 31:30. It looks 2 bit fields are too limited to use so don't know how to implement it you mentioned. Could you please elaborate or show me details? regards, Weongyo Jeonghome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100316225113.GF88159>