On Thu, Dec 23, 2010 at 10:28 PM, Rajveer Singh <[email protected]>wrote:
> On Wed, Dec 22, 2010 at 11:20 PM, Chirag Anand <[email protected] > >wrote: > > > On Dec 22 10:43PM, Rajveer Singh wrote: > > > Hello Guys, > > > > > > I've a confusion related to hard drive detection process by system > BIOS. > > > This question may sound strange to some of you but I'll appreciate if I > > can > > > get any link or lead to explore it further. > > > > > > As all of us know, to detect hardrive, we must need a suitable driver > for > > > hard disk in kernel. When we buy a new hard drive, if it's driver is > not > > in > > > the kernel, it doesn't detect but system BIOS can read it's MBR. So I'm > > just > > > wondering, What machenism or techniques are used by BIOS so it doesn't > > > require any additional drivers to detect hard drives. > > > > Talking about programming, the BIOS first reads the 1 sector of any hard > > disk by a BIOS interrupt 0x80 and tries to locate the byte "0xAA55" at > > the 512th byte, which confirms that the starting 512 bytes are bootable > > code. > > > > So, if your hard disk is detected inside the BIOS, I think it will be > > able to do the above procedure. After the kernel is loaded, the generic > > drivers for IDE/SATA etc. should do the needful. > > > > According to me, there is no need for drivers at the BIOS level, they > > are only required while/after the kernel is loaded. > > > > Thanks guys for your quick responses, > > Yes, I agree, drivers for disk(IDE/SATA/SCSI/SAS chipsets, thanks to Mahesh > for correcting me) are required by kernel not by BIOS but I'm wondering, > why > BIOS doesn't need drivers to access it. What special techniques are used in > BIOS, so it can detect disks without it's drivers. If it's true, why > kernel can not use the same technique to detect the new disks. > BIOS is not a singular entity, there are several BIOS' on any system. The motherboard bios is the master bios however. Here is a quick run down at how BIOS detects and loads OS from disk: 1. On start, the processor looks at FFF0h location for code to execute. But since there is no code yet, this location is usually the start of mapped m/b bios. 2. After POST, the m/b bios issues an Interrupt 09h which inits the IDE/SATA controller. This init is different from driver loading as it does not support UDMA modes, caching or paged r/w. In this restricted mode the drive is only able to access specific tracks and sectors. 3. After this, bios searches for other h/w rom's that may be needed to init the devices. For example, video bios is located at C000h, floppy controller at 7C00h and IDE hdd at C8000h. These addresses are reserved and hard-mapped by devices. Once it discovers all the bios' the main bios executes all of them and inits the devices. So now our hdd has been initialised and is ready to read write (in restricted mode, only 16bit txfers), and so is the video controller ready to display in a text only mode. 4. Next Int 19h is issued which is an interrupt for Bootstrap Loader. This call searches for a bootable MBR in the order specified in bios settings. MBR in hdd is always at cylinder 0, head 0, sector 1. This is where it looks for 0xAA55 pattern to detect if it is loadable or not. If it is, it is loaded into location 0x7C00h and then executed from there. Remember that once the IDE drivers are loaded the ide controller as well as hdd itself is reset and put to udma mode for faster transfers. But since the mbr is in ram, it can still be executed to load the initial kernel or ntldr or whatever bootstrap you are using. Hope this helps. > Thanks, > Rajveer Singh > _______________________________________________ > Ilugd mailing list > [email protected] > http://frodo.hserus.net/mailman/listinfo/ilugd > -- -- Ankit Chaturvedi GPG: 05DE FDC5 468B 7D9F 9F45 72F1 F7B9 9E16 ECA2 CC23 <http://www.google.com/profiles/ankit.chaturvedi> _______________________________________________ Ilugd mailing list [email protected] http://frodo.hserus.net/mailman/listinfo/ilugd
