Subject: Re: Changing NetBSD's partition ID from 0xa5
To: Duncan McEwan <duncan@MCS.VUW.AC.NZ>
From: Matthias Drochner <drochner@zelux6.zel.kfa-juelich.de>
List: port-i386
Date: 06/27/1997 12:38:52
Excerpts from netbsd: 27-Jun-97 Re: Changing NetBSD's parti.. Duncan
McEwan@MCS.VUW.AC (1751*)

> I'm pretty sure the 'a' partition does point to the right place (otherwise
> how would my netbsd partition boot correctly when it has an id of 165?).  So
> I guess I'll have to do some debugging of my change to biosdisk.c.

Yes, enabling DISK_DEBUG would be a start.
You can use dosboot.com for testing as well if it is easier
for you. The manpage is not yet published - sorry.
(Start with -i, type "mode ufs", then "ls <disk>:".)

> I guess the first 512 bytes goes into the first sector of the netbsd
partition
> and gets loaded initially either by the bios (if netbsd is the only OS on the
> disk) or a boot switcher.  Then presumably the next (up to) ~7.5K
(coresponding
> to the old boot[fsw]d file) go into the spare sectors at the start of the 'a'
> partition

That's right so far. The "~7.5K" are exactly PRIM_LOADSZ -1 sectors,
as defined in bbinfo.h. (PRIM_LOADSZ can be at max the track length
of the boot media because this chunk is loaded with 1 BIOS call - look around
line 184 in start_bootsect.S.)

> and this is the code that knows how to read /boot from the
> filesystem. 

The disk blocks used by /boot are patched by "installboot" into a table
(fraglist.S) which must be located in the first 512*PRIM_LOADSZ
bytes of the biosboot program (thus in the text segment).
This table is used in bootsectmain.c to complete the binary in memory.
Until this is finished, the data and bss segments can not be accessed,
and only code below 512*PRIM_LOADSZ can be executed.
The definition of BSSTART (in Makefile.booters) causes the
necessary object files to be linked first.

> Then /boot will be the code that does the countdown and prompts
> for the boot command, etc.

It's actually 1 big program. /boot is not self-contained, it only
holds the remainder of the biosboot program which does not
fit into PRIM_LOADSZ sectors.

> Before I start doing that, could some one give me a clue as to how the boot
> blocks in biosboot.sym are split up when they are installed by installboot?

The first PRIM_LOADSZ sectors are written to the partition start,
the remainder is put into a file "/boot".
The second sector is skipped - it holds the disklabel which should not
be overwritten.

> It would be useful to know which files in the /usr/src/sys/arch/i386/stand
> directory corespond to which parts of the bootstrap.

To summarize:
-BIOS loads first 512 bytes of start_bootsect.S to 7c00
-This loads first 512*PRIM_LOADSZ bytes to 1000 (BOOTSEG)
  and jumps to it (label _boot2).
-This switches to protected mode and calls bootsectmain.c.
-This loads /boot (using the sector table in fraglist.S, the disk
  access code in biosdisk_ll.c and the BIOS interface in bios_disk.S)
  and clears the bss. Now the biosboot program is complete.
-All later disk accesses use biosdisk.c (which uses the same
  functions for physical access but does all partition table lookups
  itself).

> The only possible problem would be if the extra code made the initial
> boot sector too large.  Is this likely?

There is not much space. SERIAL can go, however - the
serial console handling is done at a higher level now.

best regards
Matthias