Note:

This is the very first version of firedump, it's based on fireproxy which is
based on firescope, but uses physical block reads (fast) instead of physical
quadlet reads, thereby reaching about 10MB/s on normal Firewire 400 with S400
wire speed.

It does not take any options but instead only attaches to the first non-local
node and dumps all memory from 1M-2G to stdout and gives progress and errors
to stderr. You can change the range which is being dumped by modifying the
main function, but it will be very hard (or maybe even impossible) to dump
memory above the 4GB limit.

Note that this rather rude way of dumping can cause the choosen target to
completely lock up if the address range which is read is not filled
entirely with useable memory as defined in the e820 map of the target.

A proper implementation should sequire the System.map of the target's kernel
look up the location of the e820 memory range buffer (e820.nr_map/e820.map[])
from it, read it and only dump useable RAM, but no reserved address ranges.

As for setting up the machines, see the "Getting started" section in
debugging-via-ohci1394.txt - just use firedump instead of firescope
in the last section for taking the dump.

Cheers,
Bernhard Kaindl
============================================================================

Implementation details (not expected to be understood by users)
----------------------

The physical block read size used in this version is 2048 bytes, but it can
be changed to other sizes by chainging the BLOCKSIZE define.

The information below on the maximum payload size of block requests has
been provided (collected by Bernhard Kaindl) by Stefan Richter:
-------------------------------------------------------------------------
The maximum payload size of block requests depends on three things:
1. speed of the connection between the two nodes (debugged machine and
debugging machine), 2. link layer controllers of the two nodes, 3.
software on the debugging machine.

1.) S100: 512 bytes, S200: 1024 bytes, S400: 2048 bytes, S800 and more:
4096 bytes.

If there are only 1394a nodes, you can read the connection speed from
the speed map registers on the debugging machine.  It becomes difficult
for 1394b nodes and some mixtures of 1394a and b nodes.  But consumer
1394b hardware is always S800 capable.  Consumer 1394a hardware is
always S400 capable.  Except consumer camcorders which are AFAIK
typically limited to S100, but they have only one port and will
therefore never sit between debugging and debugged PC.  So it's not as
difficult in 99.9% of the cases:  You can expect S400, some people might
get S800.  But you can't use the bigger S800 block size if the debugging
machine runs ohci1394.

2.) Controllers on CardBus cards are limited to 1024 bytes payload of
asynchronous packets, for reasons I don't know.  The other available
controllers only have the above mentioned speed-dependent limit.

This is relevant if the debugging or the debugged PC have a CardBus
card.  Actually this is the limit of all 1394a CardBus card I have seen;
I don't know about 1394b CardBus cards, or Express cards.  (I suppose
Express cards have no limits of this kind, as they are just PCIe cards
in a different formfactor.)

This payload limitation of the link can be read from the bus info blocks
of the debugged and the debugging machine.  Though I am not entirely
sure right now if the ohci1394_earlyinit driven machine will have its
bus info block properly set up.

Note from Bernhard Kaindl: The FireWire card which I used on the dumping
machine while testing this version of firedump is a CardBus card, and it
I was able to use 2048 byte block size with it. Maybe something was splitting
up the read into multible chunks but on application side, I requested and
received block sizes of 2048 bytes. Maybe this limitration only applies
for the sending, not the receiving side of large packets?

3.) The ohci1394 driver has an implementation limitation which requires
that all packets including headers don't exceed PAGE_SIZE.  This does
not affect the packets which go through the physical response unit
(which they do on the debugged machine) but it affects the debugging
machine.
-------------------------------------------------------------------------

This, as I understand it, means that we should be able to use 2048 bytes
payload size normally (except with some/most? CardBus cards), and the we
might (in theory) be able to use 4096 bytes payload size when the data
transfer takes place only between 1394b nodes which are in S800 mode.
