HI All,
> I think sparsemem is working OK in 2.6.28+, modulo one bug exposed by 'cat
> /proc/pagetypeinfo'. Mel Gorman wrote a patch addressing that, but I haven't
> checked lately to see if it made it into 2.6.30 yet:
> http://marc.info/?l=linux-arm-kernel&m=124238736603218&w=4
>
>
Ok - that is great to hear. I didn't want to go too far with upgrading
to newer kernels without verifying that the memory management was
sound. When I did the initial 2.6 porting work I had about 1000 lines
of debug code in the kernel; it wasn't particularly easy - mainly
because I had to teach myself how the memory management subsystem of
arm/linux worked. (and subsequently I've forgotten it all!)
>
> This would be great. I think TS just doesn't see or doesn't understand the
> benefits of releasing the code.
>
> IIRC, one TS concern was an NDA they signed, but every NDA I've seen has had
> an escape clause (paraphrasing): if the secrets are revealed through other
> means and become widely known, the parties are released from the NDA. Sounds
> like the SD association voided a lot of NDAs when they published the SD
> commands.
>
>
Yeah - agreed. They've just got a 4 bit fifo in there with some
signaling logic. Open source it - keep it simple.
> So you have a modified driver, which requires a modified binary blob?
>
I have a modified tssdcard.c (the component that TS distributes as
source code). It will work both with TS's sdcore.o blob, sdcore2.o blob
(and presumably others). It will also compile against my sdcore.c which
is roughly a hand-decompiled and rethought variant of sdcore.o. The
advantage of using my sdcore.c is that it paves the way for using DMA
writes - and also allows us to expose bugs. Finally, this driver layer
does use one of the open source m2m dma drivers - it does not directly
bang bits onto the m2m registers.
The main complaint I have with both my implementation and TS's is the
amount of timing loop code fixes; and general junk code required to
control the sdcard interface. Finally, neither is a proper MMC driver
implementation - i.e. interfacing with Linux's existing code. Both
drivers are direct block drivers; there is likely mileage using and
extending the mmc interfaces.
>> My main question - and primarily one for the GNU's lawyers is whether or
>> not I can release the code under a GNU license.
>>
My question is now pending with GNU - ill wait to see what response we get.
> I'm pretty sure you cannot release a modified binary blob. Perhaps you could
> release a script that would patch the blob, so anyone who has a license for
> the blob could modify it as you did.
>
Decompiled and rethought - the c code compiles to a linkable module.
But my problem here is where to draw the gray lines...
Cheers,
-Brett
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|