[Unix-jun72] UNIX running up to init, I think

[Unix-jun72] UNIX running up to init, I think

[James A. Markevitch]

Hey guys.

I saw the thread about the assembler doing divide by 2 the wrong way.
I took a look at my assembler and it had a similar bug.  I fixed my
assembler, then ran the code again.

It correctly writes the RF11 image (as best as I can tell), then reads
/etc/init into the user area and executes it.  I left the TC11 disabled
on my run and it panics when /etc/init tries to read the tape.

To double-check, I ran the warm boot and it successfully gets into
the /etc/init user code as well, so I'm pretty confident the image
is right.

As far as I can tell, the source code I sent out this morning has no
problems.  Most likely, you guys are fighting assembler and/or other
tool issues.

I'll cobble together a bootable RF11 image (assuming that there really
are no kernel problems) and send out a copy of that.  Once everyone
has that, they should be able to continue generating tapes and RK03
images of other executables, etc.  I can include a copy of the
assembler listing file for both warm and cold boots so that everyone
can have a reference while they are debugging.

I've also got the M792 boot (from the documentation) as well as an
untested bos.s.  If those work, then the RF11 image I send out will
be pretty close to authentic.  Otherwise, you will still need to load
the kernel into core with the "load" command.

James Markevitch

[Unix-jun72] UNIX running up to init, I think

[Tim Newsham]

> It correctly writes the RF11 image (as best as I can tell), then reads
> /etc/init into the user area and executes it.  I left the TC11 disabled
> on my run and it panics when /etc/init tries to read the tape.

*nod* we're running up to init in the cold boot kernel and getting
into the code that reads the 65th block off the tape.  At this
point we only get 1 byte of data into the read buffer, though.
(not sure if this is due to simh, the kernel or some other issue).

to work around the asembler divide issue I had to sed the source
during build time.  These hacks are all incorporated into the
tools/assemv7 script.

it might be fun to try to use Warren's mkfs.c program to preload
the root disk and boot warm with it.

> James Markevitch

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] UNIX running up to init, I think

[Brad Parker]

Some debugging in simh makes it look like attaching the raw file (512 byte
blocks) is correct and simh is geting the data:

>>DT0: read block 65 forward
ba 40400, data 1672, pos 152927
ba 40401, data 164755, pos 152933
ba 40402, data 72145, pos 152939
ba 40403, data 27543, pos 152945
ba 40404, data 67151, pos 152951
ba 40405, data 72151, pos 152957
ba 40406, data 0, pos 152963
ba 40407, data 0, pos 152969
ba 40410, data 0, pos 152975
ba 40411, data 0, pos 152981

that matches the contents of my files.

but it doesn't seem like the dma is making it to userland.  Perhaps it's
getting into the kernel buffer but not the user buffer.  I just copied
the sysread code verbatim and didn't look at the closely.

I'll do more debugging tomorrow.  Seems like we're closing in.

(hmm. just noticed that ba 40400 != 40222)

-brad

[Unix-jun72] UNIX running up to init, I think

[Tim Newsham]

> but it doesn't seem like the dma is making it to userland.  Perhaps it's
> getting into the kernel buffer but not the user buffer.  I just copied
> the sysread code verbatim and didn't look at the closely.
>
> I'll do more debugging tomorrow.  Seems like we're closing in.

There was a missing branch instruction when copying from kernel buffer to 
userland buffer on page e08-02.  I added the branch and a note about it 
and committed.  (without the branch it will only ever copy one byte to 
userland).  Now my cold boot is writing files off the tape onto the rk0 
image.

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/