startup of the bare hardware metal

Started by piyushpandey May 24, 2012
hello guys

I want to ask one basic thing about the bootloader.

as bootloader is the first program which runs on the machine and
initialises all the process and the hardware before passing the command to
the operating system.

But what I want to know is that how it bring up the board , I mean when we
push the power button bootloader gets staarted and start doing it's job. So
I want to know the processes which happen between the powering and passing
the control to the bootloader and also how the bootloader knows from where
to start.

How it is different from running the normal LED blinking code running on an
ATMEGA8 or any other MCU like PIC.

If possible can you people help me from the hardware and software point of
view as well.

Please guys tell me what material will be helpful and what refrences ahould
I look for.

also if there is any book or article on this please give me the link of
it.


Thank you	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com
Le 24/05/2012 20:23, piyushpandey a �crit :
> hello guys > > I want to ask one basic thing about the bootloader. > > as bootloader is the first program which runs on the machine and > initialises all the process and the hardware before passing the command to > the operating system. > > But what I want to know is that how it bring up the board , I mean when we > push the power button bootloader gets staarted and start doing it's job. So > I want to know the processes which happen between the powering and passing > the control to the bootloader and also how the bootloader knows from where > to start.
When powering on a board, a reset signal is asserted by an IC called the reset circuit. See here, for instance: http://www.maxim-ic.com/datasheet/index.mvp/id/1431 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".
On Thu, 24 May 2012 13:23:37 -0500, "piyushpandey"
<piyushispandey07@n_o_s_p_a_m.gmail.com> wrote:

>hello guys > >I want to ask one basic thing about the bootloader. > >as bootloader is the first program which runs on the machine and >initialises all the process and the hardware before passing the command to >the operating system. > >But what I want to know is that how it bring up the board , I mean when we >push the power button bootloader gets staarted and start doing it's job. So >I want to know the processes which happen between the powering and passing >the control to the bootloader and also how the bootloader knows from where >to start.
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.
>How it is different from running the normal LED blinking code running on an >ATMEGA8 or any other MCU like PIC.
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.
>If possible can you people help me from the hardware and software point of >view as well. > >Please guys tell me what material will be helpful and what refrences ahould >I look for.
Read the data sheet! For example, the datasheet for the ATMega8 that you mentioned has a decent description of the reset circuitry. -- Rich Webb Norfolk, VA
piyushpandey wrote:
> But what I want to know is that how it bring up the board , I mean when we > push the power button bootloader gets staarted and start doing it's job. So > I want to know the processes which happen between the powering and passing > the control to the bootloader and also how the bootloader knows from where > to start.
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 http://www.EmbeddedRelated.com
On Sun, 27 May 2012 06:12:23 -0500, "piyushpandey"
<piyushispandey07@n_o_s_p_a_m.gmail.com> wrote:

>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
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.
>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.
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.
>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.
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. -- Rich Webb Norfolk, VA
On Thu, 24 May 2012 13:23:37 -0500, "piyushpandey"
<piyushispandey07@n_o_s_p_a_m.gmail.com> wrote:

>But what I want to know is that how it bring up the board , I mean when we >push the power button bootloader gets staarted and start doing it's job. So >I want to know the processes which happen between the powering and passing >the control to the bootloader and also how the bootloader knows from where >to start.
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.
piyushpandey wrote:
> 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.
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
On Sun, 27 May 2012 06:12:23 -0500, piyushpandey wrote:

> 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 > http://www.EmbeddedRelated.com
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. -- Chisolm
>On Sun, 27 May 2012 06:12:23 -0500, piyushpandey wrote: > >> 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 >> http://www.EmbeddedRelated.com > >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. > >-- >Chisolm >
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 http://www.EmbeddedRelated.com