John Clark wrote:

> I followed that advice, and verified that the 1.6.2 kernel boots for 
> both the bootlap1.fs and the boot-big.fs
> installation floppies.
>
> So, what are the differences in the 'from-bios-off-disk-boot-block', 
> as the 2.0 boot-big.fs floppy does not
> even get me to the initial 'loading netbsd in xx sec...' message.
>
> I'll look further, but I've not needed to venture into this area of 
> the netbsd environment before.



I've looked a little bit at the difference between the 1.6.2 boot code 
and what is a 'recent' cvs downloaded
version of 2.0.

There seems to be quite a change, so I'll just look at the 2.0 version 
for the moment.

I put the image 'boot-com1.fs' (this way I can capture the output on 
another computer using the serial line
as the console) on a CF device and 'simulated' a floppy boot.

The captured boot output is:

 >> NetBSD/i386 BIOS boot, Revison 3.2
 >> (root@netbsd_pc, Mon Jan 31 04:31:10 PST 2005)
 >> Memory: 632/252864 k

Then nothing...

On looking at the code file: sys/arch/i386/stand/boot/boot2.c

The below lists the boot2.c sequence.

------
print_banner();

bios2dev(boot_biosdev, &default_devname, &default_unit,
    boot_biossector, &default_partition);
...
default_filename = DEFFILENAME;

printf("Press return to boot now, any other key for boot menu\n");
...
----------

The line: printf("Press ....

Never is executed, or at least nothing is seen on the terminal which would
indicate the code got to this point.

The function: bios2dev

does eventually call back to the BIOS to read disk blocks.

However, in comparing the 1.6 code to the 2.0 code at the very beginning
of the 'startup', there appears to be some amount of code in the1.6 
which clears
the AX, then sets the various CS, DS, ES registers to 'zero'.

At this point, because I tuned out of the x86 world at the assembly 
level at about
the 286 era, and got a headache recalling all the extended/expended 
segment nonsense,
I'll have to leave off for the moment. But it seems that something is 
not set up correctly
when the bios2dev call eventually goes back to the BIOS and then never 
returns.

Food for thought perhaps...

John Clark