startup of the bare hardware metal

Le 24/05/2012 20:23, piyushpandey a écrit :

When powering on a board, a reset signal is asserted by an IC called the reset circuit. See here, for instance:

The reset signal is tied to the reset pin of the microprocessor. When the signal is asserted, an interrupt occurs. This interrupts is serviced by a program which is called the bootstrap.

Look for "reset interrupt" or "non maskable interrupt".

That's the job of the reset logic. Registers, including the program counter, are set to defined default values. When the processor comes out of reset, it starts executing at the address in the program counter. Exactly which address that is will be processor-specific. Sometimes, for example, the state of one or more inputs can be used to start at a different address as, say, at a bootloader routine in high memory instead of user code.

Individual data sheets will specify what else goes on prior to vectoring to the boot address, which may include things like setting a clock source or starting a watchdog timer.

It's more like register-transfer level code (gates and flip-flops) than the cycle of "fetch, decode, execute" with user code. It's also what implements the processing of user code.

Read the data sheet! For example, the datasheet for the ATMega8 that you mentioned has a decent description of the reset circuitry.

That's totally different between chips.

In general, the processor core starts with some registers initialized to default values. This always includes the program counter register, which is initialized to a specific address, where execution begins. In smaller processors, this will be the built-in flash, so execution starts with the first instruction of the program in flash. In bigger processors, there will be a built-in ROM containing a program which checks fuse bits or boot-mode pins, selects a boot device, initializes that, and loads your boot loader from there. This program can have varying complexity, from "copy a few bytes from SPI flash into internal RAM and execute that" to "initialize a MMC card, parse a FAT file system, and load a file into RAM".

When your program is running, it'll have to set up everything the processor has not yet set up. For a LED blink application in an 8 bit micro, you'll probably have nothing more to do than to set up the LED GPIO and a timer; for a bigger system, you'll have to start by configuring clocks, external RAM, etc., before loading the actual program.

Stefan

guys

is the booting process total a hardware specific process as I think since the software part comes into play only when the whole board gets powered up as I have read so far that during boot the voltage levels and other power requirements of each device is checked and each device is initialised before transfering the control to the operating system.

So what I am thinking is that it is a total hardware specific process , but at the same time I thought that after we switch the power button than the CPU gets reset, so after that the control has to be transferred to the software which takes the checking job of each device and their initialisation task in it's hand.

but again the same powering problem , actually I am little bit confused and it seems to me like the chicken and egg problem.

So first of all tell me that how much percentage or part of the boot process is the hardware specific and how much is software specific.

thank you

--------------------------------------- Posted through

The boot logic, which let us agree is the hardware-based process that occurs prior to execution of the first element of code (whether that be user-code or a vendor-installed boot loader), sets the device registers to "default" states which should be specified in the datesheet or user manual.

If the default states are sufficient there's nothing more for user code to do. That's not going to be the case for any useful application, so the application code will modify the device registers from their default settings to whatever it requires.

I think that you may be confusing "What things are called" with "What things do." Call the hardware process that occurs prior to code execution "boot" and call the application-specific process that is code driven and which occurs after the boot process "initialization." Problem solved. 100% of the boot process is hardware.

The reset operation is quite similar to any hardware interrupt, except it does not save the (non-existent) previous context.

Typically when some hardware interrupt occurs, the interrupt vector is used to load the interrupt service routine (ISR) start address into the program counter. Some other values may also be loaded from the interrupt vector, such as a private stack pointer value used only by the ISR and possibly some processor status word values.

The ISR starting at the starting address specified in the vector then takes over and performs the required function.

The reset vector operates in the exact same way. The reset vector is typically situated in a hardware specific address, typically as the first (0x0000) or last word (0xFFFF, 0xFFFFFFFF) in the processor physical memory map.

As a consequence, the reset vector must be located in some kind of non-volatile memory, such as magnetic core, (e)PROM or flash.

Obviously you have to use hardware to make it possible for software to run. Generally, you use a hardware voltage supervisor circuit which makes sure you have enough volts to run a CPU core, before releasing the CPU's reset. Those usually also have other useful properties, such as guaranteeing a minimum reset assertion time as required by CPUs, etc.

What happens then is up to the board designer. If you have a motor on your board that needs 8 volts, you could use a voltage supervisor which refuses to turn on your board if you don't have 8 volts -> hardware solution. Or you could use a voltage supervisor which turns on your CPU at 3 volts, and check availability of 8 volts in software -> software solution.

Stefan

At power on there will be a "Power On Reset (POR)" event. That event may be driven by a on-chip POR circuit or some external circiut. The hardware designer should take care of this. What happens during the POR is very circuit dependent. A microprocessor/microcontroller will set registers to a given value and then start execution from the program address that was set, by the POR event, into the program counter.

Other circuits do different things. For example, a SRAM FPGA will load it's configuration from some non-volatile storage. A GPIO extender will set some configuration registers to a value and then wait for a command on the bus. Ethernet chips will generally load some default values in the config registers or read some values from non-volatile storage. These actions are all defined in the data sheet for the device. A PC north and south bridges will be initialized by the POR hardware in them to some default values. It has been years since I have done anything with a north or south bridge so I'm not sure what all they do these days, but again, it's in the data sheets for the chip or avilable (maybe under NDA) from the vendor.

This has nothing to do with the software based boot process or the operating system. Up to this point the micro processor is not directly controlling any of the other devices on the board. This is all in the hardware and there may even be interactions between chips that the hardware designer has to deal with. For example, you might not allow a micro controller to start running code until a FPGA has finished it's configuration. It's up to the hardware design to make sure this all works.

Now back to a microprocessor.

The program counter will have been set to some value, defined in the data sheets. A Cortex M3 will first run some built in code that will check for a valid program image and if none is found, or if a GPIO pin has a given voltage on it (again see the data sheet), the M3 will start running a program (in on chip non-volatile memory) that allows you to program the device. If a valid program is found the code will load a new program counter and stack pointer from the flash and start execution. This is a simplified explanation, there are documents on the M3 and boot sequence.

For a processor like a PPC, Intel, Microchip PIC, etc, the device will begin executing code. Remember, the program counter has been set to a value, defined in the data sheet. For a simple PIC processor it will start executing the code at location zero, which is normally a branch instruction to your code. Your code will then initialzie GPIO, clocks, etc and do it's thing blinking LEDs or what ever.

For a PC, the code that starts executing is the BIOS. This is in a non-volatile chip on the board. The PC BIOS will determine the memory size, scan busses and other actions. A overclocking BIOS may even setup core voltage levels and clock ratios. When the board powers on the voltages and clocks will have been set, by the hardware, to some "reasonable" value. The hardware design will define what a "reasonable" value is.

While complex, the BIOS is just code being run by the uP. It is doing normal reads/writes, logical operations and such, just like any user app. However, when the BIOS is running it is in a processor mode that allows privileged operations that a normal user app would not be allowed.

A PC BIOS will gather the information and build a memory table at a given location (I forget the details). Based on the CMOS settings it will then try and read a sector off the boot device, again into a given memory location. It will then branch to the first instruction in the boot sector. This code will then read more data off the boot device and "boot up" the OS. The OS might look at the memory table and use that as a guide to what hardware is on the system. Or it may just scan the busses and such, just like the BIOS did.

Google PC BIOS or Linux boot sequence or some combinations of words. The Linux kernel books usually have a chapter on the boot sequence. You can also download some of the free development tools for the various micro controllers. These tools usually have examples of initialization code for setting up clock sources, GPIO, etc.

and

transferred

hardware

on

First of all a very big thanks to you chisolm for expalining in such a good manner about the boot process from your side and on every type of the boot process from simple to the complex BIOS initialisation.

chisolm from your knowledge and explanation it seems that you are a hardware designer and especially of those computer motherboards............right, if my guess is right.

also you have huge amount of experience in the hardware designing.

But chisolm I don't have that much huge experience as you have and what it seems to me is that bootloading process is a big picture of which you have showed me the trailer and not the whole movie , you have given me the taste of everything in brief but I want to go more deeper into it and therefore I got many answers to my question but also many new questions arises in my mind.

I hope you would underrstand my problem

So what I think that I must start in right manner rather than asking you people that what is this , how it works and many more how after that.

I think I should give it some time of myself and for that I need to study it in very much detail to understand each and every bit of it.

So as you are very much experienced so would you please help me in providing the documents or the links to the sources from where I can start of.

what I want you to tell me is the right direction to approach from beginner point of view.

I hope that you would have got my point chisolm.

And at last thank you once again for such a beautiful description..:)

--------------------------------------- Posted through

I cut my teeth on SDS Sigma systems and doing SDS Sigma 2/3 and Xerox 530 work. But booting those systems or any newer cpu is still the same basic idea.

I would suggest you start with something simple. The Microchip PIC18 series are easy to work with. They come in DIP packages that make breadboarding easy. They are not the only option, I just use them because I have a several tubes left over from a project a few years ago.

I do not know what your resources are for purchasing hardware. To use a PIC series you will need a programmer.

Another option is something like a LPC Xpresso development board. These are just 2 of many options. Everyone has their favorite.

You need to download data sheets for the processors. Each processor will have something in the data sheet about the power on reset (or just reset) events and what happens. Read that and understand it. Then start working from there. The LPC Xpresso board IDE comes with several existing projects you can look at and start to understand how things work and fit together. Expand on the examples -- change the clock rates, read and write to IO pins, etc.

You must be comfortable with how this works before you can progress into more complicated boot sequences. Good Luck.