Messages in this thread | | | Subject | Re: [PATCH] Use correct x86 reboot vector | From | (Eric W. Biederman) | Date | 11 May 2003 11:56:42 -0600 |
| |
Davide Libenzi <davidel@xmailserver.org> 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/
| |