Why is boot loader needed

In the embedded linux chain, the primary bootloader will setup and run the Uboot. Then Uboot will find the linux kernel and load it. Every embedded processor type E. Sometimes that something is different depending on whether the power is cycled or the device is reset.

Some embedded processors allow you to change that something based on voltages applied to different pins when the device is powered or reset. Regardless, there is a limited amount of something that a processor can do, because of the physical space on-processor required to define that something , whether it is on-chip FLASH, instruction micro-code, or some other mechanism. So what a processor does in response to reset or power-cycle cannot be changed, and cannot do very much, and we don't want it to automatically copy hundreds of megabytes or gigabytes into memory which may not exist or may not be initialized, and which could take a looooong time.

We set up a small program which is smaller than the smallest size permitted across all of the devices we are going to use. That program is stored wherever the something needs it to be.

Sometimes the small program is U-Boot. Sometimes even U-Boot is too big for initial load, so the small program then in turn loads U-Boot. The point is that whatever gets loaded by the something , is modifiable as needed for a particular system. If it is U-Boot, great, if not, it knows where to load the main operating system or where to load U-Boot or some other bootloader. U-Boot speaking of bootloaders in general then configures a minimal set of devices, memory, chip settings, etc. The main OS init takes care of any additional configuration or initialization.

The kernel requires the hardware on which you are working to be in a particular state. All the hardware you used needs to be checked for its state and initialized for its further operation. This is one of the main reasons to use a boot loader in an embedded or any other environment , apart from its use to load a kernel image into the RAM.

When you turn on a system, the RAM is also not in a useful state fully initialized to use for us to load kernel into it. Therefore, we cannot load a kernel directly to answer your question and thus arises the need for a construct to initialize it.

Apart from what is stated in all the other answers - which is correct - in some cases the system has to go through different execution modes, take as example TrustZone for secure ARM chips.

It is possible to still consider it as sort of HW initialization, but what makes it peculiar is the fact that there are additional limitations ex: memory available that make it impractical, if not impossible, to do everything in a single binary, thus multiple stages of bootloader are available.

Furthermore, for security reason, each of them is signed and can perform its job only if it meets the security requirements.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Why do we need a bootloader in an embedded device? The first available memory block or sector in the medium is always reserved for the record. Because of this important function, it is also known as the boot block or boot sector. In the second case, the operating system uses a selected partition as the storage location for the bootloader, though the underlying file system and the partition tables used can vary greatly.

The decisive factor here is always the firmware, which stipulates a specific file format for the boot manager in this bootloader storage model. Bootloaders can also be spread across several layers that build upon each other. These multi-stage bootloaders consist of up to three different levels that are launched in sequence. They are typically used if the boot program is too big for the boot sector.

Bootloaders serve as a mediator between hardware and the operating system. As soon as a bootloader has been initialized by the respective firmware, it has system responsibility to get the boot process going.

The first task is to load the main memory , which is essential for the processor to work. In the second step, the bootloader loads the kernel of the operating system, that is, the primary component of the system software that controls all storage and processor permissions and contains all important drivers.

The bootstrap loader also processes different routine tasks and commands , e. Bootloader in AVR:. An AVR comes with a memory that is divided into two sections, one application, one bootloader section. The application section contains application-specific code, and the bootloader section can contain a different variety of bootloaders. In an AVR, this section can be configured by setting up the fuses. We can set the required bootloader space as our requirements or set it to be used for application code.

The above flow chart shows what happens when an AVR enters into the bootloader. First, it erases the page memory and gets new page content from UART, and then it fills the page buffer.

After that is written, it waits for more pages from UART; If a new page is available, the process starts once again; if not, the program enters to the RWW Read While Write section and finishes the operation. This is an oversimplified version of the bootloader operation.

If you want to learn more about the topic, you can refer to the self-programming guide by Microchip Technologies. We will never spam you. Enables intelligence in applications and increases efficiency for medical and industrial applications.

Not knowing the exact software resident in flash is a recipe for confusion. My first two questions when debugging a controller are is it plugged in and what versions are on it. One of the other posts mentions the loader initializing memory, gpio, etc. We have the loader test and initialize what it needs but the application is responsible for initializing everything it uses. It doesn't need to retest memory checked by the loader but it does need to initialize everything it uses.

The application can not rely on power up values nor the state the loader may have set up. This is useful when you use a debugger which may not go through the loader and it keeps the loader requirements untangled from the application. I was involved in one project where the loader worked fine until just prior to a production deadline. The loader was tested early in the project when the application was relatively small.

During development the developers needed to use a jumper to disable the watchdog to use the debugger. The size of the application grew from one sector to five. During the final tests, the watchdog jumpers came off and the watchdog would occasionally reset during the application sector erase.

At this point many of the controllers had passed the hardware quality tests and were sealed up. Being about to update the loader to refresh the watch dog during the sector erase saved a lot of expense. It also taught me to always fill and test the application at maximum size. Keep in mind the field conditions and always test the bootloader under worst case conditions.

I have worked on shipboard CAN interfaces with extremely long cables and aviation systems mounted near strong motor interference. Being able to slow down the baud rate can make a difference when conditions get bad or the customer has a slow laptop. But slower isn't always better.

Bit rate accuracy is critical. I fixed one project that had been using The new crystal didn't divide down exactly to Most the time it would work, but you didn't know it failed until the entire application was downloaded.

We suffered for quite a while before finding the cause and changing the baud to K which had no frequency error. The communications were more reliable at K than at Make sure your communication setup is as accurate as possible. Clocks should divide exactly to the baud rate you want to use. The ability to update the loader saved me on a Marine application. The controller used the internal oscillator and the original loader did not perform temperature compensation.

It "worked" until you added long communication cables and temperature extremes when the loader started dropping bits. And if you are dealing with CAN it isn't just picking a K bit rate. If another company or group is writing the loader UI you need to know what sample point they expect and choose the appropriate sample method and jump width sync to keep the loader functional over a wide range of termination, cabling, and environment conditions.

But before your loader goes out into the field you need to assure the bit rate accuracy and all parameters give you as much margin as possible for clocks that change with temperature and cable capacitance. It may look funny to have a long coil of cable that could run the full length of a ship under your desk but using representative cables is important to CAN and communications in general so get your development setup as close as possible to the field install.

I would also stress keeping the loader requirements simple and reducing User interface opportunities for errors. What were they thinking? The starting address exists in the. Why would you give the user the opportunity to make a mistake?

Why would you add another UI item that needs to be tested? An advanced bootload subject is what to do with when you have multiple devices on a bus or multiple buses.

Multiple devices on the same bus are the norm for CAN. What happens to the other devices during updates, do they keep talking? A further complication is that some devices may be on multiple CAN buses but the UI for update may only have access to a subset. With careful planning, you can update everything on your network via a single bus. You may also wish to simultaneously update multiple devices. This may not seem important until you have dozens of devices on the bus and minutes per update with expensive systems and labor the costs add up.

Last but not least, think about manufacturing. You need to get the loader into the controller at least once. Today most systems have flash internal to a SMD micro.

As an engineer you will probably flash the loader via an emulator. But what are they going to use on the factory floor the first time?