[LMH]%IO instruction and Device Descriptors
Steve Krueger
stevelisp@grape-krueger.com
Wed Jul 23 19:59:01 2003
--------------020101060701010403090100
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
OK, I think we are getting there.
If you know that this first %IO is in a disk routine, then the
INTERRUPT-TYPE field must be the proper value for NuPI. There is the
possibility that the NUPI device descriptor block was supposed to be
initialized by the startup microcode. If it contains 0 in this field,
you'll need to generate the NUPI device descriptor as part of the VM
initialization. The old microcode contains a routine to setup the NUPI
device descriptor. The comment there says that this is needed because
virtual memory needs the NUPI before LISP is running.
There is a miscop (0211 %ADD-INTERRUPT) that adds a device descriptor
into the interrupt list for an interrupt level.
Nyef wrote:
>On Tue, 22 Jul 2003, Steve Krueger wrote:
>
>
>
>> %IO finds the device type by examining the INTERRUPT-TYPE field. The
>>values of this field are defined in microcode and I can't find where
>>it's values are exported to macrocode. I'll give you the values for
>>microcode ~208, they might have changed in Elroy.
>>
>>
>
>Ah. I had begun to suspect such, based on the keyboard initialization code
>in window-inits.lisp and the definitions in lroy-qdev.
>
>
>
>>;;; Setup RQB for the NUPI completion event required for the device IO
>>system.
>>
>>
>
>Okay, this explains the other NuPI event level...
>
>... Is this the same RQB that was passed to %IO, or is it a new one?
>
It is the same RQB. It kept on a queue of requests for the particular
formatter. On a completion interrupt only looks at busy RQBs to see if
this is the one completing.
>
>
>
>>To start NUPI request processing:
>>;;; Set the busy bit in the RQB
>>;;; Get the NUPI control space address from the device descriptor +
>>%NUPI-CONTROL-SPACE-ADDRESS
>>;;; Start the command by sending the address of the control block to the
>>NUPI at the NUPI control space
>>;;; address + %NUPI-COMMAND-REGISTER (as an unmapped write) of the RQB
>>command word,
>>;;; converted to a NuBus byte address).
>>
>>
>
>So, the NuPI has a processor on it that reads the RQB directly from NuBus
>memory... I'm going to have to cheat like mad here, if only because I
>haven't put the VMM system in place to actually -use- NuBus memory (we're
>still running directly off the load band file). That, and I don't have a
>copy of the ROMs for the processor, and don't feel like adding -another-
>CPU to exploiter right now...
>
>
I'm not sure you'll need to emulate NuBus addressing just to get the
NuPI working. You will need to have a logical address to NuBus address
mapping for all of the page frames for paging to work. The RQB will
have the NuBus address of a page frame to swap in to or swap out from.
To emulate NUPI, you'll just need to emulate the commands to access the
disk and a few control commands. You'll also need to emulate at least
one disk unit. I think I'd suggest you emulate a disk with a routine
for the disk label and a file for each partition. You'll have to use
the partition starting addresses and lengths to figure out which
partition each disk address refers to.
So yes, NUPI had a 68000 CPU (I think it is a 68020) for interpretting
the NUPI command blocks. Each disk brick contained a formatter (to
handle SCSI commands) that also contained a CPU of some sort. The
formatter + EDSI disk combination is the equivalent of a modern SCSI disk.
The NUPI commands are spelled out in the QCOM, QDEV, etc. I have both
the NUPI user documentation and an engineering spec here somewhere, so I
can answer your questions when it gets too fuzzy.
>
>
>>IO proceeds asynchronously and eventually produces an interrupt. The
>>interrupt handler again dispatches on the Interrupt Type field of the
>>device descriptor found at that interrupt level. NuPI doesn't share an
>>interrupt level with any other device.
>>
>>
>
>Okay, I just reread SSDN2 section 3 in light of all you've said and I've
>discovered myself over the past couple days. It makes a lot more sense
>now.
>
>
Funny how a bit more information helps a lot.
-Steve
--------------020101060701010403090100
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
OK, I think we are getting there. <br>
<br>
If you know that this first %IO is in a disk routine, then the INTERRUPT-TYPE
field must be the proper value for NuPI. There is the possibility that the
NUPI device descriptor block was supposed to be initialized by the startup
microcode. If it contains 0 in this field, you'll need to generate the NUPI
device descriptor as part of the VM initialization. The old microcode contains
a routine to setup the NUPI device descriptor. The comment there says that
this is needed because virtual memory needs the NUPI before LISP is running.<br>
<br>
There is a miscop (0211 %ADD-INTERRUPT) that adds a device descriptor into
the interrupt list for an interrupt level.<br>
<br>
Nyef wrote:<br>
<blockquote type="cite"
cite="midPine.LNX.4.53.0307230915480.27102@mai.paradiesanalytics.com">
<pre wrap="">On Tue, 22 Jul 2003, Steve Krueger wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> %IO finds the device type by examining the INTERRUPT-TYPE field. The
values of this field are defined in microcode and I can't find where
it's values are exported to macrocode. I'll give you the values for
microcode ~208, they might have changed in Elroy.
</pre>
</blockquote>
<pre wrap=""><!---->
Ah. I had begun to suspect such, based on the keyboard initialization code
in window-inits.lisp and the definitions in lroy-qdev.
</pre>
<blockquote type="cite">
<pre wrap="">;;; Setup RQB for the NUPI completion event required for the device IO
system.
</pre>
</blockquote>
<pre wrap=""><!---->
Okay, this explains the other NuPI event level...
... Is this the same RQB that was passed to %IO, or is it a new one?</pre>
</blockquote>
It is the same RQB. It kept on a queue of requests for the particular formatter.
On a completion interrupt only looks at busy RQBs to see if this is the
one completing.<br>
<blockquote type="cite"
cite="midPine.LNX.4.53.0307230915480.27102@mai.paradiesanalytics.com">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">To start NUPI request processing:
;;; Set the busy bit in the RQB
;;; Get the NUPI control space address from the device descriptor +
%NUPI-CONTROL-SPACE-ADDRESS
;;; Start the command by sending the address of the control block to the
NUPI at the NUPI control space
;;; address + %NUPI-COMMAND-REGISTER (as an unmapped write) of the RQB
command word,
;;; converted to a NuBus byte address).
</pre>
</blockquote>
<pre wrap=""><!---->
So, the NuPI has a processor on it that reads the RQB directly from NuBus
memory... I'm going to have to cheat like mad here, if only because I
haven't put the VMM system in place to actually -use- NuBus memory (we're
still running directly off the load band file). That, and I don't have a
copy of the ROMs for the processor, and don't feel like adding -another-
CPU to exploiter right now...
</pre>
</blockquote>
I'm not sure you'll need to emulate NuBus addressing just to get the NuPI
working. You will need to have a logical address to NuBus address mapping
for all of the page frames for paging to work. The RQB will have the NuBus
address of a page frame to swap in to or swap out from. To emulate NUPI,
you'll just need to emulate the commands to access the disk and a few control
commands. You'll also need to emulate at least one disk unit. I think I'd
suggest you emulate a disk with a routine for the disk label and a file for
each partition. You'll have to use the partition starting addresses and
lengths to figure out which partition each disk address refers to.<br>
<br>
So yes, NUPI had a 68000 CPU (I think it is a 68020) for interpretting the
NUPI command blocks. Each disk brick contained a formatter (to handle SCSI
commands) that also contained a CPU of some sort. The formatter + EDSI disk
combination is the equivalent of a modern SCSI disk.<br>
<br>
The NUPI commands are spelled out in the QCOM, QDEV, etc. I have both the
NUPI user documentation and an engineering spec here somewhere, so I can
answer your questions when it gets too fuzzy.<br>
<blockquote type="cite"
cite="midPine.LNX.4.53.0307230915480.27102@mai.paradiesanalytics.com">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">IO proceeds asynchronously and eventually produces an interrupt. The
interrupt handler again dispatches on the Interrupt Type field of the
device descriptor found at that interrupt level. NuPI doesn't share an
interrupt level with any other device.
</pre>
</blockquote>
<pre wrap=""><!---->
Okay, I just reread SSDN2 section 3 in light of all you've said and I've
discovered myself over the past couple days. It makes a lot more sense
now.
</pre>
</blockquote>
Funny how a bit more information helps a lot.<br>
<br>
-Steve<br>
<br>
<br>
</body>
</html>
--------------020101060701010403090100--