Thank you Les: I have taken the whole of what you wrote and cut and pasted it into my notes. You should stick it in a wiki or faq somewhere so that it can be shared by everyone. See notes at bottom... On Sun, 2007-08-19 at 16:10 -0700, Les wrote: > BIG SNIP!! > I am not going to BIG SNIP on this one. I deserves a re-read. I appreciated the amount of time it must of taken to write. > 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. > No Les, I am not a young student, but I hope I never grow too old to be an old student. I am retired. I spent 30 years as an user, using Dos and Windows Office applications -- all for non-IT related reports, business plans etc. But I have been working with Linux (always Red Hat or Fedora) for the last three years discovering what makes computers work. I have found that abstractions and anthropomorphism keep getting in the way of understanding computing. Computers without a doubt can be complex on one hand, while on the other they are, after all, no more than machines based on usually simple engineering and physics principles. Some answers have to be really chased down, so I thank you for giving it all to me in one spot. > I hope this helps, and I am glad you are interested. > > Regards, > Les H > -- Regards Bill
