11

from wikipedia: The reset vector for the 8086 processor is at address FFFF0h Where is the reset vector stored?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Jordan Boehm 'J.Dawg'
  • 111
  • 1
  • 5
  • I'm not sure why the snarky answer, “At address FFFF0h” isn't the correct answer. What is it you want to know? – Emmet Mar 10 '14 at 22:13
  • I want to know where the cpu get it's initial instructions upon boot up. Like how does the processor know where the firmware is and how to boot it. Also I wasn't being snarky, I know wikipedia may be wrong though. – Jordan Boehm 'J.Dawg' Mar 10 '14 at 22:21
  • I think you don't understand by what I mean by "Stored". Right. It's at FFFF0H but is that is ROM, HDD etc..?? – Jordan Boehm 'J.Dawg' Mar 10 '14 at 22:31
  • It's ROM. See my answer below. The CPU has no clue how to talk to a HDD at boot. It only acquires that capability by running some code in the BIOS that then enables it to talk to a limited set of bootable peripherals. – Emmet Mar 10 '14 at 22:34
  • If you "jmp" to it, when the program counter executes from this location, it should be equivalent to hitting the reset button. Not initial boot (FFF40h ?). There is no data here, it is executable code. – mckenzm Nov 07 '16 at 21:26

2 Answers2

19

The address of the reset vector — in this case FFFF0h — of a CPU is fixed in hardware by design. It is part of the specification of the CPU. The CPU goes to that address, fetches whatever address it finds there, jumps to that address, and begins executing. It is a kind of double indirection with a fixed first step (the CPU goes to address FFFF0h, which is most likely in a ROM of some kind) and a second step that depends on the machine. In a PC, the vector will point to early initialization code in the BIOS that begins the boot process, but more generally, it could in principle be anything that can be hardware memory-mapped into that address, but 99.9% of the time, it's some kind of ROM (PROM, EPROM, EEPROM, etc.).

For example, suppose that the design specifications for a CPU with a 32-bit address space is such that the cold boot (power on) vector is 0xffff4, the reset vector is 0xffff0, and the intention is that the bottom 1MiB (0x00000 to 0xfffff) is reserved for ROM boot code. Suppose that you buy a board with a socket for a 1MiB ROM that's mapped into that address space.

Then you write a ROM BIOS for this machine that is, say, about half a megabye, and the result of fiddling around with your compiler and assembler is that you end up with an object-code file where the very first code that you want to run on power-on is 0x1230 bytes offset into the file, where you do a little ultra-basic setup, and then jumps to offset 0x3210 in the file, where the code is adequate to start from a warm boot or reset. In this case, you would pad your object-code file out to 1MiB, make sure that the value 0x00003210 is at offset 0x000ffff0, and the value 0x00001230 is at offset 0x000ffff4.

You burn the file onto a compatible ROM starting at address 0x0 so that the file offsets translate directly into addresses in the range 0x00000000 to 0x000fffff. When the machine is turned on, it goes immediately to address 0x000ffff4, finds the value 0x00001230 there, loads that value into the instruction pointer (or program counter, whatever you want to call it) and begins executing at address 0x00001230 where your cold boot code is.

The CPU knows if it has been reset or turned completely off and then on again. If the CPU is reset (e.g. by being triple faulted), then instead of going to address 0x000ffff4, it goes to its reset vector at 0x000ffff0, loads the value 0x00003210 and begins executing that. This is essentially how a PC can skip the POST when it's rebooted, but not when it's powered off and back on again. It has different vectors depending on whether it's “cold” or “warm”.

In reality, modern CPUs almost certainly execute a bunch of microcode internally before going near the address and data buses to fetch the reset or boot vectors. This microcode is quite likely to be uploadable to the CPU, but that doesn't change the basic idea at the architectural level, and “vectoring” like this is a very, very old practice that arises from the ubiquity (on non-vectored CPUs) of the reset address containing instructions equivalent to “jump to address 0x01230”, effectively doing the “vectoring” manually.

Emmet
  • 6,192
  • 26
  • 39
  • 1
    Okay so it's usually in ROM, PROM EPROM, EEPROM etc.., but aren't there instructions to get the processor to goto that address. "The CPU goes to that address", how does it go there? Things don't just happen by themselves! I'm really trying to get an in depth process of how a computer starts up. – Jordan Boehm 'J.Dawg' Mar 10 '14 at 22:41
  • Would the answer be "The cpu is hardwired to just execute some instructions from the ROM" I want to really grasp this more than just that. – Jordan Boehm 'J.Dawg' Mar 10 '14 at 22:44
  • 3
    The CPU *does* just go there: the reset vector address is fixed by the design of the CPU, so the answer *is* that it is hard-wired into the CPU to begin executing instructions from the address provided at address 0xFFFF0 (or whatever, according to the CPU). Both of these addresses (0xFFFF0 and wherever it points to) are typically in ROM. – Emmet Mar 11 '14 at 00:12
  • 1
    *No* instructions point it to 0xFFFF0. It *always* goes to 0xFFFF0 when it is reset. Always. That's the way the CPU is designed. It's part of the CPU's specification. – Emmet Mar 11 '14 at 00:39
  • 1
    Okay I get it now, lol now how do they hardwire it to that address? – Jordan Boehm 'J.Dawg' Mar 11 '14 at 00:50
  • It's most likely microcode inside the CPU nowadays, but it used to be quite literally hard-wired on the die. I've updated my answer to make it a bit clearer (I hope!). – Emmet Mar 11 '14 at 00:53
  • So is there a table that holds the roms address values? – Jordan Boehm 'J.Dawg' Mar 11 '14 at 01:17
  • I don't think anyone outside the low-level design and test teams in Intel, AMD, ARM, etc. knows the exact implementation details for their respective products. They're entirely irrelevant from the architectural (rather than microarchitectural) perspective that everyone outside these relatively small and select groups works with. – Emmet Mar 11 '14 at 01:30
  • Those are the people I want to talk to! – Jordan Boehm 'J.Dawg' Mar 11 '14 at 01:41
  • Jordan, just relax. Maybe it could help. Take a look at http://stackoverflow.com/questions/23422594/reset-vector-in-386-processors/32721444#32721444 – fante Sep 22 '15 at 19:35
  • There is *nothing* to stop you coding it yourself, in DOS days when we had DBG it was possible to just go there... In the same way we would go to C8000h for the hard disk setup. – mckenzm Nov 07 '16 at 21:26
3

The reset vector is stored along with the firmware in the flash. The reset vector is compiled into the firmware and is located at its end. From slide 15 of Advanced x86: Introduction to BIOS & SMM Internals - Reset Vector:

  • If we dump the BIOS and look at it in a hex editor, at the end of the file we will see a jump instruction (near, relative jump)
  • The chipset aligns the flash so that the limit of the BIOS region (always either the only/last region on the flash) aligns with address FFFF_FFF0h

In EDK2, you can see the assembly code for the reset vector here.

wmjdgla
  • 335
  • 2
  • 10