Subject: Re: Problems with VIA tech EDEN ESP CPU core.
To: None <port-i386@NetBSD.org>
From: John Clark <email@example.com>
Date: 03/25/2005 18:44:51
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
On looking at the code file: sys/arch/i386/stand/boot/boot2.c
The below lists the boot2.c sequence.
bios2dev(boot_biosdev, &default_devname, &default_unit,
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
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
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
Food for thought perhaps...