From: Jos Hulzink <josh@stack.nl>
To: Jamie Lokier <jamie@shareable.org>, Andi Kleen <ak@muc.de>
Subject: Re: [PATCH] Use correct x86 reboot vector
Date: Sat, 10 May 2003 21:41:57 +0200
User-Agent: KMail/1.5
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
References: <20030510025634.GA31713@averell> <20030510161529.GB29271@mail.jlokier.co.uk>
In-Reply-To: <20030510161529.GB29271@mail.jlokier.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200305102141.57860.josh@stack.nl>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1529
Lines: 31

On Saturday 10 May 2003 18:15, Jamie Lokier wrote:
> I just did some Googling and found that there examples of DOS code
> fragments using both vectors.  Also, the original IBM BIOS (as they
> say) had a long jump at the vector, which is presumably one of the
> many de facto ABIs which real mode programmers grew to depend on.

The 16 byte code space is very small, and usually only contains that LONG jump 
to an usable address space.

When the vector f000:fff0 is used, we can survive BIOSes that use relative 
jumps with negative offsets or indirect short jumps instead.

When the vector ffff:0000 is used, the code segment effectively contains only 
16 bytes (or someone must abuse the 8086 wraparound), can't think of negative 
offset short jumps there. As the code is read-only in this early stage, (BIOS 
code is RW after the BIOS copied itself to RAM) self modifying code (which 
uses absolute addressing) can be excluded too.

Okay... now, as 386 and newer cpus need a far jump to unlock A20-A31, I think 
it is safe to assume all BIOSes will do a far jump as soon as possible, which 
means it doesn't matter which vector is used.

For the sake of bad behaving BIOSes however, I'd vote for the f000:fff0 
vector, unless someone can hand me a paper that says it is wrong.

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