[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.

[Gorka Guardiola]

Post by 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.

This is very nice work. Thanks.

Post by Richard Miller
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.

[David du Colombier]

Post by Richard Miller
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.

[Richard Miller]

Post by David du Colombier
it works
like a charm.

Thanks. Patch sdmmc-driver now submitted.

[erik quanstrom]

Post by Richard Miller

Post by David du Colombier
it works
like a charm.

Thanks. Patch sdmmc-driver now submitted.

could you explain the ccmalloc trick?

- erik

[Richard Miller]

Post by erik quanstrom
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.

[erik quanstrom]

Post by Richard Miller

Post by erik quanstrom
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

[Richard Miller]

Post by erik quanstrom
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.

[erik quanstrom]

Post by Richard Miller

Post by erik quanstrom
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

[Richard Miller]

Post by erik quanstrom
kw-style caches (16-byte lines)

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

Post by erik quanstrom
i had to look twice to verify i understood the pointer orthodontics.

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

[Charles Forsyth]

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

[erik quanstrom]

Post by Charles Forsyth
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

[Charles Forsyth]

Blocks are intended for IO.

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

[Richard Miller]

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.

[Skip Tavakkolian]

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

Post by 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.

[l***@proxima.alt.za]

Post by 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?

ripple# diff plug /n/sources/contrib/miller/9/kw/plug
59a60

Post by Richard Miller
sdmmc sdio

70a72

Post by Richard Miller
paq

72d73
< # paq
78c79,80
< /arm/bin/usb/usbd
---

Post by Richard Miller
# /arm/bin/usb/usbd
/usr/miller/bin/arm/usbd

80c82,83
< # /arm/bin/paqfs
---

Post by Richard Miller
/arm/bin/paqfs
nvram

++L

[Richard Miller]

Post by l***@proxima.alt.za

Post by Richard Miller
/n/sources/contrib/miller/9/kw

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.

[l***@proxima.alt.za]

Post by Richard Miller
Or you can look in /n/sources/patch/sdmmc-driver.

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

++L

[Skip Tavakkolian]

comment it out and uncomment the line above.

Post by l***@proxima.alt.za

Post by Richard Miller
/n/sources/contrib/miller/9/kw

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

Post by Richard Miller
sdmmc sdio

70a72

Post by Richard Miller
paq

72d73
< # paq
78c79,80
< /arm/bin/usb/usbd
---

Post by Richard Miller
# /arm/bin/usb/usbd
/usr/miller/bin/arm/usbd

80c82,83
< # /arm/bin/paqfs
---

Post by Richard Miller
/arm/bin/paqfs
nvram

++L

[Erik Quanstrom]

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

- erik

Post by Richard Miller

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.