Linux-kernel mailing list archive 1999-41,: 2.3.21: [patch] bootcode fixes, take 3.

# 2.3.21: [patch] bootcode fixes, take 3.

Chris Noe (stiker@northlink.com)
Tue, 12 Oct 1999 17:51:26 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ming Lei: "Re: : Becoming a Linux Hacker?"
- Previous message: Alan Modra: "Re: PATCH - assembler glitches"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

--8323328-2014372078-939765017=:1727
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.9910121750511.1727@localhost>

> 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)

--8323328-2014372078-939765017=:1727
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=boot-newdiff
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9910121750170.1727@localhost>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME=boot-newdiff

LS0tIGJvb3RzZWN0LlMub3JpZwlUdWUgT2N0IDEyIDA2OjM2OjE5IDE5OTkN
CisrKyBib290c2VjdC5TCVR1ZSBPY3QgMTIgMTc6MjU6MjQgMTk5OQ0KQEAg
LTI0Nyw3ICsyNDcsNyBAQA0KIAl4b3J3CSVieCwgJWJ4CQkjIGJ4IGlzIHN0
YXJ0aW5nIGFkZHJlc3Mgd2l0aGluIHNlZ21lbnQNCiBycF9yZWFkOg0KICNp
ZmRlZiBfX0JJR19LRVJORUxfXw0KLQlsY2FsbAlib290c2VjdF9rbHVkZ2UJ
CSMgaW4gc2V0dXAuUw0KKwkud29yZCAweDFlZmYsIDB4MDIyMAkJIyBsY2Fs
bCAqIGJvb3RzZWN0X2tsdWRnZSBpbiBzZXR1cC5TDQogI2Vsc2UNCiAJbW92
dwklZXMsICVheA0KIAlzdWJ3CSRTWVNTRUcsICVheA0KQEAgLTM5OCwxMSAr
Mzk4LDkgQEANCiAjIGRvbid0IGhhdmUgdG8gd29ycnkgYWJvdXQgaXQgbGF0
ZXIuDQogDQoga2lsbF9tb3RvcjoNCi0JcHVzaHcJJWR4DQogCW1vdncJJDB4
M2YyLCAlZHgNCiAJeG9yYgklYWwsICVhbA0KLQlvdXR3CSVhbCwgJWR4DQot
CXBvcHcJJWR4DQorCW91dGIJJWFsLCAlZHgNCiAJcmV0DQogDQogc2VjdG9y
czoJLndvcmQgMA0KLS0tIHNldHVwLlMub3JpZwlUdWUgT2N0IDEyIDA2OjM2
OjIzIDE5OTkNCisrKyBzZXR1cC5TCVR1ZSBPY3QgMTIgMTc6NDM6MjkgMTk5
OQ0KQEAgLTE0NSw3ICsxNDUsNyBAQA0KICNpZmRlZiBTQUZFX1JFU0VUX0RJ
U0tfQ09OVFJPTExFUg0KICMgUmVzZXQgdGhlIGRpc2sgY29udHJvbGxlci4N
CiAJbW92dwkkMHgwMDAwLCAlYXgNCi0JbW92YgkkMHg4MCwgJGRsDQorCW1v
dmIJJDB4ODAsICVkbA0KIAlpbnQJJDB4MTMNCiAjZW5kaWYNCiANCkBAIC00
MDAsNyArNDAwLDcgQEANCiAJc3VidwkkREVMVEFfSU5JVFNFRywgJWF4CQkj
IGFrYSBJTklUU0VHDQogCW1vdncJJWF4LCAlZHMNCiAJeG9ydwklYXgsICVh
eA0KLQltb3Z3CSVheCwgMHhhMAkJCSMgc2V0IHRhYmxlIGxlbmd0aCB0byAw
DQorCW1vdncJJWF4LCAoMHhhMCkJCQkjIHNldCB0YWJsZSBsZW5ndGggdG8g
MA0KIAltb3ZiCSQweGMwLCAlYWgNCiAJc3RjDQogCWludAkkMHgxNQkJCQkj
IG1vdmVzIGZlYXR1cmUgdGFibGUgdG8gZXM6YngNCkBAIC00OTYsNyArNDk2
LDcgQEANCiAJY21wdwkkMCwgJWNzOnJlYWxtb2RlX3N3dGNoDQogCWp6CXJt
b2Rlc3d0Y2hfbm9ybWFsDQogDQotCWNhbGwJKiVjczpyZWFsbW9kZV9zd3Rj
aA0KKwlsY2FsbAklY3M6cmVhbG1vZGVfc3d0Y2gNCiANCiAJam1wCXJtb2Rl
c3d0Y2hfZW5kDQogDQo=
--8323328-2014372078-939765017=:1727--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Ming Lei: "Re: : Becoming a Linux Hacker?"
- Previous message: Alan Modra: "Re: PATCH - assembler glitches"