Date: Fri, 02 Nov 2012 07:54:58 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@freebsd.org Subject: Re: BeagleBone SD card problems Message-ID: <1351864498.1120.20.camel@revolution.hippie.lan> In-Reply-To: <5C5E2EAA-DEE7-4F79-9F23-A614DE32EBF9@kientzle.com> References: <5092667B.2030908@thieprojects.ch> <5C5E2EAA-DEE7-4F79-9F23-A614DE32EBF9@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2012-11-01 at 20:24 -0700, Tim Kientzle wrote: > On Nov 1, 2012, at 5:09 AM, Werner Thie wrote: > > > Hi all > > > > just got my fingers wet with a Rev A6 Beaglebone. Being a long time user of FreeBSD I found of course Tim Kientzle's project on github. Setting up a VM and the building of an image was a nobrainer, mahalo and kudos to Tim! > > > > When experimentally adding a swap file I encountered the following message repeatedly on console: > > > > dd if=/dev/zero of=/usr/swap0 bs=1024k count=512 > > > > ti_mmchs0: Error: current cmd NULL, already done? > > Don't know for sure that it is a problem, actually. > > I think of this message more as a gentle reminder: > Someone needs to study the driver and go through the > hardware docs carefully to figure out whether > this particular case indicates a flaw in the driver or > is just an expected case that can be safely ignored. > > While you're in there <grin>, you might look at > what's involved in converting the driver to use DMA > and whether there are any other performance optimizations > we should be trying. > > Tim I don't know the TI driver, but I've worked with the equivelent Atmel driver, and the mmc and mmcsd layers above it. From a quick glance at the TI code it appears that message can only happen if another interrupt comes in after the previous command has been completed. Given the way the protocol works, a data timeout error at the end of a write is normal if the controller hardware doesn't have an explicit block-count register, or when doing an open-ended streaming or multi-block transfer. I think the first thing I'd do is print the contents of the status and interrupt-enabled registers along with that message. It may be a matter as simple as disabling some interrupts at the same time as the other end-of-command processing is done. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1351864498.1120.20.camel>