ts-7000
[Top] [All Lists]

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

To:
Subject: [ts-7000] Re: Greg Kroah-Hartman's response to SD-flash close source driver solution:
From: "charliem_1216" <>
Date: Fri, 23 Mar 2007 16:39:34 -0000
Hi Jesse --

Thanks for the insights.

--- In  "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-

How, w/o TS?  You mean using TS sdcore.o and sdcard.o in 2.6, or
without TS modules at all?  This seems close to the binary firmware
blobs that are now in use for many devices (distributed with the
kernel has hex files or some such).  Too bad we can't take that route
(can we?).

> 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 

What about EABI?

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

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

OK, I can understand that.  But OTOH, the 2.6 TS SD driver (were it to
 be released), would not be useful to anyone without a TS board,
right?  And you could still use it to attract bare-metal customers.

> > 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,

Yes, I would not expect TS to transition shipping products.

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

That's wrong and uncalled for.  I think you mis-interpret 'backward
hardware compatability' with 'stable internal API compatability'. 
Others have explained it much more eloquently that I, but AFAIK:

* Linux has no guarantee of internal, kernel API stability,
_especially_ across major versions like 2.4 to 2.6.  (And with the
develoment model used now, even within the 2.6 series to a smaller extent)

* Vendors and developers are encouraged to get their drivers released
and included in the kernel.  This virtually guarantees long-term
community HW support, even as internal APIs change.  If a kernel
developer changes an internal API, he also takes on the implied
responsibility of fixing every driver he breaks.

* Vendors that choose not to work for driver inclusion in main-line
have extra work to do, and this is true whether the outside modules
are binary only (ie VMWare, Nvidia), or open (ie, cirrus stagnating
2.6 kernel drivers).

The end result is that HW support, once in the mainline kernel, lasts
quite a long time.
   
> Our next SBC will be 2.6 based however.

Great news!

> 
> //Jesse Off
>

Regards, ............ Charlie



 
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