C0033003%DBSTU1.BITNET@cunyvm.cuny.edu (04/07/88)
Tony Goodloe <goodloe@xenon.uucp> writes: >Does anyone have any experience running Minix on a Tandy 1000? What do I >need to do to get Minix running? It will boot, but when I try to load >the root file system the computer hangs. Also, are there any special >considerations when using a hard disk on the 1000 with Minix? >Thanks for any help] I had exactly the same problem when bringing MINIX to my new ITT 80386 machine. So I posted this problem and got a response from Wes Peters (thanks Wes): >Date: Sat, 2 Apr 88 18:14:26 GMT >From: Barnacle Wes <wes@obie.uucp> >Subject: Re: MINIX on ITT 386s >This is the same behavior I've noted when trying to boot Minix on two >different 386 machines: AMT 386, with 64K SRAM cache, and Acer 1100, >using interleaved RAM. I've even tried slowing them to 6 MHz - still >didn't work. We began tracing the problem, and decided it probably >lives in the BIOS. We have some NEC APC IV's here, 2 with Rev A BIOS, >and 2 with Rev B BIOS. The two with Rev B boot Minix without >problems, the two with Rev A act the same as the 386s. >When you press `=' to tell the Minix loader program to load Minix, it >makes a BIOS call to do something (.......) Apparently, >this BIOS call is where it dies. I think this BIOS call is only made >in the AT version of Minix. > Wes Peters If it's really this way it should not be a special problem of the TANDYs or ITT 80386s. Booting is done with those standard BIOS functions the same way like MS-DOS would be booted otherwise. If you type '=' after booting MINIX is started ( jump to 1536 ). On my machine ( ITT80386 ) the floppy-drive starts and keeps running all time until I reset. If the BIOS calls would be used it should still work? This looks like MINIX is waiting for something in its own floppy drivers. Maybe discrepancies in the disc-controller's registers? Any ideas? Detlef J. Schmidt C0033003 at dbstu1.bitnet computing center university of brunswick
brucee@runx.ips.oz (Bruce Evans) (04/18/88)
Detlef J. Schmidt <C0033003%DBSTU1.BITNET> writes: >>From: Barnacle Wes <wes@obie.uucp> >>When you press `=' to tell the Minix loader program to load Minix, it >>makes a BIOS call to do something (.......) Apparently, >>this BIOS call is where it dies. I think this BIOS call is only made >>in the AT version of Minix. The BIOS call is just get_chrome() to see if there is a color monitor. Like most BIOS calls, the first thing it does is a "STI" instruction to enable interrupts. It is called right in the middle of kernel/main(), just before replacing the vector table. This violates the lock() made at the beginning of main(). Usually this causes no problem because the only active vectors belong to the BIOS and point into ROM. It is possible that some BIOS's do something more creative, but I can't think of anything reasonable which would hurt. I had problems with this when loading Minix directly from DOS, using an improved version of a program posted by Marty Leisner. The program now relocates Minix to low memory to avoid losing the "small" amount of 128K+. This makes the vector table invalid (DOS has been overwritten) and the "STI" in get_chrome() bites. To fix this, I used the interrupt controller to disable interrupts more securely: port_out(INT_CTLMASK, ~0); port_out(INT2_MASK, ~0); This belongs with the lock() at the start of kernel/main(), or even earlier with the redundant locks in the assembler startup. There's also a problem with the way Minix enables ALL interrupts at the controller level later on (writing 0 to the controller where ~0 was above). As soon as the restart() at the end of main() is done, interrupts are enabled, and this is before any of the tasks (interrupt handlers) have been initialized. The standard Minix handlers seem to cause no trouble, but problems with mouse interrupts (?) have already been reported. I had problems with a tty driver. It took the port address 0 from an unininitialized table and did i/o to it. Not safe when that port has something to do with DMA. The right way to set up the interrupt controllers is to leave each bit set until the corresponding driver has been initialised, and let the driver worry about clearing it. I use a function PUBLIC enable_int( unsigned vec_nr ); to take care of this, and a function PUBLIC set_int( unsigned vec_nr, vir_bytes (*addr)(), phys_clicks seg ); to set up a vector and enable it in one step. Bruce Evans Internet: brucee@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!brucee