CAC 2021-12-02

Trying to boot an FNP.

load_fnp has assembled the gicb and core image and the address to the DIA.

Part of the gicb listing:

       00364  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00365  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00366  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00367  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00370  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00371  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00372  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00373  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00374  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00375  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00376  0 00736                          ind     .rtrn.          spring loaded interrupt vector
       00377  0 00736                          ind     .rtrn.          spring loaded interrupt vector

assm  01  01-07-16   21.261      mcs/fnp intercomputer bootload routine                                page     22

                                       datanet fnp hardware communication region

                                    176        eject
                                    177
                                    178                i n t e r r u p t   c e l l s
                                    179
       00400  000000                180        dec     0               level  0
       00401  000000                181        dec     0               level  1
       00402  000000                182        dec     0               level  2
       00403  000000                183        dec     0               level  3
       00404  000000                184        dec     0               level  4

A dump of the data from the DIA code in the dps8m simulator: (Note that 2 dn355 words are packed into a dps8m word, so the offsets are halved; and the buffer
has a PCW word at the start, moving the offsets up by one. So offset 400 in the gicb would be 201 in the dps8m buffer)

000154 000736000736 000736000736 000736000736 000736000736
000160 000736000736 000722000736 000736000736 000736000736
000164 000736000736 000736000736 000736000736 000736000736
000170 000736000736 000722000736 000736000736 000736000736
000174 000736000736 000736000736 000736000736 000736000736
000200 000736000736 000000000000 000000000000 000000000000
000204 000000000000 000000000000 000000000000 000000000000
000210 000000000000 000000000000 000000000000 000000000000
000214 000000000000 000000000000 000000000000 000000000000

We see that the interrupt cells starting at 400 in the gicb appear at 201 in the dunp; all is good.

Now we are sending the data over to the FNP, one word at a time:

00010172:000736000736
00010173:000736000736
00010174:000574657220
00010175:000474710220

The buffer is corrupt….

Perhaps load_fnp timed out?

Yep; the corruption happens at different locations on different runs. My scheme takes too long.

I can make a local copy and send that, but the way that the bootload completion is supposed to be signaled is that the dn355 signals that it is up and running. Copying the buffer
solves the data corruption problem, but that won't stop load_fnp from timing out.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License