31 Dec
2012
31 Dec
'12
10:02 a.m.
Jan-Benedict Glaw wrote:
On Sun, 2012-12-30 20:36:49 +0100, Holm Tiffe <holm
at freibergnet.de> wrote:
I've compiled your program and it is still dumping the rtVAX..
a little slow. In the meantime I wrote a small converter that
I used to convert the previous ascii dump out of the VAX Console
to binary.
Do you use the XFER feature of the VAX console? ...haven't looked at this
jet..
The binary ROMfile is here:
http://www.tiffe.de/robotron/VAX/rtVAX300-v1.2.bin
This is Neat:
"The guilty parties are:
Yousif Asfour, Hardware
Mike Moroney, Firmware
John Day, That funny memory board
Gene Smith, Tester board
Bill Heavey, Hold 5 minute meetings
that last 3 hours
Andres Tirado, Get mad because it
is not done yet"
BTW: Why you are fiddeling with the bits in termios.c_cflag for the Baud
rate when functions like
speed_t cfgetospeed(const struct termios *t);
int cfsetospeed(struct termios *t, speed_t speed);
int cfsetspeed(struct termios *t, speed_t speed);
and friends are existing?
...patched the serial.c a little since I have no CBAUD or CBAUDEX
definition on my system.
Kind Regards and a happy new Year!
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Mouse wrote:
Fast Check:
P 20040000 0004A531
P 20040004 09110002
P 20040008 6E6E6E6E
> Did
you read the internal EEPROMs out already?
No. How should I do this?
Are they socketed?
The only way todo is reading them with the
internal Console Software,
but at first I had to know on wich Address a VAX is starting and if
the MMU is mapping the ROM somewhere later ...
You _probably_ can read them with e/l/p from the console, with suitable
addresses - I think that's how I dumped my KA630's ROM.
The problem, of course, is determining the "suitable addresses". In
the case of the KA630 I dealt with, the manual says: EK-KA630-UG-001
says, on page 3-2, that the ROM appears twice in physical address space
(once at 20040000-2004FFFF and again at 20050000-2005FFFF). I seem to P 2004000C 03020100
P 20040010 55555555
P 20040014 AAAAAAAA
P 20040018 33333333
This is the start of the system ROM, as used with the usual 3100 /
4000 class of machines. My reading of this (I've dumped a good number
of ROMs) is that the firmware is provided by four ROMs, each supplying
one byte of a longword.
[...]
...at least here is something, but w/o knowing
the machine code, I would
say that this are some vectors, not code and that followed by some
deadbeef.
You usually have some header, containing a JMP to the ROM's actual
start address. These ROMs are usually 64, 128, 256 or 512KB.
Usually, the last part of the ROM isn't used (and thus filled with
all-0x00 or all-0xff), except the very last four bytes, which often
hold a checksum. That way, it's quite easy finding the correct length.
Just jump the contents of the supposed end addresses and see if it's
all zeroes (except a 4-byte checksum that's probably there.)
I'd be _highly_ interested in getting a ROM dump! I once wrote a
firmware dumper helper, that reads the ROM byte-by-byte (slow using a
serial link, but it works.) You can find it at
http://vax-linux.org/gitweb/?p=firmware_dumper.git;a=summary
For a VAX, you probably need to start it like this:
$ ./dumper --target vax --device /dev/ttyS0 --speed 9600 --bits 8 \
--parity N --stop 1 --outfile rtVAX300.bin --start 0x20040000 \
--len 524288 --scheme 3
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de +49-172-7608481
Signature of: Fortschritt bedeutet, einen Schritt so zu machen,
the second : da? man den n?chsten auch noch machen kann.