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?

Solution 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

Solution 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.

Comments

[sawdust]

"This additional bootloader is usually referred as first-stage bootloader." -- IMO the first stage is the ROM boot. So the SPL program would be the second-stage bootloader. Atmel used to have nomenclature similar to what you wrote, but their updated documentation (i.e. SoC datasheets) has the ROM boot as the "first level bootloader":

[Sam Protsenko]

I guess it totally depends on accepted terminology. I managed to find SPL referring both as 1st stage bootloader and as 2nd stage bootloader. Such a situation is happening really often in IT, I mean not well-established terminology. Probably because IT is quite new engineering branch, or maybe it's changing too quickly for terminology to become unambiguous. Anyway, if you look at [1] and [3], you will see that they don't consider ROM-code as bootloader. Probably because it's fixed code, and we just don't think about it too much :)

[Sam Protsenko]

Complementary: original bootloader definition is "the program to load OS". So we can't consider ROM code as an actual bootloader. Also in OMAP4460 TRM we can find next definition for bootstrap term (which, I believe, is synonym for bootloader): "Bootstrap: Initial software launched by the ROM code during the memory booting phase". Using such an approach we make sure to not mix ROM code and bootloader terms.

[theadnangondal]

@SamProtsenko can you please answer this as well stackoverflow.com/questions/31263686/…

[Mouin]

@SamProtsenko , Thank u for the interesting infos just one question could u pls clarify what is meant by "because regular RAM is not initialized yet"

[Sam Protsenko]

@Mouin SDRAM is an external device (to SoC) and must be initialized before usage. As SDRAM is connected to SoC, specifically to DMM IP-core (called EMIF on OMAP platforms), first DMM must be configured. Once DMM is ready, we can configure SDRAM via DMM. Exact initialization sequence is described in particular SDRAM datasheet, but usually it's about setting timing values. For example, see sdram_init() function for OMAP platforms.

[Mouin]

@SamProtsenko Ok, thank you very much, the big picture is clear.

[Alexey Vesnin]

a little correction, if I may: they're not first stage and second stage bootloaders. To explore what is 2-stage bootloader - try to make a FreeBSD liveUSB stick via old UNetBootIn tool - and you will see it in console, first stage linux loader supports the verbose dmesg - so you can configure it on the resulting usb pendrive image and see it all in detailed explaination.

[Sam Protsenko]

@AlexeyVesnin As discussed above, it's all about frame of reference. At least I tried to explain this matter better in comments, probably I failed :) We are talking about U-Boot here, and U-Boot is a two-stage bootloader. First stage of U-Boot is SPL and second stage is U-Boot itself. From system's point of view, there is 3 stages in conventional ARMv7 system: ROM-code, SRAM bootloader and RAM bootloader. But ROM-code is fixed, so we can basically ignore it. Just the same way as on PC: we have BIOS, MBR and GRUB. But we consider BIOS fixed, so MBR referred as 1st stage and GRUB is 2nd stage.

[Alexey Vesnin]

@SamProtsenko you haven't failed in explaination in a single bit of it! It's gorgeous, Man! About 2-stage loaders - that's where I've interveined - it's a bit different, but - strictly speaking - the meaning is all the same, actually. U-Boot in 2-step bootup is actually a second step - you can take a look at the first one, it's better be called something like a "bare-boot" to keep pp; out of confusions, IMHO. About the BIOS in ARM world - well, it's a mariana's depth, but if you wish - I can cover it in comments, just drop a line if you want it!

[Sam Protsenko]

@AlexeyVesnin You mean that ROM-code is a first step in 2-step bootup? But ROM-code isn't considered as a bootloader. Also, if you check U-Boot wiki page, it says that "U-Boot is both a first-stage and second-stage bootloader". The same explanation is also mentioned here. Maybe I don't understand what you mean. Can you please quote the exact line which you think is wrong, and describe what exactly is not right with it?

[Alexey Vesnin]

@SamProtsenko not ROM-code, there can be a Trustzone stuff - some ARM CPU's do have the ability to run some code before booting via Trustzone, and it can do a lot of stuff - there's actually no limits neither in functionality, nor in API. The "Terminology 2" column looks wrong from my point of view - all the rest is absolutely correct! As an example of "Terminology 2" 2-step bootloader I mentioned the UNetBootIn loading actual FreeBSD kernel out of the Linux kernel in live sticks this program makes.

[Sam Protsenko]

@AlexeyVesnin Ok, I think I got what you mean. I'd like to stick to OMAP terminology (think BeagleBone Black), which is best described here, in details: AM335x U-Boot User's Guide. Corresponding boot diagram from Boot ROM code's point of view can be found in AM335x TRM (look at Figure 26-10 "ROM code booting procedure"). Hope you agree with mentioned documentation.

[Sam Protsenko]

@AlexeyVesnin Also, in my table (in the answer), in "Terminology #2" column, stuff like "1st stage bootloader" can be replaced with "U-Boot 1st stage bootloader", but I think it goes without saying, as the whole question is about U-Boot.

[Alexey Vesnin]

@SamProtsenko agreed 100%!

[oromoiluig]

I am not sure I understand how the MLO fits in the terminology table. My understanding is that MLO is the name of the fie that contains the SPL. Is that right?

[oromoiluig]

According to this (which is a useful addendum to this answer) processors.wiki.ti.com/index.php/The_Boot_Process , I am right, but I'd recommend you clarify that in your answer.

[Sam Protsenko]

@oromoiluig Yes. MLO is a file name, it stands for MMC LOader. You can check OMAP4460 TRM for details, section 27 Initialization. MLO is being loaded to SRAM and executed by ROM code. MLO can contain any payload, not only U-Boot SPL. You can create MLO file using mkimage -T omapimage command, see this for example. MLO is only TI-specific format, and has nothing to do with U-Boot per se. That's why I don't want to reference it in the table.