[time-nuts] Z3805A flash dump.

[Herbert Poetzl]

On Wed, Apr 17, 2013 at 08:31:49AM +0000, Mark C. Stephens wrote:
> I have dumped the 4 flash ROMS from my latest Z3805A but 
> I can't make head nor tail of the contents. 

> I am thinking the flash are interleaved.

Interleaving makes sense for performance reasons and
usually happens at bit or byte level, but I'm not (yet)
convinced that the data was dumped correctly.

> http://www.vk2hmc.net/blog/wp-content/uploads/2013/04/z3805-flash.rar

Assuming that the Z3801A and Z3805A ROM contents is
somewhat similar (1x512k = 4x128k), let's take a look
at the entropy of the data:

$ cat z3801a.bin | xz --stdout | wc -c
  110020

$ cat z3805-*.bin | xz --stdout | wc -c
   60436

This rough estimate on the amount of non redundant
data shows that the z3801a ROM contains almost twice
as much data than the z3805 ROM dumps together.

$ for n in z3805-*.bin; do xz --stdout $n | wc -c; done
   25108
   30724
   24712
   22812

This shows that the data is almost evenly distribute
between the four dumps, so some kind of interleaving
is obviously present and none of the files are purely
random or contain just padding or similar like:

$ dd if=/dev/urandom bs=1k count=128 | xz --stdout | wc -c
  131140
$ dd if=/dev/zero bs=1k count=128 | xz --stdout | wc -c
     152

Now looking at the data itself, it is simple to see
that there is a positional redundancy present:

$ for n in z3805-*.bin; do xxd -g 1 $n | head -1; done
0000000: 6f ff 00 05 04 05 00 05 10 05 00 05 28 05 00 05  o...........(...
0000000: 6f 10 00 05 04 fe 00 05 10 00 00 05 28 50 00 05  o...........(P..
0000000: 6f a0 00 05 04 00 00 05 10 42 00 05 28 42 00 05  o........B..(B..
0000000: 6f 00 00 05 04 ff 00 05 10 00 00 05 28 05 00 05  o...........(...

Columns 1, 3, 4, 5, 7, 8, 9 ... are all equal, only
the columns 2, 6, 10, 14 ... contain different values
across the files, which basically means that 3 out of
4 bytes are completely identical between the 4 dumps.
(this is, where I think something might have gone
wrong with the dumps :)

Anyway, extracting the data from the columns where the
dumps actually differ gives the following data [1]:

$ xxd col.data | head -4
0000000: ff10 a000 05fe 00ff 0500 4200 0550 4205  ..........B..PB.
0000010: 0510 0000 05b4 1105 0510 0000 05b4 0005  ................
0000020: 0510 1100 05b4 0005 0510 0000 05b4 1105  ................
0000030: 1310 0000 05b4 0005 0510 1100 05b4 0005  ................

Comparing this with the dump from z3801a ROM:

$ xxd z3801a.bin | head -4
0000000: 0010 fffe 0000 0550 0010 05b4 0010 05b4  .......P........
0000010: 0010 05b4 0010 05b4 0010 05b4 0010 05b4  ................
0000020: 0010 05b4 0010 05b4 0010 05b4 0010 05b4  ................
0000030: 0010 05b4 0010 05b4 0010 05b4 0010 05b4  ................

Suggests that there is some kind of reordering required
to get the similar structure present in the hardware
vector table.

The following mapping seems to do the trick:
Pick every odd byte from the data and switch every
two resulting bytes, or as pseudocode:

    for (n = 0; n < 2; n++) {
        for (i = 0; i < dlen; i += 4) {
            j = i/2;

            split[n][j + 0] = data[i + n + 2];
            split[n][j + 1] = data[i + n + 0];
        }
    }

The resulting data [2] seems to contain meaningful 
strings and binary code similar to the z3801a ROM:

$ strings split.data | grep psos
>@(#)$Header: psos.S,v 1.4 95/01/11 15:27:21 jacob Exp $
@(#)$Header: psos_indep.h,v 1.5 95/03/24 15:24:19 da oe uxn d
>@(#)$Header: psos.S,v 1.4 95/01/11 15:27:21 jacob Exp $
@(#)$Header: psos_indep.h,v 1.5 95/03/24 15:24:19 da oe uxn d

HTH,
Herbert

[1] http://vserver.13thfloor.at/Stuff/VARIOUS/Z3805/col1.data
[2] http://vserver.13thfloor.at/Stuff/VARIOUS/Z3805/split1.data

> I can't see any strings that make sense like the Z3801A flash.


> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.