From: Zach W. <zw...@su...> - 2004-03-18 03:04:25
Attachments:
signature.asc
|
<name withheld in case someone comes rattling the DMCA> wrote: > Zach, > > I've heard often and long that the "SD" standards preclude Open > Source development (having met that mindset on the Zaurus - the SD > driver comes from Sharp in drips and drabs and we *still* don't have > a 2.6 version yet - only up to 2.4.18 - with 2.4.21 promised.) Funny > thing is that Sharp says the Z doesn't even support enough hardware > to actual do the "S" (as in secure) so it's all moot anyway. > There are some free "sample" specs for the SD cards; these are likely what the developers worked from to get to a point that allowed them to reverse engineer the rest. URLs for these specs can be found in an earlier post to this list: http://sourceforge.net/mailarchive/forum.php?thread_id=4036287&forum_id=38940 While I have downloaded them and glanced through them, it will take some time and applied effort to make sense of it all relative to the current state of Linux affairs. > So my question: After searching for a while looking for specifics > (rather than general rumors) I can't find anything that would > actually preclude doing an Open Source SD driver other than the vague > threat of that old demon the DMCA. But if don't do (or want) the > "S"ecure part, then I personally don't see a problem. Do you know of > anything specific that would prevent it? I do not know of a limitation off hand, but that doesn't preclude the discovery of such in the future. This is really a question best posted to the list, because others might have this same question. Some of the following questions are best posed to a lawyer, I hate to say. > I have the binary (with complete symbols) for the Sharp version > (granted it's for the strong-arm (SA-1110 I think) for the 5500, but > the 5600 is PXA and I can download that driver as well - heck it > might be the same binary - I don't know if they changed the SD > hardware between units. I've objdump'd the binary and it looks > fairly modular with really descriptive (hopefully not deceptive) > function names and they are mostly short units. I'm seriously > tempted to do an opensource driver for the Z - do you know why I > shouldn't and do you think it might be helpful to the Gumstix > (assuming the hardware IS compatible - I don't know *exactly* how the > implemented the MMC hardware on the GS.) I *do* know the 4 bit/vs/1 > bit difference between the SD and MMC communication (so I'm told) > but (so I'm also told) the Sharp only uses a 1 bit interface at the > 20 mb/s max rate anyway. I honestly have no idea how the MMC is implemented either; at this point, such endeavors are truly speculation for the bold and adventurous. Since you raise these issues, it's not entirely unfeasible for those with the right skills, but further investigation is required. Personally, I'm not a reverse engineer - I require full specifications to resolve ambiguity. (I've broken enough things that way to simply know reverse engineering problems are not the kind that I enjoy solving.) That said, you would be a true hero to the open source community if you could provide a working SDIO reference implementation on the Gumstix. So to answer your questions, it would be helpful if you *could* do it; I will not enter into the debate as to whether or not you *should* do it. Ask a few lawyers - this is what I would label as a "highly non-trivial intellectual property decision." Or just build it, release the code, and flee to a safe country that will grant you amnesty from the IP gods. But send us a nice postcard occasionally. ;) > I would really rather have a broader choice for expanded memory on > this thing. There might be an I2C or UART controllable CompactFlash chip, but this would introduce yet more duplication with the PXA. Hard to avoid that. Cheers, Zach Welch Superlucidity Services |