ts-7000
[Top] [All Lists]

Re: [ts-7000] Re: Greg Kroah-Hartman's response to SD-flash close source

To:
Subject: Re: [ts-7000] Re: Greg Kroah-Hartman's response to SD-flash close source driver solution:
From: Paulo Marques <>
Date: Fri, 23 Mar 2007 03:02:16 +0000
Jesse Off wrote:
>>I guess this discussion is in the TS-7000 group since TS delivers only
>>a binary object file SD.o for SD card support.  Obviously this is a
>>stumbling block for those of us who prefer 2.6 kernels.
> 
> A 2.6 driver could still be made without TS.  TS delivers a OS-
> independent gcc or IAR compiled object file sdcore.o that contains a 
> simple and stable C API to access the SD card.  We publish a sdcard.c 
> Linux API "shim" that uses the sdcore.o routines (sdread(), sdwrite
> (), sdreset()) to implement Linux 2.4's block driver interface.  We 
> have several people using this .o in their own non-Linux applications 
> running on the raw hardware without an OS.

It is not as easy as using an open source module, but I can understand 
why TS needs to do this (SD association NDA's and stuff).

>>I can see why TS prefers this, (SD NDA in effect when they bought the
>>earlier spec from the association), but are there any other issues? 
>>Is there TS ip that needs to be protected?
>>
>>Can TS take a look at the released spec, and say "Yes, that has a good
>>chance of working with our SD slot via our FPGA"?  Or "No, it's close
>>but you need these changes ..."?
> 
> TS created an SD host controller core in Verilog that only uses 200 
> LUTs on a CPLD and 4 8bit registers.  This is very small compared to 
> companies selling standard SD logic cores.  Existing soft cores on 
> the market require much larger and expensive FPGAs.
 >
> Since the core is so small (20 times smaller than the SDHC), it 
> doesn't even come close to resembling the standard SDHC, so existing 
> SDHC drivers have no chance of working.  The hardware is basically a 
> GPIO port with some SD specific accelerations-- most of the 
> complexity and IP is in the sdcore.o routines.

That seems like a good cheap solution (and I say cheap in a good way, 
here), both from a cost of hardware perspective and probably from a 
power consumption perspective, too.

> Yes, we do have an interest in protecting this IP.  The smallness of 
> the logic core and the simplicity and OS-independence of the 
> sdcore.o "BIOS" make it valuable.  We use this IP with others to 
> attract customers for our custom designs business.

What IP? If your valuable IP is a small module that has a couple of 
functions that can't be more than a few hundred lines of code long...

I can understand that you can not expose the code because of NDA's.

Now, saying that it is a _valuable_ IP that needs protection is just 
crazy. You get 6 millions lines of code in the linux kernel for free, 
and then you protect your few hundreds because it is valuble IP.

Come on, stop protecting the SD association and their bullshit. That is 
not your fight, don't stand in the crossfire.

>>Of course I can't expect TS to support 2.6 kernels; I disagree with,
>>but respect their decision.  But a few hints to help a community
>>written & supported SD driver would mean everybody wins.
> 
> Our large customers freak out when the board silkscreen changes 
> colors-- transitioning our shipping TS-7000's to 2.6 would be chaos, 

No one is asking that you _ship_ a 2.6 kernel in your boards. People are 
just asking you to help out in the 2.6 kernel port.

And even for that saying that you have no paying costumers to support 
that work is a perfectly fine answer, that I have absolutely no problem 
understanding. Hey, I bought 2 TS-7400 boards with a 2.4 kernel, I knew 
what I was getting into. I knew the burden of making 2.6 working on them 
was on me.

> especially knowing now that Linux considers backward compatibility 
> nonsensical.

That was totaly uncalled for and weasely. I wrote on another post that 
Linux tries very hard to keep user-space backwards compatibility even to 
make it work in systems that have been long deprecated by their own 
manufacturers.

You never bothered replying to that email, and now you try to put words 
in my mouth? What is that?

> Our next SBC will be 2.6 based however.

Glad to ear,

-- 
Paulo Marques


 
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/
 

<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU