--- In "charliem_1216" <> wrote:
>
>
> Hi Jesse--
> > ------
> > The TS-7500 was released Jul. 2009 is a small embedded board with
> > a CNS2132 250Mhz ARM9 CPU, Lattice XP2 5k FPGA, 64MB DDR SDRAM,
> > and 4MByte SPI NOR flash chip.
> >
> > Hardware features include:
> > *) 250Mhz Cavium ARM9 CPU core (Faraday 526)
>
> Is there a developers manual available for this chip from Cavium?
There is. Our copy of this manual was given under NDA though and has a
watermark saying so on every page of the 344 page PDF. If I remember
correctly, it was not difficult to get the NDA from Cavium. Next time we talk
to our Cavium rep, we'll try to lobby them to release a more open datasheet we
can send to curious customers.
> > Software features include:
> > *) Boots 2.6.24 Linux out-of-the-box in 2.65 seconds (to shell prompt)
>
> Just curious, why you settled on 2.6.24, released Jan-08? Haven't looked
> yet, but I guess this is all EABI? If so, you could add that as a feature in
> your marketing (something most ARM developers are aware of now).
2.6.24 was the newest kernel Cavium provided. Ronald also ported 2.6.30, got
it booted, but had some issues that caused us to instead release with the
known-good Cavium provided kernel. We were quoted $30,000 and several man
months of time by a respected Linux community kernel developer to help port the
Cavium 2.6.24 patches to 2.6.30.
This CPU cannot run EABI. The EABI architects did not accomodate the
possibility in their specification that there may be a CPU created that did not
have Thumb support. EABI uses a couple ARM opcodes ("bx", and "blx")
explicitly created for ARM -> Thumb interworking that an ARM processor without
Thumb does not have. The Faraday core that Cavium/STAR semiconductor uses
removed the Thumb core likely since it is mostly obsolete and unnecessary on a
250Mhz CPU with 64MBytes DDR SDRAM. Unfortunately, the FA526 CPU core will
never run EABI in its current form.
> I found these binaries on the FTP site. Any plans to release the sources
> also? They seem to be core requirements for running this card well. When
> the inevitable bugs are found by customers beating on them, the TS-7500
> community could participate in solving them, rather than putting the onus
> back onto an over-burdened TS support team.
Yes, I'll be releasing this source code shortly.
> Again, I need to do more reading on NBD and how you are using it. But it
> seems to be quite a durable & useful interface. It continues to refined on
> the kernel side, ie, a big warning on nbd.sf.net is not to use it as a client
> & server on one machine, but this is solved by:
> http://lwn.net/Articles/267685/ I'm not sure if that made it into your
> 2.6.24 kernel.
I really don't think our implementation is vulnerable as our nbd server is
different and does not host NBD images from files. All memory allocation is
done and mlock()'ed before the NBD server starts up. Servicing the actual NBD
requests requires no kernel support as the sdctl process fills in the responses
completely on its own via hardware registers.
> Interesting approach, time will tell it's effectiveness. You gain some
> independence, but loose in other ways. For example, sounds like there is no
> rtc device driver?
Correct. Instead of hwclock --hctosys, we have ts7500ctl --getrtc. I don't
really see much a point to a kernel-based RTC driver for the I2C RTC we are
using, the functionality it needs to be implemented in userspace is already
provided via settimeofday() syscall.
> Seems you should look into the patch above (unless it's in 2.6.24) to keep
> nbd from locking up under memory pressure.
The issue we've had is not NBD locking up under memory pressure, its Linux
doing demand paging of executables on a process that might be holding the SBUS
lock. We've worked around this particular issue from userspace by defeating
demand paging on the *ctl binaries or anything using the sbus.c raw hardware
access API. (which, BTW, is temporarily at
ftp://ftp.embeddedARM.com/misc/sbus.c ftp://ftp.embeddedARM.com/misc/sbus.h )
>
> attached
> > /dev/nbd0 through /dev/nbd4 as follows:
> >
> > /dev/nbd0 - whole disk device of microSD card
>
> I see a recent patch for partitions on nbd:
> http://lwn.net/Articles/276044/
> This was incorporated into the kernel, and makes partition handling a little
> easier.
Thanks, I will look into that. That looks like a more appropriate way to
handle NBD partitions.
> Thanks for trying to get these low-level details out in a timely manner.
> From the POV of a potential customer seeing your ad, and interested by the
> FPGA, he might have two questions:
> * Does TS release the default load of the FPGA, so I can experiment & learn a
> new skill by adding my own functions?
Give me another week or so and I'll have written the tool to update the FPGA
and also a Lattice opencore for the TS-7500. Some of our cores will be
available in full source, some will be Lattice black box netlist-only modules,
but you will be able to build your own post-bootup FPGA bitstream for loading
via "ts7500ctl --loadfpga bitstreamfile" that retains all functionality
(including SD) as the FPGA config loaded from powerup by internal flash.
> * If not, what functions of the card will I lose if I try to develop on the
> FPGA myself?
We will not be providing our FPGA logic necessary for executing TS-BOOTROM on
initial power-on. This logic is unnecessary anyway once the board is booted.
We don't want customers attempting to rewrite the FPGA internal flash and
bricking their boards -- all mechanisms I intend to provide will only be for
reloading the FPGA SRAM configuration post-bootup from ts7500ctl.
//Jesse Off
------------------------------------
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/
|