[Simh] MOP header specs?

Discussion:

Tim Stark

2018-02-21 03:13:50 UTC

Folks,

Does anyone know any documentation provides some information about MOP
header in SYS files?

Look at first 256 bytes of SYS files:

00000000: A8 00 30 00 44 00 58 00-00 00 00 00 30 32 30 35
|..0.D.X.....0205|

00000010: 01 01 00 00 FF FF FF FF-FF FF FF FF 00 00 00 00
|................|

00000020: 20 00 00 01 00 00 00 00-00 00 00 00 00 00 00 00 |
...............|

00000030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|

00000040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|

00000050: 00 00 00 00 00 00 00 00-03 4D 4F 50 00 00 00 00
|.........MOP....|

00000060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|

00000070: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|

00000080: 04 56 31 2E 30 00 00 00-00 00 00 00 00 00 00 00
|.V1.0...........|

00000090: 00 00 00 00 00 00 00 00-05 30 35 2D 30 35 00 00
|.........05-05..|

000000A0: 00 00 00 00 00 00 00 00-10 00 87 15 00 00 00 00
|................|

000000B0: 80 00 00 00 02 00 00 00-00 00 FF FF FF FF FF FF
|................|

000000C0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|

000000D0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|

000000E0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|

000000F0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|

Thanks,

Tim

Paul Koning

2018-02-21 14:32:39 UTC

Permalink

MOP is a protocol, not a storage spec. The protocol is defined in detail, in the MOP architecture spec, which can be found in various collections of DECnet architecture specs.

I assume a SYS file is a file meant to be downloaded by a MOP server on some host. What the file contents means depends on what the sender and/or receiver do with that data; the MOP protocol spec has no opinion about it. So the question actually becomes: what do the MOP server on OS x, and/or the MOP client on hardware or OS y, expect to see in the header of the file used for MOP request z?

paul

Post by Tim Stark
Folks,
Does anyone know any documentation provides some information about MOP header in SYS files?
00000000: A8 00 30 00 44 00 58 00-00 00 00 00 30 32 30 35 |..0.D.X.....0205|
00000010: 01 01 00 00 FF FF FF FF-FF FF FF FF 00 00 00 00 |................|
00000020: 20 00 00 01 00 00 00 00-00 00 00 00 00 00 00 00 | ...............|
00000030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |................|
00000040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |................|
00000050: 00 00 00 00 00 00 00 00-03 4D 4F 50 00 00 00 00 |.........MOP....|
00000060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |................|
00000070: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |................|
00000080: 04 56 31 2E 30 00 00 00-00 00 00 00 00 00 00 00 |.V1.0...........|
00000090: 00 00 00 00 00 00 00 00-05 30 35 2D 30 35 00 00 |.........05-05..|
000000A0: 00 00 00 00 00 00 00 00-10 00 87 15 00 00 00 00 |................|
000000B0: 80 00 00 00 02 00 00 00-00 00 FF FF FF FF FF FF |................|
000000C0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF |................|
000000D0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF |................|
000000E0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF |................|
000000F0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF |................|
Thanks,
Tim
<dump.txt>_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh <http://mailman.trailing-edge.com/mailman/listinfo/simh>

Timothe Litt

2018-02-21 15:18:21 UTC

Permalink

MOP is a protocol, not a storage spec. The protocol is defined in
detail, in the MOP architecture spec, which can be found in various
collections of DECnet architecture specs.

Yes

I assume a SYS file is a file meant to be downloaded by a MOP server
on some host. What the file contents means depends on what the sender
and/or receiver do with that data; the MOP protocol spec has no
opinion about it. So the question actually becomes: what do the MOP
server on OS x, and/or the MOP client on hardware or OS y, expect to
see in the header of the file used for MOP request z?

Yes.
.SYS is a common extension for files loaded by MOP, though it has other
uses in the DEC multiverse. I've seen it used for PDP-11 code; for
68000 code (used in terminal servers); for VAX code.

MOP load often gets you a secondary loader, which is capable of
multi-block loads. And that usually loads a tertiary loader, which can
interpret an image file format. But this is all architecture specific.
The server knows nothing about it - it serves bits. The bits are
specified with NML (NCP) in the MOP load database. The PDP-11 boot
architecture is an appendix in the MOP spec. But it's not mandatory,
and other clients can (and do) vary.

The client gets whatever bits are sent & executes them. Well, it's
expected to. MOP could be used to load a bitmap into a graphics buffer
- it takes bits and puts them into memory. After that, it's up to the
client.

Tim would do better to tell us the full filename, where he found it, and
what he's trying to do.

A8 might be an offset in a VAX image header, and the rest look like the
IDENT and other fields of a header, but I don't have a reference handy.
Analyze/Image should confirm that. And 'file' on *ix is pretty good at
identifying a file format.

It's not a PDP11 boot block, which usually begins with 0240 (NOP).

Beyond that, I'm not inclined to play a guessing game.

paul

Post by Tim Stark
Folks,

Does anyone know any documentation provides some information about
MOP header in SYS files?

00000000: A8 00 30 00 44 00 58 00-00 00 00 00 30 32 30 35
|..0.D.X.....0205|
00000010: 01 01 00 00 FF FF FF FF-FF FF FF FF 00 00 00 00
|................|
00000020: 20 00 00 01 00 00 00 00-00 00 00 00 00 00 00 00 |
...............|
00000030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000050: 00 00 00 00 00 00 00 00-03 4D 4F 50 00 00 00 00
|.........MOP....|
00000060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000070: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000080: 04 56 31 2E 30 00 00 00-00 00 00 00 00 00 00 00
|.V1.0...........|
00000090: 00 00 00 00 00 00 00 00-05 30 35 2D 30 35 00 00
|.........05-05..|
000000A0: 00 00 00 00 00 00 00 00-10 00 87 15 00 00 00 00
|................|
000000B0: 80 00 00 00 02 00 00 00-00 00 FF FF FF FF FF FF
|................|
000000C0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
000000D0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
000000E0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
000000F0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|

Thanks,
Tim
<dump.txt>_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

Timothy Stark

2018-02-21 15:47:41 UTC

Permalink

Ok I figured out what is boot block in cl67srmrom.sys. There was no exe
version (only sys files) for SROM on some Alpha firmware iso files. I
checked other larger sys files with exe files are almost same boot block
for MOP loader. Exe files are raw binaries to can be loaded and run by
dummy simple loader.

Post by Paul Koning
MOP is a protocol, not a storage spec. The protocol is defined in detail,
in the MOP architecture spec, which can be found in various collections of
DECnet architecture specs.
Yes
I assume a SYS file is a file meant to be downloaded by a MOP server on
some host. What the file contents means depends on what the sender and/or
receiver do with that data; the MOP protocol spec has no opinion about it.
So the question actually becomes: what do the MOP server on OS x, and/or
the MOP client on hardware or OS y, expect to see in the header of the file
used for MOP request z?
Yes.
.SYS is a common extension for files loaded by MOP, though it has other
uses in the DEC multiverse. I've seen it used for PDP-11 code; for 68000
code (used in terminal servers); for VAX code.
MOP load often gets you a secondary loader, which is capable of
multi-block loads. And that usually loads a tertiary loader, which can
interpret an image file format. But this is all architecture specific.
The server knows nothing about it - it serves bits. The bits are specified
with NML (NCP) in the MOP load database. The PDP-11 boot architecture is an
appendix in the MOP spec. But it's not mandatory, and other clients can
(and do) vary.
The client gets whatever bits are sent & executes them. Well, it's
expected to. MOP could be used to load a bitmap into a graphics buffer -
it takes bits and puts them into memory. After that, it's up to the client.
Tim would do better to tell us the full filename, where he found it, and
what he's trying to do.
A8 might be an offset in a VAX image header, and the rest look like the
IDENT and other fields of a header, but I don't have a reference handy.
Analyze/Image should confirm that. And 'file' on *ix is pretty good at
identifying a file format.
It's not a PDP11 boot block, which usually begins with 0240 (NOP).
Beyond that, I'm not inclined to play a guessing game.
paul
Folks,
Does anyone know any documentation provides some information about MOP header in SYS files?
00000000: A8 00 30 00 44 00 58 00-00 00 00 00 30 32 30 35
|..0.D.X.....0205|
00000010: 01 01 00 00 FF FF FF FF-FF FF FF FF 00 00 00 00
|................|
00000020: 20 00 00 01 00 00 00 00-00 00 00 00 00 00 00 00 |
...............|
00000030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000050: 00 00 00 00 00 00 00 00-03 4D 4F 50 00 00 00 00
|.........MOP....|
00000060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000070: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000080: 04 56 31 2E 30 00 00 00-00 00 00 00 00 00 00 00
|.V1.0...........|
00000090: 00 00 00 00 00 00 00 00-05 30 35 2D 30 35 00 00
|.........05-05..|
000000A0: 00 00 00 00 00 00 00 00-10 00 87 15 00 00 00 00
|................|
000000B0: 80 00 00 00 02 00 00 00-00 00 FF FF FF FF FF FF
|................|
000000C0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
000000D0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
000000E0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
000000F0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
Thanks,
Tim
<dump.txt>_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

Timothe Litt

2018-02-21 16:20:17 UTC

Permalink

For VAX/Alpha code from VMS, .sys would be an executable linked
/NOHEADER.Â This would be a raw memory image; no ISDs or compression,
just bits.

In this case, it appears to be a SRM console image that was extracted
from an HP firmware update kit.

The header is used by the firmware update utility and by the SRM's show
version (IIRC).

There's no reason for this to be loaded via MOP, at least on real
hardware; SRM contains the MOP client.

FYI, when qemu was working on alpha emulation, they applied some patches
to that image - I have no clue what they do or why.Â See
https://lists.gnu.org/archive/html/qemu-devel/2009-03/msg00693.html

Post by Timothy Stark
Ok I figured out what is boot block in cl67srmrom.sys. There was no
exe version (only sys files) for SROM on some Alpha firmware iso
files.Â I checked other larger sys files with exe files are almost
same boot block for MOP loader.Â Exe files are raw binaries to can be
loaded and run by dummy simple loader. Â

Tim Stark

2018-02-22 02:41:49 UTC

Permalink

Well I analyzed SYS and EXE of cl67srmrom firmware. I now discovered that SYS have same EXE content with first 512 bytes MOP header and execute start at 0x200 offset.

To convert to EXE file, get rid of first 512 bytes (MOP header). That EXE file mentions about LFU and allow execute to the beginning of EXE file directly (zero offset).

Tim

From: Simh [mailto:simh-***@trailing-edge.com] On Behalf Of Timothe Litt
Sent: Wednesday, February 21, 2018 11:20 AM
To: ***@trailing-edge.com
Subject: Re: [Simh] MOP header specs?

For VAX/Alpha code from VMS, .sys would be an executable linked /NOHEADER. This would be a raw memory image; no ISDs or compression, just bits.

In this case, it appears to be a SRM console image that was extracted from an HP firmware update kit.

The header is used by the firmware update utility and by the SRM's show version (IIRC).

There's no reason for this to be loaded via MOP, at least on real hardware; SRM contains the MOP client.

FYI, when qemu was working on alpha emulation, they applied some patches to that image - I have no clue what they do or why. See https://lists.gnu.org/archive/html/qemu-devel/2009-03/msg00693.html

On 21-Feb-18 10:47, Timothy Stark wrote:

Ok I figured out what is boot block in cl67srmrom.sys. There was no exe version (only sys files) for SROM on some Alpha firmware iso files. I checked other larger sys files with exe files are almost same boot block for MOP loader. Exe files are raw binaries to can be loaded and run by dummy simple loader.

Johnny Billquist

2018-02-23 09:31:01 UTC

Permalink

Post by Tim Stark
Folks,
Does anyone know any documentation provides some information about MOP
header in SYS files?

MOP headers no. But if you are referring to the .SYS files DEC
distributed for things like DEC servers, which booted over MOP, those
SYS files look like "normal" task files in RSX. Task files linked with
no task header, though.

Example:
.tin sh1601ENG.SYS
TIN V1.7
Task name: SHAMRO Date: 21-MAY-96 Pri=0. Start=075000. EXTTSK=000000.
Label block revision: 0.
Task addresses - Low: 051000, W0 high: 177777, High: 177777
Load size: 02161400 Max size: 02161400 # of window blocks: 1.
Task flags (040100): -HD -CHK
Partition: SYSTEM Offset: 000000
System ID: RSX-11M.

TIN is a small program I wrote a long time ago to analyze task images
under RSX.

That file, for example, is for the DS300 (which has a 68000 CPU). And
the RSX MOP server can service that file. VMS can serve it too. But this
is totally outside the MOP protocol itself.

The MOP protocol is documented in various places as well, so if you want
that, you can find it. But the .SYS files are images that are served by
MOP. They are not verbatim MOP data.

Johnny

Post by Tim Stark
00000000: A8 00 30 00 44 00 58 00-00 00 00 00 30 32 30 35
|..0.D.X.....0205|
00000010: 01 01 00 00 FF FF FF FF-FF FF FF FF 00 00 00 00
|................|
00000020: 20 00 00 01 00 00 00 00-00 00 00 00 00 00 00 00 |
...............|
00000030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000050: 00 00 00 00 00 00 00 00-03 4D 4F 50 00 00 00 00
|.........MOP....|
00000060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000070: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|................|
00000080: 04 56 31 2E 30 00 00 00-00 00 00 00 00 00 00 00
|.V1.0...........|
00000090: 00 00 00 00 00 00 00 00-05 30 35 2D 30 35 00 00
|.........05-05..|
000000A0: 00 00 00 00 00 00 00 00-10 00 87 15 00 00 00 00
|................|
000000B0: 80 00 00 00 02 00 00 00-00 00 FF FF FF FF FF FF
|................|
000000C0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
000000D0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
000000E0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
000000F0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
|................|
Thanks,
Tim
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Tim Stark

2018-02-23 12:53:17 UTC

Permalink

Johnny,

Oh, I now got it. I mean SYS specs, not MOP specs. Is that TIN program available?

Thanks,
Tim

-----Original Message-----
From: Simh [mailto:simh-***@trailing-edge.com] On Behalf Of Johnny Billquist
Sent: Friday, February 23, 2018 4:31 AM
To: ***@trailing-edge.com
Subject: Re: [Simh] MOP header specs?

Post by Tim Stark
Folks,
Does anyone know any documentation provides some information about MOP
header in SYS files?

MOP headers no. But if you are referring to the .SYS files DEC distributed for things like DEC servers, which booted over MOP, those SYS files look like "normal" task files in RSX. Task files linked with no task header, though.

Example:
.tin sh1601ENG.SYS
TIN V1.7
Task name: SHAMRO Date: 21-MAY-96 Pri=0. Start=075000. EXTTSK=000000.
Label block revision: 0.
Task addresses - Low: 051000, W0 high: 177777, High: 177777 Load size: 02161400 Max size: 02161400 # of window blocks: 1.
Task flags (040100): -HD -CHK
Partition: SYSTEM Offset: 000000
System ID: RSX-11M.

TIN is a small program I wrote a long time ago to analyze task images under RSX.

That file, for example, is for the DS300 (which has a 68000 CPU). And the RSX MOP server can service that file. VMS can serve it too. But this is totally outside the MOP protocol itself.

The MOP protocol is documented in various places as well, so if you want that, you can find it. But the .SYS files are images that are served by MOP. They are not verbatim MOP data.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
***@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Timothe Litt

2018-02-23 13:39:29 UTC

Permalink

You're asking for something that doesn't exist.

.SYS files can be anything.Â When downloaded via MOP, can by any
architecure - not just the server's.

.SYS can be a pagefile.Â Or a swapfile.Â Or a pdp-11 task image.Â Or a
standalone VAX image.Â Or an accounting file.Â Or 68000 code.Â Or 8080
code.Â Or Alpha code.Â Or a bitmap destined for a graphics adapter.Â Or
anything else.

There is no MOP header.Â What you may be seeing, as I noted previously,
is a MOP secondary or tertiary loader.

There are specs for each usage; e.g. what Johnny provided is a program
that decodes an RSX task image.Â But it's not really an RSX image; in
his example, the RSX task builder was used to link 68000 code.Â So the
secondary loader code, to be functional, would be 68000 code.

A VAX download would have a different image header, and VAX code.Â And
so on for ANY architecture.

All MOP knows is to request a specific program; load bytes to an
address; and jump to an address.Â Any interpretation of the bytes is up
to the code that's loaded - and the client CPU.

That's why a MOP load normally consists of asking for a program - which
is the secondary loader.Â It's the secondary (or tertiary) loader that
knows how to unpack an image and make additional requests.

The file that you mentioned is Alpha SRM console code.Â The only reason
for it to have a MOP loader is so that a firmware update can be done by
booting from a network repo.Â I don't know if it was supported; the
usual path was LFU from a CDROM or disk.Â Note that you can't boot (or
run a MOP client, or do much or anything) without the SRM console
already in FLASH.Â (Or the NT ARC console.)Â It's the firmware that
knows how to negotiate MOP, and it's the firmware that provides the
instructions implemented in PALcode.Â So that path is not useful for
bare hardware.

Post by Tim Stark
Johnny,
Oh, I now got it. I mean SYS specs, not MOP specs. Is that TIN program available?
Thanks,
Tim
-----Original Message-----
Sent: Friday, February 23, 2018 4:31 AM
Subject: Re: [Simh] MOP header specs?

Post by Tim Stark
Folks,
Does anyone know any documentation provides some information about MOP
header in SYS files?

MOP headers no. But if you are referring to the .SYS files DEC distributed for things like DEC servers, which booted over MOP, those SYS files look like "normal" task files in RSX. Task files linked with no task header, though.
.tin sh1601ENG.SYS
TIN V1.7
Task name: SHAMRO Date: 21-MAY-96 Pri=0. Start=075000. EXTTSK=000000.
Label block revision: 0.
Task addresses - Low: 051000, W0 high: 177777, High: 177777 Load size: 02161400 Max size: 02161400 # of window blocks: 1.
Task flags (040100): -HD -CHK
Partition: SYSTEM Offset: 000000
System ID: RSX-11M.
TIN is a small program I wrote a long time ago to analyze task images under RSX.
That file, for example, is for the DS300 (which has a 68000 CPU). And the RSX MOP server can service that file. VMS can serve it too. But this is totally outside the MOP protocol itself.
The MOP protocol is documented in various places as well, so if you want that, you can find it. But the .SYS files are images that are served by MOP. They are not verbatim MOP data.
Johnny

Johnny Billquist

2018-02-23 22:28:07 UTC

Permalink

Post by Timothe Litt
You're asking for something that doesn't exist.
.SYS files can be anything. When downloaded via MOP, can by any
architecure - not just the server's.
.SYS can be a pagefile. Or a swapfile. Or a pdp-11 task image. Or a
standalone VAX image. Or an accounting file. Or 68000 code. Or 8080
code. Or Alpha code. Or a bitmap destined for a graphics adapter. Or
anything else.

Right. A .SYS file can be anything. It's just a name.
That said, the MOP server under RSX as well as VMS understands files
with a specific format, and I suspect that might be what you actually
are asking for. I don't know if there are any documentation about the
file format that those MOP servers can handle. (Except reading the source.)

Post by Timothe Litt
There is no MOP header. What you may be seeing, as I noted previously,
is a MOP secondary or tertiary loader.

I don't know what he was looking at, but if it was the beginning of the
file, then there was nothing MOP about it at all.

Post by Timothe Litt
There are specs for each usage; e.g. what Johnny provided is a program
that decodes an RSX task image. But it's not really an RSX image; in
his example, the RSX task builder was used to link 68000 code. So the
secondary loader code, to be functional, would be 68000 code.

Right, in that my program decodes RSX task image headers. It just so
happens that the image files DEC provided for DECservers are in the same
format. However, I seriously doubt TKB was used to build those files.
(But I could be wrong of course.)
But the thing is, the task image can be pretty much anything. The header
only gives some basic information about sizes and addresses for the
image, as well as some meta information such as name, build date, and
similar stuff.
You're supposed to just place the rest of the file in memory, at the
addresses given, and start off at the given start address. The image
itself could be for any architecture or system. Don't matter for the
task image itself.

Post by Timothe Litt
A VAX download would have a different image header, and VAX code. And so
on for ANY architecture.

True. But the file that I gave the output from is a DECserver image,
which DEC provided, and which could be served from both RSX and VMS. So
the MOP server on those two systems understand the same image format. It
might be that the VMS MOP server might understand other file formats as
well, I don't know.

Post by Timothe Litt
All MOP knows is to request a specific program; load bytes to an
address; and jump to an address. Any interpretation of the bytes is up
to the code that's loaded - and the client CPU.

Right.

Post by Timothe Litt
That's why a MOP load normally consists of asking for a program - which
is the secondary loader. It's the secondary (or tertiary) loader that
knows how to unpack an image and make additional requests.

Hum. Well, that might be, but both will be served through MOP, so it
don't make much difference if it's the primary or secondary boot. They
are served the same way. The receiving end might be doing more stuff at
the secondary or tertiary boot loader, but from the serving side it's
all the same.

Post by Timothe Litt
The file that you mentioned is Alpha SRM console code. The only reason
for it to have a MOP loader is so that a firmware update can be done by
booting from a network repo. I don't know if it was supported; the
usual path was LFU from a CDROM or disk. Note that you can't boot (or
run a MOP client, or do much or anything) without the SRM console
already in FLASH. (Or the NT ARC console.) It's the firmware that
knows how to negotiate MOP, and it's the firmware that provides the
instructions implemented in PALcode. So that path is not useful for
bare hardware.

Yup. The MOP client needs to already be on the system (obviously).

Johnny

Post by Timothe Litt

Post by Tim Stark
Folks,
Does anyone know any documentation provides some information about MOP
header in SYS files?

MOP headers no. But if you are referring to the .SYS files DEC distributed for things like DEC servers, which booted over MOP, those SYS files look like "normal" task files in RSX. Task files linked with no task header, though.
.tin sh1601ENG.SYS
TIN V1.7
Task name: SHAMRO Date: 21-MAY-96 Pri=0. Start=075000. EXTTSK=000000.
Label block revision: 0.
Task addresses - Low: 051000, W0 high: 177777, High: 177777 Load size: 02161400 Max size: 02161400 # of window blocks: 1.
Task flags (040100): -HD -CHK
Partition: SYSTEM Offset: 000000
System ID: RSX-11M.
TIN is a small program I wrote a long time ago to analyze task images under RSX.
That file, for example, is for the DS300 (which has a 68000 CPU). And the RSX MOP server can service that file. VMS can serve it too. But this is totally outside the MOP protocol itself.
The MOP protocol is documented in various places as well, so if you want that, you can find it. But the .SYS files are images that are served by MOP. They are not verbatim MOP data.
Johnny

_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Paul Koning

2018-02-24 00:56:14 UTC

Permalink

...

That's why a MOP load normally consists of asking for a program - which is the secondary loader. It's the secondary (or tertiary) loader that knows how to unpack an image and make additional requests.

Hum. Well, that might be, but both will be served through MOP, so it don't make much difference if it's the primary or secondary boot. They are served the same way.

Almost. A secondary loader response carries the entire secondary loader in a single message, so the bootstrap only needs to handle one message. Tertiary and OS loads are expected to take multiple messages.

Either way, though, the MOP protocol spec only describes bits on the wire. How those bits are derived from files on the serving host is a host matter. Since multiple host types support loading various devices such as routers or terminal servers, it seems likely that they share an on-disk format, but if they do, that's a packaging convenience question, not something the MOP spec addresses.

You can think of MOP as a simple data transfer protocol; the fact that clients use it to load executable bits into memory is not required. The same is true for TFTP, and there the name of the protocol makes the point explicit. MOP doesn't say it quite so clearly but it is just as true there.

paul

Johnny Billquist

2018-02-24 01:52:57 UTC

Permalink

Post by Paul Koning

...

Hum. Well, that might be, but both will be served through MOP, so it don't make much difference if it's the primary or secondary boot. They are served the same way.

Yes. But what difference does that make on the server side? The fact
that the requested image is small enough to fit into one frame is just a
detail that makes the client implementation easier.

Post by Paul Koning
Either way, though, the MOP protocol spec only describes bits on the wire. How those bits are derived from files on the serving host is a host matter. Since multiple host types support loading various devices such as routers or terminal servers, it seems likely that they share an on-disk format, but if they do, that's a packaging convenience question, not something the MOP spec addresses.
You can think of MOP as a simple data transfer protocol; the fact that clients use it to load executable bits into memory is not required. The same is true for TFTP, and there the name of the protocol makes the point explicit. MOP doesn't say it quite so clearly but it is just as true there.

Yup.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Paul Koning

2018-02-24 16:21:06 UTC

Permalink

Post by Paul Koning

...

Hum. Well, that might be, but both will be served through MOP, so it don't make much difference if it's the primary or secondary boot. They are served the same way.

Yes. But what difference does that make on the server side? The fact that the requested image is small enough to fit into one frame is just a detail that makes the client implementation easier.

The difference is that the server is required to answer a request for secondary loaded with a single response packet holding the entire response. For other loads, it can deliver the data in pieces, and the size of those pieces it its choice. For the second loader, it does not have that choice.

paul

Johnny Billquist

2018-02-25 01:27:01 UTC

Permalink

Post by Paul Koning

...

Hum. Well, that might be, but both will be served through MOP, so it don't make much difference if it's the primary or secondary boot. They are served the same way.

Yes. But what difference does that make on the server side? The fact that the requested image is small enough to fit into one frame is just a detail that makes the client implementation easier.

The MOP servers I know of don't even know about that distinction. They
just serve the image. If it fits in one frame, it will come in one
frame. If it don't, it won't. The server can't do more than that.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Paul Koning

2018-02-25 01:41:42 UTC

Permalink

Post by Paul Koning

...
Yes. But what difference does that make on the server side? The fact that the requested image is small enough to fit into one frame is just a detail that makes the client implementation easier.

The MOP servers I know of don't even know about that distinction. They just serve the image. If it fits in one frame, it will come in one frame. If it don't, it won't. The server can't do more than that.

If so, then that's fine. I'm just pointing out that the protocol spec has an explicit requirement for the secondary load request to be answered with a complete load response (data with transfer address) in a single message.

paul

Johnny Billquist

2018-02-25 04:08:16 UTC

Permalink

Post by Paul Koning

...
Yes. But what difference does that make on the server side? The fact that the requested image is small enough to fit into one frame is just a detail that makes the client implementation easier.

The MOP servers I know of don't even know about that distinction. They just serve the image. If it fits in one frame, it will come in one frame. If it don't, it won't. The server can't do more than that.

I need to correct myself. There is a difference on the server side
depending on what was requested (I clearly haven't read this code in too
long a time).
Looking at the RSX MOP server:
A secondary or tertiary boot image is sent using "MEMORY LOAD WITH
TRANSFER ADDRESS". In the case of a tertiary bootstrap, that is the last
message, while the others are just "MEMORY LOAD".
For a system image, the contents are sent with "MEMORY LOAD", but then
afterwards there is instead a "PARAMETER LOAD WITH TRANSFER ADDRESS", so
there is a distinction between boot loaders and general system images
that the MOP server needs to know.
The RSX MOP server makes no distinction on the files used to serve the
different types of requests. They are all processed the same way, and
needs to have the same format. But obviously, a secondary bootstrap file
must be small enough to fit into one message, or else it won't work.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Timothe Litt

2018-02-24 02:02:54 UTC

Permalink

Post by Paul Koning

...

Hum. Well, that might be, but both will be served through MOP, so it don't make much difference if it's the primary or secondary boot. They are served the same way.

Yes.

Post by Paul Koning
Either way, though, the MOP protocol spec only describes bits on the wire. How those bits are derived from files on the serving host is a host matter.

Yes

Post by Paul Koning
Since multiple host types support loading various devices such as routers or terminal servers, it seems likely that they share an on-disk format, but if they do, that's a packaging convenience question, not something the MOP spec addresses.

Yes.

The server doesn't need to understand the file format.Â It MAY, but
needn't.Â It can simply serve bytes (mapping file offset 0 to memory
offset 0).Â This is the trivial answer: load program has the secondary
loader at offset 0; the secondary loader adds its length (typically
rounded up to a disk block) to subsequent load addresses, doing the same
for any tertiary loader.Â This puts everything in one file.Â Or the
server can decode a complex header.Â In any case, the server CAN just
serve bytes.

Alternatively, the server can read a complex file format (a.out, VMS
image header) and send responses that expand demand zero pages, or
decompress an LZW-encoded stream, or keep the loaders in separate files,
- or whatever.

It can access and/or serve different file formats based on the request.

There are lots of variations.Â MOP carries bytes (octets) on the wire.Â
The server supplies (or in the case, of dump, sinks) the bits.Â
Packaging can be very simple, but involve a contract between the
embedded loader(s) and the rest of the data file.Â Or the MOP server can
have deep knowledge of the file format, and present it in a canonical
format that the client loader understands.Â Or any combination.

Again, (call this violent agreement), MOP carries bits on the wire.Â
That's all.Â There is no MOP header.Â No semantics are associated with
the bits at the MOP level.Â There are packaging conventions that involve
contracts with the server and/or the secondary loaders (which may or may
not be embedded).Â These are all decisions that are outside the scope of
the MOP protocol, usually to optimize external factors.Â

Post by Paul Koning
You can think of MOP as a simple data transfer protocol; the fact that clients use it to load executable bits into memory is not required. The same is true for TFTP, and there the name of the protocol makes the point explicit. MOP doesn't say it quite so clearly but it is just as true there.

Yes, MOP is a data transfer protocol.Â It's also more: "Maintenance
operation" - we've talked about the data transfer aspects, but it also
has built in the concepts of programs, loaders, selective loads,
providing time, loopback, redundant servers via multicast, even a remote
console service.Â It's designed to allow a remote diskless node to be
managed as if it were local: trigger boot, trigger dump, remote console,
complex load and dump sequences.Â Even a nod or two to security (as
understood at the time.)Â All with heterogeneous architectures.Â It is a
fairly complete solution to "I'm in Hawaii, the target is at the north
pole - I need to load/dump/diagnose it without getting cold".

TFTP is a different animal.Â It is designed to move files between
hosts.Â It's a file (or in a case of true weirdness, an e-mail
destination).Â But TFTP really IS Trivial.Â It moves a file by name.Â
Period.Â All you get is "read, write, data, ack and error".Â Â A file is
opened, and data is processed sequentially to EOF.Â It has no provision
for transfer address, much less providing time, non-sequential access,Â
or the many other luxuries that MOP allows for.Â Loading an executable
into memory with TFTP and having it run is not specified in the
protocol.Â In fact, anything nontrivial built on TFTP requires the
client to have a more involved contract with the server.Â (effectively,
private protocol extensions)Â However, TFTP DOES specify a "mode" in the
read/write command, which can cause the bits on the wire to be
translated or repacked.Â This is not a critique; while TFTP is often
abused ("extended"), it does do exactly what it sets out to do.Â
barebones file transfer, with no optimizations for security or
performance.Â

Post by Paul Koning
paul

Johnny Billquist

2018-02-23 22:16:26 UTC

Permalink

The TIN program is just a small RSX program. If you happen to have some
RSX system around, I can send it to you, or if you are on HECnet, you
can fetch it from MIM::

As Timothy said, it's sortof difficult to just say "SYS" specs. You can
name any file you want to as .SYS, if you want to. That will not tell
you anything about the contents of the file.

If we talk about the images DEC provided for MOP booting DECservers,
then those files have a task header which is the same as any task image
under RSX. And the format of that type of files is documented in the
task builder manual for RSX.

But, as Timothy says, there are lots of different files that officially
were named .SYS, which have been wildly different. So it all depends on
the actual file. Can you provide me with a file, I can also check if it
matches the format that the DECserver images have.

Also, understand that this is just the format that the MOP server can
read under RSX and VMS. It does not say anything about what other MOP
servers might understand. The mopd under NetBSD for example, understands
a.out images as well as dwarf and ecoff.

Johnny

Post by Tim Stark
Folks,
Does anyone know any documentation provides some information about MOP
header in SYS files?

MOP headers no. But if you are referring to the .SYS files DEC distributed for things like DEC servers, which booted over MOP, those SYS files look like "normal" task files in RSX. Task files linked with no task header, though.
.tin sh1601ENG.SYS
TIN V1.7
Task name: SHAMRO Date: 21-MAY-96 Pri=0. Start=075000. EXTTSK=000000.
Label block revision: 0.
Task addresses - Low: 051000, W0 high: 177777, High: 177777 Load size: 02161400 Max size: 02161400 # of window blocks: 1.
Task flags (040100): -HD -CHK
Partition: SYSTEM Offset: 000000
System ID: RSX-11M.
TIN is a small program I wrote a long time ago to analyze task images under RSX.
That file, for example, is for the DS300 (which has a 68000 CPU). And the RSX MOP server can service that file. VMS can serve it too. But this is totally outside the MOP protocol itself.
The MOP protocol is documented in various places as well, so if you want that, you can find it. But the .SYS files are images that are served by MOP. They are not verbatim MOP data.
Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol