Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!udel!mmdf
From: mb...@amsaa-seer.arpa (SECAD-guest)
Newsgroups: comp.os.minix
Subject: MINIX 1.2 on a 386-based machine?
Message-ID: <1569@louie.udel.EDU>
Date: 16 Mar 88 01:49:57 GMT
Sender: m...@udel.EDU
Lines: 33
[ Forgive me if this is a double-posting.. I used the wrong method of ]
[ posting it and figured this was the "right" way.. Mark. ]
Hello All -
Was thinking of purchasing a 386-based machine and wanted to see if
MINIX 1.2 would run on one.
Last Monday I went over to a local dealer who had a bare-bones 386
(Mylex motherboard, 16 MHzok, 1 MByte 100 nsec RAM, 64K static cache, WD
WA2 controller, monochrome monitor + display card to match, and a 360K
floppy drive; he wanted $1,800 for it) and tried booting MINIX.
This test was done with the stock 1.2 PC-style 360K distribution
boot disk set.
The boot software started with no problems. However, a few seconds
after inserting the root file system disk and pressing "=", MINIX
displayed a "trap <16" message, a second message telling me that block 0
on this disk is unreadable, and a third message telling me to press any
key for a re-boot.
Three cycles of this and I thought the root file system disk was
bad. Took it over to a machine with a 286-based motherboard (DTK) and
MINIX booted with no problems.
Question: Has anyone gotten MINIX to run on a 386-based machine?
Please e-mail direct.. if sufficient interest, I'll summarize.
Regards,
Mark Becker
mb...@amsaa-seer.arpa
Path: utzoo!mnetor!uunet!munnari!otc!metro!ipso!runx!brucee
From: bru...@runx.ips.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: MINIX 1.2 on a 386-based machine?
Message-ID: <1437@runx.ips.oz>
Date: 18 Mar 88 16:38:23 GMT
References: <1569@louie.udel.EDU>
Reply-To: bru...@runx.OZ (Bruce Evans)
Organization: RUNX Un*x Timeshare. Sydney, Australia.
Lines: 57
Minix runs normally on my 386. It took only a small modification to the floppy
driver. The AT hard disk driver was no problem. fdisk and fsck gave minor
problems.
My machine is a Micronics motherboard in an AT clone case with AT compatible
I/O. My software is a much hacked V1.2+ kernel, originally on a 360K disk.
This shouldn't have helped but I'm not sure. I use faster routines to write
to the I/O ports, but this hurts because the 386 is sometimes too fast.
Perhaps there are less bugs.
Floppy disk problems
--------------------
The floppy root file system was initially unreadable. A long session with my
debugger gave the following patch.
Line approx 485 in floppy.c fdc_results(), just before the line
port_in(FDC_STATUS, &status)
add a delay loop
{
int k;
for ( k = 0; k < 256; ++k )
;
}
Here 256 is far to many. I think 4 works but am still running with 256. I
don't know exactly why this works! Obviously the 386 is hitting the status
port too fast, but a disassembly of the BIOS showed shorter (programmed)
delays than the slow C code was doing naturally.
No doubt other machines will have other problems. The "trap < 16" message
could be a BIOS problem, but more likely an uninitialized interrupt.
Another thing worth trying is to reduce the machine's speed to avoid timing
problems. If there is no hardware switch, this involves finding how to in
software and doing it in kernel/main().
Hard disk problems
------------------
These have nothing to do with the 386, just with DOS 3.3 and disks > 32 MB.
fdisk has a hard-coded head count of 4, my new drive has 6. People have
reported problems with 5 heads instead of 4 but they must have been in
the XT driver. (My driver is the latest official one that I know of).
fdisk doesn't completely understand all the codes DOS fdisk uses. I previously
had problems with DOS 3.2 fdisk. It gave division by zero crashes on bad
partition tables. The 3.3 version just hangs with what fdisk naturally writes.
I ended up creating a 2nd DOS partition (new ability for 3.3) and zapping it
by hand so DOS does not see it (I hope).
The standalone fsck can't handle block numbers > 64K. It is supposed to give
an error message to that effect, but instead tried to access some unknown
unreadable block. I used a posted Minix version which worked fine.
Bruce Evans
Internet: bru...@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!brucee
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!
bloom-beacon!think!ames!pasteur!ucbvax!agate!labrea!decwrl!sun!pitstop!
sundc!seismo!uunet!munnari!otc!metro!ipso!runx!brucee
From: bru...@runx.ips.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: 386 Minix - first steps
Message-ID: <1776@runx.ips.oz>
Date: 6 Oct 88 19:34:02 GMT
Organization: RUNX Un*x Timeshare. Sydney, Australia.
Lines: 43
I just got Minix converted to run user processes >= 2 in 386 protected
mode. They still only have 64K segments because of compiler limitations,
and have (kernel) privilege 0 so the protection is incomplete. Interrupts
switch to real mode so the old tasks < 2 run unchanged. There is lots of
fiddly mode switching code in assembler, but the C code is only a new 15K
file and maybe 5K kernel diffs, mainly in system.c. When real mode is
eliminated, the assembler code will become much simpler than for the 8088.
This has been 100% reliable over 2 days while unpacking and installing 1.3c.
The user tasks should really be running at (lowest) privilege 3. I actually
had this, and MM and FS in protected mode too for a while, and downloaded
1.3c with it. But some programs core dumped and the floppy gave DMA overrun
errors, so I stepped back a version and then got sidetracked by 1.3c. I had
forgotten about some of the asm code in getutil.s (stupidly hidden in
libc.a). Get_tot_mem() failed early, so I just said 640K, but get_base()
used by fs just returns DS (segment) which fs multiplies by CLICK_SIZE and
fails when DS is just an index. I must ask kernel to look it up and return
phys_bytes instead of clicks. (Can we fix the standard system?) This will
fix the DMA bug and I must look at the other CLICK kludges for the core
dumps.
This has been an "interesting" project. Switching to and from real mode
bought me a lot of insight and a bootstrap platform, but the scaffolding
will be removed before anyone else sees it. I did lots of trial and error,
getting core dumps but rarely crashing the real mode kernel or debugger
(except core dumps themselves tended to corrupt disks when no sync was
possible - I should have disabled it but went ahead fearlessly with 80M
at risk :-)). Most exceptions were in the mode switching code but somehow
the system avoided infinite recursion (reset?).
I can see getting this as far as all protected mode, reasonable privileges,
and optional 32 bit user processes, but addresses limited to 1M, with a
16 bit kernel. Of course this only scratches the surface of the processor's
capabilities.
When the real mode is eliminated, it should almost run on 286's, and perhaps
I should post it before it grows unwieldy. I'm using a home-made compiler,
assembler and linker, but asld could handle the 16 bit version with a small
number of magic .byte's.
Bruce Evans
Internet: bru...@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!brucee