From jacques.fourie at gmail.com Mon Sep 1 09:58:49 2008 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Mon Sep 1 09:58:55 2008 Subject: MMC Controller driver for PXA255 In-Reply-To: References: <20080829231522.201a591b.stas@FreeBSD.org> Message-ID: >> On Fri, 29 Aug 2008 18:20:16 +0200 >> "Jacques Fourie" mentioned: >> >>> Hi, >>> >>> I've written a driver for the MMC controller found on the Intel Xscale >>> PXA255 (as found on the Gumstix Connex). It seems to work OK - I've >>> tested with a range of SD cards. The driver works in PIO mode (still >>> busy to debug some DMA issues) and on my Gumstix Connex I get around >>> 400kB/s. If anyone wants to review the code for inclusion let me know >>> and I'll be happy to provide it. >>> >> >> Great work! >> Upload it somewhere or post here, so we can take a look. >> >> Thanks! >> -- >> Stanislav Sedov >> ST4096-RIPE >> > Hi, > > I previously sent Warner some mods but forgot to cc the list. Here is > a diff against current (svn revision 182470). I also made some minor > mods to the mmc stack that I'll post as soon as I've cleaned them up - > they contain a lot of extra printf's at the moment. > > Jacques > Here is a diff against mmc.c that contains my mods to the mmc stack. Very minor - I've added support for retrying commands. Some SD cards that I've tested with requires one extra ACMD_SD_SEND_OP_COND so I've included that as well. Jacques -------------- next part -------------- --- fbsd_current_20080830/src/sys/dev/mmc/mmc.c 2008-08-30 08:45:11.000000000 +0200 +++ fbsd_jf_priv/src/sys/dev/mmc/mmc.c 2008-09-01 11:35:39.000000000 +0200 @@ -51,7 +51,7 @@ */ #include -__FBSDID("$FreeBSD: head/sys/dev/mmc/mmc.c 170337 2007-06-05 17:04:44Z imp $"); +__FBSDID("$FreeBSD$"); #include #include @@ -258,13 +258,22 @@ mmc_wakeup(struct mmc_request *req) { struct mmc_softc *sc; + struct mmc_command *cmd = req->cmd; // printf("Wakeup for req %p done_data %p\n", req, req->done_data); sc = (struct mmc_softc *)req->done_data; MMC_LOCK(sc); - req->flags |= MMC_REQ_DONE; - wakeup(req); - MMC_UNLOCK(sc); + if (cmd->error && cmd->retries) { + cmd->retries--; + cmd->error = 0; + MMC_UNLOCK(sc); + MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); + } + else { + req->flags |= MMC_REQ_DONE; + wakeup(req); + MMC_UNLOCK(sc); + } } static int @@ -556,7 +565,7 @@ cmd.opcode = MMC_ALL_SEND_CID; cmd.arg = 0; cmd.flags = MMC_RSP_R2 | MMC_CMD_BCR; - err = mmc_wait_for_cmd(sc, &cmd, 0); + err = mmc_wait_for_cmd(sc, &cmd, CMD_RETRIES); memcpy(rawcid, cmd.resp, 4 * sizeof(uint32_t)); return (err); } @@ -570,7 +579,7 @@ cmd.opcode = MMC_SEND_CSD; cmd.arg = rca << 16; cmd.flags = MMC_RSP_R2 | MMC_CMD_BCR; - err = mmc_wait_for_cmd(sc, &cmd, 0); + err = mmc_wait_for_cmd(sc, &cmd, CMD_RETRIES); memcpy(rawcid, cmd.resp, 4 * sizeof(uint32_t)); return (err); } @@ -584,7 +593,7 @@ cmd.opcode = SD_SEND_RELATIVE_ADDR; cmd.arg = 0; cmd.flags = MMC_RSP_R6 | MMC_CMD_BCR; - err = mmc_wait_for_cmd(sc, &cmd, 0); + err = mmc_wait_for_cmd(sc, &cmd, CMD_RETRIES); *resp = cmd.resp[0]; return (err); } @@ -664,12 +673,16 @@ /* * Reselect the cards after we've idled them above. */ - if (mmcbr_get_mode(dev) == mode_sd) - mmc_send_app_op_cond(sc, mmcbr_get_ocr(dev), NULL); + if (mmcbr_get_mode(dev) == mode_sd) { + int i; + + for (i = 0; i < 2; i++) + mmc_send_app_op_cond(sc, mmcbr_get_ocr(dev), NULL); + } else mmc_send_op_cond(sc, mmcbr_get_ocr(dev), NULL); mmc_discover_cards(sc); - + mmcbr_set_bus_mode(dev, pushpull); mmcbr_update_ios(dev); bus_generic_attach(dev); @@ -790,4 +803,5 @@ DRIVER_MODULE(mmc, at91_mci, mmc_driver, mmc_devclass, 0, 0); +DRIVER_MODULE(mmc, pxa_mci, mmc_driver, mmc_devclass, 0, 0); DRIVER_MODULE(mmc, sdh, mmc_driver, mmc_devclass, 0, 0); From raj at semihalf.com Thu Sep 4 14:00:11 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Thu Sep 4 14:00:17 2008 Subject: ARM interrupts fixes Message-ID: <48BFE533.7010602@semihalf.com> Hi, Please review the following changes around interrupts handling in ARM. We already started discussing these items with Olivier some time ago: 1. http://people.freebsd.org/~raj/patches/arm/intr-fixes.diff At the moment nexus_setup_intr() attempts to set up a number of IRQs in one take, calling arm_setup_irqhandler() in loop. This is bogus, as there's just one cookie given from the caller and it is overwritten in each iteration so that only the last handler's cookie value prevails... This patch removes such behaviour, however there's one [mis]user of the old approach i.e. the IXP425 qmgr, which needs adjustments too, see p.2. Apart from style fixes, another problem which is corrected in this patch is the unmasking the IRQ source in the PIC after the last handler has been removed from list. 2. http://people.freebsd.org/~raj/patches/arm/sys-arm-xscale-ixp425.diff This splits handling of the two QMGR interrupts so they are explicitly managed, as typically done in cases when there are a number of physical IRQs used by one driver. I don't have IXP425 hardware and was able to only compile-test it, so any help with real h/w testing would be appreciated. Let me know your comments. Rafal From imp at bsdimp.com Thu Sep 4 14:40:13 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Sep 4 14:40:19 2008 Subject: ARM interrupts fixes In-Reply-To: <48BFE533.7010602@semihalf.com> References: <48BFE533.7010602@semihalf.com> Message-ID: <20080904.083659.-1749703318.imp@bsdimp.com> In message: <48BFE533.7010602@semihalf.com> Rafal Jaworowski writes: : Hi, : Please review the following changes around interrupts handling in ARM. We : already started discussing these items with Olivier some time ago: : : 1. http://people.freebsd.org/~raj/patches/arm/intr-fixes.diff : : At the moment nexus_setup_intr() attempts to set up a number of IRQs in one : take, calling arm_setup_irqhandler() in loop. This is bogus, as there's just : one cookie given from the caller and it is overwritten in each iteration so : that only the last handler's cookie value prevails... : : This patch removes such behaviour, however there's one [mis]user of the old : approach i.e. the IXP425 qmgr, which needs adjustments too, see p.2. : : Apart from style fixes, another problem which is corrected in this patch is : the unmasking the IRQ source in the PIC after the last handler has been : removed from list. : : : 2. http://people.freebsd.org/~raj/patches/arm/sys-arm-xscale-ixp425.diff : : This splits handling of the two QMGR interrupts so they are explicitly : managed, as typically done in cases when there are a number of physical IRQs : used by one driver. I don't have IXP425 hardware and was able to only : compile-test it, so any help with real h/w testing would be appreciated. : : Let me know your comments. These look good to me. Warner From sam at errno.com Thu Sep 4 15:13:04 2008 From: sam at errno.com (Sam Leffler) Date: Thu Sep 4 15:13:23 2008 Subject: ARM interrupts fixes In-Reply-To: <48BFE533.7010602@semihalf.com> References: <48BFE533.7010602@semihalf.com> Message-ID: <48BFF768.4070804@errno.com> Rafal Jaworowski wrote: > Hi, > Please review the following changes around interrupts handling in ARM. We > already started discussing these items with Olivier some time ago: > > 1. http://people.freebsd.org/~raj/patches/arm/intr-fixes.diff > > At the moment nexus_setup_intr() attempts to set up a number of IRQs in one > take, calling arm_setup_irqhandler() in loop. This is bogus, as there's just > one cookie given from the caller and it is overwritten in each iteration so > that only the last handler's cookie value prevails... > > This patch removes such behaviour, however there's one [mis]user of the old > approach i.e. the IXP425 qmgr, which needs adjustments too, see p.2. > > Apart from style fixes, another problem which is corrected in this patch is > the unmasking the IRQ source in the PIC after the last handler has been > removed from list. > > > 2. http://people.freebsd.org/~raj/patches/arm/sys-arm-xscale-ixp425.diff > > This splits handling of the two QMGR interrupts so they are explicitly > managed, as typically done in cases when there are a number of physical IRQs > used by one driver. I don't have IXP425 hardware and was able to only > compile-test it, so any help with real h/w testing would be appreciated. > > Let me know your comments. > The qmgr stuff looks fine; don't have time right now to look carefully at the other patch. Sam From stas at FreeBSD.org Thu Sep 4 16:02:43 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Sep 4 16:02:49 2008 Subject: ARM interrupts fixes In-Reply-To: <48BFE533.7010602@semihalf.com> References: <48BFE533.7010602@semihalf.com> Message-ID: <20080904200232.a8b556c9.stas@FreeBSD.org> On Thu, 04 Sep 2008 15:40:03 +0200 Rafal Jaworowski mentioned: > Hi, > Please review the following changes around interrupts handling in ARM. We > already started discussing these items with Olivier some time ago: > > 1. http://people.freebsd.org/~raj/patches/arm/intr-fixes.diff > > At the moment nexus_setup_intr() attempts to set up a number of IRQs in one > take, calling arm_setup_irqhandler() in loop. This is bogus, as there's just > one cookie given from the caller and it is overwritten in each iteration so > that only the last handler's cookie value prevails... > > This patch removes such behaviour, however there's one [mis]user of the old > approach i.e. the IXP425 qmgr, which needs adjustments too, see p.2. > > Apart from style fixes, another problem which is corrected in this patch is > the unmasking the IRQ source in the PIC after the last handler has been > removed from list. > The patch looks goot to me. But what about splitting the whitespace fixes and the meaningful ones when committing to the tree to not pollute the history? -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20080904/1483cb01/attachment.pgp From raj at semihalf.com Thu Sep 4 16:13:38 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Thu Sep 4 16:13:45 2008 Subject: ARM interrupts fixes In-Reply-To: <20080904200232.a8b556c9.stas@FreeBSD.org> References: <48BFE533.7010602@semihalf.com> <20080904200232.a8b556c9.stas@FreeBSD.org> Message-ID: <48C0092F.3030308@semihalf.com> Stanislav Sedov wrote: > The patch looks goot to me. But what about splitting the whitespace > fixes and the meaningful ones when committing to the tree to not > pollute the history? I can do it, but was under the impression that white space fix-only commits were rather frowned upon, isn't it the case any longer? Rafal From imp at bsdimp.com Thu Sep 4 16:24:17 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Sep 4 16:24:27 2008 Subject: ARM interrupts fixes In-Reply-To: <48C0092F.3030308@semihalf.com> References: <48BFE533.7010602@semihalf.com> <20080904200232.a8b556c9.stas@FreeBSD.org> <48C0092F.3030308@semihalf.com> Message-ID: <20080904.102343.-1543903392.imp@bsdimp.com> In message: <48C0092F.3030308@semihalf.com> Rafal Jaworowski writes: : Stanislav Sedov wrote: : > The patch looks goot to me. But what about splitting the whitespace : > fixes and the meaningful ones when committing to the tree to not : > pollute the history? : : I can do it, but was under the impression that white space fix-only commits : were rather frowned upon, isn't it the case any longer? White space only commits for the sake of fixing white space only is frowned on. If you are in there doing other things, they are OK. Warner From sam at freebsd.org Thu Sep 4 16:43:04 2008 From: sam at freebsd.org (Sam Leffler) Date: Thu Sep 4 16:43:10 2008 Subject: ARM interrupts fixes In-Reply-To: <48C0092F.3030308@semihalf.com> References: <48BFE533.7010602@semihalf.com> <20080904200232.a8b556c9.stas@FreeBSD.org> <48C0092F.3030308@semihalf.com> Message-ID: <48C00C1A.10503@freebsd.org> Rafal Jaworowski wrote: > Stanislav Sedov wrote: >> The patch looks goot to me. But what about splitting the whitespace >> fixes and the meaningful ones when committing to the tree to not >> pollute the history? > > I can do it, but was under the impression that white space fix-only commits > were rather frowned upon, isn't it the case any longer? Senseless churn is frowned upon. Ya know, the gratuitous knob-polishing some folks like to do that unintentionally introduce subtle bugs because the result isn't tested (and often not found until long after). If you're working in an area and it warrants cleanup then one hopes you're also testing. That's fine but as stas requested please commit the changes separately. Sam From jacques.fourie at gmail.com Tue Sep 9 13:33:37 2008 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Tue Sep 9 13:33:43 2008 Subject: Routing benchmarks Message-ID: Hi, I've performed some benchmark tests on my Gumstix Connex 400 (Intel Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. This board has two smc network interfaces. I configure the gumstix as a router and measure network throughput with netperf running on seperate boxes on either side of the gumstix. My initial tests showed a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA this figure went up to 7Mbit/s. Although this is a significant improvement, it still seems to be a bit slow. Does anyone have any tips on how I can go about to try and figure out where the bottleneck lies? Initial profiling showed that a significant amount of time was spent doing memory to memory copies of data, but after the DMA change profiling does not show any obvious culprits. Jacques From stas at FreeBSD.org Tue Sep 9 13:56:13 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Tue Sep 9 13:56:19 2008 Subject: Routing benchmarks In-Reply-To: References: Message-ID: <20080909175556.07bac5f0.stas@FreeBSD.org> On Tue, 9 Sep 2008 15:33:30 +0200 "Jacques Fourie" mentioned: > Hi, > > I've performed some benchmark tests on my Gumstix Connex 400 (Intel > Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. > This board has two smc network interfaces. I configure the gumstix as > a router and measure network throughput with netperf running on > seperate boxes on either side of the gumstix. My initial tests showed > a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA > this figure went up to 7Mbit/s. Although this is a significant > improvement, it still seems to be a bit slow. Does anyone have any > tips on how I can go about to try and figure out where the bottleneck > lies? Initial profiling showed that a significant amount of time was > spent doing memory to memory copies of data, but after the DMA change > profiling does not show any obvious culprits. > Have you tried checking the speed of the interface itself? Without routing involved? May it be the interfaces itself being so slow? -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20080909/dc82ca9e/attachment.pgp From ticso at cicely7.cicely.de Tue Sep 9 14:06:01 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Tue Sep 9 14:07:27 2008 Subject: Routing benchmarks In-Reply-To: References: Message-ID: <20080909135021.GR1147@cicely7.cicely.de> On Tue, Sep 09, 2008 at 03:33:30PM +0200, Jacques Fourie wrote: > Hi, > > I've performed some benchmark tests on my Gumstix Connex 400 (Intel > Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. > This board has two smc network interfaces. I configure the gumstix as > a router and measure network throughput with netperf running on > seperate boxes on either side of the gumstix. My initial tests showed > a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA > this figure went up to 7Mbit/s. Although this is a significant > improvement, it still seems to be a bit slow. Does anyone have any > tips on how I can go about to try and figure out where the bottleneck > lies? Initial profiling showed that a significant amount of time was > spent doing memory to memory copies of data, but after the DMA change > profiling does not show any obvious culprits. I don't know the PXA255, but I do know the AT91RM9200 and I expect the PXA255 to be a bit faster. With the RM9200 I can get ~8Mbit/s routing PPPoE with NAT and small ipfw table. This is done with the internal MAC using VLAN, so there is also VLAN overhead. Plain routing should be faster. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From jacques.fourie at gmail.com Tue Sep 9 14:36:24 2008 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Tue Sep 9 14:36:30 2008 Subject: Routing benchmarks In-Reply-To: <20080909175556.07bac5f0.stas@FreeBSD.org> References: <20080909175556.07bac5f0.stas@FreeBSD.org> Message-ID: On Tue, Sep 9, 2008 at 3:55 PM, Stanislav Sedov wrote: > On Tue, 9 Sep 2008 15:33:30 +0200 > "Jacques Fourie" mentioned: > >> Hi, >> >> I've performed some benchmark tests on my Gumstix Connex 400 (Intel >> Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. >> This board has two smc network interfaces. I configure the gumstix as >> a router and measure network throughput with netperf running on >> seperate boxes on either side of the gumstix. My initial tests showed >> a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA >> this figure went up to 7Mbit/s. Although this is a significant >> improvement, it still seems to be a bit slow. Does anyone have any >> tips on how I can go about to try and figure out where the bottleneck >> lies? Initial profiling showed that a significant amount of time was >> spent doing memory to memory copies of data, but after the DMA change >> profiling does not show any obvious culprits. >> > > Have you tried checking the speed of the interface itself? Without > routing involved? May it be the interfaces itself being so slow? > > -- > Stanislav Sedov > ST4096-RIPE > Running netserver on the gumstix shows a throughput of 2.4Mbit/s. At the moment I can't get if_bridge to work - will try to figure out what is going on. A bridging benchmark may be more informative. From imp at bsdimp.com Tue Sep 9 14:42:38 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Sep 9 14:42:45 2008 Subject: Routing benchmarks In-Reply-To: <20080909135021.GR1147@cicely7.cicely.de> References: <20080909135021.GR1147@cicely7.cicely.de> Message-ID: <20080909.084053.-1816817147.imp@bsdimp.com> In message: <20080909135021.GR1147@cicely7.cicely.de> Bernd Walter writes: : On Tue, Sep 09, 2008 at 03:33:30PM +0200, Jacques Fourie wrote: : > Hi, : > : > I've performed some benchmark tests on my Gumstix Connex 400 (Intel : > Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. : > This board has two smc network interfaces. I configure the gumstix as : > a router and measure network throughput with netperf running on : > seperate boxes on either side of the gumstix. My initial tests showed : > a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA : > this figure went up to 7Mbit/s. Although this is a significant : > improvement, it still seems to be a bit slow. Does anyone have any : > tips on how I can go about to try and figure out where the bottleneck : > lies? Initial profiling showed that a significant amount of time was : > spent doing memory to memory copies of data, but after the DMA change : > profiling does not show any obvious culprits. : : I don't know the PXA255, but I do know the AT91RM9200 and I expect the : PXA255 to be a bit faster. : With the RM9200 I can get ~8Mbit/s routing PPPoE with NAT and small : ipfw table. : This is done with the internal MAC using VLAN, so there is also VLAN : overhead. : Plain routing should be faster. Does the gumstick have 100BaseTX? The AT91RM9200 is 10BaseT only... Well, 10Mbps only since the phy is external.. Warner From jacques.fourie at gmail.com Tue Sep 9 14:47:38 2008 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Tue Sep 9 14:47:45 2008 Subject: Routing benchmarks In-Reply-To: <20080909.084053.-1816817147.imp@bsdimp.com> References: <20080909135021.GR1147@cicely7.cicely.de> <20080909.084053.-1816817147.imp@bsdimp.com> Message-ID: On Tue, Sep 9, 2008 at 4:40 PM, M. Warner Losh wrote: > In message: <20080909135021.GR1147@cicely7.cicely.de> > Bernd Walter writes: > : On Tue, Sep 09, 2008 at 03:33:30PM +0200, Jacques Fourie wrote: > : > Hi, > : > > : > I've performed some benchmark tests on my Gumstix Connex 400 (Intel > : > Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. > : > This board has two smc network interfaces. I configure the gumstix as > : > a router and measure network throughput with netperf running on > : > seperate boxes on either side of the gumstix. My initial tests showed > : > a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA > : > this figure went up to 7Mbit/s. Although this is a significant > : > improvement, it still seems to be a bit slow. Does anyone have any > : > tips on how I can go about to try and figure out where the bottleneck > : > lies? Initial profiling showed that a significant amount of time was > : > spent doing memory to memory copies of data, but after the DMA change > : > profiling does not show any obvious culprits. > : > : I don't know the PXA255, but I do know the AT91RM9200 and I expect the > : PXA255 to be a bit faster. > : With the RM9200 I can get ~8Mbit/s routing PPPoE with NAT and small > : ipfw table. > : This is done with the internal MAC using VLAN, so there is also VLAN > : overhead. > : Plain routing should be faster. > > Does the gumstick have 100BaseTX? The AT91RM9200 is 10BaseT only... > Well, 10Mbps only since the phy is external.. > > Warner > Yes, it does have 100BaseTX - both according to the specs and ifconfig : smc0: flags=8943 metric 0 mtu 1500 ether 00:0a:95:a5:47:3a media: Ethernet autoselect (100baseTX ) status: active smc1: flags=8943 metric 0 mtu 1500 ether 00:0a:95:a5:47:3b media: Ethernet autoselect (100baseTX ) status: active From ticso at cicely7.cicely.de Tue Sep 9 15:01:10 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Tue Sep 9 15:01:16 2008 Subject: Routing benchmarks In-Reply-To: <20080909.084053.-1816817147.imp@bsdimp.com> References: <20080909135021.GR1147@cicely7.cicely.de> <20080909.084053.-1816817147.imp@bsdimp.com> Message-ID: <20080909150057.GT1147@cicely7.cicely.de> On Tue, Sep 09, 2008 at 08:40:53AM -0600, M. Warner Losh wrote: > In message: <20080909135021.GR1147@cicely7.cicely.de> > Bernd Walter writes: > : On Tue, Sep 09, 2008 at 03:33:30PM +0200, Jacques Fourie wrote: > : > Hi, > : > > : > I've performed some benchmark tests on my Gumstix Connex 400 (Intel > : > Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. > : > This board has two smc network interfaces. I configure the gumstix as > : > a router and measure network throughput with netperf running on > : > seperate boxes on either side of the gumstix. My initial tests showed > : > a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA > : > this figure went up to 7Mbit/s. Although this is a significant > : > improvement, it still seems to be a bit slow. Does anyone have any > : > tips on how I can go about to try and figure out where the bottleneck > : > lies? Initial profiling showed that a significant amount of time was > : > spent doing memory to memory copies of data, but after the DMA change > : > profiling does not show any obvious culprits. > : > : I don't know the PXA255, but I do know the AT91RM9200 and I expect the > : PXA255 to be a bit faster. > : With the RM9200 I can get ~8Mbit/s routing PPPoE with NAT and small > : ipfw table. > : This is done with the internal MAC using VLAN, so there is also VLAN > : overhead. > : Plain routing should be faster. > > Does the gumstick have 100BaseTX? The AT91RM9200 is 10BaseT only... > Well, 10Mbps only since the phy is external.. The RM9200 is definitive 100mbit (MII and RMII interface). -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From sam at freebsd.org Tue Sep 9 15:02:39 2008 From: sam at freebsd.org (Sam Leffler) Date: Tue Sep 9 15:02:46 2008 Subject: Routing benchmarks In-Reply-To: References: <20080909175556.07bac5f0.stas@FreeBSD.org> Message-ID: <48C6900C.8070708@freebsd.org> Jacques Fourie wrote: > On Tue, Sep 9, 2008 at 3:55 PM, Stanislav Sedov wrote: > >> On Tue, 9 Sep 2008 15:33:30 +0200 >> "Jacques Fourie" mentioned: >> >> >>> Hi, >>> >>> I've performed some benchmark tests on my Gumstix Connex 400 (Intel >>> Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. >>> This board has two smc network interfaces. I configure the gumstix as >>> a router and measure network throughput with netperf running on >>> seperate boxes on either side of the gumstix. My initial tests showed >>> a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA >>> this figure went up to 7Mbit/s. Although this is a significant >>> improvement, it still seems to be a bit slow. Does anyone have any >>> tips on how I can go about to try and figure out where the bottleneck >>> lies? Initial profiling showed that a significant amount of time was >>> spent doing memory to memory copies of data, but after the DMA change >>> profiling does not show any obvious culprits. >>> >>> >> Have you tried checking the speed of the interface itself? Without >> routing involved? May it be the interfaces itself being so slow? >> >> -- >> Stanislav Sedov >> ST4096-RIPE >> >> > > Running netserver on the gumstix shows a throughput of 2.4Mbit/s. At > the moment I can't get if_bridge to work - will try to figure out what > is going on. A bridging benchmark may be more informative. > You said you did profiling but you didn't provide the data to inspect. It's possible kernel profiling has never been tried on your platform; did you sanity check the results? (e.g. run a known test load and check results; verify all routines that should execute appear in the profile). Also if copy overhead shows up as significant look to see why those copies are being done; it's often possible to avoid a copy. My experience in working with architectures like this is that cache handling can be a significant cost that doesn't always show up on a profile. Also you may find useful information by tracking mbufs using the h/w clock at important places along the "fast path" then look at whether the overhead for each step is reasonable. I did this for bridged traffic by forcing the rx dma to go to an mbuf+cluster then used the free storage in the mbuf header to store timestamps. At the end of the processing path I sorted the data into buckets by the sample points and added a sysctl to dump the histogram to see min/max/avg. Sam From imp at bsdimp.com Tue Sep 9 15:12:28 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Sep 9 15:12:35 2008 Subject: Routing benchmarks In-Reply-To: <20080909150057.GT1147@cicely7.cicely.de> References: <20080909135021.GR1147@cicely7.cicely.de> <20080909.084053.-1816817147.imp@bsdimp.com> <20080909150057.GT1147@cicely7.cicely.de> Message-ID: <20080909.091130.-1185936283.imp@bsdimp.com> In message: <20080909150057.GT1147@cicely7.cicely.de> Bernd Walter writes: : On Tue, Sep 09, 2008 at 08:40:53AM -0600, M. Warner Losh wrote: : > In message: <20080909135021.GR1147@cicely7.cicely.de> : > Bernd Walter writes: : > : On Tue, Sep 09, 2008 at 03:33:30PM +0200, Jacques Fourie wrote: : > : > Hi, : > : > : > : > I've performed some benchmark tests on my Gumstix Connex 400 (Intel : > : > Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. : > : > This board has two smc network interfaces. I configure the gumstix as : > : > a router and measure network throughput with netperf running on : > : > seperate boxes on either side of the gumstix. My initial tests showed : > : > a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA : > : > this figure went up to 7Mbit/s. Although this is a significant : > : > improvement, it still seems to be a bit slow. Does anyone have any : > : > tips on how I can go about to try and figure out where the bottleneck : > : > lies? Initial profiling showed that a significant amount of time was : > : > spent doing memory to memory copies of data, but after the DMA change : > : > profiling does not show any obvious culprits. : > : : > : I don't know the PXA255, but I do know the AT91RM9200 and I expect the : > : PXA255 to be a bit faster. : > : With the RM9200 I can get ~8Mbit/s routing PPPoE with NAT and small : > : ipfw table. : > : This is done with the internal MAC using VLAN, so there is also VLAN : > : overhead. : > : Plain routing should be faster. : > : > Does the gumstick have 100BaseTX? The AT91RM9200 is 10BaseT only... : > Well, 10Mbps only since the phy is external.. : : The RM9200 is definitive 100mbit (MII and RMII interface). Yea. You're right... Warner From jacques.fourie at gmail.com Tue Sep 9 15:16:35 2008 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Tue Sep 9 15:16:40 2008 Subject: Routing benchmarks In-Reply-To: <48C6900C.8070708@freebsd.org> References: <20080909175556.07bac5f0.stas@FreeBSD.org> <48C6900C.8070708@freebsd.org> Message-ID: On Tue, Sep 9, 2008 at 5:02 PM, Sam Leffler wrote: > Jacques Fourie wrote: >> >> On Tue, Sep 9, 2008 at 3:55 PM, Stanislav Sedov wrote: >> >>> >>> On Tue, 9 Sep 2008 15:33:30 +0200 >>> "Jacques Fourie" mentioned: >>> >>> >>>> >>>> Hi, >>>> >>>> I've performed some benchmark tests on my Gumstix Connex 400 (Intel >>>> Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. >>>> This board has two smc network interfaces. I configure the gumstix as >>>> a router and measure network throughput with netperf running on >>>> seperate boxes on either side of the gumstix. My initial tests showed >>>> a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA >>>> this figure went up to 7Mbit/s. Although this is a significant >>>> improvement, it still seems to be a bit slow. Does anyone have any >>>> tips on how I can go about to try and figure out where the bottleneck >>>> lies? Initial profiling showed that a significant amount of time was >>>> spent doing memory to memory copies of data, but after the DMA change >>>> profiling does not show any obvious culprits. >>>> >>>> >>> >>> Have you tried checking the speed of the interface itself? Without >>> routing involved? May it be the interfaces itself being so slow? >>> >>> -- >>> Stanislav Sedov >>> ST4096-RIPE >>> >>> >> >> Running netserver on the gumstix shows a throughput of 2.4Mbit/s. At >> the moment I can't get if_bridge to work - will try to figure out what >> is going on. A bridging benchmark may be more informative. >> > > You said you did profiling but you didn't provide the data to inspect. It's > possible kernel profiling has never been tried on your platform; did you > sanity check the results? (e.g. run a known test load and check results; > verify all routines that should execute appear in the profile). Also if > copy overhead shows up as significant look to see why those copies are being > done; it's often possible to avoid a copy. > > My experience in working with architectures like this is that cache handling > can be a significant cost that doesn't always show up on a profile. > > Also you may find useful information by tracking mbufs using the h/w clock > at important places along the "fast path" then look at whether the overhead > for each step is reasonable. I did this for bridged traffic by forcing the > rx dma to go to an mbuf+cluster then used the free storage in the mbuf > header to store timestamps. At the end of the processing path I sorted the > data into buckets by the sample points and added a sysctl to dump the > histogram to see min/max/avg. > > Sam > > Thanks for the nice idea - will try something similar. At the moment I'm also suspecting that cache handling has got a lot to do with the performance figures that I'm seeing. The PXA255 has a 32KB data and 32KB instruction cache. Jacques From sam at freebsd.org Tue Sep 9 15:33:08 2008 From: sam at freebsd.org (Sam Leffler) Date: Tue Sep 9 15:33:19 2008 Subject: Routing benchmarks In-Reply-To: References: <20080909175556.07bac5f0.stas@FreeBSD.org> <48C6900C.8070708@freebsd.org> Message-ID: <48C69733.2050601@freebsd.org> Jacques Fourie wrote: > On Tue, Sep 9, 2008 at 5:02 PM, Sam Leffler wrote: > >> Jacques Fourie wrote: >> >>> On Tue, Sep 9, 2008 at 3:55 PM, Stanislav Sedov wrote: >>> >>> >>>> On Tue, 9 Sep 2008 15:33:30 +0200 >>>> "Jacques Fourie" mentioned: >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> I've performed some benchmark tests on my Gumstix Connex 400 (Intel >>>>> Xscale PXA 255 CPU clocked at 400MHz) with a netDuo expansion board. >>>>> This board has two smc network interfaces. I configure the gumstix as >>>>> a router and measure network throughput with netperf running on >>>>> seperate boxes on either side of the gumstix. My initial tests showed >>>>> a TCP throughput of 2Mbit/s. After adapting the smc driver to use DMA >>>>> this figure went up to 7Mbit/s. Although this is a significant >>>>> improvement, it still seems to be a bit slow. Does anyone have any >>>>> tips on how I can go about to try and figure out where the bottleneck >>>>> lies? Initial profiling showed that a significant amount of time was >>>>> spent doing memory to memory copies of data, but after the DMA change >>>>> profiling does not show any obvious culprits. >>>>> >>>>> >>>>> >>>> Have you tried checking the speed of the interface itself? Without >>>> routing involved? May it be the interfaces itself being so slow? >>>> >>>> -- >>>> Stanislav Sedov >>>> ST4096-RIPE >>>> >>>> >>>> >>> Running netserver on the gumstix shows a throughput of 2.4Mbit/s. At >>> the moment I can't get if_bridge to work - will try to figure out what >>> is going on. A bridging benchmark may be more informative. >>> >>> >> You said you did profiling but you didn't provide the data to inspect. It's >> possible kernel profiling has never been tried on your platform; did you >> sanity check the results? (e.g. run a known test load and check results; >> verify all routines that should execute appear in the profile). Also if >> copy overhead shows up as significant look to see why those copies are being >> done; it's often possible to avoid a copy. >> >> My experience in working with architectures like this is that cache handling >> can be a significant cost that doesn't always show up on a profile. >> >> Also you may find useful information by tracking mbufs using the h/w clock >> at important places along the "fast path" then look at whether the overhead >> for each step is reasonable. I did this for bridged traffic by forcing the >> rx dma to go to an mbuf+cluster then used the free storage in the mbuf >> header to store timestamps. At the end of the processing path I sorted the >> data into buckets by the sample points and added a sysctl to dump the >> histogram to see min/max/avg. >> >> Sam >> >> >> > > Thanks for the nice idea - will try something similar. At the moment > I'm also suspecting that cache handling has got a lot to do with the > performance figures that I'm seeing. The PXA255 has a 32KB data and > 32KB instruction cache. > I was thinking more of cases where you must flush the d-cache because a memory object is treated r/w (e.g. packet data). bus_dmamap_sync ops can do cache flushes and may not be required or may be overly expensive. Also, sometimes you can get away with treating objects as read-only and avoid the cache flush. Sam From jacques.fourie at gmail.com Tue Sep 9 16:24:02 2008 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Tue Sep 9 16:24:08 2008 Subject: Routing benchmarks In-Reply-To: <200809091614.m89GEAc4088266@casselton.net> References: <200809091614.m89GEAc4088266@casselton.net> Message-ID: On Tue, Sep 9, 2008 at 6:14 PM, Mark Tinguely wrote: > > (trimmed the thread text) > >> >> Running netserver on the gumstix shows a throughput of 2.4Mbit/s. At >> >> the moment I can't get if_bridge to work - will try to figure out what >> >> is going on. A bridging benchmark may be more informative. > >> > My experience in working with architectures like this is that cache handling >> > can be a significant cost that doesn't always show up on a profile. >> > >> >> Thanks for the nice idea - will try something similar. At the moment >> I'm also suspecting that cache handling has got a lot to do with the >> performance figures that I'm seeing. The PXA255 has a 32KB data and >> 32KB instruction cache. >> >> Jacques > > which version of freebsd are you using - we changed some cache flushing > routines between FreeBSD 7.x and current. Unless errors were introduced > or removed, there should not be that large of a change. > > As mentioned, the ARM caches are pretty small. The ARM processors before > version 6, (anything before ARM10) uses virtually indexed / virtually tagged > caches, so they need to be flushed on context changes. > > The version 6 and version 7 ARM processors (ARM10/ARM11) are either virtually > indexed / physically tagged or physically indexed / physically tagged. > The PIPT caches don't need to be flushed on context changes and were needed > for multiple processor support. The pmap code will have to be re-written to > take advantage of the PIPT caches (put a process value into the MMU and remove > most flushes). > > Also, the pre version 6 ARM processors didn't allow for any spare bits in the > PTE for OS use. The newer processors have a bit or two, still not enough > for FreeBSD's needs, so we need to shadow these bits. > > Thirdly, we dynamically allocate a seperate structure that mirrors the > page table. I think I have all the "paper scratching" required to move from > this structure to the FreeBSD i386/amd64 recursive page table approach. > > --Mark Tinguely. > I'm using -current from about a week ago. Jacques From tinguely at casselton.net Tue Sep 9 16:27:37 2008 From: tinguely at casselton.net (Mark Tinguely) Date: Tue Sep 9 16:27:43 2008 Subject: Routing benchmarks In-Reply-To: Message-ID: <200809091614.m89GEAc4088266@casselton.net> (trimmed the thread text) > >> Running netserver on the gumstix shows a throughput of 2.4Mbit/s. At > >> the moment I can't get if_bridge to work - will try to figure out what > >> is going on. A bridging benchmark may be more informative. > > My experience in working with architectures like this is that cache handling > > can be a significant cost that doesn't always show up on a profile. > > > > Thanks for the nice idea - will try something similar. At the moment > I'm also suspecting that cache handling has got a lot to do with the > performance figures that I'm seeing. The PXA255 has a 32KB data and > 32KB instruction cache. > > Jacques which version of freebsd are you using - we changed some cache flushing routines between FreeBSD 7.x and current. Unless errors were introduced or removed, there should not be that large of a change. As mentioned, the ARM caches are pretty small. The ARM processors before version 6, (anything before ARM10) uses virtually indexed / virtually tagged caches, so they need to be flushed on context changes. The version 6 and version 7 ARM processors (ARM10/ARM11) are either virtually indexed / physically tagged or physically indexed / physically tagged. The PIPT caches don't need to be flushed on context changes and were needed for multiple processor support. The pmap code will have to be re-written to take advantage of the PIPT caches (put a process value into the MMU and remove most flushes). Also, the pre version 6 ARM processors didn't allow for any spare bits in the PTE for OS use. The newer processors have a bit or two, still not enough for FreeBSD's needs, so we need to shadow these bits. Thirdly, we dynamically allocate a seperate structure that mirrors the page table. I think I have all the "paper scratching" required to move from this structure to the FreeBSD i386/amd64 recursive page table approach. --Mark Tinguely. From tinguely at casselton.net Tue Sep 9 17:02:05 2008 From: tinguely at casselton.net (Mark Tinguely) Date: Tue Sep 9 17:02:11 2008 Subject: Routing benchmarks In-Reply-To: Message-ID: <200809091702.m89H24Bs091763@casselton.net> (more trimmed thread text) I asked: > > which version of freebsd are you using - we changed some cache flushing > > routines between FreeBSD 7.x and current. Unless errors were introduced > > or removed, there should not be that large of a change. Jacques answered: > I'm using -current from about a week ago. I doubt FreeBSD 7.x will be faster, but it may be worth a try. Also a fourth item, If I remember correctly, the ARM DMA is done to RAM only. The cache had to be flushed before the read and write DMAs. Therefore, any access by the processor to the packet brought in by DMA (to do checksum, decrease the TTL, read header for packet for IP destination, etc), involves a cache miss. Also we need to flush the cache before another DMA can be performed - for example transmit the packet. I am hazy on remembering, but I think this cache non-involvement in DMA feature is still in the newer ARMv6/ARMv7 arch. These arch features can't be programmed around, but keeping the processor involvement in the packet as little are possible and profiling may tell us what we are doing inefficiently. --Mark Tinguely. From benno at jeamland.net Tue Sep 9 23:32:58 2008 From: benno at jeamland.net (Benno Rice) Date: Tue Sep 9 23:33:04 2008 Subject: Routing benchmarks In-Reply-To: References: <20080909175556.07bac5f0.stas@FreeBSD.org> <48C6900C.8070708@freebsd.org> Message-ID: <200B1D7A-5D33-4E0F-A0C3-7F1C21FCF324@jeamland.net> On 10/09/2008, at 1:16 AM, Jacques Fourie wrote: [snip] > Thanks for the nice idea - will try something similar. At the moment > I'm also suspecting that cache handling has got a lot to do with the > performance figures that I'm seeing. The PXA255 has a 32KB data and > 32KB instruction cache. As the author of the pxa, smc and related code, I can also attest to the fact that they could do with work. In particular, I always seemed to get what I thought were oddly high interrupt rates coming off the smc interfaces. This would be tying the CPU up in the interrupt/gpio- as-interrupt code and slowing things down. -- Benno Rice benno@jeamland.net From tinderbox at freebsd.org Wed Sep 10 14:40:46 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Sep 10 14:40:52 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20080910144039.EC8CC73039@freebsd-current.sentex.ca> TB --- 2008-09-10 14:40:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-10 14:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2008-09-10 14:40:01 - cleaning the object tree TB --- 2008-09-10 14:40:31 - cvsupping the source tree TB --- 2008-09-10 14:40:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-09-10 14:40:39 - building world (CFLAGS=-O -pipe) TB --- 2008-09-10 14:40:39 - cd /src TB --- 2008-09-10 14:40:39 - /usr/bin/make -B buildworld TB --- 2008-09-10 14:40:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-10 14:40:39 - ERROR: failed to build world TB --- 2008-09-10 14:40:39 - tinderbox aborted TB --- 1.85 user 2.09 system 38.69 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From hselasky at c2i.net Sat Sep 13 12:08:51 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Sep 13 12:08:57 2008 Subject: Openmoko phones and USB on FreeBSD Message-ID: <200809131310.33495.hselasky@c2i.net> Hi, There are some problems using the dfu-util to flash Openmoko phones from FreeBSD. The problem resides in the USB stack on the phone, which does not support the libusb-0.1 string requests. I'm planning to work around this in the kernel to avoid future problems. I have tested patches for this, but they have not committed yet. Secondly I plan to add support for RNDIS so that you can access the OpenMoko phone through USB ethernet. I'm currently awaiting approval from the Linux people to port their RNDIS driver to the new USB stack under a BSD license. Really they should have used CDC ethernet, but there are too many Windows users out there I guess :-) --HPS From guru at unixarea.de Sat Sep 13 12:25:17 2008 From: guru at unixarea.de (Matthias Apitz) Date: Sat Sep 13 12:25:24 2008 Subject: Openmoko phones and USB on FreeBSD In-Reply-To: <200809131310.33495.hselasky@c2i.net> References: <200809131310.33495.hselasky@c2i.net> Message-ID: <20080913122220.GA3162@rebelion.Sisis.de> El d?a Saturday, September 13, 2008 a las 01:10:32PM +0200, Hans Petter Selasky escribi?: > Hi, > > There are some problems using the dfu-util to flash Openmoko phones from > FreeBSD. The problem resides in the USB stack on the phone, which does not > support the libusb-0.1 string requests. I'm planning to work around this in > the kernel to avoid future problems. I have tested patches for this, but they > have not committed yet. Hi Hans, I'm using FreeBSD on my normal laptop and my eeePC 900 gadget; my Openmoko will arrive next week (hopefully) and so I'm interested and willing to test your stuff (hoping that it is based on RELENG_7); > Secondly I plan to add support for RNDIS so that you can access the OpenMoko > phone through USB ethernet. I'm currently awaiting approval from the Linux > people to port their RNDIS driver to the new USB stack under a BSD license. > Really they should have used CDC ethernet, but there are too many Windows > users out there I guess :-) Concerning accessing the Openmoko through USB I thought that this is possible, at least the Openmoko's Wiki says this: http://wiki.openmoko.org/wiki/USB_Networking#FreeBSD or are you talking about running FreeBSD on the Openmoko at all (this would be great news :-)) Thx matthias PD: I'm only subscribed to -arm, not to -usb; -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ A computer is like an air conditioner, it stops working when you open Windows Una computadora es como aire acondicionado, deja de funcionar si abres Windows From hselasky at c2i.net Sat Sep 13 14:31:35 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Sep 13 14:31:48 2008 Subject: Openmoko phones and USB on FreeBSD In-Reply-To: <20080913122220.GA3162@rebelion.Sisis.de> References: <200809131310.33495.hselasky@c2i.net> <20080913122220.GA3162@rebelion.Sisis.de> Message-ID: <200809131633.21922.hselasky@c2i.net> Hi Matthias, The OpenMoko distributions I've tried so far does not come with CDC-ethernet like default. The network page you are referring to assumes that the OpenMoko software is programmed for CDC ethernet on the device side. No, I'm not talking about FreeBSD on the OpenMoko itself. --HPS On Saturday 13 September 2008, Matthias Apitz wrote: > El d?a Saturday, September 13, 2008 a las 01:10:32PM +0200, Hans Petter Selasky escribi?: > > Hi, > > > > There are some problems using the dfu-util to flash Openmoko phones from > > FreeBSD. The problem resides in the USB stack on the phone, which does > > not support the libusb-0.1 string requests. I'm planning to work around > > this in the kernel to avoid future problems. I have tested patches for > > this, but they have not committed yet. > > Hi Hans, > > I'm using FreeBSD on my normal laptop and my eeePC 900 gadget; my > Openmoko will arrive next week (hopefully) and so I'm interested and > willing to test your stuff (hoping that it is based on RELENG_7); > > > Secondly I plan to add support for RNDIS so that you can access the > > OpenMoko phone through USB ethernet. I'm currently awaiting approval from > > the Linux people to port their RNDIS driver to the new USB stack under a > > BSD license. Really they should have used CDC ethernet, but there are too > > many Windows users out there I guess :-) > > Concerning accessing the Openmoko through USB I thought that this is > possible, at least the Openmoko's Wiki says this: > http://wiki.openmoko.org/wiki/USB_Networking#FreeBSD > > or are you talking about running FreeBSD on the Openmoko at all (this > would be great news :-)) > > Thx > > matthias From torfinn.ingolfsen at broadpark.no Sat Sep 13 19:46:55 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Sat Sep 13 19:47:10 2008 Subject: Openmoko phones and USB on FreeBSD In-Reply-To: <20080913122220.GA3162@rebelion.Sisis.de> References: <200809131310.33495.hselasky@c2i.net> <20080913122220.GA3162@rebelion.Sisis.de> Message-ID: <20080913204646.fe60109d.torfinn.ingolfsen@broadpark.no> On Sat, 13 Sep 2008 14:22:20 +0200 Matthias Apitz wrote: > Concerning accessing the Openmoko through USB I thought that this is > possible, at least the Openmoko's Wiki says this: > http://wiki.openmoko.org/wiki/USB_Networking#FreeBSD Yes, this is possible. When I plug in my Neo FreeRunner into this FreeeBSD workstation, I get this in /var/log/messages: Sep 13 20:36:14 kg-work2 root: Unknown USB device: vendor 0x1457 product 0x5122 bus uhub1 Sep 13 20:36:15 kg-work2 kernel: cdce0: on uhub1 Sep 13 20:36:15 kg-work2 kernel: cdce0: faking MAC address Sep 13 20:36:15 kg-work2 kernel: cdce0: Ethernet address: 2a:fd:05:61:9b:00 Sep 13 20:36:15 kg-work2 kernel: cdce0: if_start running deferred for Giant This machine is running: tingo@kg-work2$ uname -a FreeBSD kg-work2.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Jul 21 20:40:31 CEST 2008 root@kg-work2.kg4.no:/usr/obj/usr/src/sys/GENERIC i386 Lets set up the interface: root@kg-work2# ifconfig cdce0 inet 192.168.0.200 netmask 255.255.255.0 root@kg-work2# ifconfig cdce0 cdce0: flags=108843 metric 0 mtu 1500 ether 2a:fd:05:61:9b:00 inet 192.168.0.200 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet 10baseT/UTP status: active root@kg-work2# ping 192.168.0.202 PING 192.168.0.202 (192.168.0.202): 56 data bytes 64 bytes from 192.168.0.202: icmp_seq=0 ttl=64 time=5.501 ms 64 bytes from 192.168.0.202: icmp_seq=1 ttl=64 time=0.856 ms 64 bytes from 192.168.0.202: icmp_seq=2 ttl=64 time=1.672 ms ^C --- 192.168.0.202 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.856/2.676/5.501/2.025 ms Ok, try ssh now: root@kg-work2# ssh 192.168.0.202 root@192.168.0.202's password: root@om-gta02:~# uptime 20:43:48 up 7 days, 22:36, 2 users, load average: 0.28, 0.37, 0.45 root@om-gta02:~# uname -a Linux om-gta02 2.6.24 #1 PREEMPT Tue Aug 26 08:33:29 CST 2008 armv4tl unknown root@om-gta02:~# cat /etc/angstrom-version Angstrom P1-Snapshot-20080902 HTH -- Regards, Torfinn Ingolfsen From hselasky at c2i.net Sun Sep 14 02:48:54 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Sep 14 02:49:06 2008 Subject: Openmoko phones and USB on FreeBSD In-Reply-To: <20080913204646.fe60109d.torfinn.ingolfsen@broadpark.no> References: <200809131310.33495.hselasky@c2i.net> <20080913122220.GA3162@rebelion.Sisis.de> <20080913204646.fe60109d.torfinn.ingolfsen@broadpark.no> Message-ID: <200809140450.43940.hselasky@c2i.net> On Saturday 13 September 2008, Torfinn Ingolfsen wrote: > On Sat, 13 Sep 2008 14:22:20 +0200 > > Matthias Apitz wrote: > > Concerning accessing the Openmoko through USB I thought that this is > > possible, at least the Openmoko's Wiki says this: > > http://wiki.openmoko.org/wiki/USB_Networking#FreeBSD > > Yes, this is possible. When I plug in my Neo FreeRunner into this > FreeeBSD workstation, I get this in /var/log/messages: > Sep 13 20:36:14 kg-work2 root: Unknown USB device: vendor 0x1457 product > 0x5122 bus uhub1 Sep 13 20:36:15 kg-work2 kernel: cdce0: 2.6.24/s3c2410_udc RNDIS/Ethernet Gadget, class 2/0, rev 2.00/2.12, addr 2> > on uhub1 Sep 13 20:36:15 kg-work2 kernel: cdce0: faking MAC address Sep 13 > 20:36:15 kg-work2 kernel: cdce0: Ethernet address: 2a:fd:05:61:9b:00 > Sep 13 20:36:15 kg-work2 kernel: cdce0: if_start running deferred for Giant > Hi, I figured it it now: My new USB stack selects configuration index 0 first, which is RNDIS. When I ran: usbconfig -u 2 -a 2 set_config 1 I got: cdce0: on usbus2 cdce0: Ethernet address: 5a:a0:96:da:00:00 --HPS From guru at unixarea.de Tue Sep 16 10:32:02 2008 From: guru at unixarea.de (Matthias Apitz) Date: Tue Sep 16 10:32:09 2008 Subject: Openmoko phones and USB on FreeBSD In-Reply-To: <20080913204646.fe60109d.torfinn.ingolfsen@broadpark.no> References: <200809131310.33495.hselasky@c2i.net> <20080913122220.GA3162@rebelion.Sisis.de> <20080913204646.fe60109d.torfinn.ingolfsen@broadpark.no> Message-ID: <20080916103159.GA17166@rebelion.Sisis.de> El d?a Saturday, September 13, 2008 a las 08:46:46PM +0200, Torfinn Ingolfsen escribi?: > On Sat, 13 Sep 2008 14:22:20 +0200 > Matthias Apitz wrote: > > > Concerning accessing the Openmoko through USB I thought that this is > > possible, at least the Openmoko's Wiki says this: > > http://wiki.openmoko.org/wiki/USB_Networking#FreeBSD > > Yes, this is possible. When I plug in my Neo FreeRunner into this > FreeeBSD workstation, I get this in /var/log/messages: > Sep 13 20:36:14 kg-work2 root: Unknown USB device: vendor 0x1457 product 0x5122 bus uhub1 > Sep 13 20:36:15 kg-work2 kernel: cdce0: on uhub1 > Sep 13 20:36:15 kg-work2 kernel: cdce0: faking MAC address Sep 13 20:36:15 kg-work2 kernel: cdce0: Ethernet address: > 2a:fd:05:61:9b:00 > Sep 13 20:36:15 kg-work2 kernel: cdce0: if_start running deferred for Giant ... To prepare things a bit while still waiting for my Openmoko Gadget, I've pulled out 'dfu-util' from SVN as described in the Openmoko Wiki: http://wiki.openmoko.org/wiki/Dfu-util $ svn co http://svn.openmoko.org/trunk/src/host/dfu-util/ $ cd dfu-util $ ./autogen.sh $ ./configure $ make but it does not compile because of missing header files: main.c:29:22: error: byteswap.h: No such file or directory main.c:30:20: error: endian.h: No such file or directory before digging into the details, is there already a port of 'dfu-util' to FreeBSD? thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ A computer is like an air conditioner, it stops working when you open Windows Una computadora es como aire acondicionado, deja de funcionar si abres Windows From imp at bsdimp.com Tue Sep 16 11:00:55 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Sep 16 11:03:37 2008 Subject: Openmoko phones and USB on FreeBSD In-Reply-To: <20080916103159.GA17166@rebelion.Sisis.de> References: <20080913122220.GA3162@rebelion.Sisis.de> <20080913204646.fe60109d.torfinn.ingolfsen@broadpark.no> <20080916103159.GA17166@rebelion.Sisis.de> Message-ID: <20080916.045915.117918889.imp@bsdimp.com> In message: <20080916103159.GA17166@rebelion.Sisis.de> Matthias Apitz writes: : El d?a Saturday, September 13, 2008 a las 08:46:46PM +0200, Torfinn Ingolfsen escribi?: : : > On Sat, 13 Sep 2008 14:22:20 +0200 : > Matthias Apitz wrote: : > : > > Concerning accessing the Openmoko through USB I thought that this is : > > possible, at least the Openmoko's Wiki says this: : > > http://wiki.openmoko.org/wiki/USB_Networking#FreeBSD : > : > Yes, this is possible. When I plug in my Neo FreeRunner into this : > FreeeBSD workstation, I get this in /var/log/messages: : > Sep 13 20:36:14 kg-work2 root: Unknown USB device: vendor 0x1457 product 0x5122 bus uhub1 : > Sep 13 20:36:15 kg-work2 kernel: cdce0: on uhub1 : > Sep 13 20:36:15 kg-work2 kernel: cdce0: faking MAC address Sep 13 20:36:15 kg-work2 kernel: cdce0: Ethernet address: : > 2a:fd:05:61:9b:00 : > Sep 13 20:36:15 kg-work2 kernel: cdce0: if_start running deferred for Giant : : ... : : To prepare things a bit while still waiting for my Openmoko Gadget, I've : pulled out 'dfu-util' from SVN as described in the Openmoko Wiki: : : http://wiki.openmoko.org/wiki/Dfu-util : : $ svn co http://svn.openmoko.org/trunk/src/host/dfu-util/ : $ cd dfu-util : $ ./autogen.sh : $ ./configure : $ make : : but it does not compile because of missing header files: : : main.c:29:22: error: byteswap.h: No such file or directory : main.c:30:20: error: endian.h: No such file or directory : : before digging into the details, is there already a port of 'dfu-util' : to FreeBSD? Looks like somebody didn't do their homework right: and are Linuxisms not protected by proper autoconf goo. Warner From que_deseja at hotmail.com Thu Sep 18 08:46:01 2008 From: que_deseja at hotmail.com (Desmond Chapman) Date: Thu Sep 18 08:46:07 2008 Subject: First try Message-ID: Is there a tutorial available for installing FreeBSD/ARM on a qemu vm? _________________________________________________________________ See how Windows Mobile brings your life together?at home, work, or on the go. http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/ From stas at FreeBSD.org Thu Sep 18 16:31:32 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Sep 18 16:31:37 2008 Subject: First try In-Reply-To: References: Message-ID: <20080918203129.f77587ff.stas@FreeBSD.org> On Thu, 18 Sep 2008 08:34:00 +0000 Desmond Chapman mentioned: > Is there a tutorial available for installing FreeBSD/ARM on a qemu vm? > FreeBSD currently doesn't support any of QEMU arm platforms, AFAIK. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20080918/8a39e452/attachment.pgp From jacques.fourie at gmail.com Thu Sep 18 17:11:26 2008 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Thu Sep 18 17:11:33 2008 Subject: First try In-Reply-To: <20080918203129.f77587ff.stas@FreeBSD.org> References: <20080918203129.f77587ff.stas@FreeBSD.org> Message-ID: On Thu, Sep 18, 2008 at 6:31 PM, Stanislav Sedov wrote: > On Thu, 18 Sep 2008 08:34:00 +0000 > Desmond Chapman mentioned: > >> Is there a tutorial available for installing FreeBSD/ARM on a qemu vm? >> > > FreeBSD currently doesn't support any of QEMU arm platforms, AFAIK. > > -- > Stanislav Sedov > ST4096-RIPE > QEMU can emulate the Gumstix platform but the last time I tried it QEMU exited with a "unsupported instruction" error. The same binary worked perfectly on real hardware. From tinderbox at freebsd.org Sun Sep 21 00:01:08 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:01:11 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20080921000104.F1B6173039@freebsd-current.sentex.ca> TB --- 2008-09-21 00:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-09-21 00:00:00 - cleaning the object tree TB --- 2008-09-21 00:00:26 - cvsupping the source tree TB --- 2008-09-21 00:00:26 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-09-21 00:00:33 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:00:33 - cd /src TB --- 2008-09-21 00:00:33 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:00:36 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:01:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:01:04 - ERROR: failed to build world TB --- 2008-09-21 00:01:04 - tinderbox aborted TB --- 17.95 user 4.66 system 64.59 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Sun Sep 21 00:20:33 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:20:47 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20080921002031.35C587303E@freebsd-current.sentex.ca> TB --- 2008-09-21 00:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-09-21 00:20:00 - cleaning the object tree TB --- 2008-09-21 00:20:02 - cvsupping the source tree TB --- 2008-09-21 00:20:02 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-09-21 00:20:08 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:20:08 - cd /src TB --- 2008-09-21 00:20:08 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:20:09 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:20:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:20:31 - ERROR: failed to build world TB --- 2008-09-21 00:20:31 - tinderbox aborted TB --- 17.30 user 2.68 system 30.83 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Sun Sep 21 00:40:35 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:40:57 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20080921004033.244A17303E@freebsd-current.sentex.ca> TB --- 2008-09-21 00:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-09-21 00:40:00 - cleaning the object tree TB --- 2008-09-21 00:40:03 - cvsupping the source tree TB --- 2008-09-21 00:40:03 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-09-21 00:40:09 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:40:09 - cd /src TB --- 2008-09-21 00:40:09 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:40:10 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:40:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:40:33 - ERROR: failed to build world TB --- 2008-09-21 00:40:33 - tinderbox aborted TB --- 17.38 user 2.56 system 32.65 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Sun Sep 21 23:59:10 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 23:59:15 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20080921235905.4E37B73039@freebsd-current.sentex.ca> TB --- 2008-09-21 23:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 23:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-09-21 23:00:00 - cleaning the object tree TB --- 2008-09-21 23:00:26 - cvsupping the source tree TB --- 2008-09-21 23:00:26 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-09-21 23:00:36 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 23:00:36 - cd /src TB --- 2008-09-21 23:00:36 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 23:00:38 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipresend/../../../sys -I/src/sbin/ipf/ipresend/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o /obj/arm/src/sbin/ipf/ipresend/../libipf/libipf.a -lkvm gzip -cn /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/ipresend.1 > ipresend.1.gz ===> sbin/ipfw (all) cc -O -pipe -Wno-pointer-sign -c /src/sbin/ipfw/ipfw2.c /src/sbin/ipfw/ipfw2.c: In function 'table_handler': /src/sbin/ipfw/ipfw2.c:5877: error: 'a' undeclared (first use in this function) /src/sbin/ipfw/ipfw2.c:5877: error: (Each undeclared identifier is reported only once /src/sbin/ipfw/ipfw2.c:5877: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ipfw. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 23:59:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 23:59:05 - ERROR: failed to build world TB --- 2008-09-21 23:59:05 - tinderbox aborted TB --- 2574.95 user 328.57 system 3544.58 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From imp at bsdimp.com Mon Sep 22 02:24:24 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Sep 22 02:24:28 2008 Subject: Code review request Message-ID: <20080921.202430.-893473872.imp@bsdimp.com> I did this a long time ago, but never committed it. I believe that this works. It uses the common bus space methods to implement the default arm bus space methods. Comments? Warner -------------- next part -------------- Index: sys/arm/include/bus.h =================================================================== --- sys/arm/include/bus.h (revision 183185) +++ sys/arm/include/bus.h (working copy) @@ -1,733 +1,86 @@ -/* $NetBSD: bus.h,v 1.11 2003/07/28 17:35:54 thorpej Exp $ */ - /*- - * Copyright (c) 1996, 1997, 1998, 2001 The NetBSD Foundation, Inc. - * All rights reserved. + * Copyright (c) 2008, by Cisco Systems, Inc. All rights reserved. * - * This code is derived from software contributed to The NetBSD Foundation - * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility, - * NASA Ames Research Center. - * * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * 3. All advertising materials mentioning features or use of this software - * must display the following acknowledgement: - * This product includes software developed by the NetBSD - * Foundation, Inc. and its contributors. - * 4. Neither the name of The NetBSD Foundation nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. + * modification, are permitted provided that the following conditions are met: * - * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS - * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED - * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR - * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS - * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR - * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF - * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS - * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN - * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) - * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE - * POSSIBILITY OF SUCH DAMAGE. - */ - -/*- - * Copyright (c) 1996 Charles M. Hannum. All rights reserved. - * Copyright (c) 1996 Christopher G. Demetriou. All rights reserved. + * a) Redistributions of source code must retain the above copyright notice, + * this list of conditions and the following disclaimer. * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * 3. All advertising materials mentioning features or use of this software - * must display the following acknowledgement: - * This product includes software developed by Christopher G. Demetriou - * for the NetBSD Project. - * 4. The name of the author may not be used to endorse or promote products - * derived from this software without specific prior written permission + * b) Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the distribution. * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * c) Neither the name of Cisco Systems, Inc. nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED + * OF THE POSSIBILITY OF SUCH DAMAGE. + * * $FreeBSD$ */ #ifndef _MACHINE_BUS_H_ #define _MACHINE_BUS_H_ +/* + * Arm uses the generic bus space indirection routines to implement its bus + * space. To setup, one must define bus_addr_t, bus_size_t, + * bus_space_tag_t, and bus_space_handle_t. bus_space_tag_t must be defined + * as + * typedef struct bus_space *bus_space_tag_t; + * for this sys/bs_ind.h to work correctly. + */ #include /* - * int bus_space_map (bus_space_tag_t t, bus_addr_t addr, - * bus_size_t size, int flags, bus_space_handle_t *bshp); - * - * Map a region of bus space. + * Define the bus spaces that we're using in the arm port. */ - #define BUS_SPACE_MAP_CACHEABLE 0x01 #define BUS_SPACE_MAP_LINEAR 0x02 #define BUS_SPACE_MAP_PREFETCHABLE 0x04 -struct bus_space { - /* cookie */ - void *bs_cookie; - - /* mapping/unmapping */ - int (*bs_map) (void *, bus_addr_t, bus_size_t, - int, bus_space_handle_t *); - void (*bs_unmap) (void *, bus_space_handle_t, bus_size_t); - int (*bs_subregion) (void *, bus_space_handle_t, - bus_size_t, bus_size_t, bus_space_handle_t *); - - /* allocation/deallocation */ - int (*bs_alloc) (void *, bus_addr_t, bus_addr_t, - bus_size_t, bus_size_t, bus_size_t, int, - bus_addr_t *, bus_space_handle_t *); - void (*bs_free) (void *, bus_space_handle_t, - bus_size_t); - - /* get kernel virtual address */ - /* barrier */ - void (*bs_barrier) (void *, bus_space_handle_t, - bus_size_t, bus_size_t, int); - - /* read (single) */ - u_int8_t (*bs_r_1) (void *, bus_space_handle_t, bus_size_t); - u_int16_t (*bs_r_2) (void *, bus_space_handle_t, bus_size_t); - u_int32_t (*bs_r_4) (void *, bus_space_handle_t, bus_size_t); - u_int64_t (*bs_r_8) (void *, bus_space_handle_t, bus_size_t); - - /* read multiple */ - void (*bs_rm_1) (void *, bus_space_handle_t, bus_size_t, - u_int8_t *, bus_size_t); - void (*bs_rm_2) (void *, bus_space_handle_t, bus_size_t, - u_int16_t *, bus_size_t); - void (*bs_rm_4) (void *, bus_space_handle_t, - bus_size_t, u_int32_t *, bus_size_t); - void (*bs_rm_8) (void *, bus_space_handle_t, - bus_size_t, u_int64_t *, bus_size_t); - - /* read region */ - void (*bs_rr_1) (void *, bus_space_handle_t, - bus_size_t, u_int8_t *, bus_size_t); - void (*bs_rr_2) (void *, bus_space_handle_t, - bus_size_t, u_int16_t *, bus_size_t); - void (*bs_rr_4) (void *, bus_space_handle_t, - bus_size_t, u_int32_t *, bus_size_t); - void (*bs_rr_8) (void *, bus_space_handle_t, - bus_size_t, u_int64_t *, bus_size_t); - - /* write (single) */ - void (*bs_w_1) (void *, bus_space_handle_t, - bus_size_t, u_int8_t); - void (*bs_w_2) (void *, bus_space_handle_t, - bus_size_t, u_int16_t); - void (*bs_w_4) (void *, bus_space_handle_t, - bus_size_t, u_int32_t); - void (*bs_w_8) (void *, bus_space_handle_t, - bus_size_t, u_int64_t); - - /* write multiple */ - void (*bs_wm_1) (void *, bus_space_handle_t, - bus_size_t, const u_int8_t *, bus_size_t); - void (*bs_wm_2) (void *, bus_space_handle_t, - bus_size_t, const u_int16_t *, bus_size_t); - void (*bs_wm_4) (void *, bus_space_handle_t, - bus_size_t, const u_int32_t *, bus_size_t); - void (*bs_wm_8) (void *, bus_space_handle_t, - bus_size_t, const u_int64_t *, bus_size_t); - - /* write region */ - void (*bs_wr_1) (void *, bus_space_handle_t, - bus_size_t, const u_int8_t *, bus_size_t); - void (*bs_wr_2) (void *, bus_space_handle_t, - bus_size_t, const u_int16_t *, bus_size_t); - void (*bs_wr_4) (void *, bus_space_handle_t, - bus_size_t, const u_int32_t *, bus_size_t); - void (*bs_wr_8) (void *, bus_space_handle_t, - bus_size_t, const u_int64_t *, bus_size_t); - - /* set multiple */ - void (*bs_sm_1) (void *, bus_space_handle_t, - bus_size_t, u_int8_t, bus_size_t); - void (*bs_sm_2) (void *, bus_space_handle_t, - bus_size_t, u_int16_t, bus_size_t); - void (*bs_sm_4) (void *, bus_space_handle_t, - bus_size_t, u_int32_t, bus_size_t); - void (*bs_sm_8) (void *, bus_space_handle_t, - bus_size_t, u_int64_t, bus_size_t); - - /* set region */ - void (*bs_sr_1) (void *, bus_space_handle_t, - bus_size_t, u_int8_t, bus_size_t); - void (*bs_sr_2) (void *, bus_space_handle_t, - bus_size_t, u_int16_t, bus_size_t); - void (*bs_sr_4) (void *, bus_space_handle_t, - bus_size_t, u_int32_t, bus_size_t); - void (*bs_sr_8) (void *, bus_space_handle_t, - bus_size_t, u_int64_t, bus_size_t); - - /* copy */ - void (*bs_c_1) (void *, bus_space_handle_t, bus_size_t, - bus_space_handle_t, bus_size_t, bus_size_t); - void (*bs_c_2) (void *, bus_space_handle_t, bus_size_t, - bus_space_handle_t, bus_size_t, bus_size_t); - void (*bs_c_4) (void *, bus_space_handle_t, bus_size_t, - bus_space_handle_t, bus_size_t, bus_size_t); - void (*bs_c_8) (void *, bus_space_handle_t, bus_size_t, - bus_space_handle_t, bus_size_t, bus_size_t); - - /* read stream (single) */ - u_int8_t (*bs_r_1_s) (void *, bus_space_handle_t, bus_size_t); - u_int16_t (*bs_r_2_s) (void *, bus_space_handle_t, bus_size_t); - u_int32_t (*bs_r_4_s) (void *, bus_space_handle_t, bus_size_t); - u_int64_t (*bs_r_8_s) (void *, bus_space_handle_t, bus_size_t); - - /* read multiple stream */ - void (*bs_rm_1_s) (void *, bus_space_handle_t, bus_size_t, - u_int8_t *, bus_size_t); - void (*bs_rm_2_s) (void *, bus_space_handle_t, bus_size_t, - u_int16_t *, bus_size_t); - void (*bs_rm_4_s) (void *, bus_space_handle_t, - bus_size_t, u_int32_t *, bus_size_t); - void (*bs_rm_8_s) (void *, bus_space_handle_t, - bus_size_t, u_int64_t *, bus_size_t); - - /* read region stream */ - void (*bs_rr_1_s) (void *, bus_space_handle_t, - bus_size_t, u_int8_t *, bus_size_t); - void (*bs_rr_2_s) (void *, bus_space_handle_t, - bus_size_t, u_int16_t *, bus_size_t); - void (*bs_rr_4_s) (void *, bus_space_handle_t, - bus_size_t, u_int32_t *, bus_size_t); - void (*bs_rr_8_s) (void *, bus_space_handle_t, - bus_size_t, u_int64_t *, bus_size_t); - - /* write stream (single) */ - void (*bs_w_1_s) (void *, bus_space_handle_t, - bus_size_t, u_int8_t); - void (*bs_w_2_s) (void *, bus_space_handle_t, - bus_size_t, u_int16_t); - void (*bs_w_4_s) (void *, bus_space_handle_t, - bus_size_t, u_int32_t); - void (*bs_w_8_s) (void *, bus_space_handle_t, - bus_size_t, u_int64_t); - - /* write multiple stream */ - void (*bs_wm_1_s) (void *, bus_space_handle_t, - bus_size_t, const u_int8_t *, bus_size_t); - void (*bs_wm_2_s) (void *, bus_space_handle_t, - bus_size_t, const u_int16_t *, bus_size_t); - void (*bs_wm_4_s) (void *, bus_space_handle_t, - bus_size_t, const u_int32_t *, bus_size_t); - void (*bs_wm_8_s) (void *, bus_space_handle_t, - bus_size_t, const u_int64_t *, bus_size_t); - - /* write region stream */ - void (*bs_wr_1_s) (void *, bus_space_handle_t, - bus_size_t, const u_int8_t *, bus_size_t); - void (*bs_wr_2_s) (void *, bus_space_handle_t, - bus_size_t, const u_int16_t *, bus_size_t); - void (*bs_wr_4_s) (void *, bus_space_handle_t, - bus_size_t, const u_int32_t *, bus_size_t); - void (*bs_wr_8_s) (void *, bus_space_handle_t, - bus_size_t, const u_int64_t *, bus_size_t); -}; - - /* - * Utility macros; INTERNAL USE ONLY. + * Bring in the generic indirection routines */ -#define __bs_c(a,b) __CONCAT(a,b) -#define __bs_opname(op,size) __bs_c(__bs_c(__bs_c(bs_,op),_),size) +#include -#define __bs_rs(sz, t, h, o) \ - (*(t)->__bs_opname(r,sz))((t)->bs_cookie, h, o) -#define __bs_ws(sz, t, h, o, v) \ - (*(t)->__bs_opname(w,sz))((t)->bs_cookie, h, o, v) -#define __bs_nonsingle(type, sz, t, h, o, a, c) \ - (*(t)->__bs_opname(type,sz))((t)->bs_cookie, h, o, a, c) -#define __bs_set(type, sz, t, h, o, v, c) \ - (*(t)->__bs_opname(type,sz))((t)->bs_cookie, h, o, v, c) -#define __bs_copy(sz, t, h1, o1, h2, o2, cnt) \ - (*(t)->__bs_opname(c,sz))((t)->bs_cookie, h1, o1, h2, o2, cnt) - -#define __bs_opname_s(op,size) __bs_c(__bs_c(__bs_c(__bs_c(bs_,op),_),size),_s) -#define __bs_rs_s(sz, t, h, o) \ - (*(t)->__bs_opname_s(r,sz))((t)->bs_cookie, h, o) -#define __bs_ws_s(sz, t, h, o, v) \ - (*(t)->__bs_opname_s(w,sz))((t)->bs_cookie, h, o, v) -#define __bs_nonsingle_s(type, sz, t, h, o, a, c) \ - (*(t)->__bs_opname_s(type,sz))((t)->bs_cookie, h, o, a, c) - - /* - * Mapping and unmapping operations. + * Define the largest bus_addr_t and bus_size_t respectively. Maybe these + * should be defined in terms of other constants, but in the ideal bus space + * model, the size of these types is defined to be large enough to hold the + * biggest address that is a natural size on the architecture. While the + * largest address or size might be a subset of that type. */ -#define bus_space_map(t, a, s, c, hp) \ - (*(t)->bs_map)((t)->bs_cookie, (a), (s), (c), (hp)) -#define bus_space_unmap(t, h, s) \ - (*(t)->bs_unmap)((t)->bs_cookie, (h), (s)) -#define bus_space_subregion(t, h, o, s, hp) \ - (*(t)->bs_subregion)((t)->bs_cookie, (h), (o), (s), (hp)) +#define BUS_SPACE_MAXADDR 0xFFFFFFFFul +#define BUS_SPACE_MAXSIZE 0xFFFFFFFFul - /* - * Allocation and deallocation operations. + * Maximum number of dma segments: no restrictions. */ -#define bus_space_alloc(t, rs, re, s, a, b, c, ap, hp) \ - (*(t)->bs_alloc)((t)->bs_cookie, (rs), (re), (s), (a), (b), \ - (c), (ap), (hp)) -#define bus_space_free(t, h, s) \ - (*(t)->bs_free)((t)->bs_cookie, (h), (s)) +#define BUS_SPACE_UNRESTRICTED (~0) /* - * Bus barrier operations. + * Different types of bus space barrier. Not sure if this should be here + * or if these are really common. */ -#define bus_space_barrier(t, h, o, l, f) \ - (*(t)->bs_barrier)((t)->bs_cookie, (h), (o), (l), (f)) - #define BUS_SPACE_BARRIER_READ 0x01 #define BUS_SPACE_BARRIER_WRITE 0x02 /* - * Bus read (single) operations. + * bus dma impelemenation, which is described in bus_dma(9) */ -#define bus_space_read_1(t, h, o) __bs_rs(1,(t),(h),(o)) -#define bus_space_read_2(t, h, o) __bs_rs(2,(t),(h),(o)) -#define bus_space_read_4(t, h, o) __bs_rs(4,(t),(h),(o)) -#define bus_space_read_8(t, h, o) __bs_rs(8,(t),(h),(o)) - -#define bus_space_read_stream_1(t, h, o) __bs_rs_s(1,(t), (h), (o)) -#define bus_space_read_stream_2(t, h, o) __bs_rs_s(2,(t), (h), (o)) -#define bus_space_read_stream_4(t, h, o) __bs_rs_s(4,(t), (h), (o)) -#define bus_space_read_stream_8(t, h, o) __bs_rs_s(8,8,(t),(h),(o)) - -/* - * Bus read multiple operations. - */ -#define bus_space_read_multi_1(t, h, o, a, c) \ - __bs_nonsingle(rm,1,(t),(h),(o),(a),(c)) -#define bus_space_read_multi_2(t, h, o, a, c) \ - __bs_nonsingle(rm,2,(t),(h),(o),(a),(c)) -#define bus_space_read_multi_4(t, h, o, a, c) \ - __bs_nonsingle(rm,4,(t),(h),(o),(a),(c)) -#define bus_space_read_multi_8(t, h, o, a, c) \ - __bs_nonsingle(rm,8,(t),(h),(o),(a),(c)) - -#define bus_space_read_multi_stream_1(t, h, o, a, c) \ - __bs_nonsingle_s(rm,1,(t),(h),(o),(a),(c)) -#define bus_space_read_multi_stream_2(t, h, o, a, c) \ - __bs_nonsingle_s(rm,2,(t),(h),(o),(a),(c)) -#define bus_space_read_multi_stream_4(t, h, o, a, c) \ - __bs_nonsingle_s(rm,4,(t),(h),(o),(a),(c)) -#define bus_space_read_multi_stream_8(t, h, o, a, c) \ - __bs_nonsingle_s(rm,8,(t),(h),(o),(a),(c)) - - -/* - * Bus read region operations. - */ -#define bus_space_read_region_1(t, h, o, a, c) \ - __bs_nonsingle(rr,1,(t),(h),(o),(a),(c)) -#define bus_space_read_region_2(t, h, o, a, c) \ - __bs_nonsingle(rr,2,(t),(h),(o),(a),(c)) -#define bus_space_read_region_4(t, h, o, a, c) \ - __bs_nonsingle(rr,4,(t),(h),(o),(a),(c)) -#define bus_space_read_region_8(t, h, o, a, c) \ - __bs_nonsingle(rr,8,(t),(h),(o),(a),(c)) - -#define bus_space_read_region_stream_1(t, h, o, a, c) \ - __bs_nonsingle_s(rr,1,(t),(h),(o),(a),(c)) -#define bus_space_read_region_stream_2(t, h, o, a, c) \ - __bs_nonsingle_s(rr,2,(t),(h),(o),(a),(c)) -#define bus_space_read_region_stream_4(t, h, o, a, c) \ - __bs_nonsingle_s(rr,4,(t),(h),(o),(a),(c)) -#define bus_space_read_region_stream_8(t, h, o, a, c) \ - __bs_nonsingle_s(rr,8,(t),(h),(o),(a),(c)) - - -/* - * Bus write (single) operations. - */ -#define bus_space_write_1(t, h, o, v) __bs_ws(1,(t),(h),(o),(v)) -#define bus_space_write_2(t, h, o, v) __bs_ws(2,(t),(h),(o),(v)) -#define bus_space_write_4(t, h, o, v) __bs_ws(4,(t),(h),(o),(v)) -#define bus_space_write_8(t, h, o, v) __bs_ws(8,(t),(h),(o),(v)) - -#define bus_space_write_stream_1(t, h, o, v) __bs_ws_s(1,(t),(h),(o),(v)) -#define bus_space_write_stream_2(t, h, o, v) __bs_ws_s(2,(t),(h),(o),(v)) -#define bus_space_write_stream_4(t, h, o, v) __bs_ws_s(4,(t),(h),(o),(v)) -#define bus_space_write_stream_8(t, h, o, v) __bs_ws_s(8,(t),(h),(o),(v)) - - -/* - * Bus write multiple operations. - */ -#define bus_space_write_multi_1(t, h, o, a, c) \ - __bs_nonsingle(wm,1,(t),(h),(o),(a),(c)) -#define bus_space_write_multi_2(t, h, o, a, c) \ - __bs_nonsingle(wm,2,(t),(h),(o),(a),(c)) -#define bus_space_write_multi_4(t, h, o, a, c) \ - __bs_nonsingle(wm,4,(t),(h),(o),(a),(c)) -#define bus_space_write_multi_8(t, h, o, a, c) \ - __bs_nonsingle(wm,8,(t),(h),(o),(a),(c)) - -#define bus_space_write_multi_stream_1(t, h, o, a, c) \ - __bs_nonsingle_s(wm,1,(t),(h),(o),(a),(c)) -#define bus_space_write_multi_stream_2(t, h, o, a, c) \ - __bs_nonsingle_s(wm,2,(t),(h),(o),(a),(c)) -#define bus_space_write_multi_stream_4(t, h, o, a, c) \ - __bs_nonsingle_s(wm,4,(t),(h),(o),(a),(c)) -#define bus_space_write_multi_stream_8(t, h, o, a, c) \ - __bs_nonsingle_s(wm,8,(t),(h),(o),(a),(c)) - - -/* - * Bus write region operations. - */ -#define bus_space_write_region_1(t, h, o, a, c) \ - __bs_nonsingle(wr,1,(t),(h),(o),(a),(c)) -#define bus_space_write_region_2(t, h, o, a, c) \ - __bs_nonsingle(wr,2,(t),(h),(o),(a),(c)) -#define bus_space_write_region_4(t, h, o, a, c) \ - __bs_nonsingle(wr,4,(t),(h),(o),(a),(c)) -#define bus_space_write_region_8(t, h, o, a, c) \ - __bs_nonsingle(wr,8,(t),(h),(o),(a),(c)) - -#define bus_space_write_region_stream_1(t, h, o, a, c) \ - __bs_nonsingle_s(wr,1,(t),(h),(o),(a),(c)) -#define bus_space_write_region_stream_2(t, h, o, a, c) \ - __bs_nonsingle_s(wr,2,(t),(h),(o),(a),(c)) -#define bus_space_write_region_stream_4(t, h, o, a, c) \ - __bs_nonsingle_s(wr,4,(t),(h),(o),(a),(c)) -#define bus_space_write_region_stream_8(t, h, o, a, c) \ - __bs_nonsingle_s(wr,8,(t),(h),(o),(a),(c)) - - -/* - * Set multiple operations. - */ -#define bus_space_set_multi_1(t, h, o, v, c) \ - __bs_set(sm,1,(t),(h),(o),(v),(c)) -#define bus_space_set_multi_2(t, h, o, v, c) \ - __bs_set(sm,2,(t),(h),(o),(v),(c)) -#define bus_space_set_multi_4(t, h, o, v, c) \ - __bs_set(sm,4,(t),(h),(o),(v),(c)) -#define bus_space_set_multi_8(t, h, o, v, c) \ - __bs_set(sm,8,(t),(h),(o),(v),(c)) - - -/* - * Set region operations. - */ -#define bus_space_set_region_1(t, h, o, v, c) \ - __bs_set(sr,1,(t),(h),(o),(v),(c)) -#define bus_space_set_region_2(t, h, o, v, c) \ - __bs_set(sr,2,(t),(h),(o),(v),(c)) -#define bus_space_set_region_4(t, h, o, v, c) \ - __bs_set(sr,4,(t),(h),(o),(v),(c)) -#define bus_space_set_region_8(t, h, o, v, c) \ - __bs_set(sr,8,(t),(h),(o),(v),(c)) - - -/* - * Copy operations. - */ -#define bus_space_copy_region_1(t, h1, o1, h2, o2, c) \ - __bs_copy(1, t, h1, o1, h2, o2, c) -#define bus_space_copy_region_2(t, h1, o1, h2, o2, c) \ - __bs_copy(2, t, h1, o1, h2, o2, c) -#define bus_space_copy_region_4(t, h1, o1, h2, o2, c) \ - __bs_copy(4, t, h1, o1, h2, o2, c) -#define bus_space_copy_region_8(t, h1, o1, h2, o2, c) \ - __bs_copy(8, t, h1, o1, h2, o2, c) - -/* - * Macros to provide prototypes for all the functions used in the - * bus_space structure - */ - -#define bs_map_proto(f) \ -int __bs_c(f,_bs_map) (void *t, bus_addr_t addr, \ - bus_size_t size, int cacheable, bus_space_handle_t *bshp); - -#define bs_unmap_proto(f) \ -void __bs_c(f,_bs_unmap) (void *t, bus_space_handle_t bsh, \ - bus_size_t size); - -#define bs_subregion_proto(f) \ -int __bs_c(f,_bs_subregion) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, bus_size_t size, \ - bus_space_handle_t *nbshp); - -#define bs_alloc_proto(f) \ -int __bs_c(f,_bs_alloc) (void *t, bus_addr_t rstart, \ - bus_addr_t rend, bus_size_t size, bus_size_t align, \ - bus_size_t boundary, int cacheable, bus_addr_t *addrp, \ - bus_space_handle_t *bshp); - -#define bs_free_proto(f) \ -void __bs_c(f,_bs_free) (void *t, bus_space_handle_t bsh, \ - bus_size_t size); - -#define bs_mmap_proto(f) \ -int __bs_c(f,_bs_mmap) (struct cdev *, vm_offset_t, vm_paddr_t *, int); - -#define bs_barrier_proto(f) \ -void __bs_c(f,_bs_barrier) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, bus_size_t len, int flags); - -#define bs_r_1_proto(f) \ -u_int8_t __bs_c(f,_bs_r_1) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset); - -#define bs_r_2_proto(f) \ -u_int16_t __bs_c(f,_bs_r_2) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset); - -#define bs_r_4_proto(f) \ -u_int32_t __bs_c(f,_bs_r_4) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset); - -#define bs_r_8_proto(f) \ -u_int64_t __bs_c(f,_bs_r_8) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset); - -#define bs_r_1_s_proto(f) \ -u_int8_t __bs_c(f,_bs_r_1_s) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset); - -#define bs_r_2_s_proto(f) \ -u_int16_t __bs_c(f,_bs_r_2_s) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset); - -#define bs_r_4_s_proto(f) \ -u_int32_t __bs_c(f,_bs_r_4_s) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset); - -#define bs_w_1_proto(f) \ -void __bs_c(f,_bs_w_1) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int8_t value); - -#define bs_w_2_proto(f) \ -void __bs_c(f,_bs_w_2) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int16_t value); - -#define bs_w_4_proto(f) \ -void __bs_c(f,_bs_w_4) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int32_t value); - -#define bs_w_8_proto(f) \ -void __bs_c(f,_bs_w_8) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int64_t value); - -#define bs_w_1_s_proto(f) \ -void __bs_c(f,_bs_w_1_s) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int8_t value); - -#define bs_w_2_s_proto(f) \ -void __bs_c(f,_bs_w_2_s) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int16_t value); - -#define bs_w_4_s_proto(f) \ -void __bs_c(f,_bs_w_4_s) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int32_t value); - -#define bs_rm_1_proto(f) \ -void __bs_c(f,_bs_rm_1) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int8_t *addr, bus_size_t count); - -#define bs_rm_2_proto(f) \ -void __bs_c(f,_bs_rm_2) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int16_t *addr, bus_size_t count); - -#define bs_rm_4_proto(f) \ -void __bs_c(f,_bs_rm_4) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int32_t *addr, bus_size_t count); - -#define bs_rm_8_proto(f) \ -void __bs_c(f,_bs_rm_8) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int64_t *addr, bus_size_t count); - -#define bs_wm_1_proto(f) \ -void __bs_c(f,_bs_wm_1) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, const u_int8_t *addr, bus_size_t count); - -#define bs_wm_2_proto(f) \ -void __bs_c(f,_bs_wm_2) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, const u_int16_t *addr, bus_size_t count); - -#define bs_wm_4_proto(f) \ -void __bs_c(f,_bs_wm_4) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, const u_int32_t *addr, bus_size_t count); - -#define bs_wm_8_proto(f) \ -void __bs_c(f,_bs_wm_8) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, const u_int64_t *addr, bus_size_t count); - -#define bs_rr_1_proto(f) \ -void __bs_c(f, _bs_rr_1) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int8_t *addr, bus_size_t count); - -#define bs_rr_2_proto(f) \ -void __bs_c(f, _bs_rr_2) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int16_t *addr, bus_size_t count); - -#define bs_rr_4_proto(f) \ -void __bs_c(f, _bs_rr_4) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int32_t *addr, bus_size_t count); - -#define bs_rr_8_proto(f) \ -void __bs_c(f, _bs_rr_8) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int64_t *addr, bus_size_t count); - -#define bs_wr_1_proto(f) \ -void __bs_c(f, _bs_wr_1) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, const u_int8_t *addr, bus_size_t count); - -#define bs_wr_2_proto(f) \ -void __bs_c(f, _bs_wr_2) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, const u_int16_t *addr, bus_size_t count); - -#define bs_wr_4_proto(f) \ -void __bs_c(f, _bs_wr_4) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, const u_int32_t *addr, bus_size_t count); - -#define bs_wr_8_proto(f) \ -void __bs_c(f, _bs_wr_8) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, const u_int64_t *addr, bus_size_t count); - -#define bs_sm_1_proto(f) \ -void __bs_c(f,_bs_sm_1) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int8_t value, bus_size_t count); - -#define bs_sm_2_proto(f) \ -void __bs_c(f,_bs_sm_2) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int16_t value, bus_size_t count); - -#define bs_sm_4_proto(f) \ -void __bs_c(f,_bs_sm_4) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int32_t value, bus_size_t count); - -#define bs_sm_8_proto(f) \ -void __bs_c(f,_bs_sm_8) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int64_t value, bus_size_t count); - -#define bs_sr_1_proto(f) \ -void __bs_c(f,_bs_sr_1) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int8_t value, bus_size_t count); - -#define bs_sr_2_proto(f) \ -void __bs_c(f,_bs_sr_2) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int16_t value, bus_size_t count); - -#define bs_sr_4_proto(f) \ -void __bs_c(f,_bs_sr_4) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int32_t value, bus_size_t count); - -#define bs_sr_8_proto(f) \ -void __bs_c(f,_bs_sr_8) (void *t, bus_space_handle_t bsh, \ - bus_size_t offset, u_int64_t value, bus_size_t count); - -#define bs_c_1_proto(f) \ -void __bs_c(f,_bs_c_1) (void *t, bus_space_handle_t bsh1, \ - bus_size_t offset1, bus_space_handle_t bsh2, \ - bus_size_t offset2, bus_size_t count); - -#define bs_c_2_proto(f) \ -void __bs_c(f,_bs_c_2) (void *t, bus_space_handle_t bsh1, \ - bus_size_t offset1, bus_space_handle_t bsh2, \ - bus_size_t offset2, bus_size_t count); - -#define bs_c_4_proto(f) \ -void __bs_c(f,_bs_c_4) (void *t, bus_space_handle_t bsh1, \ - bus_size_t offset1, bus_space_handle_t bsh2, \ - bus_size_t offset2, bus_size_t count); - -#define bs_c_8_proto(f) \ -void __bs_c(f,_bs_c_8) (void *t, bus_space_handle_t bsh1, \ - bus_size_t offset1, bus_space_handle_t bsh2, \ - bus_size_t offset2, bus_size_t count); - -#define bs_protos(f) \ -bs_map_proto(f); \ -bs_unmap_proto(f); \ -bs_subregion_proto(f); \ -bs_alloc_proto(f); \ -bs_free_proto(f); \ -bs_mmap_proto(f); \ -bs_barrier_proto(f); \ -bs_r_1_proto(f); \ -bs_r_2_proto(f); \ -bs_r_4_proto(f); \ -bs_r_8_proto(f); \ -bs_r_1_s_proto(f); \ -bs_r_2_s_proto(f); \ -bs_r_4_s_proto(f); \ -bs_w_1_proto(f); \ -bs_w_2_proto(f); \ -bs_w_4_proto(f); \ -bs_w_8_proto(f); \ -bs_w_1_s_proto(f); \ -bs_w_2_s_proto(f); \ -bs_w_4_s_proto(f); \ -bs_rm_1_proto(f); \ -bs_rm_2_proto(f); \ -bs_rm_4_proto(f); \ -bs_rm_8_proto(f); \ -bs_wm_1_proto(f); \ -bs_wm_2_proto(f); \ -bs_wm_4_proto(f); \ -bs_wm_8_proto(f); \ -bs_rr_1_proto(f); \ -bs_rr_2_proto(f); \ -bs_rr_4_proto(f); \ -bs_rr_8_proto(f); \ -bs_wr_1_proto(f); \ -bs_wr_2_proto(f); \ -bs_wr_4_proto(f); \ -bs_wr_8_proto(f); \ -bs_sm_1_proto(f); \ -bs_sm_2_proto(f); \ -bs_sm_4_proto(f); \ -bs_sm_8_proto(f); \ -bs_sr_1_proto(f); \ -bs_sr_2_proto(f); \ -bs_sr_4_proto(f); \ -bs_sr_8_proto(f); \ -bs_c_1_proto(f); \ -bs_c_2_proto(f); \ -bs_c_4_proto(f); \ -bs_c_8_proto(f); - -#define BUS_SPACE_ALIGNED_POINTER(p, t) ALIGNED_POINTER(p, t) - -#define BUS_SPACE_MAXADDR_24BIT 0xFFFFFF -#define BUS_SPACE_MAXADDR_32BIT 0xFFFFFFFF -#define BUS_SPACE_MAXADDR 0xFFFFFFFF -#define BUS_SPACE_MAXSIZE_24BIT 0xFFFFFF -#define BUS_SPACE_MAXSIZE_32BIT 0xFFFFFFFF -#define BUS_SPACE_MAXSIZE 0xFFFFFFFF - #include #endif /* _MACHINE_BUS_H_ */ From tinderbox at freebsd.org Mon Sep 22 04:18:56 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 22 04:19:00 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20080922041852.B6E7973039@freebsd-current.sentex.ca> TB --- 2008-09-22 03:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-22 03:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-09-22 03:20:00 - cleaning the object tree TB --- 2008-09-22 03:20:26 - cvsupping the source tree TB --- 2008-09-22 03:20:26 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-09-22 03:20:36 - building world (CFLAGS=-O -pipe) TB --- 2008-09-22 03:20:36 - cd /src TB --- 2008-09-22 03:20:36 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 22 03:20:38 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipresend/../../../sys -I/src/sbin/ipf/ipresend/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o /obj/arm/src/sbin/ipf/ipresend/../libipf/libipf.a -lkvm gzip -cn /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/ipresend.1 > ipresend.1.gz ===> sbin/ipfw (all) cc -O -pipe -Wno-pointer-sign -c /src/sbin/ipfw/ipfw2.c /src/sbin/ipfw/ipfw2.c: In function 'table_handler': /src/sbin/ipfw/ipfw2.c:5877: error: 'a' undeclared (first use in this function) /src/sbin/ipfw/ipfw2.c:5877: error: (Each undeclared identifier is reported only once /src/sbin/ipfw/ipfw2.c:5877: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ipfw. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-22 04:18:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-22 04:18:52 - ERROR: failed to build world TB --- 2008-09-22 04:18:52 - tinderbox aborted TB --- 2578.04 user 324.55 system 3531.68 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From imp at bsdimp.com Mon Sep 22 05:36:40 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Sep 22 05:36:44 2008 Subject: Code review request In-Reply-To: <1222061003.10402.4.camel@nsl> References: <20080921.202430.-893473872.imp@bsdimp.com> <1222061003.10402.4.camel@nsl> Message-ID: <20080921.233644.1649786512.imp@bsdimp.com> In message: <1222061003.10402.4.camel@nsl> Kevin Lo writes: : M. Warner Losh wrote: : > I did this a long time ago, but never committed it. I believe that : > this works. It uses the common bus space methods to implement the : > default arm bus space methods. : > : > Comments? : : You're missing the bs_ind.h header file and this patch doesn't apply : cleanly against -HEAD. Hmmm.... I'll try again. Sorry about that... Warner From kevlo at FreeBSD.org Mon Sep 22 05:49:06 2008 From: kevlo at FreeBSD.org (Kevin Lo) Date: Mon Sep 22 05:49:09 2008 Subject: Code review request In-Reply-To: <20080921.202430.-893473872.imp@bsdimp.com> References: <20080921.202430.-893473872.imp@bsdimp.com> Message-ID: <1222061003.10402.4.camel@nsl> M. Warner Losh wrote: > I did this a long time ago, but never committed it. I believe that > this works. It uses the common bus space methods to implement the > default arm bus space methods. > > Comments? You're missing the bs_ind.h header file and this patch doesn't apply cleanly against -HEAD. > Warner Kevin From raj at semihalf.com Wed Sep 24 12:25:31 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Wed Sep 24 12:25:37 2008 Subject: FreeBSD/arm support for Marvell chips -- please review Message-ID: <48DA31B3.5040906@semihalf.com> All, With the recent series of submits in P4's arm-devel branch, I have completed import of FreeBSD/arm support for three families of Marvell integrated systems-on-chip built on ARMv5TE-compliant core. Orion support has been around for a while already, and recently added were extensions for Kirkwood and Discovery support, new drivers for integrated peripherals and other improvements. I'd like to merge this with SVN within the coming weeks, so would like to ask everyone to review the code and let me know about any comments or notes: 1. CPU + SOC specific integrated peripherals http://p4web.freebsd.org/@md=d&cd=//depot/&c=jjG@//depot/projects/arm/src/sys/arm/mv/?ac=83 2. Other peripherals: http://p4web.freebsd.org/@md=d&cd=//depot/&c=jjG@//depot/projects/arm/src/sys/dev/mge/?ac=83 http://p4web.freebsd.org/@md=d&cd=//depot/&c=jjG@//depot/projects/arm/src/sys/dev/usb/ehci_mbus.c?ac=22 http://p4web.freebsd.org/@md=d&cd=//depot/&c=jjG@//depot/projects/arm/src/sys/dev/uart/uart_bus_mbus.c?ac=22 http://p4web.freebsd.org/@md=d&cd=//depot/&c=jjG@//depot/projects/arm/src/sys/dev/uart/uart_cpu_mv.c?ac=22 The code is synced with up-to-date CURRENT and has been successfully tested on the following chips: * 88F5182, 88F5281 * 88F6281 * MV78100 Supported functionality highlights: * EHCI USB 2.0 * Ethernet * GPIO * Interrupt controller * L1, L2 cache * Timers, watchdog, RTC * TWSI (I2C) * UART * Multiuser operation * Self-hosted kernel/world builds * NFS- or USB-mounted root filesystem For users reference I have put together an initial howto with examples and other details: http://wiki.freebsd.org/FreeBSDMarvell Rafal From jhein at timing.com Wed Sep 24 20:46:29 2008 From: jhein at timing.com (John Hein) Date: Wed Sep 24 20:46:35 2008 Subject: kernel panic: "Translation Fault" Message-ID: <18650.37992.131070.673817@gromit.timing.com> Has anyone ever seen this? ... vm_fault(0xc0c61a20, bf7dd000, 1, 0) -> 5 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc5a4cc90 FSR=00000005, FAR=bf7ddff4, spsr=20000013 r0 =bf7ddfb8, r1 =00000001, r2 =00001000, r3 =c02ed000 r4 =c02bb000, r5 =00000000, r6 =00000000, r7 =00001000 r8 =00000000, r9 =c02005f8, r10=00000001, r11=c5a4ccf8 r12=c5a4ccfc, ssp=c5a4ccdc, slr=c0179890, pc =c0179220 [thread pid 4149 tid 100095 ] Stopped at pmap_wb_page+0xc: ldr r4, [r0, #0x03c] This is a somewhat older codebase (FreeBSD 6.2-ish + patches) and may not have more recent vm fixes. Sorry for the vague report, but I'm just curious if this has been seen by anyone. From mav at FreeBSD.org Sat Sep 27 21:43:09 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Sep 27 21:43:15 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements Message-ID: <48DEA8E7.2080503@FreeBSD.org> Hi. I would like to present initial revision of my generic PCI SD Host Controller driver (sdhci). It support PCI devices with class 8 and subclass 5 according to SD Host Controller Specification. With some limitations it successfully works on my Acer TM6292 notebook with ENE CB714 card reader. Things that are working now: - PIO mode single and multiple block read and write, - 1 and 4 bits bus width support. In PIO mode with 4GB SD card on 30MHz 4bit bus I have reached about 3.5MB/s (limited by CPU) linear read and 7MB/s (limited by card) linear write. Small blocks read/write performance limited by card. Things that are not working yet: - DMA modes (code is written, but as my controller looks like has broken DMA I have no ability to debug it), - card insert/remove detection (need more thinking), you should reload mmc module to rescan cards, - SDHC and MMC cards (have no such cards now to debug that code), only standard capacity SD Memory cards up to 4GB size are supported now, - high speed (double rate) bus mode (need more thinking and DMA support). Also to get such results I have improved existing mmc and mmcsd drivers a bit. mmc driver got: - 4 bit bus width support, - write protection switch support, - cards with more then 2GB capacity support. mmcsd driver got: - multiple block read and write support, - cards with more then 2GB capacity support, - I/O error reporting, - write protection switch support. Latest patches against 8-CURRENT (should also fit 7-STABLE) may be found at: http://people.freebsd.org/~mav/sdhci/ I will be grateful for any feedbacks, comments and support. -- Alexander Motin From gonzo at bluezbox.com Sat Sep 27 21:52:34 2008 From: gonzo at bluezbox.com (Oleksandr Tymoshenko) Date: Sat Sep 27 21:52:41 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48DEA8E7.2080503@FreeBSD.org> References: <48DEA8E7.2080503@FreeBSD.org> Message-ID: <48DEA4EC.3030300@bluezbox.com> Alexander Motin wrote: > Hi. > > Latest patches against 8-CURRENT (should also fit 7-STABLE) may be found > at: > http://people.freebsd.org/~mav/sdhci/ Thanks! That's just what I was looking for about three weeks ago :) > > I will be grateful for any feedbacks, comments and support. 7.1 requires s/kproc/kthread/ but otherwise works fine: sdhci0: mem 0xff9fb800-0xff9fb8ff irq 9 at device 1.2 on pci2 sdhci0: 1 slot(s) allocated sdhci0: [ITHREAD] mmc0: on sdhci0 mmc0: SD card: 507379712 bytes mmcsd0: 483MB (read-only) at mmc0 mmc0: setting transfer rate to 30.000MHz mmc0: setting bus width to 4 bits GEOM_LABEL: Label for provider mmcsd0s1 is msdosfs/SD. From rpaulo at fnop.net Sat Sep 27 23:25:48 2008 From: rpaulo at fnop.net (Rui Paulo) Date: Sat Sep 27 23:25:55 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48DEA8E7.2080503@FreeBSD.org> References: <48DEA8E7.2080503@FreeBSD.org> Message-ID: <9D33158B-B28D-4D22-B3BF-A7CE376FCAD1@freebd.org> On 27 Sep 2008, at 22:43, Alexander Motin wrote: > Hi. > > I would like to present initial revision of my generic PCI SD Host > Controller driver (sdhci). It support PCI devices with class 8 and > subclass 5 according to SD Host Controller Specification. With some > limitations it successfully works on my Acer TM6292 notebook with > ENE CB714 card reader. > > Things that are working now: > - PIO mode single and multiple block read and write, > - 1 and 4 bits bus width support. > > In PIO mode with 4GB SD card on 30MHz 4bit bus I have reached about > 3.5MB/s (limited by CPU) linear read and 7MB/s (limited by card) > linear write. Small blocks read/write performance limited by card. > > Things that are not working yet: > - DMA modes (code is written, but as my controller looks like has > broken DMA I have no ability to debug it), > - card insert/remove detection (need more thinking), you should > reload mmc module to rescan cards, > - SDHC and MMC cards (have no such cards now to debug that code), > only standard capacity SD Memory cards up to 4GB size are supported > now, > - high speed (double rate) bus mode (need more thinking and DMA > support). > > Also to get such results I have improved existing mmc and mmcsd > drivers a bit. mmc driver got: > - 4 bit bus width support, > - write protection switch support, > - cards with more then 2GB capacity support. > mmcsd driver got: > - multiple block read and write support, > - cards with more then 2GB capacity support, > - I/O error reporting, > - write protection switch support. > > Latest patches against 8-CURRENT (should also fit 7-STABLE) may be > found at: > http://people.freebsd.org/~mav/sdhci/ > > I will be grateful for any feedbacks, comments and support. Well, here's my support: Great work! :-) -- Rui Paulo From unixmania at gmail.com Sun Sep 28 06:02:26 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Sun Sep 28 06:02:32 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48DEA4EC.3030300@bluezbox.com> References: <48DEA8E7.2080503@FreeBSD.org> <48DEA4EC.3030300@bluezbox.com> Message-ID: On Sat, Sep 27, 2008 at 6:26 PM, Oleksandr Tymoshenko wrote: > Alexander Motin wrote: >> >> Hi. > >> >> Latest patches against 8-CURRENT (should also fit 7-STABLE) may be found >> at: >> http://people.freebsd.org/~mav/sdhci/ > > Thanks! That's just what I was looking for about three weeks ago :) >> >> I will be grateful for any feedbacks, comments and support. > > 7.1 requires s/kproc/kthread/ but otherwise works fine: > > sdhci0: mem 0xff9fb800-0xff9fb8ff irq 9 at device 1.2 on > pci2 > sdhci0: 1 slot(s) allocated > sdhci0: [ITHREAD] > > mmc0: on sdhci0 > mmc0: SD card: 507379712 bytes > mmcsd0: 483MB (read-only) at mmc0 > mmc0: setting transfer rate to 30.000MHz > mmc0: setting bus width to 4 bits > GEOM_LABEL: Label for provider mmcsd0s1 is msdosfs/SD. It did not detect the hardware on my Compaq 6910p: none2@pci0:2:6:3: class=0x080500 card=0x30be103c chip=0x08221180 rev=0x20 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'R5C832, R5C843 SDA Standard Compliant SD Host Controller' class = base peripheral none3@pci0:2:6:4: class=0x088000 card=0x30be103c chip=0x08431180 rev=0x10 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh MMC Host Controller' class = base peripheral Suggestions are welcome. :-) -- cd /usr/ports/sysutils/life make clean From unixmania at gmail.com Sun Sep 28 06:12:28 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Sun Sep 28 06:12:45 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: References: <48DEA8E7.2080503@FreeBSD.org> <48DEA4EC.3030300@bluezbox.com> Message-ID: On Sun, Sep 28, 2008 at 2:35 AM, Carlos A. M. dos Santos wrote: > On Sat, Sep 27, 2008 at 6:26 PM, Oleksandr Tymoshenko > wrote: >> Alexander Motin wrote: >>> >>> Hi. >> >>> >>> Latest patches against 8-CURRENT (should also fit 7-STABLE) may be found >>> at: >>> http://people.freebsd.org/~mav/sdhci/ >> >> Thanks! That's just what I was looking for about three weeks ago :) >>> >>> I will be grateful for any feedbacks, comments and support. >> >> 7.1 requires s/kproc/kthread/ but otherwise works fine: >> >> sdhci0: mem 0xff9fb800-0xff9fb8ff irq 9 at device 1.2 on >> pci2 >> sdhci0: 1 slot(s) allocated >> sdhci0: [ITHREAD] >> >> mmc0: on sdhci0 >> mmc0: SD card: 507379712 bytes >> mmcsd0: 483MB (read-only) at mmc0 >> mmc0: setting transfer rate to 30.000MHz >> mmc0: setting bus width to 4 bits >> GEOM_LABEL: Label for provider mmcsd0s1 is msdosfs/SD. > > It did not detect the hardware on my Compaq 6910p: > > none2@pci0:2:6:3: class=0x080500 card=0x30be103c chip=0x08221180 > rev=0x20 hdr=0x00 > vendor = 'Ricoh Company, Ltd.' > device = 'R5C832, R5C843 SDA Standard Compliant SD Host Controller' > class = base peripheral > none3@pci0:2:6:4: class=0x088000 card=0x30be103c chip=0x08431180 > rev=0x10 hdr=0x00 > vendor = 'Ricoh Company, Ltd.' > device = 'unknown Ricoh MMC Host Controller' > class = base peripheral > > Suggestions are welcome. :-) Here goes a good suggestion: do not forget to load the module, you dumb ass! Now I got this: sdhci0: mem 0xe4103000-0xe41030ff irq 19 at device 6.3 on pci2 sdhci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xe4103000 sdhci0: 1 slot(s) allocated sdhci0: [MPSAFE] sdhci0: [ITHREAD] mmc0: on sdhci0 mmc0: Reset 0x6 never completed - 0x6. mmc0: ============== REGISTER DUMP ============== mmc0: Sys addr: 0x00000000 | Version: 0x00000400 mmc0: Blk size: 0x00000000 | Blk cnt: 0x00000000 mmc0: Argument: 0x00000000 | Trn mode: 0x00000000 mmc0: Present: 0x01f20000 | Host ctl: 0x00000000 mmc0: Power: 0x0000000f | Blk gap: 0x00000000 mmc0: Wake-up: 0x00000000 | Clock: 0x00008007 mmc0: Timeout: 0x00000000 | Int stat: 0x00000000 mmc0: Int enab: 0x00ff00fb | Sig enab: 0x00ff00fb mmc0: AC12 err: 0x00000000 | Slot int: 0x00000000 mmc0: Caps: 0x018021a1 | Max curr: 0x00000040 mmc0: =========================================== mmc0: Reset 0x6 never completed - 0x6. mmc0: ============== REGISTER DUMP ============== mmc0: Sys addr: 0x00000000 | Version: 0x00000400 mmc0: Blk size: 0x00000000 | Blk cnt: 0x00000000 mmc0: Argument: 0x00000000 | Trn mode: 0x00000000 mmc0: Present: 0x01f20000 | Host ctl: 0x00000000 mmc0: Power: 0x0000000f | Blk gap: 0x00000000 mmc0: Wake-up: 0x00000000 | Clock: 0x00008007 mmc0: Timeout: 0x00000000 | Int stat: 0x00000000 mmc0: Int enab: 0x00ff00fb | Sig enab: 0x00ff00fb mmc0: AC12 err: 0x00000000 | Slot int: 0x00000000 mmc0: Caps: 0x018021a1 | Max curr: 0x00000040 mmc0: =========================================== mmc0: setting transfer rate to 33.000MHz mmc0: Reset 0x6 never completed - 0x6. mmc0: ============== REGISTER DUMP ============== mmc0: Sys addr: 0x00000000 | Version: 0x00000400 mmc0: Blk size: 0x00000000 | Blk cnt: 0x00000000 mmc0: Argument: 0x00000000 | Trn mode: 0x00000000 mmc0: Present: 0x01f20000 | Host ctl: 0x00000000 mmc0: Power: 0x0000000f | Blk gap: 0x00000000 mmc0: Wake-up: 0x00000000 | Clock: 0x00000007 mmc0: Timeout: 0x00000000 | Int stat: 0x00000000 mmc0: Int enab: 0x00ff00fb | Sig enab: 0x00ff00fb mmc0: AC12 err: 0x00000000 | Slot int: 0x00000000 mmc0: Caps: 0x018021a1 | Max curr: 0x00000040 mmc0: =========================================== Much better. However, I got a system crash and reboot attempting to unload the module. -- cd /usr/ports/sysutils/life make clean From imp at bsdimp.com Sun Sep 28 09:30:45 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Sep 28 09:30:58 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48DEA8E7.2080503@FreeBSD.org> References: <48DEA8E7.2080503@FreeBSD.org> Message-ID: <20080928.032929.-1264103837.imp@bsdimp.com> In message: <48DEA8E7.2080503@FreeBSD.org> Alexander Motin writes: : Hi. : : I would like to present initial revision of my generic PCI SD Host : Controller driver (sdhci). It support PCI devices with class 8 and : subclass 5 according to SD Host Controller Specification. With some : limitations it successfully works on my Acer TM6292 notebook with ENE : CB714 card reader. : : Things that are working now: : - PIO mode single and multiple block read and write, : - 1 and 4 bits bus width support. : : In PIO mode with 4GB SD card on 30MHz 4bit bus I have reached about : 3.5MB/s (limited by CPU) linear read and 7MB/s (limited by card) linear : write. Small blocks read/write performance limited by card. : : Things that are not working yet: : - DMA modes (code is written, but as my controller looks like has : broken DMA I have no ability to debug it), : - card insert/remove detection (need more thinking), you should reload : mmc module to rescan cards, : - SDHC and MMC cards (have no such cards now to debug that code), only : standard capacity SD Memory cards up to 4GB size are supported now, : - high speed (double rate) bus mode (need more thinking and DMA support). : : Also to get such results I have improved existing mmc and mmcsd drivers : a bit. mmc driver got: : - 4 bit bus width support, : - write protection switch support, : - cards with more then 2GB capacity support. : mmcsd driver got: : - multiple block read and write support, : - cards with more then 2GB capacity support, : - I/O error reporting, : - write protection switch support. : : Latest patches against 8-CURRENT (should also fit 7-STABLE) may be found at: : http://people.freebsd.org/~mav/sdhci/ : : I will be grateful for any feedbacks, comments and support. I'll take a look at the driver and post a code review... Warner From admin at lissyara.su Sun Sep 28 11:01:32 2008 From: admin at lissyara.su (Alex Keda) Date: Sun Sep 28 11:01:44 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48DEA8E7.2080503@FreeBSD.org> References: <48DEA8E7.2080503@FreeBSD.org> Message-ID: <48DF5C9D.2000702@lissyara.su> Alexander Motin ?????: > Hi. > > I would like to present initial revision of my generic PCI SD Host > Controller driver (sdhci). It support PCI devices with class 8 and > subclass 5 according to SD Host Controller Specification. With some > limitations it successfully works on my Acer TM6292 notebook with ENE > CB714 card reader. > > Things that are working now: > - PIO mode single and multiple block read and write, > - 1 and 4 bits bus width support. > > In PIO mode with 4GB SD card on 30MHz 4bit bus I have reached about > 3.5MB/s (limited by CPU) linear read and 7MB/s (limited by card) linear > write. Small blocks read/write performance limited by card. > > Things that are not working yet: > - DMA modes (code is written, but as my controller looks like has > broken DMA I have no ability to debug it), > - card insert/remove detection (need more thinking), you should reload > mmc module to rescan cards, > - SDHC and MMC cards (have no such cards now to debug that code), only > standard capacity SD Memory cards up to 4GB size are supported now, > - high speed (double rate) bus mode (need more thinking and DMA support). > > Also to get such results I have improved existing mmc and mmcsd drivers > a bit. mmc driver got: > - 4 bit bus width support, > - write protection switch support, > - cards with more then 2GB capacity support. > mmcsd driver got: > - multiple block read and write support, > - cards with more then 2GB capacity support, > - I/O error reporting, > - write protection switch support. > > Latest patches against 8-CURRENT (should also fit 7-STABLE) may be found > at: > http://people.freebsd.org/~mav/sdhci/ > > I will be grateful for any feedbacks, comments and support. > Thanks! It work =) I have Acer Aspire 5101 but, when I attempt unload module - system hangs ========= messages ====== Sep 28 14:25:24 acer kernel: sdhci0: mem 0xd0210800-0xd02108ff irq 23 at device 4.2 on pci6 Sep 28 14:25:24 acer kernel: sdhci0: 1 slot(s) allocated Sep 28 14:25:24 acer kernel: sdhci0: [ITHREAD] Sep 28 14:25:24 acer kernel: mmc0: on sdhci0 Sep 28 14:25:24 acer kernel: mmc0: setting transfer rate to 33.000MHz Sep 28 14:25:24 acer kernel: sdhci1: at device 4.4 on pci6 Sep 28 14:25:24 acer kernel: sdhci1: 1 slot(s) allocated Sep 28 14:25:24 acer kernel: sdhci1: [ITHREAD] Sep 28 14:25:24 acer kernel: mmc1: on sdhci1 Sep 28 14:25:25 acer kernel: mmc1: SD card: 31129600 bytes Sep 28 14:25:25 acer kernel: mmcsd0: 29MB at mmc1 Sep 28 14:25:25 acer kernel: mmc1: setting transfer rate to 30.000MHz Sep 28 14:25:25 acer kernel: mmc1: setting bus width to 4 bits ========== pciconf -lv ============= cbb0@pci0:6:4:0: class=0x060700 card=0x009f1025 chip=0x14121524 rev=0x10 hdr=0x02 vendor = 'ENE Technology Inc' device = 'CB-712/714 CardBus Controller' class = bridge subclass = PCI-CardBus none1@pci0:6:4:1: class=0x050100 card=0x009f1025 chip=0x05301524 rev=0x01 hdr=0x00 vendor = 'ENE Technology Inc' device = 'CB-712/714/810 Memory Stick Card Reader' class = memory subclass = flash sdhci0@pci0:6:4:2: class=0x080501 card=0x009f1025 chip=0x05501524 rev=0x01 hdr=0x00 vendor = 'ENE Technology Inc' device = 'CB-712/714/810 Secure Digital Card Reader' class = base peripheral none2@pci0:6:4:3: class=0x050100 card=0x009f1025 chip=0x05201524 rev=0x01 hdr=0x00 vendor = 'ENE Technology Inc' device = 'PCI SmartMedia / xD Card Reader Controller' class = memory subclass = flash sdhci1@pci0:6:4:4: class=0x050100 card=0x009f1025 chip=0x05511524 rev=0x01 hdr=0x00 vendor = 'ENE Technology Inc' device = 'PCI SD/MMC Card Reader Controller' class = memory subclass = flash acer$ ============ uname -a =========== FreeBSD acer.lissyara.int.otradno.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Sep 27 16:35:08 MSD 2008 lissyara@acer.lissyara.int.otradno.ru:/usr/obj/usr/src/sys/color-console amd64 =========== kldstat ========== acer$ kldstat Id Refs Address Size Name 1 71 0xffffffff80100000 da1698 kernel (/boot/kernel/kernel) 2 2 0xffffffff80ea2000 759b8 sound.ko (/boot/kernel/sound.ko) 3 1 0xffffffff80f18000 21ae0 snd_hda.ko (/boot/kernel/snd_hda.ko) 4 1 0xffffffff80f3a000 2cf0 umodem.ko (/boot/kernel/umodem.ko) 5 1 0xffffffff80f3d000 6360 acpi_video.ko (/boot/kernel/acpi_video.ko) 6 1 0xffffffff80f44000 5538 atapicam.ko (/boot/kernel/atapicam.ko) 7 1 0xffffffff80f4a000 2f58 acpi_aiboost.ko (/boot/kernel/acpi_aiboost.ko) 8 1 0xffffffff80f4d000 3eb8 acpi_dock.ko (/boot/kernel/acpi_dock.ko) 9 1 0xffffffff80f51000 6e20 ng_bt3c.ko (/boot/kernel/ng_bt3c.ko) 10 5 0xffffffff80f58000 15bf8 netgraph.ko (/boot/kernel/netgraph.ko) 11 1 0xffffffff80f6e000 39660 ng_btsocket.ko (/boot/kernel/ng_btsocket.ko) 12 3 0xffffffff80fa8000 2da0 ng_bluetooth.ko (/boot/kernel/ng_bluetooth.ko) 13 1 0xffffffff80fab000 bec8 ng_ubt.ko (/boot/kernel/ng_ubt.ko) 14 1 0xffffffff80fb7000 2938 ubtbcmfw.ko (/boot/kernel/ubtbcmfw.ko) 15 1 0xffffffff80fba000 17890 ng_l2cap.ko (/boot/kernel/ng_l2cap.ko) 16 1 0xffffffff80fd2000 3fc8 iicbb.ko (/boot/kernel/iicbb.ko) 17 2 0xffffffff80fd6000 3f48 iicbus.ko (/boot/kernel/iicbus.ko) 19 1 0xffffffff80ff1000 14db0 tmpfs.ko (/boot/kernel/tmpfs.ko) 20 1 0xffffffff81222000 a48c ipfw.ko (/boot/kernel/ipfw.ko) 21 1 0xffffffff8122d000 b8ba fuse.ko (/usr/local/modules/fuse.ko) 22 1 0xffffffff81239000 3652 vkbd.ko (/boot/kernel/vkbd.ko) 23 1 0xffffffff8123d000 754 rtc.ko (/usr/local/modules/rtc.ko) 24 1 0xffffffff8123e000 1ab19 linux.ko (/boot/kernel/linux.ko) 25 1 0xffffffff81259000 24fd3 radeon.ko (/boot/kernel/radeon.ko) 26 1 0xffffffff8127e000 10341 drm.ko (/boot/kernel/drm.ko) 27 1 0xffffffff8128f000 2a02 mmc.ko (/boot/modules/mmc.ko) 28 1 0xffffffff81292000 b97 mmcsd.ko (/boot/modules/mmcsd.ko) 29 1 0xffffffff81293000 2a28 sdhci.ko (/boot/modules/sdhci.ko) From mav at FreeBSD.org Sun Sep 28 21:01:01 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Sep 28 21:01:19 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: References: <48DEA8E7.2080503@FreeBSD.org> <48DEA4EC.3030300@bluezbox.com> Message-ID: <48DFFE9A.9070302@FreeBSD.org> Carlos A. M. dos Santos wrote: > Here goes a good suggestion: do not forget to load the module, you > dumb ass! Now I got this: > > sdhci0: mem 0xe4103000-0xe41030ff irq 19 at device 6.3 on pci2 > sdhci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xe4103000 > sdhci0: 1 slot(s) allocated > sdhci0: [MPSAFE] > sdhci0: [ITHREAD] > mmc0: on sdhci0 > mmc0: Reset 0x6 never completed - 0x6. Looks like there is several version of this controller requiring special driver quirks. At least Linux driver includes several. I have implemented some, so you can try to play with them. > Much better. However, I got a system crash and reboot attempting to > unload the module. I have rewritten detach function. PS: Also I have implemented card insert/remove in a way specific for this device via mmc bus attach/detach. Not sure it is the best way for mmc subsystem generally, but it recommended by SD Host controller specification and works for now. -- Alexander Motin