0

How Computers Boot Up




An outline of the boot sequence

Things start rolling when you press the power button on the computer (no! do tell!). Once the motherboard is powered up it initializes its own firmware - the chipset and other tidbits - and tries to get the CPU running. If things fail at this point (e.g., the CPU is busted or missing) then you will likely have a system that looks completely dead except for rotating fans. A few motherboards manage to emit beeps for an absent or faulty CPU, but the zombie-with-fans state is the most common scenario based on my experience. Sometimes USB or other devices can cause this to happen: unplugging all non-essential devices is a possible cure for a system that was working and suddenly appears dead like this. You can then single out the culprit device by elimination.

If all is well the CPU starts running. In a multi-processor or multi-core system one CPU is dynamically chosen to be the bootstrap processor (BSP) that runs all of the BIOS and kernel initialization code. The remaining processors, called application processors (AP) at this point, remain halted until later on when they are explicitly activated by the kernel. Intel CPUs have been evolving over the years but they’re fully backwards compatible, so modern CPUs can behave like the original 1978 Intel 8086, which is exactly what they do after power up. In this primitive power up state the processor is in real mode with memory paging disabled. This is like ancient MS-DOS where only 1 MB of memory can be addressed and any code can write to any place in memory - there’s no notion of protection or privilege.

Most registers in the CPU have well-defined values after power up, including the instruction pointer (EIP) which holds the memory address for the instruction being executed by the CPU. Intel CPUs use a hack whereby even though only 1MB of memory can be addressed at power up, a hidden base address (an offset, essentially) is applied to EIP so that the first instruction executed is at address 0xFFFFFFF0 (16 bytes short of the end of 4 gigs of memory and well above one megabyte). This magical address is called the reset vector and is standard for modern Intel CPUs.

The motherboard ensures that the instruction at the reset vector is a jump to the memory location mapped to the BIOS entry point. This jump implicitly clears the hidden base address present at power up. All of these memory locations have the right contents needed by the CPU thanks to the memory map kept by the chipset. They are all mapped to flash memory containing the BIOS since at this point the RAM modules have random crap in them. An example of the relevant memory regions is shown below:


The CPU then starts executing BIOS code, which initializes some of the hardware in the machine. Afterwards the BIOS kicks off the Power-on Self Test (POST) which tests various components in the computer. Lack of a working video card fails the POST and causes the BIOS to halt and emit beeps to let you know what’s wrong, since messages on the screen aren’t an option. A working video card takes us to a stage where the computer looks alive: manufacturer logos are printed, memory starts to be tested, angels blare their horns. Other POST failures, like a missing keyboard, lead to halts with an error message on the screen. The POST involves a mixture of testing and initialization, including sorting out all the resources - interrupts, memory ranges, I/O ports - for PCI devices. Modern BIOSes that follow the Advanced Configuration and Power Interface build a number of data tables that describe the devices in the computer; these tables are later used by the kernel.

After the POST the BIOS wants to boot up an operating system, which must be found somewhere: hard drives, CD-ROM drives, floppy disks, etc. The actual order in which the BIOS seeks a boot device is user configurable. If there is no suitable boot device the BIOS halts with a complaint like “Non-System Disk or Disk Error.” A dead hard drive might present with this symptom. Hopefully this doesn’t happen and the BIOS finds a working disk allowing the boot to proceed.

The BIOS now reads the first 512-byte sector (sector zero) of the hard disk. This is called the Master Boot Record and it normally contains two vital components: a tiny OS-specific bootstrapping program at the start of the MBR followed by a partition table for the disk. The BIOS however does not care about any of this: it simply loads the contents of the MBR into memory location 0×7c00 and jumps to that location to start executing whatever code is in the MBR.

The specific code in the MBR could be a Windows MBR loader, code from Linux loaders such as LILO or GRUB, or even a virus. In contrast the partition table is standardized: it is a 64-byte area with four 16-byte entries describing how the disk has been divided up (so you can run multiple operating systems or have separate volumes in the same disk). Traditionally Microsoft MBR code takes a look at the partition table, finds the (only) partition marked as active, loads the boot sector for that partition, and runs that code. The boot sector is the first sector of a partition, as opposed to the first sector for the whole disk. If something is wrong with the partition table you would get messages like “Invalid Partition Table” or “Missing Operating System.” This message does not come from the BIOS but rather from the MBR code loaded from disk. Thus the specific message depends on the MBR flavor.

Boot loading has gotten more sophisticated and flexible over time. The Linux boot loaders Lilo and GRUB can handle a wide variety of operating systems, file systems, and boot configurations. Their MBR code does not necessarily follow the “boot the active partition” approach described above. But functionally the process goes like this:

  1. The MBR itself contains the first stage of the boot loader. GRUB calls this stage 1.
  2. Due to its tiny size, the code in the MBR does just enough to load another sector from disk that contains additional boostrap code. This sector might be the boot sector for a partition, but could also be a sector that was hard-coded into the MBR code when the MBR was installed.
  3. The MBR code plus code loaded in step 2 then read a file containing the second stage of the boot loader. In GRUB this is GRUB Stage 2, and in Windows Server this is c:\NTLDR. If step 2 fails in Windows you’d get a message like “NTLDR is missing”. The stage 2 code then reads a boot configuration file (e.g., grub.conf in GRUB, boot.ini in Windows). It then presents boot choices to the user or simply goes ahead in a single-boot system.
  4. At this point the boot loader code needs to fire up a kernel. It must know enough about file systems to read the kernel from the boot partition. In Linux this means reading a file like “vmlinuz-2.6.22-14-server” containing the kernel, loading the file into memory and jumping to the kernel bootstrap code. In Windows Server 2003 some of the kernel start-up code is separate from the kernel image itself and is actually embedded into NTLDR. After performing several initializations, NTDLR loads the kernel image from file c:\Windows\System32\ntoskrnl.exe and, just as GRUB does, jumps to the kernel entry point.

There’s a complication worth mentioning (aka, I told you this thing is hacky). The image for a current Linux kernel, even compressed, does not fit into the 640K of RAM available in real mode. My vanilla Ubuntu kernel is 1.7 MB compressed. Yet the boot loader must run in real mode in order to call the BIOS routines for reading from the disk, since the kernel is clearly not available at that point. The solution is the venerable unreal mode. This is not a true processor mode (I wish the engineers at Intel were allowed to have fun like that), but rather a technique where a program switches back and forth between real mode and protected mode in order to access memory above 1MB while still using the BIOS. If you read GRUB source code, you’ll see these transitions all over the place (look under stage2/ for calls to real_to_prot and prot_to_real). At the end of this sticky process the loader has stuffed the kernel in memory, by hook or by crook, but it leaves the processor in real mode when it’s done.

We’re now at the jump from “Boot Loader” to “Early Kernel Initialization” as shown in the first diagram. That’s when things heat up as the kernel starts to unfold and set things in motion. The next post will be a guided tour through the Linux Kernel initialization with links to sources at the Linux Cross Reference. I can’t do the same for Windows ;) but I’ll point out the highlights.


This Article Is From : http://duartes.org/gustavo/blog/post/how-computers-boot-up


0

Project jaNET!

jaNET is a Digital Life Assistant inspired from JARVIS on Iron Man movie.

Introduction

The virtual she-butler comes to life through project jaNET, a platform ready to host multiple creative and innovative pieces of code concerning domestic everyday tasks.
jaNET provides a built in framework to fulfil most of our daily information manners (like e-mail notification, weather conditions etc) but it can also be extend by wrapping 3rd party applications, processes or scripts in order to become a more flexible and smart system!

Framework
Some built in functions (currently 23) and commands, are explained below and used for the final custom synthesis.

Functions
User and Greetings
%user% - get user login
%daypart% and %partofday% - get the current part of the day (morning, noon, evening, afternoon, night, midnight)
%salute% - get the human greets like good morning, good evening and good afternoon

Weather (retrieve information from yahoo web service)
%todayday% - get the current day
%todayconditions% - get the today conditions as partly cloudy, sunny etc
%todaylow% - get current day low temperature
%todayhigh% - get current day high temperature
%tomorrowday% - get the day after
%tommorowconditions% - get the day after conditions as partly cloudy, sunny etc
%tommorowlow% - get day after low temperature
%tommorowhigh% - get day after high temperature

Localization
%day% - get system day
%time% - get current system time
%time24% - get the current system time in 24
%date% - get current system date

Net
%mailnum% - returns the number of a pop3 mail account that you have setup
%inetcon% - if it has an internet connection

Location
%whereami% - retrieves information have been sent from my mobile phone gps. The phone runs a custom python script that sends the location to a web service which produce a google maps page. This function is responsible to extract the readable address

System Console
%cls% and %clear% - clearing the console
%quit% and %exit% - terminate program

Commands
2.1. Bluetooth
set bluetooth on - enable bluetooth
set bluetooth enable - enable bluetooth
set bluetooth off - disable bluetooth
set bluetooth disable - disable bluetooth
get bluetooth state - returns the state of bluetooth as boolean (true/false)
get bluetooth status - returns the state of bluetooth as boolean (true/false)

2.2. Mail
set mail add - setup a pop3 account for %mailnum% function
set mail check - enable mail check every x milliseconds
set mail check off - disable mail check
set mail check 0 - disable mail check
get mail settings - returns pop3 settings
get mail state - returns the number of ms, 0 if it is disabled
get mail status - returns the number of ms, 0 if it is disabled

2.3. Sms
set sms add - supports Clickatel sms gateway
get sms settings - returns sms settings

2.4. Alarm, wake up call
set alarm add
0

‘Imaginary’ interface could replace real thing

Researchers are experimenting with a new interface system for mobile devices that could replace the screen and even the keyboard with gestures supported by our visual memory.

Called Imaginary Interfaces, the German project uses a small, chest-mounted computer and camera to detect hand movements. Unlike Tony Stark in "Iron Man," who manipulates holographic elements in his lab with his hands, users conjure up their own imaginary set of graphical interfaces. For example, people can manually draw shapes and select points in space that have programmed functions, such as a power switch or a "send" key, for example.



This interface could allow people to use gestures during phone calls, much as they do in face-to-face conversations, while eliminating traditional hardware elements.

"We definitely envision a system like this replacing all input for mobile devices," said Sean Gustafson, a research student at the Hasso Plattner Institute at Potsdam University in Germany and lead author of an upcoming study on the Imaginary Interfaces concept.

Button-pushers, screen watchers
The standard way one operates a cell phone or a computer, of course, involves using a touchpad, mouse or buttons to select options electronically displayed on a screen.

These devices cannot get any smaller really, Gustafson and his co-authors contend, because screens and buttons require a minimum size to remain viewable, touchable and hence usable.

Many attempts to advance beyond keyboards and mice have focused on gestures.
Yet these gesture-based interfaces have still relied on some sort of "real" visual reference, meaning one that other people can see and that does not exist solely in a user's mind: Think of "Minority Report"-style screens that people manipulate rather like conductors of an orchestra, or gaming on a Nintendo Wii.

In place of the screens found in these setups, some interface concepts use head-mounted projectors that display imagery on a wall or a hand, say, in order to provide a frame of reference. Sixth Sense, a project out of MIT, and Brainy Hand from the University of Tokyo are two such examples.

With Imaginary Interfaces, however, there is nothing to see; short-term visual memory instead serves as the reference, and like mimes, people can mentally record and "touch" these make-believe elements.

"People are able to interact spatially without seeing what it is that they create," said Patrick Baudisch, a professor of computer science at the Hasso Plattner Institute and Gustafson's teacher.

The un-imaginary device
In generating a virtual reality interface, the Imaginary Interfaces device combines a camera and a computer to see and then interpret gestures.

The device for now is about 2 inches by 2 inches square and attaches to the clothes on a user's chest. Its makers envision shrinking it down to the size of an unobtrusive button.

A ring of light emitting diodes (LEDs) around the camera beams out invisible infrared light. The camera sees this light reflected by the nearby gesturing hands but the distant background does not get illuminated.

To operate Imaginary Interfaces, people use two basic commands. Making an 'L' shape with one's non-dominant hand (typically the left) 'opens up' a two-dimensional plane where the finger tracing interaction will take place; the L acts as the lower left corner of the plane in this example.

Users can 'pinch' with the dominant hand to select a point in space on this plane that can serve a function. As an easy frame of reference, a grid can be visualized based on the lengths of the finger and thumb in the L gesture as a 'Y' and 'X' coordinate, respectively. Pinching at approximately 3, 2 — or three finger-lengths up and two thumb-lengths over — could press a virtual button.

Other more sophisticated methods of interfacing via one's imagination are in the works. "We are exploring how users can sketch interfaces, then use them," said Baudisch. "It has a cartoony quality to it."

Such a "draw your own interface" would have advantages, Gustafson said. "If the user places the user interface elements themselves then they will remember — visually and proprioceptually – the location for later use," he said. (Proprioception refers to the sense of our body parts and their relation to one another in space.) "If they ever forget the location, they can just redraw it."

Applications easy to imagine
This ability to create simple sketches on the fly opens up a range of new application scenarios, and could make phone conversations more like person-to-person interactions that often involve gestures.
"I would love to reclaim the hand gestures that are missing from normal telephone conversations," Gustafson told TechNewsDaily.

"We use our hands in conversation to, amongst other things, transmit spatial information that is hard to get across otherwise," Gustafson continued. "For example, driving directions and the like are much easier to get across with some simple hand movements. It would be wonderful to re-enable this communication channel for telephone conversations."

Imaginary Interfaces still needs work. The infrared detection of hand gestures by the camera does not function well outdoors in sunlight, for example.

And Imaginary Interfaces would not be detailed or precise enough for engineering schematics or the like. "Architectural drawings require a large amount of precision that is probably not possible without a high-res input and output channel," said Gustafson. "I like to think this system is best for 'napkin drawings' — simple visual representations of ideas that aid conversation."

A study about Imaginary Interfaces that includes several user trials will be presented at the 23rd Symposium of User Interface Software and Technology held by the Association for Computing Machinery in New York this coming October.
 
Copyright © Design Your Dream!!