Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261827AbTEKRrX (ORCPT ); Sun, 11 May 2003 13:47:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261832AbTEKRrX (ORCPT ); Sun, 11 May 2003 13:47:23 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:58446 "EHLO frodo.biederman.org") by vger.kernel.org with ESMTP id S261827AbTEKRrV (ORCPT ); Sun, 11 May 2003 13:47:21 -0400 To: Davide Libenzi Cc: Jamie Lokier , Jos Hulzink , Linus Torvalds , Andi Kleen , Linux Kernel Mailing List Subject: Re: [PATCH] Use correct x86 reboot vector References: <200305111137.29743.josh@stack.nl> <20030511140144.GA5602@mail.jlokier.co.uk> From: ebiederm@xmission.com (Eric W. Biederman) Date: 11 May 2003 11:56:42 -0600 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1768 Lines: 33 Davide Libenzi writes: > On Sun, 11 May 2003, Jamie Lokier wrote: > > > Jos Hulzink wrote: > > > On Sunday 11 May 2003 05:50, Linus Torvalds wrote: > > > > Hmm.. Doesnt' a _real_ hardware reset actually use a magic segment that > > > > isn't even really true real mode? I have this memory that the reset value > > > > for a i386 has CS=0xf000, but the shadow base register actually contains > > > > 0xffff0000. In other words, the CPU actually starts up in "unreal" mode, > > > > and will fetch the first instruction from physical address 0xfffffff0. > > > > > > > > At least that was true on an original 386. It's something that could > > > > easily have changed since. > > > > I got my info from an article on the net which says that a 386 does > > behave as you say, but it is possible for the system designer to > > arrange that it boots into the 286-compatible vector at physical > > address 0x000ffff0. It states that the feature is specifically so > > that system designers don't have to create a "memory hole" (that's as > > much detail as it gives). > > Guys, mem[0xfffffff0,...] == mem[0x000ffff0,...] since the hw remaps the > bios. Being picky about Intel specs, it should be f000:fff0 though. The remapping is quite common but it usually happens that after bootup: 0xf0000-0xfffff is shadowed RAM. While 0xffff0000-0xffffffff still points to the rom chip. Now if someone could tell me how to do a jump to 0xffff0000:0xfff0 in real mode I would find that very interesting. Eric - 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/