> Technically are there two watchdogs on the board, yours and the
Orion one?
We've had two watchdogs on previous boards too. From previous
experience, having your watchdog on the same silicon as the CPU is
less foolproof than an external watchdog. For instance, the CPU
could be get into a SCR latchup state with some nasty ESD in which
the internal watchdog becomes useless. The 2nd watchdog on the 7800
is on the AVR and the AVR chip has direct control to a MOSFET to cut
off the board power. Most embedded engineers will trust a low tech
extremely rugged AVR chip with direct control over power more than a
self-policing internal watchdog on the same chip as the CPU.
> I'm only guessing as it looks like the microsecond timer you added
is defunct
> being that the two orion nanosecond accurate timers are there?
No. Its there for a reason. It starts counting up at 0 when the
FPGA first comes alive allowing us to more accurately measure and
test bootup time optimizations. Also, a timer available in precise
microseconds is sometimes more convenient than doing math on 166Mhz
counters. The feature cost about 40 LUTs out of 12000 and all of 30
seconds to implement. It cost the company more to write this
paragraph than include the timer. Up till a few days ago, I forgot I
even implemented it in the FPGA.
> A guess in the dark is that you were more comfortable with your
> own hardware implementations than the Mavell supplied ones? Same
> applies for DMA, any reason the Mavell DMA engines (all four of
> them) could not be used on your NAND? This I'm asking as one day
> I plan to build a driver that hooks the Marvell DMA engines to the
> DMA offloading framework (along with the crypto and XOR
> accelerators)...the FPGA based DMA thingy seems kinda out of place.
The Marvell IDMA has no provision for DMA op initiated from an
external pin. It is just CPU offloaded memory to memory copy; the
NAND controller uses bus mastering. You could use IDMA for NAND
if you wanted -- though you'd have to make sure you don't do your
DMA when the NAND is not ready (this is handled automatically on
the FPGA DMA core). Perhaps I should have named that internal FPGA
core something like "bus master coordinator" rather than DMA to
avoid naive assumptions about its function and tempt NIH syndrome
style redesign. Please, if you are serious about changing the MTD
driver, do so, but please, please have a better reason for changing
things than subjective "seemings of out of placeness". This kind of
rationale for rework I would expect from artists, not engineers.
Even if IDMA did have external DRQ support, we wouldn't have wasted
a pin on the FPGA to use it. Performance would still suffer with
the Marvell IDMA core. This is because it is on the other side of
the PCI bus issueing non-burstable PCI reads. The PCI
request/response latency would limit practical throughput probably to
something around 4 megabytes/sec. In PCI peripheral design, you do
whatever you can to minimize PCI read transactions as reads
inevitably stall pipelines-- bus mastered burst writes are best for
max bandwidth when trying to get data from one chip to another.
Having said that, there are plenty of opportunities for improvement
in the MTD driver. The NAND controller acheives 17 megabytes/sec
in the 4kbyte bootrom code, but only 10 megabytes/sec in our Linux
MTD driver. Some portion of that discrepancy may be beyond the
driver itself and be a result of MTD, general Linux, and/or block
layer deficiencies, but certainly not out of scope for an ambitious
kernel developer to fix/improve.
//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/
|