From jhay at meraka.org.za Sun Oct 5 20:40:25 2008 From: jhay at meraka.org.za (John Hay) Date: Sun Oct 5 20:40:31 2008 Subject: boot2 for avila In-Reply-To: <48DEEB8D.8020201@errno.com> References: <48DEEB8D.8020201@errno.com> Message-ID: <20081005204022.GA58869@zibbi.meraka.csir.co.za> Hi Guys, I have put the latest code at http://people.freebsd.org/~jhay/ixp425-boot-20081005.tgz I have included most of Sam's stuff and also the patches I got from Andrew Thompson. I have tried to make it autodetect the partitioning schemes mostly used, so that we do not need to use compile options for that. It should now handle slices+bsdlabel+partions, slices-only and also bsdlabel+partitions (without slices). It should also handle the various ROOTDEVNAME options used: ufs:ad0s1a, ufs:ad0s1, ufs:ad0a and also ufs:ROOTDEVNAME if you have FIXUP_BOOT_DRV defined (which is the default). I think it is ready for commit. Anybody want to look at it or try it to make sure your stuff still works before I commit it? John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From imp at bsdimp.com Sun Oct 5 23:37:12 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Oct 5 23:37:18 2008 Subject: boot2 for avila In-Reply-To: <20081005204022.GA58869@zibbi.meraka.csir.co.za> References: <48DEEB8D.8020201@errno.com> <20081005204022.GA58869@zibbi.meraka.csir.co.za> Message-ID: <20081005.173544.-432815076.imp@bsdimp.com> In message: <20081005204022.GA58869@zibbi.meraka.csir.co.za> John Hay writes: : Hi Guys, : : I have put the latest code at : http://people.freebsd.org/~jhay/ixp425-boot-20081005.tgz : : I have included most of Sam's stuff and also the patches I got from : Andrew Thompson. I have tried to make it autodetect the partitioning : schemes mostly used, so that we do not need to use compile options : for that. It should now handle slices+bsdlabel+partions, slices-only : and also bsdlabel+partitions (without slices). : : It should also handle the various ROOTDEVNAME options used: ufs:ad0s1a, : ufs:ad0s1, ufs:ad0a and also ufs:ROOTDEVNAME if you have FIXUP_BOOT_DRV : defined (which is the default). : : I think it is ready for commit. Anybody want to look at it or try it : to make sure your stuff still works before I commit it? Since this doesn't change the at91/boot2 stuff at all, the stuff I care most about will still work. I'd like to merge these two files, since I didn't see anything in the diffs that can't be resolved between the two systems... I wouldn't block commits based on this, but these two files are very similar... Warner From zbeeble at gmail.com Mon Oct 6 05:57:23 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Mon Oct 6 05:57:29 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: <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> On Sat, Sep 27, 2008 at 5:43 PM, 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 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). Most 4G cards are SDHC that I've seen. The notes on this that I've read talk about the fact that you can have a 4G regular SD card but that many (most) devices don't support it because of the need for a larger FAT to support 4G. I have two laptops with these controllers, but I have only SDHC media (4 and 8 gig cards). From imp at bsdimp.com Mon Oct 6 07:01:22 2008 From: imp at bsdimp.com (Warner Losh) Date: Mon Oct 6 07:01:29 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> References: <48DEA8E7.2080503@FreeBSD.org> <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> Message-ID: <20081006.005828.104066981.imp@bsdimp.com> From: "Zaphod Beeblebrox" Subject: Re: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements Date: Mon, 6 Oct 2008 01:26:19 -0400 > On Sat, Sep 27, 2008 at 5:43 PM, 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 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). > > > Most 4G cards are SDHC that I've seen. The notes on this that I've read > talk about the fact that you can have a 4G regular SD card but that many > (most) devices don't support it because of the need for a larger FAT to > support 4G. s/many/a few/g. 4GB SD cards work fine in every device I've tried them in... > I have two laptops with these controllers, but I have only SDHC media (4 and > 8 gig cards). Yes. The SDHC isolation protocol and media decoding stuff isn't written yet. Warner From tom.hurst at clara.net Mon Oct 6 08:20:39 2008 From: tom.hurst at clara.net (Thomas Hurst) Date: Mon Oct 6 08:20:51 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: <20081006075707.GA76333@voi.aagh.net> * Alexander Motin (mav@FreeBSD.org) wrote: > 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. RELENG_7_0, Sony TX1XP: sdhci0: mem 0xb0107000-0xb01070ff,0xb0106c00-0xb0106cff,0xb0106800-0xb01068ff irq 21 at device 5.4 on pci6 sdhci0: 3 slot(s) allocated none2@pci0:6:5:3: class=0x018000 card=0x81e2104d chip=0x8033104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'PCIxx11/21 Integrated FlashMedia Controller' class = mass storage sdhci0@pci0:6:5:4: class=0x080500 card=0x00000000 chip=0x8034104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = '10981734 SDA Standard Compliant SD Host Controller' class = base peripheral This is an integrated SD and MemoryStick reader; sadly it doesn't actually attach any usable devices. -- Thomas 'Freaky' Hurst http://hur.st/ From mav at FreeBSD.org Mon Oct 6 09:13:20 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Oct 6 09:13:27 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081006075707.GA76333@voi.aagh.net> References: <48DEA8E7.2080503@FreeBSD.org> <20081006075707.GA76333@voi.aagh.net> Message-ID: <48E9D6AD.8010202@FreeBSD.org> Thomas Hurst wrote: > * Alexander Motin (mav@FreeBSD.org) wrote: > >> 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. > > RELENG_7_0, Sony TX1XP: > > sdhci0: mem > 0xb0107000-0xb01070ff,0xb0106c00-0xb0106cff,0xb0106800-0xb01068ff irq 21 > at device 5.4 on pci6 > sdhci0: 3 slot(s) allocated > > none2@pci0:6:5:3: class=0x018000 card=0x81e2104d chip=0x8033104c rev=0x00 hdr=0x00 > vendor = 'Texas Instruments (TI)' > device = 'PCIxx11/21 Integrated FlashMedia Controller' > class = mass storage > sdhci0@pci0:6:5:4: class=0x080500 card=0x00000000 chip=0x8034104c rev=0x00 hdr=0x00 > vendor = 'Texas Instruments (TI)' > device = '10981734 SDA Standard Compliant SD Host Controller' > class = base peripheral > > This is an integrated SD and MemoryStick reader; sadly it doesn't > actually attach any usable devices. At this moment driver creates mmc bus only on card insert and destroyes on remove. Have you tried to insert something there? Do you have any reaction on card insert? -- Alexander Motin From tom.hurst at clara.net Mon Oct 6 10:42:48 2008 From: tom.hurst at clara.net (Thomas Hurst) Date: Mon Oct 6 10:43:04 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48E9D6AD.8010202@FreeBSD.org> References: <48DEA8E7.2080503@FreeBSD.org> <20081006075707.GA76333@voi.aagh.net> <48E9D6AD.8010202@FreeBSD.org> Message-ID: <20081006104245.GA24462@voi.aagh.net> * Alexander Motin (mav@FreeBSD.org) wrote: > > This is an integrated SD and MemoryStick reader; sadly it doesn't > > actually attach any usable devices. > > At this moment driver creates mmc bus only on card insert and > destroyes on remove. Have you tried to insert something there? Do you > have any reaction on card insert? Yup, I've tried a 1GB and 2GB SD card and a 1GB and 64MB MS with two different adaptors. No combination of inserting, reloading mmc, or sdhci seems to make any usable device nodes. I note it doesn't appear to be allocating any IRQ's according to vmstat -i. Is it supposed to? -- Thomas 'Freaky' Hurst http://hur.st/ From mav at FreeBSD.org Mon Oct 6 10:50:11 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Oct 6 10:50:18 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081006104245.GA24462@voi.aagh.net> References: <48DEA8E7.2080503@FreeBSD.org> <20081006075707.GA76333@voi.aagh.net> <48E9D6AD.8010202@FreeBSD.org> <20081006104245.GA24462@voi.aagh.net> Message-ID: <48E9ED5F.1060102@FreeBSD.org> Thomas Hurst wrote: >>> This is an integrated SD and MemoryStick reader; sadly it doesn't >>> actually attach any usable devices. >> At this moment driver creates mmc bus only on card insert and >> destroyes on remove. Have you tried to insert something there? Do you >> have any reaction on card insert? > > Yup, I've tried a 1GB and 2GB SD card and a 1GB and 64MB MS with two > different adaptors. No combination of inserting, reloading mmc, or > sdhci seems to make any usable device nodes. > > I note it doesn't appear to be allocating any IRQ's according to vmstat > -i. Is it supposed to? SD host should provide one IRQ and 256 bytes memory range per each slot. -- Alexander Motin From ticso at cicely7.cicely.de Tue Oct 7 12:53:34 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Tue Oct 7 12:53:41 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081006.005828.104066981.imp@bsdimp.com> References: <48DEA8E7.2080503@FreeBSD.org> <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> <20081006.005828.104066981.imp@bsdimp.com> Message-ID: <20081007125320.GD25586@cicely7.cicely.de> On Mon, Oct 06, 2008 at 12:58:28AM -0600, Warner Losh wrote: > From: "Zaphod Beeblebrox" > Subject: Re: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements > Date: Mon, 6 Oct 2008 01:26:19 -0400 > > > On Sat, Sep 27, 2008 at 5:43 PM, 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 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). > > > > > > Most 4G cards are SDHC that I've seen. The notes on this that I've read > > talk about the fact that you can have a 4G regular SD card but that many > > (most) devices don't support it because of the need for a larger FAT to > > support 4G. > > s/many/a few/g. 4GB SD cards work fine in every device I've tried > them in... You are quite lucky then. 4G-SD are non standard and I have a few devices where they don't work with. Sadly I even own a USB reader, which is still being sold, that doen't work with 2G cards - it just truncates them at 1G - sigh. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From mav at FreeBSD.org Wed Oct 8 07:54:49 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Oct 8 07:55:00 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081008113848.c9b44354.webmaster@kibab.com> References: <48DEA8E7.2080503@FreeBSD.org> <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> <20081008113848.c9b44354.webmaster@kibab.com> Message-ID: <48EC6745.8020404@FreeBSD.org> Ilya Bakulin wrote: > I have another SD card, 2 Gb size, in my camera. It's from Kingston. It doesn't work: > > sdhci0-slot0: Card inserted > mmc0: on sdhci0 > sdhci0-slot0: Command error 1 (opcode 2 arg 0 flags 103 dlen 0 dflags 0) > mmc0: setting transfer rate to 50.000MHz > > ... and no new storage devices appear. Theoretically it may be an SDHC card. They are not responding to incompatible host with alike symptoms. I have already implemented MMC and SDHC support and going to publish it soon. -- Alexander Motin From webmaster at kibab.com Wed Oct 8 08:58:24 2008 From: webmaster at kibab.com (Ilya Bakulin) Date: Wed Oct 8 08:58:30 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48EC6745.8020404@FreeBSD.org> References: <48DEA8E7.2080503@FreeBSD.org> <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> <20081008113848.c9b44354.webmaster@kibab.com> <48EC6745.8020404@FreeBSD.org> Message-ID: <20081008125820.64e72352.webmaster@kibab.com> On Wed, 08 Oct 2008 10:54:45 +0300 Alexander Motin wrote: > Theoretically it may be an SDHC card. They are not responding to > incompatible host with alike symptoms. I have already implemented MMC > and SDHC support and going to publish it soon. > > -- > Alexander Motin It's not SDHC, because none of my home card readers understand SDHC, and this card can be read in all of them. Under Windows (installed on the same laptop) this card can be read. If you need any further information about this card - just say what you need :-) I also have micro SDHC card (not mine), it responds exactly as that 2 Gb SD... But it can't be read in all my home equipment either :) -- Ilya Bakulin -------------- 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/20081008/87855a4d/attachment.pgp From webmaster at kibab.com Wed Oct 8 16:58:51 2008 From: webmaster at kibab.com (Ilya Bakulin) Date: Wed Oct 8 16:59:05 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> References: <48DEA8E7.2080503@FreeBSD.org> <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> Message-ID: <20081008113848.c9b44354.webmaster@kibab.com> On Mon, 6 Oct 2008 01:26:19 -0400 "Zaphod Beeblebrox" wrote: > Most 4G cards are SDHC that I've seen. The notes on this that I've read > talk about the fact that you can have a 4G regular SD card but that many > (most) devices don't support it because of the need for a larger FAT to > support 4G. > > I have two laptops with these controllers, but I have only SDHC media (4 and > 8 gig cards). I have 4G SD card (not SDHC), this driver works perfectly with it. Card is Transcend 4Gb 150x. Output from dmesg: sdhci0-slot0: Card inserted mmc0: on sdhci0 mmcsd0: 3926MB at mmc0 mmc0: setting transfer rate to 30.000MHz mmc0: setting bus width to 4 bits GEOM_LABEL: Label for provider mmcsd0 is msdosfs/WM_ILYA. I've been able to copy large file (diablo jdk 1.6) to and from this card, with no file corruption. I have another SD card, 2 Gb size, in my camera. It's from Kingston. It doesn't work: sdhci0-slot0: Card inserted mmc0: on sdhci0 sdhci0-slot0: Command error 1 (opcode 2 arg 0 flags 103 dlen 0 dflags 0) mmc0: setting transfer rate to 50.000MHz ... and no new storage devices appear. -- Ilya Bakulin -------------- 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/20081008/9558c7f5/attachment.pgp From raj at semihalf.com Fri Oct 10 09:46:44 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Fri Oct 10 09:46:51 2008 Subject: FreeBSD/arm support for Marvell chips -- please review In-Reply-To: <48DA31B3.5040906@semihalf.com> References: <48DA31B3.5040906@semihalf.com> Message-ID: <48EF2481.2010307@semihalf.com> Rafal Jaworowski wrote: > 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: I haven't received much feedback, are people still reviewing this? Rafal From stas at FreeBSD.org Fri Oct 10 09:56:53 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Oct 10 09:57:00 2008 Subject: FreeBSD/arm support for Marvell chips -- please review In-Reply-To: <48EF2481.2010307@semihalf.com> References: <48DA31B3.5040906@semihalf.com> <48EF2481.2010307@semihalf.com> Message-ID: <20081010135642.9e4b3449.stas@FreeBSD.org> On Fri, 10 Oct 2008 11:46:41 +0200 Rafal Jaworowski mentioned: > > I haven't received much feedback, are people still reviewing this? > Yeah, but there're still nothing to say except the code is great:-). Though, I still have some parts to look into. -- 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/20081010/42b47c2f/attachment.pgp From raj at semihalf.com Fri Oct 10 16:27:29 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Fri Oct 10 16:27:35 2008 Subject: FreeBSD/arm support for Marvell chips -- please review In-Reply-To: References: <48DA31B3.5040906@semihalf.com> <48EF2481.2010307@semihalf.com> Message-ID: <48EF826E.2050005@semihalf.com> Marcel Moolenaar wrote: > Just my $0.02: > > I personally don't like the deep nesting of directories, > but other than that: it looks and works great. Yea, this dirs hierarchy is best what we could come up with given multiple SOCs, cores, and integrated peripherals in play, sharing the functionality/code in some N:M fashion depending on revisions :-) I'm all for making it more clever, if you see a way. > I have some tweaks to add later. For example: > FPA support on little endian ARM (FPA has the words in > big-endian, irrespective of the byte order). We have > 4 places where we define the IEEE representation and > where we need to account for this. Sure, all improvements and extension more than welcome. Rafal From xcllnt at mac.com Fri Oct 10 16:49:35 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Oct 10 16:49:42 2008 Subject: FreeBSD/arm support for Marvell chips -- please review In-Reply-To: <48EF2481.2010307@semihalf.com> References: <48DA31B3.5040906@semihalf.com> <48EF2481.2010307@semihalf.com> Message-ID: On Oct 10, 2008, at 2:46 AM, Rafal Jaworowski wrote: > Rafal Jaworowski wrote: >> 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: > > I haven't received much feedback, are people still reviewing this? Just my $0.02: I personally don't like the deep nesting of directories, but other than that: it looks and works great. I have some tweaks to add later. For example: FPA support on little endian ARM (FPA has the words in big-endian, irrespective of the byte order). We have 4 places where we define the IEEE representation and where we need to account for this. FYI, -- Marcel Moolenaar xcllnt@mac.com From imp at bsdimp.com Fri Oct 10 17:13:22 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Oct 10 17:13:28 2008 Subject: FreeBSD/arm support for Marvell chips -- please review In-Reply-To: References: <48DA31B3.5040906@semihalf.com> <48EF2481.2010307@semihalf.com> Message-ID: <20081010.111120.-1704377131.imp@bsdimp.com> In message: Marcel Moolenaar writes: : : On Oct 10, 2008, at 2:46 AM, Rafal Jaworowski wrote: : : > Rafal Jaworowski wrote: : >> 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: : > : > I haven't received much feedback, are people still reviewing this? : : Just my $0.02: : : I personally don't like the deep nesting of directories, : but other than that: it looks and works great. I don't have a problem with the deep nesting of these directories. It seems a good balance. The mips32/ extra layer in the mips port, however, was just gratuitous. The xscale stuff isn't too bad either, but sometimes feels a little deep. Each time I've looked at it, however, I can't come up with anything better... : I have some tweaks to add later. For example: : FPA support on little endian ARM (FPA has the words in : big-endian, irrespective of the byte order). We have : 4 places where we define the IEEE representation and : where we need to account for this. FPA? : FYI, : : -- : Marcel Moolenaar : xcllnt@mac.com : : : : _______________________________________________ : freebsd-arm@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-arm : To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" : : From xcllnt at mac.com Fri Oct 10 17:39:18 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Oct 10 17:39:24 2008 Subject: FreeBSD/arm support for Marvell chips -- please review In-Reply-To: <20081010.111120.-1704377131.imp@bsdimp.com> References: <48DA31B3.5040906@semihalf.com> <48EF2481.2010307@semihalf.com> <20081010.111120.-1704377131.imp@bsdimp.com> Message-ID: On Oct 10, 2008, at 10:11 AM, M. Warner Losh wrote: > : I have some tweaks to add later. For example: > : FPA support on little endian ARM (FPA has the words in > : big-endian, irrespective of the byte order). We have > : 4 places where we define the IEEE representation and > : where we need to account for this. > > FPA? The original FP format used by some ARM processors. Obsoleted by VFP AFAICT. VFP is like FPA, except that VFP has the words of a double in the native byte order. FPA always has the words in big-endian order. -- Marcel Moolenaar xcllnt@mac.com From sniperpr at gmail.com Sat Oct 11 13:22:13 2008 From: sniperpr at gmail.com (linux_pro) Date: Sat Oct 11 13:22:20 2008 Subject: freebsd-arm Digest, Vol 134, Issue 5 In-Reply-To: <20081011120012.6549D10656BE@hub.freebsd.org> References: <20081011120012.6549D10656BE@hub.freebsd.org> Message-ID: <82f887e20810110554k7032a368hbc42f9bab73c923f@mail.gmail.com> Hi, :) i have a mss ii? mss ii is arm, ARMv5TE MSS II have a SATA . i want install pfsense in my mssii. 2008/10/11, freebsd-arm-request@freebsd.org : > Send freebsd-arm mailing list submissions to > freebsd-arm@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > or, via email, send a message with subject or body 'help' to > freebsd-arm-request@freebsd.org > > You can reach the person managing the list at > freebsd-arm-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-arm digest..." > > > Today's Topics: > > 1. Re: FreeBSD/arm support for Marvell chips -- please review > (Rafal Jaworowski) > 2. Re: FreeBSD/arm support for Marvell chips -- please review > (Marcel Moolenaar) > 3. Re: FreeBSD/arm support for Marvell chips -- please review > (M. Warner Losh) > 4. Re: FreeBSD/arm support for Marvell chips -- please review > (Marcel Moolenaar) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 10 Oct 2008 18:27:26 +0200 > From: Rafal Jaworowski > Subject: Re: FreeBSD/arm support for Marvell chips -- please review > To: Marcel Moolenaar > Cc: freebsd-arm@freebsd.org > Message-ID: <48EF826E.2050005@semihalf.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Marcel Moolenaar wrote: >> Just my $0.02: >> >> I personally don't like the deep nesting of directories, >> but other than that: it looks and works great. > > Yea, this dirs hierarchy is best what we could come up with given multiple > SOCs, cores, and integrated peripherals in play, sharing the > functionality/code in some N:M fashion depending on revisions :-) I'm all > for > making it more clever, if you see a way. > >> I have some tweaks to add later. For example: >> FPA support on little endian ARM (FPA has the words in >> big-endian, irrespective of the byte order). We have >> 4 places where we define the IEEE representation and >> where we need to account for this. > > Sure, all improvements and extension more than welcome. > > Rafal > > > ------------------------------ > > Message: 2 > Date: Fri, 10 Oct 2008 08:49:21 -0700 > From: Marcel Moolenaar > Subject: Re: FreeBSD/arm support for Marvell chips -- please review > To: Rafal Jaworowski > Cc: freebsd-arm@freebsd.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Oct 10, 2008, at 2:46 AM, Rafal Jaworowski wrote: > >> Rafal Jaworowski wrote: >>> 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: >> >> I haven't received much feedback, are people still reviewing this? > > Just my $0.02: > > I personally don't like the deep nesting of directories, > but other than that: it looks and works great. > > I have some tweaks to add later. For example: > FPA support on little endian ARM (FPA has the words in > big-endian, irrespective of the byte order). We have > 4 places where we define the IEEE representation and > where we need to account for this. > > FYI, > > -- > Marcel Moolenaar > xcllnt@mac.com > > > > > > ------------------------------ > > Message: 3 > Date: Fri, 10 Oct 2008 11:11:20 -0600 (MDT) > From: "M. Warner Losh" > Subject: Re: FreeBSD/arm support for Marvell chips -- please review > To: xcllnt@mac.com > Cc: freebsd-arm@freebsd.org > Message-ID: <20081010.111120.-1704377131.imp@bsdimp.com> > Content-Type: Text/Plain; charset=us-ascii > > In message: > Marcel Moolenaar writes: > : > : On Oct 10, 2008, at 2:46 AM, Rafal Jaworowski wrote: > : > : > Rafal Jaworowski wrote: > : >> 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: > : > > : > I haven't received much feedback, are people still reviewing this? > : > : Just my $0.02: > : > : I personally don't like the deep nesting of directories, > : but other than that: it looks and works great. > > I don't have a problem with the deep nesting of these directories. It > seems a good balance. The mips32/ extra layer in the mips port, > however, was just gratuitous. The xscale stuff isn't too bad either, > but sometimes feels a little deep. Each time I've looked at it, > however, I can't come up with anything better... > > : I have some tweaks to add later. For example: > : FPA support on little endian ARM (FPA has the words in > : big-endian, irrespective of the byte order). We have > : 4 places where we define the IEEE representation and > : where we need to account for this. > > FPA? > > > : FYI, > : > : -- > : Marcel Moolenaar > : xcllnt@mac.com > : > : > : > : _______________________________________________ > : freebsd-arm@freebsd.org mailing list > : http://lists.freebsd.org/mailman/listinfo/freebsd-arm > : To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > : > : > > > ------------------------------ > > Message: 4 > Date: Fri, 10 Oct 2008 10:39:16 -0700 > From: Marcel Moolenaar > Subject: Re: FreeBSD/arm support for Marvell chips -- please review > To: "M. Warner Losh" > Cc: freebsd-arm@freebsd.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed > > > On Oct 10, 2008, at 10:11 AM, M. Warner Losh wrote: > >> : I have some tweaks to add later. For example: >> : FPA support on little endian ARM (FPA has the words in >> : big-endian, irrespective of the byte order). We have >> : 4 places where we define the IEEE representation and >> : where we need to account for this. >> >> FPA? > > The original FP format used by some ARM processors. > Obsoleted by VFP AFAICT. VFP is like FPA, except > that VFP has the words of a double in the native > byte order. FPA always has the words in big-endian > order. > > -- > Marcel Moolenaar > xcllnt@mac.com > > > > > > ------------------------------ > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > End of freebsd-arm Digest, Vol 134, Issue 5 > ******************************************* > -- for the linux From mav at FreeBSD.org Sat Oct 11 20:46:03 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Oct 11 20:46:10 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: <48F11087.20403@FreeBSD.org> Alexander Motin wrote: > 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. > > Latest patches against 8-CURRENT (mostly fit 7-STABLE) may be found at: > http://people.freebsd.org/~mav/sdhci/ For those who are not tracking actively, I would like to report that most of original driver's child illnesses are now healed. Driver now supports both PIO and DMA modes. Because of some special tunings DMA works fine even on almost broken ENE chips. I am reaching 15MB/s transfer (maximum for my controller's bus) with only about 1% of CPU load. Implemented 4 bits bus width and high speed timing modes support for high data rates up to 52MHz. Cards hot insertion/removing is now working. Together with in-tree mmc/mmcsd drivers improvements most of card types (SD, SDHC, standard and high capacity MMC) are now supported. -- Alexander Motin From webmaster at kibab.com Sun Oct 12 13:12:14 2008 From: webmaster at kibab.com (Ilya Bakulin) Date: Sun Oct 12 13:12:21 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081008113848.c9b44354.webmaster@kibab.com> References: <48DEA8E7.2080503@FreeBSD.org> <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> <20081008113848.c9b44354.webmaster@kibab.com> Message-ID: <20081012171201.da4da754.webmaster@kibab.com> Skipped content of type multipart/mixed-------------- 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/20081012/a8eca561/attachment.pgp From imp at bsdimp.com Mon Oct 13 17:04:01 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Oct 13 17:04:14 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081012171201.da4da754.webmaster@kibab.com> References: <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> <20081008113848.c9b44354.webmaster@kibab.com> <20081012171201.da4da754.webmaster@kibab.com> Message-ID: <20081013.110310.-1622595361.imp@bsdimp.com> In message: <20081012171201.da4da754.webmaster@kibab.com> Ilya Bakulin writes: : On Wed, 8 Oct 2008 11:38:48 +0400 : Ilya Bakulin wrote: : : > I have another SD card, 2 Gb size, in my camera. It's from Kingston. It doesn't work: : > : > sdhci0-slot0: Card inserted : > mmc0: on sdhci0 : > sdhci0-slot0: Command error 1 (opcode 2 arg 0 flags 103 dlen 0 dflags 0) : > mmc0: setting transfer rate to 50.000MHz : > : > ... and no new storage devices appear. : : Problem was solved by increasing the number of answer read attempts in mmc_send_app_op_cond(). With attached patch (against latest driver version) card is recognized properly on ~ 190th attempt (while in original driver there are only 100 attempts). : : Output from dmesg now: : sdhci0-slot0: Card inserted : mmc0: on sdhci0 : sdhci0-slot0: Command error 1 (opcode 8 arg 426 flags 101 dlen 0 dflags 0) : mmc_send_app_ocond(): cmd completed in 0 iter : sdhci0-slot0: Command error 1 (opcode 8 arg 426 flags 101 dlen 0 dflags 0) : mmc_send_app_ocond(): cmd completed in 195 iter : mmcsd0: 1964MB at mmc0 50MHz/4bit : GEOM_LABEL: Label for provider mmcsd0s1 is msdosfs/KODAK. : : Furthermore, non-mine SDHC card is now also recognized in this cardreader (it doesn't even under Windows). In this case, it takes about 400 attempts to read answer. I think I bumped the number of iterations to 100 when I found that 10 wasn't enough. 25 different cards worked just fine, but I got use of a 16MB SD card at BSDcan that needed like 65. Bumping it from 100 to 1000, however, makes the timeout go from 1s to 10s. That opens up window for insertion races, but that's the only downside I see... Of course, we want to fix those races, but this may expose them a little more.. I can't believe that you had a card that took 4s to become active! Can you confirm the elapsed time is really 4s for that card? Otherwise, this may be pointing out a bug in another area of the code... Warner From vibarus at googlemail.com Tue Oct 14 01:39:08 2008 From: vibarus at googlemail.com (Vincent Barus) Date: Tue Oct 14 01:39:15 2008 Subject: FreeBSD/arm support for Marvell chips -- please review In-Reply-To: <48DA31B3.5040906@semihalf.com> References: <48DA31B3.5040906@semihalf.com> Message-ID: Hi, nice progress. Maybe someday there's a way to get a stripped down FreeBSD working on a d-link dns-323 (http://wiki.dns323.info/ ) ? It's a 88F5181 CPU. Regards, Vincent On Wed, Sep 24, 2008 at 2:25 PM, Rafal Jaworowski wrote: > 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 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From raj at semihalf.com Tue Oct 14 12:15:49 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Tue Oct 14 12:15:54 2008 Subject: FreeBSD/arm support for Marvell chips -- please review In-Reply-To: References: <48DA31B3.5040906@semihalf.com> Message-ID: <48F48D71.4030008@semihalf.com> Vincent Barus wrote: > Hi, > nice progress. Maybe someday there's a way to get a stripped down > FreeBSD working on a d-link dns-323 (http://wiki.dns323.info/ ) ? > It's a 88F5181 CPU. The port is reported to work on 88F5181 (kevlo@ had his LinkstationPro running), so the device you mention should only require some configuration tweaks, if anything. Rafal From raj at semihalf.com Tue Oct 14 14:40:32 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Tue Oct 14 14:40:38 2008 Subject: FreeBSD/arm for Marvell chips in the tree Message-ID: <48F4AF5C.9000205@semihalf.com> All, I have finished integration of FreeBSD/arm support for Marvell systems-on-chip into the SVN repository. There are still items to improve, and new drivers (PCIE, PCI) and extensions (minidumps, gdbserver) will be introduced soon, but generally the port is in quite decent state already, so enjoy! This would not be possible without all great work of the following people at Semihalf: Grzegorz Bernacki Rafal Czubak Michal Hajduk Bartlomiej Sieka Jan Sieka Piotr Ziecik Special thanks to Maen Suleiman of Marvell for help and assistance. Rafal From imp at bsdimp.com Tue Oct 14 14:53:05 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Oct 14 14:53:12 2008 Subject: FreeBSD/arm support for Marvell chips -- please review In-Reply-To: <48F48D71.4030008@semihalf.com> References: <48DA31B3.5040906@semihalf.com> <48F48D71.4030008@semihalf.com> Message-ID: <20081014.085149.-857170835.imp@bsdimp.com> In message: <48F48D71.4030008@semihalf.com> Rafal Jaworowski writes: : Vincent Barus wrote: : > Hi, : > nice progress. Maybe someday there's a way to get a stripped down : > FreeBSD working on a d-link dns-323 (http://wiki.dns323.info/ ) ? : > It's a 88F5181 CPU. : : The port is reported to work on 88F5181 (kevlo@ had his LinkstationPro : running), so the device you mention should only require some configuration : tweaks, if anything. I have plans on doing a DIR-615 too once things are in the tree... Warner From henning.petersen at t-online.de Tue Oct 14 16:00:07 2008 From: henning.petersen at t-online.de (Henning Petersen) Date: Tue Oct 14 16:00:19 2008 Subject: arm/128095: Sizeof(pointer) bug . Message-ID: <200810141556.m9EFuxdm014658@www.freebsd.org> >Number: 128095 >Category: arm >Synopsis: Sizeof(pointer) bug . >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 14 16:00:05 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Henning Petersen >Release: current-Freebsd >Organization: >Environment: >Description: >How-To-Repeat: >Fix: --- src/sys/arm/xscale/ixp425/if_npe.c 22 Mar 2008 16:53:28 -0000 1.9 +++ src/sys/arm/xscale/ixp425/if_npe.c 14 Oct 2008 06:50:58 -0000 @@ -448,7 +448,7 @@ { int error, i; - memset(dma, 0, sizeof(dma)); + memset(dma, 0, sizeof(*dma)); dma->name = name; dma->nbuf = nbuf; Patch attached with submission follows: Index: src/sys/arm/xscale/ixp425/if_npe.c =================================================================== RCS file: /usr/ncvs/src/sys/arm/xscale/ixp425/if_npe.c,v retrieving revision 1.9 diff -u -r1.9 if_npe.c --- src/sys/arm/xscale/ixp425/if_npe.c 22 Mar 2008 16:53:28 -0000 1.9 +++ src/sys/arm/xscale/ixp425/if_npe.c 14 Oct 2008 06:50:58 -0000 @@ -448,7 +448,7 @@ { int error, i; - memset(dma, 0, sizeof(dma)); + memset(dma, 0, sizeof(*dma)); dma->name = name; dma->nbuf = nbuf; >Release-Note: >Audit-Trail: >Unformatted: From xcllnt at mac.com Tue Oct 14 16:09:08 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Oct 14 16:09:14 2008 Subject: FreeBSD/arm for Marvell chips in the tree In-Reply-To: <48F4AF5C.9000205@semihalf.com> References: <48F4AF5C.9000205@semihalf.com> Message-ID: On Oct 14, 2008, at 7:40 AM, Rafal Jaworowski wrote: > I have finished integration of FreeBSD/arm support for Marvell > systems-on-chip > into the SVN repository. There are still items to improve, and new > drivers > (PCIE, PCI) and extensions (minidumps, gdbserver) will be introduced > soon, but > generally the port is in quite decent state already, so enjoy! Thanks Rafal. Great work as usual! -- Marcel Moolenaar xcllnt@mac.com From jhein at timing.com Tue Oct 14 20:25:36 2008 From: jhein at timing.com (John Hein) Date: Tue Oct 14 20:25:43 2008 Subject: loadable drivers Message-ID: <18677.60.434738.596456@gromit.timing.com> What needs to be done to support loadable drivers under arm/freebsd? From stas at FreeBSD.org Tue Oct 14 20:59:25 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Tue Oct 14 20:59:31 2008 Subject: loadable drivers In-Reply-To: <18677.60.434738.596456@gromit.timing.com> References: <18677.60.434738.596456@gromit.timing.com> Message-ID: <20081015003842.a2bd682b.stas@FreeBSD.org> On Tue, 14 Oct 2008 14:25:32 -0600 John Hein mentioned: > What needs to be done to support loadable drivers under arm/freebsd? I think they should work, aren't they? -- 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/20081014/32351e3c/attachment.pgp From dubaylu at gmail.com Tue Oct 14 21:17:28 2008 From: dubaylu at gmail.com (luasi dubay) Date: Tue Oct 14 21:17:34 2008 Subject: FreeBSD/arm support for Marvell chips -- please review In-Reply-To: <48F48D71.4030008@semihalf.com> References: <48DA31B3.5040906@semihalf.com> <48F48D71.4030008@semihalf.com> Message-ID: <55a968a30810141350r3249adx85c289363e1b092a@mail.gmail.com> On 10/14/08, Rafal Jaworowski wrote: > Vincent Barus wrote: > > Hi, > > nice progress. Maybe someday there's a way to get a stripped down > > FreeBSD working on a d-link dns-323 (http://wiki.dns323.info/ ) ? > > It's a 88F5181 CPU. And some now have a 88F5182. I am running NetBSD on mine. The bootloader u-boot is stripped down and has no network access so be prepared to download kernels using kermit. Something else to think about if you want to turn it into a server, ...when it is power cycled the DNS323 needs a kick to get it going again. > > > The port is reported to work on 88F5181 (kevlo@ had his LinkstationPro > running), so the device you mention should only require some configuration > tweaks, if anything. The gpio's need reverse engineering too. The wiki does not provide enough information to power off the device. I am working on this. From imp at bsdimp.com Tue Oct 14 21:34:43 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Oct 14 21:34:49 2008 Subject: loadable drivers In-Reply-To: <20081015003842.a2bd682b.stas@FreeBSD.org> References: <18677.60.434738.596456@gromit.timing.com> <20081015003842.a2bd682b.stas@FreeBSD.org> Message-ID: <20081014.153418.1353606085.imp@bsdimp.com> In message: <20081015003842.a2bd682b.stas@FreeBSD.org> Stanislav Sedov writes: : On Tue, 14 Oct 2008 14:25:32 -0600 : John Hein mentioned: : : > What needs to be done to support loadable drivers under arm/freebsd? : : I think they should work, aren't they? Build them... They work.. Err, no, it would take hundreds of hours on contract work done only by me... :-) Warner P.S. I used to work at timing.com :-) From jhein at timing.com Tue Oct 14 22:50:28 2008 From: jhein at timing.com (John Hein) Date: Tue Oct 14 22:50:43 2008 Subject: loadable drivers In-Reply-To: <20081014.153418.1353606085.imp@bsdimp.com> References: <18677.60.434738.596456@gromit.timing.com> <20081015003842.a2bd682b.stas@FreeBSD.org> <20081014.153418.1353606085.imp@bsdimp.com> Message-ID: <18677.7678.159413.615726@gromit.timing.com> M. Warner Losh wrote at 15:34 -0600 on Oct 14, 2008: > In message: <20081015003842.a2bd682b.stas@FreeBSD.org> > Stanislav Sedov writes: > : On Tue, 14 Oct 2008 14:25:32 -0600 > : John Hein mentioned: > : > : > What needs to be done to support loadable drivers under arm/freebsd? > : > : I think they should work, aren't they? > > Build them... They work.. Sorry for the poor problem statement. They do load, but I'm not getting into the probe or attach. At first I thought the load was failing, but that was driver error (pardon the pun). Let me get better debug info, and I'll come back with a better question or an explanation. From imp at bsdimp.com Wed Oct 15 16:25:38 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Oct 15 16:25:44 2008 Subject: loadable drivers In-Reply-To: <20081015162140.GQ25586@cicely7.cicely.de> References: <20081014.153418.1353606085.imp@bsdimp.com> <18677.7678.159413.615726@gromit.timing.com> <20081015162140.GQ25586@cicely7.cicely.de> Message-ID: <20081015.102514.796899934.imp@bsdimp.com> In message: <20081015162140.GQ25586@cicely7.cicely.de> Bernd Walter writes: : On Tue, Oct 14, 2008 at 04:32:30PM -0600, John Hein wrote: : > M. Warner Losh wrote at 15:34 -0600 on Oct 14, 2008: : > > In message: <20081015003842.a2bd682b.stas@FreeBSD.org> : > > Stanislav Sedov writes: : > > : On Tue, 14 Oct 2008 14:25:32 -0600 : > > : John Hein mentioned: : > > : : > > : > What needs to be done to support loadable drivers under arm/freebsd? : > > : : > > : I think they should work, aren't they? : > > : > > Build them... They work.. : > : > Sorry for the poor problem statement. They do load, but I'm not : > getting into the probe or attach. At first I thought the load : > was failing, but that was driver error (pardon the pun). : : Then it is likely a driver or configuration specific problem. : One of the possible reasons is that you may missing hints, because many : devices in embedded systems don't support probing. : IIRC I already successfully loaded USB modules on AT91. The problem, communicated privately, was there's no identify routine, so it never was added to atmelbus so nothing happened when the module was loaded. Warner From ticso at cicely7.cicely.de Wed Oct 15 16:39:50 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Wed Oct 15 16:39:57 2008 Subject: loadable drivers In-Reply-To: <18677.7678.159413.615726@gromit.timing.com> References: <18677.60.434738.596456@gromit.timing.com> <20081015003842.a2bd682b.stas@FreeBSD.org> <20081014.153418.1353606085.imp@bsdimp.com> <18677.7678.159413.615726@gromit.timing.com> Message-ID: <20081015162140.GQ25586@cicely7.cicely.de> On Tue, Oct 14, 2008 at 04:32:30PM -0600, John Hein wrote: > M. Warner Losh wrote at 15:34 -0600 on Oct 14, 2008: > > In message: <20081015003842.a2bd682b.stas@FreeBSD.org> > > Stanislav Sedov writes: > > : On Tue, 14 Oct 2008 14:25:32 -0600 > > : John Hein mentioned: > > : > > : > What needs to be done to support loadable drivers under arm/freebsd? > > : > > : I think they should work, aren't they? > > > > Build them... They work.. > > Sorry for the poor problem statement. They do load, but I'm not > getting into the probe or attach. At first I thought the load > was failing, but that was driver error (pardon the pun). Then it is likely a driver or configuration specific problem. One of the possible reasons is that you may missing hints, because many devices in embedded systems don't support probing. IIRC I already successfully loaded USB modules on AT91. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From jhein at timing.com Wed Oct 15 16:45:50 2008 From: jhein at timing.com (John Hein) Date: Wed Oct 15 16:45:57 2008 Subject: loadable drivers In-Reply-To: <20081015162140.GQ25586@cicely7.cicely.de> References: <18677.60.434738.596456@gromit.timing.com> <20081015003842.a2bd682b.stas@FreeBSD.org> <20081014.153418.1353606085.imp@bsdimp.com> <18677.7678.159413.615726@gromit.timing.com> <20081015162140.GQ25586@cicely7.cicely.de> Message-ID: <18678.7732.431604.484585@gromit.timing.com> Bernd Walter wrote at 18:21 +0200 on Oct 15, 2008: > On Tue, Oct 14, 2008 at 04:32:30PM -0600, John Hein wrote: > > M. Warner Losh wrote at 15:34 -0600 on Oct 14, 2008: > > > In message: <20081015003842.a2bd682b.stas@FreeBSD.org> > > > Stanislav Sedov writes: > > > : On Tue, 14 Oct 2008 14:25:32 -0600 > > > : John Hein mentioned: > > > : > > > : > What needs to be done to support loadable drivers under arm/freebsd? > > > : > > > : I think they should work, aren't they? > > > > > > Build them... They work.. > > > > Sorry for the poor problem statement. They do load, but I'm not > > getting into the probe or attach. At first I thought the load > > was failing, but that was driver error (pardon the pun). > > Then it is likely a driver or configuration specific problem. > One of the possible reasons is that you may missing hints, because many > devices in embedded systems don't support probing. > IIRC I already successfully loaded USB modules on AT91. Yes, it was my error... missing identify method. I've been using drivers parented to self-identifying busses for so long, I forgot that important little detail. Sorry for the gross misdirection. Note that loading the uftdi driver via kldload behaves differently on arm than when it's compiled into the kernel. It boils down to uaa->iface being NULL (in uftdi_match) in the former case and not NULL in the latter. I haven't tracked that down yet, but kldload works fine on x86. From imp at bsdimp.com Wed Oct 15 17:25:28 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Oct 15 17:25:34 2008 Subject: loadable drivers In-Reply-To: <18678.7732.431604.484585@gromit.timing.com> References: <18677.7678.159413.615726@gromit.timing.com> <20081015162140.GQ25586@cicely7.cicely.de> <18678.7732.431604.484585@gromit.timing.com> Message-ID: <20081015.112549.35219823.imp@bsdimp.com> In message: <18678.7732.431604.484585@gromit.timing.com> John Hein writes: : Bernd Walter wrote at 18:21 +0200 on Oct 15, 2008: : > On Tue, Oct 14, 2008 at 04:32:30PM -0600, John Hein wrote: : > > M. Warner Losh wrote at 15:34 -0600 on Oct 14, 2008: : > > > In message: <20081015003842.a2bd682b.stas@FreeBSD.org> : > > > Stanislav Sedov writes: : > > > : On Tue, 14 Oct 2008 14:25:32 -0600 : > > > : John Hein mentioned: : > > > : : > > > : > What needs to be done to support loadable drivers under arm/freebsd? : > > > : : > > > : I think they should work, aren't they? : > > > : > > > Build them... They work.. : > > : > > Sorry for the poor problem statement. They do load, but I'm not : > > getting into the probe or attach. At first I thought the load : > > was failing, but that was driver error (pardon the pun). : > : > Then it is likely a driver or configuration specific problem. : > One of the possible reasons is that you may missing hints, because many : > devices in embedded systems don't support probing. : > IIRC I already successfully loaded USB modules on AT91. : : Yes, it was my error... missing identify method. I've been using : drivers parented to self-identifying busses for so long, I forgot : that important little detail. : : Sorry for the gross misdirection. : : Note that loading the uftdi driver via kldload behaves differently on : arm than when it's compiled into the kernel. It boils down to : uaa->iface being NULL (in uftdi_match) in the former case and not NULL : in the latter. I haven't tracked that down yet, but kldload works : fine on x86. There's issue with loading usb drivers because it was never designed for that... Some drivers work, others don't. Warner From jhein at timing.com Wed Oct 15 19:15:31 2008 From: jhein at timing.com (John Hein) Date: Wed Oct 15 19:15:37 2008 Subject: loadable drivers In-Reply-To: <20081015.112549.35219823.imp@bsdimp.com> References: <18677.7678.159413.615726@gromit.timing.com> <20081015162140.GQ25586@cicely7.cicely.de> <18678.7732.431604.484585@gromit.timing.com> <20081015.112549.35219823.imp@bsdimp.com> Message-ID: <18678.15002.142599.726@gromit.timing.com> M. Warner Losh wrote at 11:25 -0600 on Oct 15, 2008: > There's issue with loading usb drivers because it was never designed > for that... Some drivers work, others don't. I remember that, but I wonder why it works okay on x86. Hmmm... now that I check it again, it seems it only works on x86 if the ko is specified to be loaded in loader.conf (even if ugen is compiled out and not loaded). Loading it later after boot makes the uftdi_match fail. So that explains why it doesn't work on arm (no loader support for loading .ko's) at all. Ah... it also works if it's loaded at boot, unloaded later, then reloaded. From mav at FreeBSD.org Wed Oct 15 20:25:14 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Oct 15 20:25:21 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081013.110310.-1622595361.imp@bsdimp.com> References: <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> <20081008113848.c9b44354.webmaster@kibab.com> <20081012171201.da4da754.webmaster@kibab.com> <20081013.110310.-1622595361.imp@bsdimp.com> Message-ID: <48F651A7.3040001@FreeBSD.org> M. Warner Losh wrote: > : Problem was solved by increasing the number of answer read attempts in mmc_send_app_op_cond(). With attached patch (against latest driver version) card is recognized properly on ~ 190th attempt (while in original driver there are only 100 attempts). > : > : Furthermore, non-mine SDHC card is now also recognized in this cardreader (it doesn't even under Windows). In this case, it takes about 400 attempts to read answer. > > I think I bumped the number of iterations to 100 when I found that 10 > wasn't enough. 25 different cards worked just fine, but I got use of > a 16MB SD card at BSDcan that needed like 65. Bumping it from 100 to > 1000, however, makes the timeout go from 1s to 10s. That opens up > window for insertion races, but that's the only downside I see... Of > course, we want to fix those races, but this may expose them a little > more.. > > I can't believe that you had a card that took 4s to become active! > > Can you confirm the elapsed time is really 4s for that card? > Otherwise, this may be pointing out a bug in another area of the > code... Completely fortunate I have noticed that number of iterations depends on my laptop power source. After small investigation I have found that it actually depends on dev.cpu.0.freq value. With default value 2400 I have only several iterations. But every double frequency decrease doubles iteration count. With minimum value 100MHz I have more then 100 iterations. Same time it doesn't looks like this time is a real wall time. It looks like DELAY() used in a loop has some problems with time counting. -- Alexander Motin From stas at FreeBSD.org Wed Oct 15 20:45:18 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed Oct 15 20:45:25 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48F651A7.3040001@FreeBSD.org> References: <5f67a8c40810052226k3070a11ah463a819c677f6307@mail.gmail.com> <20081008113848.c9b44354.webmaster@kibab.com> <20081012171201.da4da754.webmaster@kibab.com> <20081013.110310.-1622595361.imp@bsdimp.com> <48F651A7.3040001@FreeBSD.org> Message-ID: <20081016004548.437cba9d.stas@FreeBSD.org> On Wed, 15 Oct 2008 23:25:11 +0300 Alexander Motin mentioned: > > Completely fortunate I have noticed that number of iterations depends on > my laptop power source. After small investigation I have found that it > actually depends on dev.cpu.0.freq value. With default value 2400 I have > only several iterations. But every double frequency decrease doubles > iteration count. With minimum value 100MHz I have more then 100 > iterations. Same time it doesn't looks like this time is a real wall > time. It looks like DELAY() used in a loop has some problems with time > counting. > What do you mean? DELAY(9) on your laptop doesn't correspond to the real time? AFAIK, DELAY(9) relies on current timecounter for time accountiong, so there might be problems with it. Have you tried switching the kern.timecounter.hardware sysctl to see if it will affect results? -- 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/20081015/7bb60ce8/attachment.pgp From mav at FreeBSD.org Thu Oct 16 10:06:25 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Oct 16 11:13:39 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <1224123783.00025735.1224113402@10.7.7.3> References: <1223284984.00022179.1223272802@10.7.7.3> <1223497390.00023332.1223487003@10.7.7.3> <1223832181.00024566.1223819402@10.7.7.3> <1223929384.00025003.1223917802@10.7.7.3> <1224112991.00025726.1224102602@10.7.7.3> <1224123783.00025735.1224113402@10.7.7.3> Message-ID: <48F7121A.2010307@FreeBSD.org> Stanislav Sedov wrote: > On Wed, 15 Oct 2008 23:25:11 +0300 > Alexander Motin mentioned: >> Completely fortunate I have noticed that number of iterations depends on >> my laptop power source. After small investigation I have found that it >> actually depends on dev.cpu.0.freq value. With default value 2400 I have >> only several iterations. But every double frequency decrease doubles >> iteration count. With minimum value 100MHz I have more then 100 >> iterations. Same time it doesn't looks like this time is a real wall >> time. It looks like DELAY() used in a loop has some problems with time >> counting. > > What do you mean? DELAY(9) on your laptop doesn't correspond to the > real time? Yes. It works fine when laptop operates at full frequency, but proportionally reduces time interval when powerd drops frequency down. I have also evidence about the same problem on another laptop with 7.1-PRERELEASE. > AFAIK, DELAY(9) relies on current timecounter for time > accountiong, so there might be problems with it. Have you tried > switching the kern.timecounter.hardware sysctl to see if it will > affect results? It was late and I am not very aware in FreeBSD time counting, so I have not tried to investigate it deeper. -- Alexander Motin From gavin at FreeBSD.org Thu Oct 16 14:10:59 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Oct 16 14:11:04 2008 Subject: arm/128095: Sizeof(pointer) bug . Message-ID: <200810161410.m9GEAwRN039877@freefall.freebsd.org> Synopsis: Sizeof(pointer) bug . State-Changed-From-To: open->patched State-Changed-By: gavin State-Changed-When: Thu Oct 16 14:09:54 UTC 2008 State-Changed-Why: Patched in r183886. http://www.freebsd.org/cgi/query-pr.cgi?pr=128095 From imp at bsdimp.com Thu Oct 16 14:16:37 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Oct 16 14:16:55 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48F7121A.2010307@FreeBSD.org> References: <1224112991.00025726.1224102602@10.7.7.3> <1224123783.00025735.1224113402@10.7.7.3> <48F7121A.2010307@FreeBSD.org> Message-ID: <20081016.081628.43009259.imp@bsdimp.com> In message: <48F7121A.2010307@FreeBSD.org> Alexander Motin writes: : Stanislav Sedov wrote: : > On Wed, 15 Oct 2008 23:25:11 +0300 : > Alexander Motin mentioned: : >> Completely fortunate I have noticed that number of iterations depends on : >> my laptop power source. After small investigation I have found that it : >> actually depends on dev.cpu.0.freq value. With default value 2400 I have : >> only several iterations. But every double frequency decrease doubles : >> iteration count. With minimum value 100MHz I have more then 100 : >> iterations. Same time it doesn't looks like this time is a real wall : >> time. It looks like DELAY() used in a loop has some problems with time : >> counting. : > : > What do you mean? DELAY(9) on your laptop doesn't correspond to the : > real time? : : Yes. It works fine when laptop operates at full frequency, but : proportionally reduces time interval when powerd drops frequency down. I : have also evidence about the same problem on another laptop with : 7.1-PRERELEASE. Is the slower clock making DELAY take less/more time? Or is the slower clock fed to the SDHCI part who feeds it to the SD card so less time accumulates on the SD card because the clock line to it is running slower? : > AFAIK, DELAY(9) relies on current timecounter for time : > accountiong, so there might be problems with it. Have you tried : > switching the kern.timecounter.hardware sysctl to see if it will : > affect results? : : It was late and I am not very aware in FreeBSD time counting, so I have : not tried to investigate it deeper. I would have thought that if DELAY(10) went from 10us to 100us because you are battery power, you'd have more cards working rather than fewer.. Warner From imp at bsdimp.com Thu Oct 16 15:28:48 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Oct 16 15:28:54 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48F75773.7030100@FreeBSD.org> References: <48F7121A.2010307@FreeBSD.org> <20081016.081628.43009259.imp@bsdimp.com> <48F75773.7030100@FreeBSD.org> Message-ID: <20081016.092844.-1548243521.imp@bsdimp.com> In message: <48F75773.7030100@FreeBSD.org> Alexander Motin writes: : M. Warner Losh wrote: : > In message: <48F7121A.2010307@FreeBSD.org> : > Alexander Motin writes: : > : Stanislav Sedov wrote: : > : > On Wed, 15 Oct 2008 23:25:11 +0300 : > : > Alexander Motin mentioned: : > : >> Completely fortunate I have noticed that number of iterations depends on : > : >> my laptop power source. After small investigation I have found that it : > : >> actually depends on dev.cpu.0.freq value. With default value 2400 I have : > : >> only several iterations. But every double frequency decrease doubles : > : >> iteration count. With minimum value 100MHz I have more then 100 : > : >> iterations. Same time it doesn't looks like this time is a real wall : > : >> time. It looks like DELAY() used in a loop has some problems with time : > : >> counting. : > : > : > : > What do you mean? DELAY(9) on your laptop doesn't correspond to the : > : > real time? : > : : > : Yes. It works fine when laptop operates at full frequency, but : > : proportionally reduces time interval when powerd drops frequency down. I : > : have also evidence about the same problem on another laptop with : > : 7.1-PRERELEASE. : > : > Is the slower clock making DELAY take less/more time? Or is the : > slower clock fed to the SDHCI part who feeds it to the SD card so less : > time accumulates on the SD card because the clock line to it is : > running slower? : > : > : > AFAIK, DELAY(9) relies on current timecounter for time : > : > accountiong, so there might be problems with it. Have you tried : > : > switching the kern.timecounter.hardware sysctl to see if it will : > : > affect results? : > : : > : It was late and I am not very aware in FreeBSD time counting, so I have : > : not tried to investigate it deeper. : > : > I would have thought that if DELAY(10) went from 10us to 100us because : > you are battery power, you'd have more cards working rather than : > fewer.. : : No, it's opposite. With lower frequency I have proportionally smaller : delays (more loop iterations). I don't remember exact numbers now, but : general tendency was like: with 2400MHz - 10 iterations, with 1200MHz - : 20 iterations and with 100MHz - 240 iterations. But neither syslog, nor : my eyes saw any visible delay there. You have more iterations. I'd have expected less. This doesn't say anything at all about DELAY, per se. If you are waiting for 1M cycles at 100MHz, it is only .01s, while at 10MHz it is .1s. Delay is implemented by reading a counter in the 8254 that's been calibrated. So unless the clock that's clocking it is running FASTER, delay won't be the source of additional iterations. Hmmm, looking at the i386 delay code, it looks like it depends on tsc_frequency being right when tsc isn't broken. If that's set bogusly, that could cause DELAY to be slower... : It looks like working on battery power DELAY() code expects timer speed : reduced, while estimating final timer value, but looks like timer itself : runs on full speed. Have you confirmed this with getting timestamps per loop? The delay code doesn't seem to adjust at all. We should likely look at i386/i386/tsc.c and instrument it to see what it is doing to tsc_freq in your case... Warner From mav at FreeBSD.org Thu Oct 16 15:02:15 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Oct 16 16:16:10 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081016.081628.43009259.imp@bsdimp.com> References: <1224112991.00025726.1224102602@10.7.7.3> <1224123783.00025735.1224113402@10.7.7.3> <48F7121A.2010307@FreeBSD.org> <20081016.081628.43009259.imp@bsdimp.com> Message-ID: <48F75773.7030100@FreeBSD.org> M. Warner Losh wrote: > In message: <48F7121A.2010307@FreeBSD.org> > Alexander Motin writes: > : Stanislav Sedov wrote: > : > On Wed, 15 Oct 2008 23:25:11 +0300 > : > Alexander Motin mentioned: > : >> Completely fortunate I have noticed that number of iterations depends on > : >> my laptop power source. After small investigation I have found that it > : >> actually depends on dev.cpu.0.freq value. With default value 2400 I have > : >> only several iterations. But every double frequency decrease doubles > : >> iteration count. With minimum value 100MHz I have more then 100 > : >> iterations. Same time it doesn't looks like this time is a real wall > : >> time. It looks like DELAY() used in a loop has some problems with time > : >> counting. > : > > : > What do you mean? DELAY(9) on your laptop doesn't correspond to the > : > real time? > : > : Yes. It works fine when laptop operates at full frequency, but > : proportionally reduces time interval when powerd drops frequency down. I > : have also evidence about the same problem on another laptop with > : 7.1-PRERELEASE. > > Is the slower clock making DELAY take less/more time? Or is the > slower clock fed to the SDHCI part who feeds it to the SD card so less > time accumulates on the SD card because the clock line to it is > running slower? > > : > AFAIK, DELAY(9) relies on current timecounter for time > : > accountiong, so there might be problems with it. Have you tried > : > switching the kern.timecounter.hardware sysctl to see if it will > : > affect results? > : > : It was late and I am not very aware in FreeBSD time counting, so I have > : not tried to investigate it deeper. > > I would have thought that if DELAY(10) went from 10us to 100us because > you are battery power, you'd have more cards working rather than > fewer.. No, it's opposite. With lower frequency I have proportionally smaller delays (more loop iterations). I don't remember exact numbers now, but general tendency was like: with 2400MHz - 10 iterations, with 1200MHz - 20 iterations and with 100MHz - 240 iterations. But neither syslog, nor my eyes saw any visible delay there. It looks like working on battery power DELAY() code expects timer speed reduced, while estimating final timer value, but looks like timer itself runs on full speed. -- Alexander Motin From taku at tackymt.homeip.net Thu Oct 16 16:39:50 2008 From: taku at tackymt.homeip.net (Taku YAMAMOTO) Date: Thu Oct 16 16:40:01 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081016.092844.-1548243521.imp@bsdimp.com> References: <48F7121A.2010307@FreeBSD.org> <20081016.081628.43009259.imp@bsdimp.com> <48F75773.7030100@FreeBSD.org> <20081016.092844.-1548243521.imp@bsdimp.com> Message-ID: <20081017013946.3534221e.taku@tackymt.homeip.net> On Thu, 16 Oct 2008 09:28:44 -0600 (MDT) "M. Warner Losh" wrote: > In message: <48F75773.7030100@FreeBSD.org> > Alexander Motin writes: > : No, it's opposite. With lower frequency I have proportionally smaller > : delays (more loop iterations). I don't remember exact numbers now, but > : general tendency was like: with 2400MHz - 10 iterations, with 1200MHz - > : 20 iterations and with 100MHz - 240 iterations. But neither syslog, nor > : my eyes saw any visible delay there. > > You have more iterations. I'd have expected less. This doesn't say > anything at all about DELAY, per se. If you are waiting for 1M cycles > at 100MHz, it is only .01s, while at 10MHz it is .1s. Delay is > implemented by reading a counter in the 8254 that's been calibrated. > So unless the clock that's clocking it is running FASTER, delay won't > be the source of additional iterations. > > Hmmm, looking at the i386 delay code, it looks like it depends on > tsc_frequency being right when tsc isn't broken. If that's set > bogusly, that could cause DELAY to be slower... I have a Core 2 Duo whose TSC ticks regardless of how EST is set. In conjunction of tsc_freq_changed() function defined in tsc.c, tsc_freq becomes lower than actual, thus shorter DELAY(). Maybe his machine has the same. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From imp at bsdimp.com Thu Oct 16 16:52:17 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Oct 16 16:52:23 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081017013946.3534221e.taku@tackymt.homeip.net> References: <48F75773.7030100@FreeBSD.org> <20081016.092844.-1548243521.imp@bsdimp.com> <20081017013946.3534221e.taku@tackymt.homeip.net> Message-ID: <20081016.105002.-1975970550.imp@bsdimp.com> In message: <20081017013946.3534221e.taku@tackymt.homeip.net> Taku YAMAMOTO writes: : On Thu, 16 Oct 2008 09:28:44 -0600 (MDT) : "M. Warner Losh" wrote: : : > In message: <48F75773.7030100@FreeBSD.org> : > Alexander Motin writes: : > : No, it's opposite. With lower frequency I have proportionally smaller : > : delays (more loop iterations). I don't remember exact numbers now, but : > : general tendency was like: with 2400MHz - 10 iterations, with 1200MHz - : > : 20 iterations and with 100MHz - 240 iterations. But neither syslog, nor : > : my eyes saw any visible delay there. : > : > You have more iterations. I'd have expected less. This doesn't say : > anything at all about DELAY, per se. If you are waiting for 1M cycles : > at 100MHz, it is only .01s, while at 10MHz it is .1s. Delay is : > implemented by reading a counter in the 8254 that's been calibrated. : > So unless the clock that's clocking it is running FASTER, delay won't : > be the source of additional iterations. : > : > Hmmm, looking at the i386 delay code, it looks like it depends on : > tsc_frequency being right when tsc isn't broken. If that's set : > bogusly, that could cause DELAY to be slower... : : I have a Core 2 Duo whose TSC ticks regardless of how EST is set. : In conjunction of tsc_freq_changed() function defined in tsc.c, : tsc_freq becomes lower than actual, thus shorter DELAY(). : : Maybe his machine has the same. That would cause the problem. If we're bogusly adjusting tsc_freq we should fix that... Warner From mav at FreeBSD.org Thu Oct 16 17:25:38 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Oct 16 17:25:44 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081017013946.3534221e.taku@tackymt.homeip.net> References: <48F7121A.2010307@FreeBSD.org> <20081016.081628.43009259.imp@bsdimp.com> <48F75773.7030100@FreeBSD.org> <20081016.092844.-1548243521.imp@bsdimp.com> <20081017013946.3534221e.taku@tackymt.homeip.net> Message-ID: <48F7790F.5000904@FreeBSD.org> Taku YAMAMOTO wrote: > On Thu, 16 Oct 2008 09:28:44 -0600 (MDT) > "M. Warner Losh" wrote: > >> In message: <48F75773.7030100@FreeBSD.org> >> Alexander Motin writes: >> : No, it's opposite. With lower frequency I have proportionally smaller >> : delays (more loop iterations). I don't remember exact numbers now, but >> : general tendency was like: with 2400MHz - 10 iterations, with 1200MHz - >> : 20 iterations and with 100MHz - 240 iterations. But neither syslog, nor >> : my eyes saw any visible delay there. >> >> You have more iterations. I'd have expected less. This doesn't say >> anything at all about DELAY, per se. If you are waiting for 1M cycles >> at 100MHz, it is only .01s, while at 10MHz it is .1s. Delay is >> implemented by reading a counter in the 8254 that's been calibrated. >> So unless the clock that's clocking it is running FASTER, delay won't >> be the source of additional iterations. >> >> Hmmm, looking at the i386 delay code, it looks like it depends on >> tsc_frequency being right when tsc isn't broken. If that's set >> bogusly, that could cause DELAY to be slower... > > I have a Core 2 Duo whose TSC ticks regardless of how EST is set. > In conjunction of tsc_freq_changed() function defined in tsc.c, > tsc_freq becomes lower than actual, thus shorter DELAY(). > > Maybe his machine has the same. Indeed: CPU: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 FreeBSD 8.0-CURRENT amd64. -- Alexander Motin From webmaster at kibab.com Fri Oct 17 07:16:52 2008 From: webmaster at kibab.com (Ilya Bakulin) Date: Fri Oct 17 07:17:10 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48F7790F.5000904@FreeBSD.org> References: <48F7121A.2010307@FreeBSD.org> <20081016.081628.43009259.imp@bsdimp.com> <48F75773.7030100@FreeBSD.org> <20081016.092844.-1548243521.imp@bsdimp.com> <20081017013946.3534221e.taku@tackymt.homeip.net> <48F7790F.5000904@FreeBSD.org> Message-ID: <20081017111650.a84afa26.webmaster@kibab.com> On Thu, 16 Oct 2008 20:25:35 +0300 Alexander Motin wrote: > Indeed: > CPU: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (2394.01-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > Features=0xbfebfbff MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS, > HTT,TM,PBE> > Features2=0xe3bd xTPR,PDCM> > AMD Features=0x20100800 > AMD Features2=0x1 > Cores per package: 2 > > FreeBSD 8.0-CURRENT amd64. > > -- > Alexander Motin Same here: CPU: Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz (1995.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Running FreeBSD 7-STABLE i386. On Mon, 13 Oct 2008 11:03:10 -0600 (MDT) "M. Warner Losh" wrote: > I can't believe that you had a card that took 4s to become active! > > Can you confirm the elapsed time is really 4s for that card? > Otherwise, this may be pointing out a bug in another area of the > code... > > Warner I don't have this card any more. And regarging my SD... I can't do exact measures. What I have done yesterday is: ; Running at full frequency: Oct 16 11:53:50 kibab-nb sudo: kibab : TTY=ttyp3 ; PWD=/home/kibab ; USER=root ; COMMAND=/etc/rc.d/powerd stop Oct 16 11:54:00 kibab-nb sudo: kibab : TTY=ttyp3 ; PWD=/home/kibab ; USER=root ; COMMAND=/usr/sbin/powerd -a max Oct 16 11:54:49 kibab-nb kernel: mmc0: on sdhci 0 Oct 16 11:54:49 kibab-nb kernel: mmc_send_app_ocond(): cmd completed in 0 iter Oct 16 11:54:50 kibab-nb kernel: mmc_send_app_ocond(): cmd completed in 35 iter 35 iterations! ; Running at lowest possible frequency: Oct 16 11:55:27 kibab-nb sudo: kibab : TTY=ttyp3 ; PWD=/home/kibab ; USER=root ; COMMAND=/etc/rc.d/powerd stop Oct 16 11:55:30 kibab-nb sudo: kibab : TTY=ttyp3 ; PWD=/home/kibab ; USER=root ; COMMAND=/usr/sbin/powerd -a min Oct 16 11:55:46 kibab-nb kernel: mmc0: on sdhci0 Oct 16 11:55:46 kibab-nb kernel: mmc_send_app_ocond(): cmd completed in 0 iter Oct 16 11:55:46 kibab-nb kernel: mmc_send_app_ocond(): cmd completed in 185 iter 185 iterations at lowest frequency... Sorry for long answer delay. -- Ilya Bakulin -------------- 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/20081017/3f9985a3/attachment.pgp From jacques.fourie at gmail.com Sat Oct 18 08:03:20 2008 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Sat Oct 18 08:03:26 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48F11087.20403@FreeBSD.org> References: <48DEA8E7.2080503@FreeBSD.org> <48F11087.20403@FreeBSD.org> Message-ID: > Alexander Motin wrote: >> >> 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. >> Latest patches against 8-CURRENT (mostly fit 7-STABLE) may be found at: >> http://people.freebsd.org/~mav/sdhci/ > > For those who are not tracking actively, I would like to report that most of > original driver's child illnesses are now healed. > > Driver now supports both PIO and DMA modes. Because of some special tunings > DMA works fine even on almost broken ENE chips. I am reaching 15MB/s > transfer (maximum for my controller's bus) with only about 1% of CPU load. > Implemented 4 bits bus width and high speed timing modes support for high > data rates up to 52MHz. Cards hot insertion/removing is now working. > Together with in-tree mmc/mmcsd drivers improvements most of card types (SD, > SDHC, standard and high capacity MMC) are now supported. > > -- > Alexander Motin > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > The device in my HP nw8240 notebook is a Texas Instruments 7621. This device is a multi-function PCI device with a CardBus, firewire, Flash Media and SD controller. The only way that I could get this driver to work for me is to disable SD card detection on the Flash Media controller, which is function 3 : pcitweak -w 02:06:03 -b 0x4c 0x02 Thanks for the great work! From imp at bsdimp.com Sat Oct 18 15:58:42 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Oct 18 15:58:59 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: References: <48DEA8E7.2080503@FreeBSD.org> <48F11087.20403@FreeBSD.org> Message-ID: <20081018.095703.-135512205.imp@bsdimp.com> In message: "Jacques Fourie" writes: : > Alexander Motin wrote: : >> : >> 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. : >> Latest patches against 8-CURRENT (mostly fit 7-STABLE) may be found at: : >> http://people.freebsd.org/~mav/sdhci/ : > : > For those who are not tracking actively, I would like to report that most of : > original driver's child illnesses are now healed. : > : > Driver now supports both PIO and DMA modes. Because of some special tunings : > DMA works fine even on almost broken ENE chips. I am reaching 15MB/s : > transfer (maximum for my controller's bus) with only about 1% of CPU load. : > Implemented 4 bits bus width and high speed timing modes support for high : > data rates up to 52MHz. Cards hot insertion/removing is now working. : > Together with in-tree mmc/mmcsd drivers improvements most of card types (SD, : > SDHC, standard and high capacity MMC) are now supported. : > : > -- : > Alexander Motin : > _______________________________________________ : > freebsd-arm@freebsd.org mailing list : > http://lists.freebsd.org/mailman/listinfo/freebsd-arm : > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" : > : : The device in my HP nw8240 notebook is a Texas Instruments 7621. This : device is a multi-function PCI device with a CardBus, firewire, Flash : Media and SD controller. The only way that I could get this driver to : work for me is to disable SD card detection on the Flash Media : controller, which is function 3 : : : pcitweak -w 02:06:03 -b 0x4c 0x02 I have patches to mav's sdhci driver to do this. However, I can't get the driver to work. It detects the cards are inserted, but then all commands that require a response from the card fail. How many slots does your controller report? Which one is sd? Warner From jacques.fourie at gmail.com Sat Oct 18 17:01:10 2008 From: jacques.fourie at gmail.com (Jacques Fourie) Date: Sat Oct 18 17:01:16 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <20081018.095703.-135512205.imp@bsdimp.com> References: <48DEA8E7.2080503@FreeBSD.org> <48F11087.20403@FreeBSD.org> <20081018.095703.-135512205.imp@bsdimp.com> Message-ID: > In message: > "Jacques Fourie" writes: > : > Alexander Motin wrote: > : >> > : >> 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. > : >> Latest patches against 8-CURRENT (mostly fit 7-STABLE) may be found at: > : >> http://people.freebsd.org/~mav/sdhci/ > : > > : > For those who are not tracking actively, I would like to report that most of > : > original driver's child illnesses are now healed. > : > > : > Driver now supports both PIO and DMA modes. Because of some special tunings > : > DMA works fine even on almost broken ENE chips. I am reaching 15MB/s > : > transfer (maximum for my controller's bus) with only about 1% of CPU load. > : > Implemented 4 bits bus width and high speed timing modes support for high > : > data rates up to 52MHz. Cards hot insertion/removing is now working. > : > Together with in-tree mmc/mmcsd drivers improvements most of card types (SD, > : > SDHC, standard and high capacity MMC) are now supported. > : > > : > -- > : > Alexander Motin > : > _______________________________________________ > : > freebsd-arm@freebsd.org mailing list > : > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > : > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > : > > : > : The device in my HP nw8240 notebook is a Texas Instruments 7621. This > : device is a multi-function PCI device with a CardBus, firewire, Flash > : Media and SD controller. The only way that I could get this driver to > : work for me is to disable SD card detection on the Flash Media > : controller, which is function 3 : > : > : pcitweak -w 02:06:03 -b 0x4c 0x02 > > I have patches to mav's sdhci driver to do this. However, I can't get > the driver to work. It detects the cards are inserted, but then all > commands that require a response from the card fail. > > How many slots does your controller report? Which one is sd? > > Warner > My controller reports 3 slots, with the third one being sd. Jacques From bugmaster at FreeBSD.org Mon Oct 20 11:06:49 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 20 11:07:25 2008 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200810201106.m9KB6mPt082603@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- p arm/128095 arm Sizeof(pointer) bug . 1 problem total. From tinderbox at freebsd.org Sat Oct 25 20:40:48 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat Oct 25 20:41:00 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20081025204045.0316A73039@freebsd-current.sentex.ca> TB --- 2008-10-25 20:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-25 20:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-10-25 20:40:00 - cleaning the object tree TB --- 2008-10-25 20:40:25 - cvsupping the source tree TB --- 2008-10-25 20:40:25 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-10-25 20:40:43 - building world (CFLAGS=-O -pipe) TB --- 2008-10-25 20:40:43 - cd /src TB --- 2008-10-25 20:40:43 - /usr/bin/make -B buildworld TB --- 2008-10-25 20:40:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-25 20:40:43 - ERROR: failed to build world TB --- 2008-10-25 20:40:43 - tinderbox aborted TB --- 1.87 user 2.39 system 43.26 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From bugmaster at FreeBSD.org Mon Oct 27 11:07:09 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 27 11:07:35 2008 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200810271107.m9RB78jc001880@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- p arm/128095 arm Sizeof(pointer) bug . 1 problem total. From tinderbox at freebsd.org Mon Oct 27 13:32:11 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 27 13:32:22 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20081025204045.0316A73039@freebsd-current.sentex.ca> TB --- 2008-10-25 20:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-25 20:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-10-25 20:40:00 - cleaning the object tree TB --- 2008-10-25 20:40:25 - cvsupping the source tree TB --- 2008-10-25 20:40:25 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-10-25 20:40:43 - building world (CFLAGS=-O -pipe) TB --- 2008-10-25 20:40:43 - cd /src TB --- 2008-10-25 20:40:43 - /usr/bin/make -B buildworld TB --- 2008-10-25 20:40:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-25 20:40:43 - ERROR: failed to build world TB --- 2008-10-25 20:40:43 - tinderbox aborted TB --- 1.87 user 2.39 system 43.26 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From gaijin.k at gmail.com Mon Oct 27 22:12:08 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Mon Oct 27 22:12:15 2008 Subject: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements In-Reply-To: <48F11087.20403@FreeBSD.org> References: <48DEA8E7.2080503@FreeBSD.org> <48F11087.20403@FreeBSD.org> Message-ID: <1225144135.1052.18.camel@RabbitsDen> On Sat, 2008-10-11 at 23:45 +0300, Alexander Motin wrote: > Alexander Motin wrote: > > 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. > > > > Latest patches against 8-CURRENT (mostly fit 7-STABLE) may be found at: > > http://people.freebsd.org/~mav/sdhci/ > > For those who are not tracking actively, I would like to report that > most of original driver's child illnesses are now healed. > > Driver now supports both PIO and DMA modes. Because of some special > tunings DMA works fine even on almost broken ENE chips. I am reaching > 15MB/s transfer (maximum for my controller's bus) with only about 1% of > CPU load. Implemented 4 bits bus width and high speed timing modes > support for high data rates up to 52MHz. Cards hot insertion/removing is > now working. Together with in-tree mmc/mmcsd drivers improvements most > of card types (SD, SDHC, standard and high capacity MMC) are now supported. > This works well on my ThinkPad X60 (1709-73U) with RELENG_7 circa October 23rd (s/kproc/kthread/, thanks to Oleksandr Tymoshenko): sdhci0: mem 0xe4301800-0xe43018ff irq 18 at device 0.2 on pci21 sdhci0: 1 slot(s) allocated sdhci0: [ITHREAD] Tested with 1GB, 2GB and 4GB (SDHC) cards. The side note: write-lock switch on the card was also correctly detected and reported. Thank you very much for your work! -- Alexandre "Sunny" Kovalenko (????????? ?????????)