[9fans] sheevaplug SD card driver

[9fans] sheevaplug SD card driver

[Richard Miller]

As a side effect of the raspberry pi work, I've produced an SD card
driver for the sheevaplug (and presumably other kirkwood platforms).
It's in two sections: the top layer does the card protocol and is
identical between rpi and kw (could go into /sys/src/9/port?), while
the lower layer does the host sdio interface.  The two layers link via
the usual table of functions, so if we encounter a platform with more
than one sd host interface [anybody seen one?] it won't be hard to
cope with.

Would anyone with a sheevaplug or similar, and a collection of SD
cards, like to try it out before I submit a patch?  Source is in
/n/sources/contrib/miller/9/kw, and if you haven't pulled kernel
sources recently you'll need to update /sys/src/9/port/sd.h as well.
The drive appears as '#S/sdM0', and a FAT-formatted SD card can be
mounted simply by doing "diskparts; dosmnt 1 /n/sd".  You can of
course hot-swap cards without rebooting, but don't forget to unmount
first.

Although the driver is called sdmmc.c, it handles only SD cards and
not the older MMC standard.  I think it's only a matter of slightly
different initialisation, but I haven't got an actual MMC card to
test it with.  If anyone cares enough to send me one, I'll see if
I can make that work too.

Re: [9fans] sheevaplug SD card driver

[Gorka Guardiola]

On Thu, Oct 18, 2012 at 2:42 PM, Richard Miller <9fans@hamnavoe.com> wrote:
> As a side effect of the raspberry pi work, I've produced an SD card
> driver for the sheevaplug (and presumably other kirkwood platforms).
> It's in two sections: the top layer does the card protocol and is
> identical between rpi and kw (could go into /sys/src/9/port?), while
> the lower layer does the host sdio interface.  The two layers link via
> the usual table of functions, so if we encounter a platform with more
> than one sd host interface [anybody seen one?] it won't be hard to
> cope with.

This is very nice work. Thanks.

>
> Would anyone with a sheevaplug or similar, and a collection of SD
> cards, like to try it out before I submit a patch?  Source is in

I have a sheeva but no SD cards, sorry.

G.

Re: [9fans] sheevaplug SD card driver

[David du Colombier]

> Would anyone with a sheevaplug or similar, and a collection of SD
> cards, like to try it out before I submit a patch?

I just tried with various 2 GB to 16 GB Kingston SD and
microSD (with adapter) cards on my SheevaPlug and it works
like a charm.

Thanks for your very nice work.

--
David du Colombier

Re: [9fans] sheevaplug SD card driver

[Skip Tavakkolian]

Thanks!!!  I plan to try it out on sheeva and guru later today.

On Thu, Oct 18, 2012 at 5:42 AM, Richard Miller <9fans@hamnavoe.com> wrote:
> As a side effect of the raspberry pi work, I've produced an SD card
> driver for the sheevaplug (and presumably other kirkwood platforms).
> It's in two sections: the top layer does the card protocol and is
> identical between rpi and kw (could go into /sys/src/9/port?), while
> the lower layer does the host sdio interface.  The two layers link via
> the usual table of functions, so if we encounter a platform with more
> than one sd host interface [anybody seen one?] it won't be hard to
> cope with.
>
> Would anyone with a sheevaplug or similar, and a collection of SD
> cards, like to try it out before I submit a patch?  Source is in
> /n/sources/contrib/miller/9/kw, and if you haven't pulled kernel
> sources recently you'll need to update /sys/src/9/port/sd.h as well.
> The drive appears as '#S/sdM0', and a FAT-formatted SD card can be
> mounted simply by doing "diskparts; dosmnt 1 /n/sd".  You can of
> course hot-swap cards without rebooting, but don't forget to unmount
> first.
>
> Although the driver is called sdmmc.c, it handles only SD cards and
> not the older MMC standard.  I think it's only a matter of slightly
> different initialisation, but I haven't got an actual MMC card to
> test it with.  If anyone cares enough to send me one, I'll see if
> I can make that work too.
>
>

Re: [9fans] sheevaplug SD card driver

[Richard Miller]

> it works
> like a charm.

Thanks.  Patch sdmmc-driver now submitted.

Re: [9fans] sheevaplug SD card driver

[erik quanstrom]

On Fri Oct 19 09:37:40 EDT 2012, 9fans@hamnavoe.com wrote:
> > it works
> > like a charm.
>
> Thanks.  Patch sdmmc-driver now submitted.

could you explain the ccmalloc trick?

- erik

Re: [9fans] sheevaplug SD card driver

[Richard Miller]

> could you explain the ccmalloc trick?

"cache coherent malloc" - not really a trick, just a way to
ensure SD buffers are cache-aligned and occupy an integral
number of cache lines, to avoid embarrassment when doing
dma on ARM (which bypasses the cache).  It costs a bit of
space but saves copying.

Re: [9fans] sheevaplug SD card driver

[erik quanstrom]

On Fri Oct 19 10:01:11 EDT 2012, 9fans@hamnavoe.com wrote:
> > could you explain the ccmalloc trick?
>
> "cache coherent malloc" - not really a trick, just a way to
> ensure SD buffers are cache-aligned and occupy an integral
> number of cache lines, to avoid embarrassment when doing
> dma on ARM (which bypasses the cache).  It costs a bit of
> space but saves copying.

that's what i thought.

we ran into this problem and decided that it was easiest to just
cacheline-align everything in malloc, at the obvious expense of
a tiny bit of memory.  the reason for this was we were using a few
kw devices that could get just about any chunk of malloc'd memory.

ideally we would have written a kw-specific malloc with tracking
segregated from the managed memory.

- erik

Re: [9fans] sheevaplug SD card driver

[Richard Miller]

> easiest to just
> cacheline-align everything in malloc

Might be a good idea for ARM.  Until someone produces a
chip with gigantic cache lines?

Another alternative might be to have a separate pool of
uncached memory.

Re: [9fans] sheevaplug SD card driver

[erik quanstrom]

On Fri Oct 19 11:40:41 EDT 2012, 9fans@hamnavoe.com wrote:
> > easiest to just
> > cacheline-align everything in malloc
> 
> Might be a good idea for ARM.  Until someone produces a
> chip with gigantic cache lines?
> 
> Another alternative might be to have a separate pool of
> uncached memory.

i'm certainly not claiming this is a general solution for all possible
arms, but for kw-style caches (16-byte lines) and kw-style hardware
(very little cache-coherency), i think the idea has a lot of merit.
especially with quickfit with external (that is cache-coherent) tracking.

i really do like your cc malloc, though.  very clean.  though
i had to look twice to verify i understood the pointer orthodontics.
☺.

- erik

Re: [9fans] sheevaplug SD card driver

[Richard Miller]

> kw-style caches (16-byte lines)

mem.h says it's 32.  But yeah, it's not much.

> i had to look twice to verify i understood the pointer orthodontics.

Correctness proof (or refutation) is left as an exercise for the reader...

Re: [9fans] sheevaplug SD card driver

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 122 bytes --]

I think it's better to specify memory that must have special cache
properties, rather than assuming that everything is.

[-- Attachment #2: Type: text/html, Size: 133 bytes --]

Re: [9fans] sheevaplug SD card driver

[erik quanstrom]

On Fri Oct 19 17:31:50 EDT 2012, charles.forsyth@gmail.com wrote:

> I think it's better to specify memory that must have special cache
> properties, rather than assuming that everything is.

this depends on the ratio of memory that has special cache
properties to the memory that doesn't.  if you have devices
like the kirkwood that can do dma, pci transfers, crcs, etc and
it turns out that you can't predict ahead of time what memory
you'd like to transfer, then, making a small concession in
malloc might make sense.  Block*s (well at least the buffer)
needs to be special because the ethernet on the marvell is not
cache coherent.

- erik

Re: [9fans] sheevaplug SD card driver

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

Blocks are intended for IO.

On 19 October 2012 22:49, erik quanstrom <quanstro@quanstro.net> wrote:

> Block*s (well at least the buffer)
> needs to be special because the ethernet on the marvell is not
> cache coherent.
>

[-- Attachment #2: Type: text/html, Size: 496 bytes --]

Re: [9fans] sheevaplug SD card driver

[Richard Miller]

quanstro@quanstro.net wrote:
> i really do like your cc malloc, though. very clean.

Actually I've just noticed that my ccmalloc() function just duplicates
what the standard mallocalign() already does.  So I've removed it from
the yet-to-be-applied sdmmc-driver patch.

Re: [9fans] sheevaplug SD card driver

[Erik Quanstrom]

Interesting.  Speaking of odd bits. Just noticed that devether does qbwrite not pass.  Why? It defeats TCP congestion CTL.

- erik


Richard Miller <9fans@hamnavoe.com> wrote:

>quanstro@quanstro.net wrote:
>> i really do like your cc malloc, though. very clean.
>
>Actually I've just noticed that my ccmalloc() function just duplicates
>what the standard mallocalign() already does.  So I've removed it from
>the yet-to-be-applied sdmmc-driver patch.
>
>
>

Re: [9fans] sheevaplug SD card driver

[lucio]

> Or you can look in /n/sources/patch/sdmmc-driver.

Thanks, will do.  Time to dust off the Plug again.  Thank you.

++L

Re: [9fans] sheevaplug SD card driver

[Skip Tavakkolian]

comment it out and uncomment the line above.


On Fri, Oct 19, 2012 at 8:21 AM,  <lucio@proxima.alt.za> wrote:
>> /n/sources/contrib/miller/9/kw
>
> in "plug":
>
> I see you use /usr/miller/bin/arm/usbd, is there something special in
> it?
>
> Also, "paq" reappears, do we want it, or is it just leftover?
>
>         ripple# diff plug /n/sources/contrib/miller/9/kw/plug
>         59a60
>         >       sdmmc           sdio
>         70a72
>         >       paq
>         72d73
>         < #     paq
>         78c79,80
>         <       /arm/bin/usb/usbd
>         ---
>         > #     /arm/bin/usb/usbd
>         >       /usr/miller/bin/arm/usbd
>         80c82,83
>         < #     /arm/bin/paqfs
>         ---
>         >       /arm/bin/paqfs
>         >       nvram
>
> ++L
>
>

Re: [9fans] sheevaplug SD card driver

[Richard Miller]

>> /n/sources/contrib/miller/9/kw
>
> in "plug":
>
> I see you use /usr/miller/bin/arm/usbd, is there something special in
> it?
>
> Also, "paq" reappears, do we want it, or is it just leftover?

Sorry, this was leakage from my own experiments.  I've now
replaced that plug config with a standard one.

Or you can look in /n/sources/patch/sdmmc-driver.

Re: [9fans] sheevaplug SD card driver

[lucio]

> /n/sources/contrib/miller/9/kw

in "plug":

I see you use /usr/miller/bin/arm/usbd, is there something special in
it?

Also, "paq" reappears, do we want it, or is it just leftover?

	ripple# diff plug /n/sources/contrib/miller/9/kw/plug
	59a60
	> 	sdmmc		sdio
	70a72
	> 	paq
	72d73
	< #	paq
	78c79,80
	< 	/arm/bin/usb/usbd
	---
	> #	/arm/bin/usb/usbd
	> 	/usr/miller/bin/arm/usbd
	80c82,83
	< #	/arm/bin/paqfs
	---
	> 	/arm/bin/paqfs
	> 	nvram

++L