Messages in this thread Patch in this message | | | Date | Tue, 12 Oct 1999 17:51:26 -0400 (EDT) | From | Chris Noe <> | Subject | 2.3.21: [patch] bootcode fixes, take 3. |
| |
> Almost asleep when I realized that setup.S and video.S hold the same > treasure trove of 16-bit bases. So much for 'has been well tested' - guess > all the testers had the same version of binutils. Bugger. > > Now why couldn't the 'index/base must be 32 bit' error just be a warning > instead of something that bombs a compile. > > This is an accumulated patch that has all the previous fixes included and > should fix *all* of the various buglets in 2.3.21's bootcode caused by the > incompatibility of certain binutils versions.
Now after all that worrying and quick patching, I discovered that the '32 bit base' bug is non-existant and non-relevant as long as it is compiled with binutils 2.9.1.0.7 or above.
I had known this all along (the horrible compatability problems with early binutils) but all the reports so far had (mistakenly) said that they had used a recent binutils, leading me to believe it truly was just an overlooked problem.
All the '32 bit' errors caused so far have been due to older versions of binutils which don't do the right things (in more than one instance).
<wipes cold sweat from brow>
I guess I was trying to stay a bit *too* on top of this -- being responsible for breaking the compile singlehandedly and all :)
Anyway, here's the latest attempt at all fixes. Please try with binutils 2.9.1.0.7 and up (and with the new 2.9.5's too; I'm curious as to what they have to say).
There is something to be said in breaking from 2.9.1 binutils altogether, and going for 2.9.5.0.xx -- I've seen a tremendous improvement in the code gen (esp 16 bit), and seems to be a bit better versed in error reporting. There are a few codegen bugs in 2.9.1 that I had to explicitly code around (in video.S), that I'd love to get rid of.
I'd recommend adding something to Changes that moves the minimum to 2.9.5, but I'm not at all sure what the latest 2.9.5 is, nor which is considered most stable/bugfree.
Chris Noe (stiker@northlink.com) --- bootsect.S.orig Tue Oct 12 06:36:19 1999 +++ bootsect.S Tue Oct 12 17:25:24 1999 @@ -247,7 +247,7 @@ xorw %bx, %bx # bx is starting address within segment rp_read: #ifdef __BIG_KERNEL__ - lcall bootsect_kludge # in setup.S + .word 0x1eff, 0x0220 # lcall * bootsect_kludge in setup.S #else movw %es, %ax subw $SYSSEG, %ax @@ -398,11 +398,9 @@ # don't have to worry about it later. kill_motor: - pushw %dx movw $0x3f2, %dx xorb %al, %al - outw %al, %dx - popw %dx + outb %al, %dx ret sectors: .word 0 --- setup.S.orig Tue Oct 12 06:36:23 1999 +++ setup.S Tue Oct 12 17:43:29 1999 @@ -145,7 +145,7 @@ #ifdef SAFE_RESET_DISK_CONTROLLER # Reset the disk controller. movw $0x0000, %ax - movb $0x80, $dl + movb $0x80, %dl int $0x13 #endif @@ -400,7 +400,7 @@ subw $DELTA_INITSEG, %ax # aka INITSEG movw %ax, %ds xorw %ax, %ax - movw %ax, 0xa0 # set table length to 0 + movw %ax, (0xa0) # set table length to 0 movb $0xc0, %ah stc int $0x15 # moves feature table to es:bx @@ -496,7 +496,7 @@ cmpw $0, %cs:realmode_swtch jz rmodeswtch_normal - call *%cs:realmode_swtch + lcall %cs:realmode_swtch jmp rmodeswtch_end
| |