> -----Original Message----- > From: kernelnewbies-bounce@xxxxxxxxxxxx > [mailto:kernelnewbies-bounce@xxxxxxxxxxxx] On Behalf Of > Milind Arun Choudhary > Sent: 30 March 2007 08:03 AM > To: Queenie de Melo > Cc: kernelnewbies@xxxxxxxxxxxx > Subject: Re: Bootloader and Device driver queries > > On 3/30/07, Queenie de Melo <queenie245@xxxxxxxxx> wrote: > > > > As per me... Kernel is the OS and Device driver comes in it.. > > > > Now I want to know... what the bootloader does then... > > > > I understand that it brings up the processor (initialization) and > > initializes the peripherals... > on general purpose computers > there is one more player in the game > BIOS: basic input output system > On Standard Intel/AMD PCs yes, on the vast majority of embedded and computers using other processors (such as PPC computers) this is not the case. The bootloader is responsible for the basic initialisation. > this is the first code which run on your system > > > Initialization of the peripherals like... Uart or Ethernet > etc.... if its done > > by bootloader then... driver would have to be written rite? > So r drivers also > > written in bootloader? > > this is done by BIOS > which then invokes the boot loader > Now the bootloaders job is to get the kernel image > and pump life into it > On Intel, yes. On the majority of embedded machines the bootloader generally will include code to initialise peripherals (to allow the use of a serial console in the bootloader, load images over TFTP etc. > It depends on the OS whether to use the BIOS' services or not > > Linux kernel does not use BIOS services > it reinitializes the device in its own style > > so we can say that bare minimum drivers are written in/for the BIOS > due to the size limitations > > & the linux kernel provides full fledged & > more intelligient drivers > As above, most embedded bootloaders offer different services than the PC's rather basic BIOS. > > on most of embedded platforms both responsibilites of BIOS & > bootloader > are usually handled by a single entity > so we don;t see a clear distinction between the two > > CMIIW > Yes, the bootloader on most embedded platform does the equivalent of what is done by the BIOS and bootloader on a PC. > > then how does the flash( where bootloader is stored) and > SDRAM ( where > > Bootloader is run from) get initialized? > > usually the memory device where the code which runs first is stored > is mapped to an address which the processor can access without > any initialization > then this code will do all the fancy stuff > IIRC (in the case of PPC) the bootloader will use the L1 cache in the processor initially to store data, whilst it initiallises the SDRAM. The bootloader is also likely to contain routines to "reflash" the bootloader. > > Hmmm... > > Another question is... once the bootloader is run... it initializes the > > peripherals and then tried to load the kernel. What if > kernel is not there? > > It would wait for the kernel... putting a message on console maybe... > > What stage would the hardware be at this point? Does it > enter any wait > > state? > depends on what all the BIOS/bootloader has done before > loading the kernel > An example, I believe U-boot either drops back to it's prompt or reboots. Exactly what happens depends on the bootloader you use and the options you have available. AFAIK a lot of embedded systems have a serial port and bootloader messages are sent to it. > > Will the bootloader still be in the SDRAM at this point of time? > yes > > > Still another question is.... > > > > Y is virtual addressing used? What is the benefit of using > virtual address... > > why cant we just give the physical address? Pyisical address and the > > corresponding virtual address , both r anyway unique for a > processor na. > > then y virtual addressing is used? > this should have been asked in a different thread i think > anyways > I think one reason might be to make every process think that > it owns the whole 4GB of virtual address space even if the > system does not have that much of physical memory > > which makes multiprogramming easier It also allows each process to have it's own address space. Each process "thinks" that it is the only process running on the processor, I believe this is one of the principles of multitasking OSes. Id suggest getting a hold of O Reilly's "Understanding the Linux Kernel", this covers memory management issues quite well, I think. I can also recommend looking at "Linux Devices Drivers", google for "LDD3" - it's available online or it's in print from O Reilly. Hope this helps, Martyn ---- Martyn Welch Principal Software Engineer Radstone Digital Processing Part of GE Fanuc Embedded Systems Phone: +44 (0) 1327 322748 email: martyn.welch@xxxxxxxxxxxxxx web: www.radstone.com ________________________________________________________________________ This e-mail has been scanned for all viruses by Star.The service is powered by MessageLabs. ________________________________________________________________________ -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
