> A TS-7260 would not need NAND flash if we booted directly from an
SD Card.
> Perhaps TS could sell this as an option!
The TS-7300 does this. No NAND flash whatsoever. Boots an initrd
that loads the module and then mounts the SD card as root. To make
the TS-7260 w/SD do this would be as simple as rewriting the 2KB
EEPROM with the TS-SDBOOT boot program in the TS-7300. The TS-7260
and TS-7300 have the SD card registers in the same spot. Building
the TS-7260 without NAND flash is a real possibility just like
building it with 256MB SDRAM would be. Both are in the realm of
trivial modifications we could do free of charge if someone would
agree to some minimum quantity. We can still do this one or two
boards at a time, but we end up having to charge a rework fee to
remove the chip from existing stock.
>
>
> So my question is this:
>
> Will TS provide us with the CPLD SD Flash registers?
>
We might be able to, but we're a little intimidated by the rules of
the SD card association and prefer to stay safe and not get on their
bad side. :-) The SD core in the TS-7260 and TS-7300 was designed
for minimum FPGA size (~220 LUTs). The way it was designed it is
extremely reliant on intelligent software (think of it like hardware
accelerated bit-banging) so I'm not sure how much good just
describing the registers would be without the SD specification
documents and intimate knowledge of the source Verilog. We looked
at other off-the-shelf SD cores we could purchase that could do the
4-bit SD modes, but they ended up wanting around 2000 LUTs and were
quite expensive-- I imagine these you may be able to make useful and
reverse engineer a driver with just a register map.
What we have planned to do is to release an ARM .o with generic OS-
independent read/write routines and also expose some of the neat SD
association proprietary security functionality. This would allow
Linux developers to write/rewrite the Linux block driver, but
Linux's GPL licensing would still prohibit the code from ever being
included in the kernel. As-is, the initrd kludge isn't really too
bad and only adds maybe 1.5-2.5 seconds to the root FS mount. This
could even be made faster with a fancier initrd that doesn't use
busybox. What would be really nice is a more elegant way than using
initrd's that run "insmod" in a shell script to link in kernel
modules pre-boot. Initrd's seem to give everyone thats had to use
them an impression of kludginess-- probably because 99% of the work
in designing an initrd has nothing to do with the relatively simple
thing you're likely trying to do.
//Jesse Off
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|