what is the use of SPL (secondary program loader)

Question

I am confused in clearing my concepts regarding these three questions

1. why do we need a secondary program loader ?

2. in which memory it gets loaded and relocated ?

3. what is the difference between system internal memory and RAM ?

as far as I understand via reading links is .. SPL is required when the system internal memory can not hold the uboot completely so we need to initialize memory using a minimal piece of code called SPL. Does SPL actually relocate or it is only uboot which relocates itself?

Answer 1

Let me explain it using OMAP platform as an example (just to provide some actual background rather than just theory or common knowledge). Take a look at some facts for starters:

• On OMAP-based platforms the first program being run after power-on is ROM code (which is similar to BIOS on PC).
• ROM code looks for bootloader (which must be a file named "MLO" and located on active first partition of MMC, which must be formatted as FAT12/16/32, -- but that's details)
• ROM code copies content of that "MLO" file to static RAM (because regular RAM is not initialized yet). Next picture shows SRAM memory layout for OMAP4460 SoC:

• SRAM memory is limited (due to physical reasons), so we only have 48 KiB for bootloader. Usually regular bootloader (e.g. U-Boot) binary is bigger than that. So we need to create some additional bootloader, which will initialize regular RAM and copy regular bootloader from MMC to RAM, and then will jump to execute that regular bootloader. This additional bootloader is usually referred as first-stage bootloader (in two-stage bootloader scenario).

So this first-stage bootloader is U-Boot SPL; and second-stage bootloader is regular U-Boot (or U-Boot proper). To be clear: SPL stands for Secondary Program Loader. Which means that ROM code is the first thing that loads (and executes) other program, and SPL is the second thing that loads (and executes) other program. So usually boot sequence is next: ROM code -> SPL -> u-boot -> kernel. And actually it's very similar to PC boot, which is: BIOS -> MBR -> GRUB -> kernel.

UPDATE

To make things absolutely clear, here is the table describing all stages of boot sequence (to clarify possible uncertainty in terminology used):

+--------+----------------+----------------+----------+ | Boot   | Terminology #1 | Terminology #2 | Actual   | | stage  |                |                | program  | | number |                |                | name     | +--------+----------------+----------------+----------+ | 1      |  Primary       |  -             | ROM code | |        |  Program       |                |          | |        |  Loader        |                |          | |        |                |                |          | | 2      |  Secondary     |  1st stage     | u-boot   | |        |  Program       |  bootloader    | SPL      | |        |  Loader (SPL)  |                |          | |        |                |                |          | | 3      |  -             |  2nd stage     | u-boot   | |        |                |  bootloader    |          | |        |                |                |          | | 4      |  -             |  -             | kernel   | |        |                |                |          | +--------+----------------+----------------+----------+ 

So I'm just using bootloader as synonym for U-Boot, and Program Loader as common term for any program that loads other program.

See also:

[1] SPL (at Wikipedia)

[2] TPL: SPL loading SPL - Denx

[3] Bootloader (at OSDev Wiki)

[4] Boot ROM vs Bootloader

Answer 2

There is no theoretical need for a Secondary Program Loader (SPL). However, there are often pragmatic reasons for having one. Two off the top of my head.

• First, modularity and ease of development.
• Second, the hardware boot process may be too restrictive. It may expect the bootloader to be in a specific location where there is not enough room to store the entire boot process.

The primary loader does whatever is necessary to load the full boot process (SPL). The primary loader, for example, may be stored in ROM with memory limitations.