Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!munnari.oz.au!metro!dmssyd.syd.dms.CSIRO.AU!ditsydh.syd.dit.CSIRO.AU!evans
From: evans@syd.dit.CSIRO.AU (Bruce.Evans)
Newsgroups: comp.os.minix
Subject: Re: bootblok.s and/or build.c for Minix-386
Message-ID: <1991Jun6.114503.9942@syd.dit.CSIRO.AU>
Date: 6 Jun 91 11:45:03 GMT
References: <33395@usc.edu>
Organization: CSIRO Division of Info Tech, Sydney, Australia
Lines: 33

In article <33395@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes:
>There is a strange phenomenon happening for me while building boot disks
>for Minix-386.  I am using the traditional tools in /usr/src/tools, and
>my boot floppy is a 1.2M in /dev/at0.
>
>When NR_BUFS is >= 200, the boot process fails somewhere in bootblok.s
>after printing the greet message, and before running menu.
>
>When NR_BUFS is <= 150, everything works great.  Nothing else changed.

The following problems with the "traditional tools" are known:

1) bootblok overwrites itself without checking if the image is large.
Kludge fix: increase BOOTSEG to 0x9FA0 (or less if you don't have 640K).
Correct fix: ask the BIOS for the size, give up if not enough, otherwise
calculate BOOTSEG to be just large enough and continue as now.

2) build doesn't handle NR_BUFS above about 50 in 16-bit mode. Fix: leave
NR_BUFS as 30 and use the 16-bit build. Rebuild the system with NR_BUFS
big and use the 32-bit build.

3) build gets the sector count short by 1. Usually this doesn't matter
because the symbol table for menu provides suitable (junk) padding. It
does matter with the dummy db. Fixes: use the standard build and bootblok.s
(patched for bug 1) so as not to get db; add 1 in build; or add 512 bytes
of dummy data in db.s.

I'm not sure how versions built with the ACK compiler work, because there
is no symble table. Perhaps unimportant bss is left out, and this is why
menu1.s wastes time clearing the bss after it has already been cleared
by build.
-- 
Bruce Evans		evans@syd.dit.csiro.au