On Tue, Jul 15, 2003 at 06:10:04PM +0000, Matthias Scheler wrote:
> In article <20030713201012.B980@snowdrop.l8s.co.uk>,
> 	David Laight <david@l8s.co.uk> writes:
> > Because you will have reset the CHS values in the mbr when you ran
> > sysinst.
> 
> I never ran sysint on this system. It was installed back in the NetBSD 1.0
> timeframe and update afterwards. I rewrote the bootblocks manually after
> using a boot floppy to load the kernel from the harddisk.

Ok - you had said that you'd installed netbsd again...

I've finally looked at the code (instead of guessing what was in which
version).  The biosboot.sym from current is different from that for 1.6.1
because I commited the version that moves the stack in order to get around
a problem with the stack hitting the bss after some other minor changes.

It also looks as though the 'new' biosboot code is using much the same
code (albeit from different source files) for the real to/from protected
flip (which is what is likely to be misbehaving).

This code is painfully tedious to debug.  If you can get a boot floppy
built on a different system to fail you'll be able to do more tests.

You (I can't do the same tests) need to work out how far it actually
gets before locking up.

Look at src/sys/arch/i386/stand/lib/crt/bootsect/start_bootsect.S
and add calls to dump_eax or message while in 16-bit mode
or trace_int or trace_str in 32-bit modes.

A trace just before the first real_to_prot call (line 520) might
be a good first check.
Then flip immediately back to real mode for another trace, before
re-entering protected mode for bootsectmain.  eg:

	call	dump_eax
        /* change to protected mode */
        calll   _C_LABEL(real_to_prot)
        .code32
	call    _C_LABEL(prot_to_real)
	.code16
	call	dump_eax
        calll   _C_LABEL(real_to_prot)
        .code32

        pushl   %esi            /* sector where we found bootstrap */
        movzbl  %dl, %edx       /* discard head (%dh) and random high bits */
        pushl   %edx

        call    _C_LABEL(bootsectmain)

Might also be worth checking that the objects are all built from the
current sources.  (delete the relevant part of the the object tree
and build again)

	David

-- 
David Laight: david@l8s.co.uk