lenny@icus.ICUS.COM (Lenny Tropiano) (04/08/90)
I was able to get a copy of the kern.o.cpio.Z file before Brant had
a chance to release it to the osu-cis Internet archives. According
to a "autoreply" message from him (since he's away for the week) he
said,
[...]
"NB: If you're sending me mail about the UNIXpc kernel object archive,
then relax; it will be appearing at osu-cis sometime after 13 April."
Anyhow here's the contents of the kern.o.cpio.Z archive disk.
total 1016
1 -rw-r--r-- 1 lenny icus 398 Apr 6 07:16 README
18 -rw-rw-r-- 1 lenny icus 8988 Apr 6 07:16 conf.o
1 -rw-r--r-- 1 lenny icus 310 Apr 6 07:16 id.o
1 -r--r--r-- 1 lenny icus 239 Apr 6 07:16 ifile.0407
325 -rw-rw-r-- 1 lenny icus 166096 Apr 6 07:16 lib1
214 -rw-rw-r-- 1 lenny icus 109290 Apr 6 07:17 lib2
4 -rw-rw-r-- 1 lenny icus 1712 Apr 6 07:17 lib3
71 -rw-rw-r-- 1 lenny icus 36222 Apr 6 07:17 lib4
3 -rw-rw-r-- 1 lenny icus 1414 Apr 6 07:17 linesw.o
28 -rw-rw-r-- 1 lenny icus 14283 Apr 6 07:17 locore.o
8 -rw-rw-r-- 1 lenny icus 3948 Apr 6 07:17 low.o
1 -rw-rw-r-- 1 lenny icus 350 Apr 6 07:17 name.o
===
And the README says,
This disk contains the files (*.o and archives) needed to build UNIX3.51m.
The files are:
conf.o
id.o
ifile.0407
lib1 # Operating system files (kernel)
lib2 # I/O modules
lib3 # Misc routines
lib4 # Misc routines
linesw.o
locore.o
low.o
name.o
To create a runnable unix, execute the following:
ld -x -N ifile.0407 -o UNIX3.51m low.o locore.o conf.o linesw.o lib* name.o id.o
===
Each of the archives lib[1-4] are 5.2 archive files.
lib1:
rw-r--r-- 0/ 100 5692 Mar 15 08:09 1990 main.o
rw-r--r-- 0/ 100 6794 Mar 15 08:10 1990 trap.o
rw-r--r-- 0/ 100 2815 Mar 15 08:11 1990 sysent.o
rw-r--r-- 0/ 100 7858 Mar 15 08:11 1990 sys1.o
rw-r--r-- 0/ 100 4505 Mar 15 08:12 1990 sys2.o
rw-r--r-- 0/ 100 4817 Mar 15 08:13 1990 sys3.o
rw-r--r-- 0/ 100 5164 Mar 15 08:14 1990 sys4.o
rw-r--r-- 0/ 100 1854 Mar 15 08:14 1990 acct.o
rw-r--r-- 0/ 100 3314 Mar 15 08:15 1990 alloc.o
rw-r--r-- 0/ 100 6629 Mar 15 08:16 1990 clock.o
rw-r--r-- 0/ 100 5024 Mar 15 08:17 1990 drv.o
rw-r--r-- 0/ 100 3252 Mar 15 08:17 1990 fio.o
rw-r--r-- 0/ 100 3222 Mar 15 08:18 1990 iget.o
rw-r--r-- 0/ 100 1020 Mar 15 08:18 1990 lock.o
rw-r--r-- 0/ 100 7149 Mar 15 08:19 1990 machdep.o
rw-r--r-- 0/ 100 3895 Mar 15 08:20 1990 flock.o
rw-r--r-- 0/ 100 2016 Mar 15 08:21 1990 locsys.o
rw-r--r-- 0/ 100 4604 Mar 15 08:21 1990 msg.o
rw-r--r-- 0/ 100 2278 Mar 15 08:22 1990 nami.o
rw-r--r-- 0/ 100 1434 Mar 15 08:22 1990 pipe.o
rw-r--r-- 0/ 100 1706 Mar 15 08:23 1990 prf.o
rw-r--r-- 0/ 100 3372 Mar 15 08:24 1990 rdwri.o
rw-r--r-- 0/ 100 6707 Mar 15 08:24 1990 sem.o
rw-r--r-- 0/ 100 745 Mar 15 08:25 1990 ipcfunc.o
rw-r--r-- 0/ 100 880 Mar 15 08:25 1990 ipc.o
rw-r--r-- 0/ 100 4613 Mar 15 08:26 1990 sig.o
rw-r--r-- 0/ 100 4419 Mar 15 08:27 1990 slp.o
rw-r--r-- 0/ 100 1880 Mar 15 08:27 1990 subr.o
rw-r--r-- 0/ 100 868 Mar 15 08:27 1990 utssys.o
rw-r--r-- 0/ 100 862 Mar 15 08:28 1990 copy.o
rw-r--r-- 0/ 100 1030 Mar 15 08:28 1990 rmap.o
rw-r--r-- 0/ 100 3228 Mar 15 08:29 1990 text.o
rw-r--r-- 0/ 100 5070 Mar 15 08:30 1990 shm.o
rw-r--r-- 0/ 100 1792 Mar 15 08:30 1990 shlib.o
rw-r--r-- 0/ 100 3883 Mar 15 08:31 1990 vmdrum.o
rw-r--r-- 0/ 100 3028 Mar 15 08:32 1990 vmproc.o
rw-r--r-- 0/ 100 4149 Mar 15 08:32 1990 vmsched.o
rw-r--r-- 0/ 100 1840 Mar 15 08:33 1990 vmsubr.o
rw-r--r-- 0/ 100 2348 Mar 15 08:33 1990 vmswap.o
rw-r--r-- 0/ 100 7808 Mar 15 08:34 1990 vmmem.o
rw-r--r-- 0/ 100 7789 Mar 15 08:36 1990 vmpage.o
rw-r--r-- 0/ 100 5599 Mar 15 08:37 1990 vmpt.o
rw-r--r-- 0/ 100 664 Mar 15 08:59 1990 ic.o
lib2:
rw-r--r-- 0/ 100 7373 Mar 15 08:43 1990 bio.o
rw-r--r-- 0/ 100 6544 Mar 15 08:44 1990 tt1.o
rw-r--r-- 0/ 100 4102 Mar 15 08:44 1990 tty.o
rw-r--r-- 0/ 100 1626 Mar 15 08:45 1990 clist.o
rw-r--r-- 0/ 100 2100 Mar 15 08:45 1990 err.o
rw-r--r-- 0/ 100 4245 Mar 15 08:46 1990 console.o
rw-r--r-- 0/ 100 8563 Mar 15 08:47 1990 i8274.o
rw-r--r-- 0/ 100 1778 Mar 15 08:48 1990 mem.o
rw-r--r-- 0/ 100 912 Mar 15 08:48 1990 sys.o
rw-r--r-- 0/ 100 430 Mar 15 08:48 1990 partab.o
rw-r--r-- 0/ 100 4595 Mar 15 08:49 1990 lp.o
rw-r--r-- 0/ 100 669 Mar 15 08:49 1990 sw.o
rw-r--r-- 0/ 100 11430 Mar 15 08:51 1990 gd.o
rw-r--r-- 0/ 100 5099 Mar 15 08:52 1990 gdfp.o
rw-r--r-- 0/ 100 5688 Mar 15 08:53 1990 gdhd.o
rw-r--r-- 0/ 100 8168 Mar 15 08:54 1990 kbd.o
rw-r--r-- 0/ 100 12168 Mar 15 08:54 1990 rastop.o
rw-r--r-- 0/ 100 4983 Mar 15 08:55 1990 ph.o
rw-r--r-- 0/ 100 10156 Mar 15 08:56 1990 phsub.o
rw-r--r-- 0/ 100 2682 Mar 15 08:57 1990 sysfont.o
lib3:
rw-r--r-- 0/ 100 1484 Mar 15 08:58 1990 prof.o
lib4:
rw-r--r-- 0/ 100 1500 Mar 15 09:00 1990 main.o
rw-r--r-- 0/ 100 807 Mar 15 09:00 1990 trap.o
rw-r--r-- 0/ 100 2662 Mar 15 09:00 1990 getcmd.o
rw-r--r-- 0/ 100 1374 Mar 15 09:00 1990 memory.o
rw-r--r-- 0/ 100 1054 Mar 15 09:00 1990 regs.o
rw-r--r-- 0/ 100 248 Mar 15 09:00 1990 dload.o
rw-r--r-- 0/ 100 614 Mar 15 09:00 1990 io.o
rw-r--r-- 0/ 100 661 Mar 15 09:01 1990 atoh.o
rw-r--r-- 0/ 100 1475 Mar 15 09:01 1990 8251.o
rw-r--r-- 0/ 100 1821 Mar 15 09:01 1990 break.o
rw-r--r-- 0/ 100 676 Mar 15 09:01 1990 dispreg.o
rw-r--r-- 0/ 100 1030 Mar 15 09:01 1990 modbyte.o
rw-r--r-- 0/ 100 762 Mar 15 09:01 1990 disass.o
rw-r--r-- 0/ 100 898 Mar 15 09:01 1990 dispblk.o
rw-r--r-- 0/ 100 12000 Mar 15 09:02 1990 text68.o
rw-r--r-- 0/ 100 1148 Mar 15 09:03 1990 pnt.o
rw-r--r-- 0/ 100 2727 Mar 15 09:03 1990 btrace.o
rw-r--r-- 0/ 100 350 Mar 15 09:03 1990 getpid.o
rw-r--r-- 0/ 100 306 Mar 15 09:03 1990 misc.o
rw-r--r-- 0/ 100 1594 Mar 15 09:04 1990 dbstr.o
Well after looking at all this, the first thing that any normal person would
do is to try to link it... I did just that, I linked the UNIX3.51m and amazing
enough I got a binary...
341 -rwxr-xr-x 1 lenny icus 174174 Apr 7 13:12 UNIX3.51m
The FIXDISK2.0 version was:
341 -rwxrwxr-x 2 root sys 174174 Feb 5 20:34 /UNIX3.51m
The 4-bytes that differed (and that's why the sum(1) doesn't match, is the
COFF file time and date stamp (long, which is 4 bytes).
5 45 46
6 153 36
7 3 37
8 233 171
See <a.out.h> for information on COFF file headers, and you'll note
that the first header is the struct filehdr ...
struct filehdr {
unsigned short f_magic; /* magic number */
unsigned short f_nscns; /* number of sections */
long f_timdat; /* time & date stamp */
long f_symptr; /* file pointer to symtab */
long f_nsyms; /* number of symtab entries */
unsigned short f_opthdr; /* sizeof(optional hdr) */
unsigned short f_flags; /* flags */
};
The member that differs is f_timdat. Great!
Now what? Most people would like to hack their kernel, and without source
that becomes a bit of a challenge. Since none of us are going to get 3.51m
source (or it seems quite unlikely in the future), we need to go to other
extremes. Thanks to Alex Crain's work on unc (a good disassembler), it
makes ripping apart binaries to assembly code a bit easier. For those
real-hardcore hackers, adb will do in a lot of cases ;-).
First project for some will be increasing the number of mount points, which
was kindly increased to 8 in 3.51m (from 4), but some of you have big
disks [you know who you are :-)] and need a few more... Looking at the
assembly of conf.o, the common blocks of memory are allocated there.
[...]
comm mount,144
Hmm, 144 / sizeof(struct mount) = 8... wonder why? :-)
Ok, now looking in (lib1)sys3.o there is the system call mount(). Assembly
shows that the "8" is compared to bdevcnt, and then if not it returns
errno=6. (#define ENXIO 6 /* No such device or address */)
I guess that could easily be reassembled and then relinked. As soon
as it's released, I'd like to hear the hardcore hacking stories.
You can even go as far as changing your version number, for those who
what to confuse the rest of the world, in name.o :-)
utsname is compiled as:
UNIX
UNIXPC
SYSTEM5
3.51m
mc68k
You'll all be happy hacking soon!
-Lenny
--
| Lenny Tropiano ICUS Software Systems lenny@icus.ICUS.COM |
| {ames,pacbell,decuac,sbcs,hombre,rayssd}!icus!lenny attmail!icus!lenny |
+------ ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752 ------+andy@juno.caltech.edu (Andy Fyfe) (04/11/90)
A while back someone made the observation that one can easily buy a board that houses a 68020 and plugs into a 68010 (or was it 68000) socket. The problem, of course, was the software. Now that the kernel is available in its consistuent pieces, is it now possible to correct the software problem? The Gnu C compiler is capable of generating 68020 code, and, it seems, the assembler and linker are more than happy to deal with it. Included below are diffs to tm-3b1.h that correct a few minor 68020 boo-boos. (If someone would like to check them, I'll delay forwarding them to bug-gcc.) I've been able to make a 68020 version of gcc, though, of course, I can't run it! Maybe this would even permit a 68881 to be added. (This is where a problem comes up with the loader. A file that uses floating point is flagged by the assembler as either "soft" or "68881". Unfortunately, the loader doesn't appear to allow these two types of objects to be mixed together.) Here are a few lines you can add to /etc/magic to get the cpu and fpu type of a file (this in the m68k executable section): >18 short &0x1800 0x0000 [68010] >18 short &0x1800 0x0800 [68020] >18 short &0xe000 0x0000 [float-none] >18 short &0xe000 0x2000 [float-soft] >18 short &0xe000 0x4000 [68881] >18 short &0xe000 0x8000 [sky] Any thoughts from the experts? Andy Fyfe andy@csvax.caltech.edu *** tm-3b1.h-save Tue Apr 10 02:00:06 1990 --- tm-3b1.h Tue Apr 10 13:33:17 1990 *************** *** 35,39 **** #undef ASM_SPEC ! #define ASM_SPEC "%{m68020:-68020}%{!m68020:-68010}" /* we use /lib/libp/lib* when profiling */ --- 35,39 ---- #undef ASM_SPEC ! #define ASM_SPEC "%{m68020:-68020}%{!m68020:-68010} %{m68881:-68881}" /* we use /lib/libp/lib* when profiling */ *************** *** 97,100 **** --- 97,101 ---- #undef TARGET_VERSION + #undef REGISTER_NAMES #undef ASM_FORMAT_PRIVATE_NAME #undef ASM_OUTPUT_DOUBLE *************** *** 116,119 **** --- 117,125 ---- #define TARGET_VERSION fprintf (stderr, " (68k, SGS/AT&T unixpc syntax)"); + #define REGISTER_NAMES \ + {"%d0", "%d1", "%d2", "%d3", "%d4", "%d5", "%d6", "%d7", \ + "%a0", "%a1", "%a2", "%a3", "%a4", "%a5", "%fp", "%sp", \ + "%f0", "%f1", "%f2", "%f3", "%f4", "%f5", "%f6", "%f7"} + /* Store in OUTPUT a string (made with alloca) containing an assembler-name for a local static variable named NAME. *************** *** 299,303 **** CODE_LABEL_NUMBER (XEXP (addr, 0)), \ reg_names[REGNO (ireg)]); \ ! if (scale != 1) fprintf (FILE, ":%d", scale); \ fprintf (FILE, ")"); \ break; } \ --- 305,309 ---- CODE_LABEL_NUMBER (XEXP (addr, 0)), \ reg_names[REGNO (ireg)]); \ ! if (scale != 1) fprintf (FILE, "*%d", scale); \ fprintf (FILE, ")"); \ break; } \ *************** *** 324,328 **** else if (ireg != 0) \ fprintf (FILE, "%s.l", reg_names[REGNO (ireg)]); \ ! if (scale != 1) fprintf (FILE, ":%d", scale); \ putc (')', FILE); \ break; \ --- 330,334 ---- else if (ireg != 0) \ fprintf (FILE, "%s.l", reg_names[REGNO (ireg)]); \ ! if (scale != 1) fprintf (FILE, "*%d", scale); \ putc (')', FILE); \ break; \ *************** *** 384,389 **** if (!strncmp ((PTR), "fmove", 5)) \ { fprintf ((FILE), "fmov"); (PTR) += 5; } \ ! else if (!strncmp ((PTR), "ftst", 4)) \ ! { fprintf ((FILE), "ftest"); (PTR) += 4; } \ } \ /* MOVE, MOVEA, MOVEQ, MOVEC ==> MOV */ \ --- 390,395 ---- if (!strncmp ((PTR), "fmove", 5)) \ { fprintf ((FILE), "fmov"); (PTR) += 5; } \ ! else if (!strncmp ((PTR), "fbne", 4)) \ ! { fprintf ((FILE), "fbneq"); (PTR) += 4; } \ } \ /* MOVE, MOVEA, MOVEQ, MOVEC ==> MOV */ \
jan@bagend.UUCP (Jan Isley) (04/12/90)
In article <1990Apr11.042020.5317@laguna.ccsf.caltech.edu> andy@csvax.caltech.edu writes: >A while back someone made the observation that one can easily buy a >board that houses a 68020 and plugs into a 68010 (or was it 68000) >socket. The problem, of course, was the software. Now that the kernel >is available in its consistuent pieces, is it now possible to correct >the software problem? Yea, that was me. In fact I have such a board sitting here, waiting for the day that I have software to run on it. Since I am a dealer for the company that makes the board, I am of course interested in doing a group buy for these things. :-) When I plug the board in the system turn the power on, all four LEDs light up and the dreaded squiggly line, total failure, screen appears. >Any thoughts from the experts? ditto... ? jan -- jan@bagend {..gatech..}!bagend!jan (404)434-1335 voice@home