Perhaps TS could make a BIOS for the SD Card functions.
TS would switch to an 8KB EEPROM which doesn't cost much more than the 2KB
EEPROM. The additional 6KB would hold the BIOS that gets loaded into SDRAM as
part of the 2KB EEPROM boot procedure.
This way Linux would not need to use the initrd boot method. People using
Redboot or other OSs could still have access to the SD Cards. And the SD code
does not get released. Everyone is happy!
If PCs can have closed source BIOSes then we can too!!!
-Curtis.
On April 17, 2006 06:28 pm, Jesse Off wrote:
>
> > 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
>
>
>
>
>
>
>
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/
|