Normal 'boot sequence' for a CPU?
phil
for your average old CPU?
I originally posted this to sci.electronics.basics but have been
advised to try here, so here goes:
Let's take a Z80 for example - when a board with a Z80 (and relevant
RAM, ROM and support chips) is powered on, what is the sequence of
events that takes place?
Does the CPU, for example, first expect an interrupt from some other
part of the circuit? Does it immediately try and access RAM or ROM via
the address lines? Etc.
Or is there a web site somewhere with this info?
I'd really like to know this as it will help my understanding
considerably.
Thanks
Phil
Andy Holt
> I'm curious, please indulge me - what is the normal 'boot sequence'
> for your average old CPU?
>
>
> Does the CPU, for example, first expect an interrupt from some other
> part of the circuit? Does it immediately try and access RAM or ROM via
> the address lines? Etc.
The exact details vary a bit with type of CPU and can be found in the
datasheet for that CPU but in general:
some (usually) external circuitry generates a RESET signal for the CPU
this set the processor into a specified state - almost always with
interrupts disabled. Then the processor either sets the program counter
to a predetermined value (usually, but not always, 0) or reads the
starting value from a fixed memory location (usually, but not always,
near the highest addressable value). Thus you are going to want to have
ROM (or at least non-volatile RAM or a shadow ROM) at the addresses
specified in the data sheet.
The x86 family read the information from the top of memory, most
embedded processors start at 0.
Hope that's a starting point.
Andy
Buddy Smith
> I'm curious, please indulge me - what is the normal 'boot sequence'
> for your average old CPU?
Very dependent on the CPU :)
> Let's take a Z80 for example - when a board with a Z80 (and relevant
> RAM, ROM and support chips) is powered on, what is the sequence of
> events that takes place?
Z80 - made by zilog. Go to www.zilog.com and download the datasheet.
Or look around for sample circuits/code. See if you can get their
development kit, which will include examples.
It probably starts executing from address 0 of RAM or ROM or Flash or
.....
--buddy
Hans Summers
> Let's take a Z80 for example - when a board with a Z80 (and relevant
> RAM, ROM and support chips) is powered on, what is the sequence of
> events that takes place?
>
> Does the CPU, for example, first expect an interrupt from some other
> part of the circuit? Does it immediately try and access RAM or ROM via
> the address lines? Etc.
>
As far as I know, the Z80 just starts executing at address 0000. Normally
the designer would put some ROM there telling it what to do next.
Bill Buzbee
"phil" <pd...@hotmail.com> wrote in message
news:cah_000...@mmc.et.tudelft.nl...
> I'm curious, please indulge me - what is the normal 'boot sequence'
> for your average old CPU?
As the other posters have said, it's CPU dependent, and your best bet is to
pick a CPU and read the data sheet. However, since I've just been
intimately involved in this very question for my own hobby project
(homebuilt TTL cpu - http://www.homebrewcpu.com), I'll blather on a bit
here.
The boot sequence for a processor can be quite complex. In a sense, it's
simple - the cpu must power on into a known base state, and from there pull
itself up. That base state is usually as simple as possible. For example,
interrupts off, PC set to fixed address (often 0), hardware address
translation off (i.e. - you operate on real physical addresses, not virtual
addresses) and running in supervisor mode.
For my machine, I start up as above (operate out of physical memory (code
from ROM with a little bit of RAM to play in). Execution starts at physical
address 0x0000 in device space (which is mapped to ROM). The ROM bootstrap
code then sets a set of page table entries pointing to the first 64K bytes
of RAM in my memory space. Next up, the bootstrap code copies itself from
ROM to RAM. To do this, hardware address translation is temporarily
enabled. Finally, once the environment is set up a somewhat complex
transition is performed that atomically turns on hardware address
translation and interrupts (uses a return from interrupt instruction). From
this point on, we are now executing out of RAM rather than ROM.
At this point, you could consider the boot-up of the CPU complete. It's
operating in it's intended mode. However, the machine still has to complete
the rest of the boot-up sequence to get the simple hack I have that passes
as an operating system running. This involves enabling the real-time clock,
ide hard drive interface and serial ports and then loading an OS/monitor
image from disk. Once the new OS image is loaded, another "return from
interrupt" transition is made, and control is transferred again.
I think I've babbled on a bit too much here. The key thing to think about
is that when a CPU is powered up, it has little to no idea about the
hardware configuration of the rest of the computer. How much memory is
there? What devices? Interrupt sources? It just doesn't know. So, there
has to be some base level of operating environment that it can count on. It
will begin execution from that base state, and then the boot-up code has to
discover what the environment is like and enable and configure CPU features
as necessary.
....Bill Buzbee
phil
Thanks very much for all the helpful replies. :-)
John Hudak
Buddy Smith wrote:
> phil <pd...@hotmail.com> wrote:
>
>>I'm curious, please indulge me - what is the normal 'boot sequence'
>>for your average old CPU?
>
>
> Very dependent on the CPU :)
More or less true, but...many of the popular micros (8 bit) of the late
70s and 80s would boot to FFFF and FFFE to pick up the address of the
first byte of application code. FFFC-FFFD would be the non-maskable
interrupt vector, and other continous addresses (FFF0-FFFB) were other
'predefined' vector locations that the architecture would know about.
Its been a while since I programmed any of them, but referring to the
specific device data sheet will provide the necessary information.
>
>
>>Let's take a Z80 for example - when a board with a Z80 (and relevant
>>RAM, ROM and support chips) is powered on, what is the sequence of
>>events that takes place?
>
>
> Z80 - made by zilog. Go to www.zilog.com and download the datasheet.
>
> Or look around for sample circuits/code. See if you can get their
> development kit, which will include examples.
>
> It probably starts executing from address 0 of RAM or ROM or Flash or
> .....
No, Low addresses were almost always RAM and used for data stores. SOme
processors, like the 6502, had special addressing modes to more
efficiently access and manipulate data in the 0 page of memory (for an
address space of 64Kb, a page is defined at 256 bytes)
>
> --buddy
>
cr...@ruffspot.net
Buddy Smith <nullset....@dookie.net> wrote:
>phil <pd...@hotmail.com> wrote:
>> I'm curious, please indulge me - what is the normal 'boot sequence'
>> for your average old CPU?
>
>Very dependent on the CPU :)
Yes, indeed. For at least some of the more modern Alpha processors,
the CPU loads the contents of a serial rom into the instruction cache,
then executes that code from the cache. That code then takes care
of configuring the CPU (running in privileged mode, aka palcode) to
actually start talking to the outside world. RAM is configured and
then code in another external ROM can then be jumped to to continue
the process.
Norm Dresner
news:cah_000...@mmc.et.tudelft.nl...
> Buddy Smith wrote:
> > Z80 - made by zilog. Go to www.zilog.com and download the datasheet.
> >
> > Or look around for sample circuits/code. See if you can get their
> > development kit, which will include examples.
> >
> > It probably starts executing from address 0 of RAM or ROM or Flash or
> > .....
> No, Low addresses were almost always RAM and used for data stores. SOme
> processors, like the 6502, had special addressing modes to more
> efficiently access and manipulate data in the 0 page of memory (for an
> address space of 64Kb, a page is defined at 256 bytes)
Many Z-80s used in embedded systems did in fact have (E)PROM at the low
addresses since there was no reason to put it anywhere else. A large
percentage of CP/M systems had (E)PROM that started at a low address and
then relocated itself to a high location to reveal an underlying RAM.
Norm