The 16-bit and 32-bit SD interface is completely different from the
7400/7260/7300. The original 7260/7400/7300 core was designed to fit in
200 LUTs of an FPGA but I didn't have that requirement once we started
moving to larger FPGAs. The newer SD FPGA cores are about 500 LUTs and
capable of running at higher FPGA and SD clock rates with more timing
margin and take advantage of wider bus widths (original core was only
8-bits wide).
There have not been any hardware bugs in the FPGA or CPLD Verilog
cores. There have only been few bugs in the low-level closed-source
software cores (mostly to work around quirky SD cards). Most of the
issues we've identified have been in the open-source Linux block layer
shim. This is why we're moving away from writing Linux drivers
altogether and creating all hardware support in userspace via mechanism
such as NBD (for the SD driver) and pseudo-tty's in userspace for serial
ports. In fact, we've only modified a few lines of code for the TS-7500
from the reference kernel for this CPU's eval board which will allow
technically savvy customers more flexibility to pursuit newer kernels
(or operating systems) as they become available.
I'm not sure whats meant by chilling out and "coming clean"? I was
under the impression that the days equating closed-source software to a
life of crime have come and gone from the bulk of the open source
community.
Is this the code you're looking for?
ftp://ftp.embeddedarm.com/misc/sdcore2.c
I hope you're right regarding the recent SD association public release
of the spec. We'll continue to keep the Verilog closed source though at
least for a couple more years. We'll likely release a binary netlist
of that soon for the TS-7500 FPGA reimplementations though.
//Jesse Off
>
|