55

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?

Chan Kim
  • 5,177
  • 12
  • 57
  • 112
theadnangondal
  • 1,546
  • 3
  • 14
  • 28

3 Answers3

122

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 layout on OMAP4460

  • 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

Sam Protsenko
  • 14,045
  • 4
  • 59
  • 75
  • *"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": – sawdust Jul 06 '15 at 20:46
  • 1
    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 Jul 06 '15 at 21:42
  • 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. – Sam Protsenko Jul 06 '15 at 22:02
  • @SamProtsenko can you please answer this as well http://stackoverflow.com/questions/31263686/how-sabre-sd-boots-directly-from-uboot-without-spl – theadnangondal Jul 07 '15 at 08:50
  • @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" – Mouin Nov 26 '16 at 21:06
  • @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()](http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-omap2/emif-common.c;h=b26984e26c5e8648598a36380d991fb34d1dd3df;hb=HEAD#l1405) function for OMAP platforms. – Sam Protsenko Nov 27 '16 at 12:07
  • @SamProtsenko Ok, thank you very much, the big picture is clear. – Mouin Nov 28 '16 at 07:48
  • 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. – Alexey Vesnin May 02 '18 at 18:41
  • 1
    @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. – Sam Protsenko May 02 '18 at 21:43
  • @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! – Alexey Vesnin May 02 '18 at 22:09
  • @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](https://en.wikipedia.org/wiki/Das_U-Boot), it says that "U-Boot is both a first-stage and second-stage bootloader". The same explanation is also mentioned [here](https://wiki.osdev.org/Bootloader#Two-Stage_Bootloader). 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? – Sam Protsenko May 02 '18 at 22:52
  • @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. – Alexey Vesnin May 03 '18 at 15:02
  • 1
    @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](http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide). Corresponding boot diagram from Boot ROM code's point of view can be found in [AM335x TRM](http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf) (look at Figure 26-10 "ROM code booting procedure"). Hope you agree with mentioned documentation. – Sam Protsenko May 20 '18 at 14:25
  • 1
    @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. – Sam Protsenko May 20 '18 at 14:28
  • @SamProtsenko agreed 100%! – Alexey Vesnin May 20 '18 at 20:42
  • 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 May 12 '19 at 12:25
  • 1
    According to this (which is a useful addendum to this answer) http://processors.wiki.ti.com/index.php/The_Boot_Process , I am right, but I'd recommend you clarify that in your answer. – oromoiluig May 12 '19 at 12:46
  • @oromoiluig Yes. `MLO` is a file name, it stands for `MMC LOader`. You can check [OMAP4460 TRM](http://www.ti.com/lit/ug/swpu235ab/swpu235ab.pdf) 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](https://github.com/joe-skb7/dra7xx-hello/blob/master/Makefile#L32) 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. – Sam Protsenko May 12 '19 at 12:52
1

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.

Daniel Selvan
  • 959
  • 10
  • 23
user3344003
  • 20,574
  • 3
  • 26
  • 62
0

Internal SoC sram memories goes from 4kB to 512KB or sometimes more. SPL is generally used as a stepping stone since full u-boot cannot fit in internal SRAM. But not only. In some casaes, can be used as performing DDR tuning at SPL stage or other needs.

Internal ram memory is static ram. External is generally sdram and needs initialization, so can't be used before sdram/DDR controller init.

Note that also XIP exists, as per i.e. parallel nor chips, where no SPL is generally needed, even with small internal SRAM, since sdram can be initialized executing from XIP flash.