Re: BIOS startup ??

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



BIG SNIP!!

To describe what happens depends on what kind of hardware is being
discussed.  So first lets talk about how the processor itself starts
up.  
	The power supply will receive AC, which is passed through a transformer
and rectified (in switching mode supplies, sometimes the AC is rectified
and chopped before going to the transformer), but eventually DC is
created and controlled by circuitry in the powersupply.  The voltage
appears on the power supply lines with the return via ground in the
boards.  At the processor control function is a "reset flipflop", and a
time delay.  The time delay components are designed to operate either
based on voltage (the supply exceeds a threshold), or just time by a
resistor in series with a capacitor.  As long as the voltage is below
the reset threshold of the processor, the processor is stopped.  At the
point where the threshold is crossed the processor receives its first
clock and begins processing from the default address (typically
0x0000000 on Intel x86 and related devices).  At that location in ROM is
a program called the bootstrap and from there the processor executes the
bootstrap code.  At the same time, disk drives have their heads
retracted (they were moved there during the powerdown cycle) and the
disk spins up.  A tachometer monitors disk speed and holds off disk
access until the disk is spinning correctly to prevent a "head crash".
The air held to the disk by friction creates a small cushion so the head
really "flys" a small distance from the disk.  The head then moves to
track 0, which is the inside track of the disk.  When the boot strap
starts up, it reasserts the move to track 0 and looks for the first
sector.  The head decodes the information on the disk, looking for the
tunnel markers that center the head in the track, and also decoding the
data looking for the sector marks.  When the sector matching that sent
by the program, the disk begins reading and reads the sector under the
head.  This is the MBR of the disk.  This code is only slightly smarter
than the hardware bootstrap, and so it needs disk and sector location to
find the program to actually boot.  Once the boot-strap has loaded the
boot sector, that code is then executed and tells the disk to seek to
the proper location to find the loader to use.  The correct disk is
selected, the correct sector for the loader is found and the loader is
loaded and then program controll jumps to it.  Now the loader will
either load a program, or will read some file(s) to discover what
alternatives are available.  If more than one, the code will typically
print out (using bios calls) the alternatives to select from.  Most
loaders will time out to the first selection if no choice is forth
coming from the user.

	The loader then loads the kernel.  The kernel loads the drivers for all
applicable hardware, and begins the process of resetting and setting the
access to each of the various pieces of hardware needed by the computer
(that is why you hear the disks, see the access lights on hubs, and the
various external drives all flickering.  They are being accessed and
tested for proper operation (generally "Hello, are you there" kind of
code, nothing spectacular in terms of test.  Disks are then mounted, the
monitor reset and the correct refresh rates setup, and things begin to
look like an OS is working.

	At another level, during power up, each card receives a copy of the
reset line being brought high.  These cards all do whatever their
designers intended for them as the base starting point in hardware.  I
need to mention here that all buss specifications generally have three
forms of reset.  First is the one being discussed here, that is HARD
reset or power on reset.  This is a brutal form of reset and is not
interruptable.  All other actions are immediately stopped and the
hardware goes to its initial state.  This can be hazardous for some
kinds of hardware, like disk drives.  That is why hot swappable drives
contain a way to invoke another form of reset prior to the hard reset.
This is the software reset.  In this case the current operation is
completed, and then the interrupt is permitted to continue.  In most
cases back to the level of hard reset, but some instruments require
something less.  And the final form of reset is a "data reset".
Sometimes you just want the current operation interrupted and the
instrument to go to a nice form of standby.  This is a data reset, and
is implemented on things like audio systems where you want to stop the
song that is playing, but want it to really shut down the output and
turn off the data stream, but not go to a full reset.

	So the memory will do a reset to ensure its clocking and refresh
circuitry are in sync with the buss access, the Direct Memory Access
controller and CPU interface for multiple CPU's will go to reset to
properly synchronize the buss access, and the video processor will go to
reset to begin executing its own bootstrap start up.  Some systems with
smart buss controllers for firewire, USB, and ports will also execute
their own bootstrap.  Each processor sets a flat to tell the main
processor it is not ready, and when they have finished their own
bootstrap their flags will reset and the system proceeds.

	At the same time, it is reasonable to remember that there are multiple
clocks in the system, for buss access, video control, port clocking etc.
etc.  And typically all the clocks (except the real time clock) are
reset at power on reset.  This establishes a known condition, and helps
the designer control glitch energy which could cause problems.

	As clock speeds have increased from kilohertz (the Altair ran at 650Khz
originally) to hundreds of gigahertz, some of these processes are being
modified.  It is impossible to accurately control the relative phase of
two separate 400Ghz clocks.  Instead, they are created by Phase locked
loops such that each is locked to a master clock.  This master clock and
the edges provided to each other high clock are controlled to prevent
too much concentrated switch energy.  So, memory chips are staggered,
the processor busses are staggered and so forth by controlling the
relative phase of these clocks using a voltage bias applied to the PLL
to create a fixed offset of each relative clock.  At least this is one
of about 50 methods used.  In any event, clocking is undergoing some
radical design requirements changes, so some of this may be archaic as
you read it.

	However the need for a known logical starting state for each subsystem
is more or less universal, and on all systems, from PC's to exotic
hardware I have worked on to test integrated circuits this is how busses
are implemented.  It is also necessary to realize that signals have a
relative time factor as well.  Address must preceed data, which must
preceed read or write strobes.  The time relevance must remain across
the buss, so as speeds increase the need to accurately control buss line
length has become more imperative.  As we move toward photo computation,
the era of wire signaling is comming to an end.  Wire is not fast
enough, nor can edges be accurately sustained.  This has already caused
the creation of compound architectures where data is sent on one line
and received on another or complex switching such as DDRR processes for
RAM.

	If you are interested in the physics changes being discussed, I suggest
you join the ACM (Association for Computing Machinery) or the IEEE
(Institute of Electrical and Electronic Engineers).  If you are young
and working in the field you need to remain in touch with the
professional associations to know which way the future winds are
blowing.  Computing and Electronics are careers where learning never
stops.  I still know AM and vacuum tubes, but never use it and that was
only 40 years ago.  I haven't switched in a bootstrap on my Altair in
nearly 30 years, but that knowledge gives me an edge in some of these
discussions.

I hope this helps, and I am glad you are interested.

Regards,
Les H

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux