Date: Mon, 14 May 2007 22:31:54 +0100 From: "Bruce M. Simpson" <bms@incunabulum.net> To: freebsd-mips@FreeBSD.org Subject: Re: Broadcom MIPS progress Message-ID: <4648D54A.9060100@incunabulum.net> In-Reply-To: <464291D7.7060603@incunabulum.net> References: <463F4F7D.6070001@incunabulum.net> <463FD2EB.7040504@incunabulum.net> <46412370.20002@incunabulum.net> <4641F795.9030309@incunabulum.net> <464291D7.7060603@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
bfe(4) now attempts to attach to the Broadcom EMAC core on the SiBa bus. It does not satisfy its busdma allocations (the chip can only DMA into a 1GB range, a known limitation) therefore attach currently fails; I think these functions have yet to be implemented in mips nexus: bfe0: <Broadcom 10/100 EMAC> at mem 0x18001000-0x18001fff irq 1 on siba0 siba_alloc_resource: proxying request to parent nexus_alloc_resource: entry (0x802de080, 0x802dfa80, 1, 0x80203e48, 0x1, 0x1, 1, 6) nexus_alloc_resource: requested rid is 0 bfe0: could not allocate parent dma tag bfe0: failed to allocate DMA resources device_attach: bfe0 attach returned 6 I have begun trying to get the PCI bridge to work, borrowing from both Linux and CuWiN/NetBSD. At the moment it looks like PCI bus enumeration does not work correctly, due to the way configuration space is mapped and probed; the Broadcom PCI core seems to format the tags usually sent to a bridge controller to initiate PCI Type 0 configuration transactions differently. If I byte-swap the data read back in siba_pcib_read_config() I see more "sensible" results however the ath(4) card is not detected and matched correctly (it is an AR5213). There is an ehci(4) controller on the PCI bus on the WGT634U. At the moment I see this: pci0: <bridge, PCI-NuBus> at device 0.0 (no driver attached) (the host bridge itself) pci0: <network, fddi> at device 1.0 (no driver attached) (supposedly ath) pci0: <serial bus> at device 2.0 (no driver attached) (supposedly ehci) The device and function numbers returned in Linux are the same, however, Linux is also able to enumerate the sub-functions of the ehci controller (the legacy USB 1.1 endpoints). I had to hardcode siba_pcib to only return 2 as the maximum number of 'slots', as trying to probe further results in the system hanging. I don't see a way of forcing an interrupt or trap when a master abort is initiated. A full PCI bus reconfiguration may be needed as the firmware does not set things up like an x86 BIOS does. I'm not sure that FreeBSD currently does this. The remaining SiBa cores are believed to be ohci(4) and ubsec(4) compatible. The remaining SiBa ChipCommon core functions which need to be implemented are determination of onboard CPU and board clocks, access to the serial UARTs, and interrupt routing. The bfe(4) and clock probes need to be tackled before we can think about targetting the Linksys WRT. As mentioned earlier, I am leaving access to onboard flash memory as a separate topic to be revisited later. regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4648D54A.9060100>