On Sat, 13 Mar 2010 16:55:58 -0800
Weongyo Jeong weongyo.je...@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.je...@gmail.com wrote:
I thought that your opinion was right and if mem is
0xf400-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 0x1800-0x18006fff on
nexus0
siba_cc0: ChipCommon core at mem 0x1800-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 0x1800 that I think this is a
reason why it doesn't require core switching and each cores have their
own memory region at starting 0x1800.
But in a case of PCI device with PCI to SSB bridge, it normally used
0xf400, 0xfe20 or other address which reserved by parent PCI
bridge.
With PCI device, when device report memory window
0xf400-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 0xf400
(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:
0x1800-0x18000fff ChipCommon
0x18001000-0x18001fff EMAC
0x18002000-0x18002fff PCI
0x18003000-0x18003fff PCMCIA
When it attached at siba_bwn it shows its memory region at 0xfe2fe000 -
0xfe2f (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.
If your opinion is right the memory region for full window should be
0xfe2fe000 - 0xfe301fff (16 Kb for 4 core, each core consumes 0x1000
size)
Even if I tried to remap memory region from 0xfe2fe000 to 0xfe301fff and
setting PCI BAR0 to 0x1800, another problem is occurred for reading
SPROM data. To access external SPROM it could be possible to access
bus_space_read_2(bt, bh, 0x1000 ~ 0x17ff) at ChipCommon core. But
accessing register in a core could not over 0xfff because maximum size
of a core limited within 0x1000.
That means internally in Silicon Backplane it has a special meaning if
it try to access over 0x1000 or 0x2000 which mentioned a quote at
Section 3: PCI Core, PCI Bus (Page 34).
I guess you're thinking that we could access EMAC core using
bus_space_read_2(bt, bh, 0x1000 ~ 0x1fff) after setting full memory
window. But it looks it's not possible.
regards,
Weongyo Jeong
--
Alex RAY r...@ddteam.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr
