subelman@ttidca.UUCP (05/05/87)
I finally got MINIX to work on my XT-2000 clone with a Seagate ST225 and a WD1002S-WX2 controller. The main problems were with a read-only disk, cured by Don Dugger's (n0ano@wldrdg) patch (thanks, Don), and with an fsck that refused to work at all. The problem with fsck is that it uses the BIOS for its I/O. The BIOS in the controller uses part of the first 1K of RAM as a scratch pad. This same area is used for the stack of the MINIX bootblock. Thus MINIX and the BIOS step on each others toes. The cure is easy: move the bootblock's stack to high memory. In file /user/tools/bootblok.s make the following change: lines 62-63 were: mov ss,ax |set ss to 0 mov sp,#1024 |initialize sp (top of vector table) and should be changed to mov ss,dx |set ss to our cs mov sp,#1536 |set stack 1K above bootblock (This is the bootblok.s file used when MINIX is the development environment). After this change, recompile bootblok using the makefile and rebuild the boot diskette. There are two caveats: 1) if you hit CTRL-ALT-DEL while in MINIX, it brings up the bootstrap menu. However, the BIOS tables have been wiped out by the kernel, so fsck won't work again. Hit CTRL-ALT-DEL a second time in the menu. This forces the BIOS to reset itself, and a fresh menu to be brought up. Fsck will then work. 2) If you strapped the controller for its autoconfig option (I didn't) then the controller builds a table in RAM, in this same area. While fsck will still work with my patch, the kernel will not be able to read this table and the device driver will not work. Richard Todd (rmtodd@uokmax) first discussed how to solve this one. -- Ed Subelman {csun|philabs|psivax|trwrb}!ttidca!subelman Citicorp(+)TTI (213) 450-9111, x2972 3100 Ocean Park Blvd., Santa Monica, CA 90405