All Of The Above Are Flow Variables Previous Next ARM Linux Booting Process

You are searching about All Of The Above Are Flow Variables Previous Next, today we will share with you article about All Of The Above Are Flow Variables Previous Next was compiled and edited by our team from many sources on the internet. Hope this article on the topic All Of The Above Are Flow Variables Previous Next is useful to you.

ARM Linux Booting Process

This will be a series of articles explaining how the Linux kernel boots on ARM architecture. This is part one.

ARM Linux Boot Process:

We’ll explain the boot process built around the AT91RM9200 system-on-chip, an ARM920T ARM thumb processor. Kwickbyte makes an embedded board called the kb9202 based on the AT91RM9200. Let’s take this board as an example and see how Linux boots on this board.

You should read the AT91RM9200 data sheet (specification) before you start reading this.

You also need to read the ARM Architecture Reference Manual to better understand the boot process.

Components of the Linux boot process:

The Linux boot process includes the following components.


Col image

root filesystem

Before looking at how the above components work, the following is the call flow of the Linux kernel boot process for the Arm architecture. This gives a big picture on the entire Linux boot process. We use U-boot bootloader.

ARM Linux Boot Process: The Big Picture


_start (cpu/arm920t/start.S)

start_code (cpu/arm920t/start.S)

start_armboot (lib_arm/board.c)

board_init (board/kb9202/kb9202.c)

timer_init (cpu/arm920t/at91/timer.c)

serial_init (drivers/serial/at91rm9200_usart.c)

main_loop (lib_arm/board.c)

Now u-boot is running and in u-boot prompt and ready to accept commands. Assume that the kernel image is loaded into RAM and the bootm command is issued.

do_bootm (common/cmd_bootm.c)

bootm_start (common/cmd_bootm.c)

bootm_load_os (common/cmd_bootm.c)

do_bootm_linux (lib_arm/bootm.c)

Text (linux/arch/arm/kernel/head.S)

Control is given to Linux.

Linux kernel:

Text (arch/arm/kernel/head.S:78)

__lookup_processor_type (arch/arm/kernel/head-common.S:160)

__lookup_machine_type (arch/arm/kernel/head-common.S:211)

__create_page_tables (arch/arm/kernel/head.S:219)

__arm920_setup (arch/arm/mm/proc-arm920.S:389)

__enable_mmu (arch/arm/kernel/head.S:160)

__turn_mmu_on (arch/arm/kernel/head.S:205)

__switch_data (arch/arm/kernel/head-common.S:20)

start_kernel (init/main.c:529)

start_kernel (init/main.c:529)


setup_arch (arch/arm/kernel/setup.c:666)

setup_machine (arch/arm/kernel/setup.c:369)

lookup_machine_type ( )

setup_command_line (init/main.c:408)

build_all_zonelists (mm/page_alloc.c:3031)

parse_args (kernel/params.c:129)

mm_init (init/main.c:516)

mem_init (arch/arm/mm/init.c:528)

kmem_cache_init (mm/slab.c, mm/slob.c, mm/slub.c)

sched_init (kernel/sched.c)

init_IRQ (arch/arm/kernel/irq.c)

init_timers (kernel/timer.c:1713)

hrtimer_init (kernel/hrtimer.c:1741)

softirq_init (kernel/softirq.c:674)

console_init (drivers/char/tty_io.c:3084)

vfs_caches_init (fs/dcache.c:2352)

mnt_init (fs/namespace.c:2308)


init_mount_tree (fs/namespace.c:2285)

do_kern_mount (fs/namespace.c:1053)



bdev_cache_init (fs/block_dev.c:465)

chrdev_init (fs/char_dev.c:566)

signals_init (kernel/signal.c:2737)

rest_init (init/main.c:425)

kernel_thread (431, arch/arm/kernel/process.c:388)

kernel_thread() creates a kernel thread and passes control to kernel_init().

kernel_init (431, init/main.c:856)

do_basic_setup (888, init/main.c:787)

init_workqueues (789, kernel/workqueue.c:1204)

drive_init (793, drivers/base/init.c:20)

do_initcalls (796, init/main.c:769) /* calls all subsystem init functions */

prepare_namespace (906, init/do_mounts.c:366)

initrd_load (399, init/do_mounts_initrd.c:107)

rd_load_image (117, init/do_mounts_rd.c:158) /* initrd if given */

identify_ramdisk_image (179, init/do_mounts_rd.c:53)

handle_initrd (119, init/do_mounts_initrd.c:37) /*if rd_load_image is successful */

mount_block_root (45, init/do_mounts.c:233)

do_mount_root (247, init/do_mounts.:218)

mount_root (417, init/do_mounts.c:334) /* if initrd is not given */

mount_block_root (359, init/do_mounts.c:233)

do_mount_root (247, init/do_mounts.c:218)

init_post (915, init/main.c:816)

run_init_process (847, init/main.c:807)

kernel_execve (810, arch/arm/kernel/sys_arm.c:81)

user space

init() /*userspace /sbin/init*/


A bootloader is a small program that will load the kernel image into RAM and boot the kernel image. It is also called bootstrap because it loads (pulls) the system by loading the operating system. The bootloader starts before any other software starts and initializes the processor and prepares the CPU to execute programs like an operating system. Most processors have a default address from which the first bytes of code are retrieved when power is applied or the board is reset. Hardware designers use this information to store bootloader code in ROM or flash at that address. Bootloaders are highly processor specific and board specific as it must initialize the cpu and run a program at an architecture specific address. Each embedded board comes with a bootstrap for downloading a kernel image or standalone application to the board and executing the kernel image or application. The bootloader will execute when power is applied to the processor board. Basically there will be some minimal features to load and boot the image.

It is also possible to control the system using a hardware debug interface such as JTAG. This interface can be used to write the boot loader program into bootable non-volatile memory (eg, flash) by instructing the processor core to perform the actions necessary to program the non-volatile memory. Usually the first time is done to download the basic bootloader and do some recovery process. JTAG is a standard and popular interface provided by many board vendors. Some microcontrollers provide special hardware interfaces that cannot be used to take arbitrary control of the system or run code directly, but instead allow boot code to be inserted into bootable non-volatile memory (such as flash memory) via a simple protocol. Later at the manufacturing stage, such an interface is used to inject boot code (and possibly other code) into non-volatile memory. After the system is reset, the microcontroller starts executing the code programmed in its non-volatile memory, just like the usual processors use ROM for booting. In most cases such interfaces are implemented by hardwired logic. In other cases such interfaces can be created from the GPIO pins by software running in the integrated on-chip boot ROM.

There are some other third party bootloaders available that provide a richer set of features and a simpler user interface. You can download these third party bootloaders to the board and make them the default bootloader for your board. Usually the bootloaders provided by board vendors are replaced by third party bootloaders. There are some third party bootloaders available and some of them are open source (or free bootloader) and some are commercial. Some of them are U-Boot, Red boot, GRUB (for desktop), LILO, Loadlin, bootsect-loader, SYSLINUX, EtherBoot, ELILO.

We will take U-boot boot loader as our boot loader. U-boot is a widely used boot loader in embedded systems. We will explain the code from u-boot-2010.03 source. You can download U-boot from the following site.

How U-Boot is created:

Based on the configuration of U-boot, all assembly files (.S) and C files (.c) are compiled using a cross compiler designed for a specific architecture and object files (.o) will be created. All these object files are linked by the linker and an executable file will be created. An object file or executable file is a collection of sections like text, data, bss etc. Object files and executable files have a file format like elf. All sections of object files will be organized into an executable file based on a script called linker script. This script tells where in memory all sections should be loaded when it runs. Understanding this script is very important to know how the boot loader and kernel are built and how different sections of the boot loader or kernel are loaded into memory.

Generally, when a program is run (executed), the loader reads the executable file and loads different sections of the executable file into the specified memory location and starts executing the start function (entry point) specified in the linker script. But, if you want to run (load) the boot loader then there is no loader to load different sections of the executable file into memory (basically understand the file format). Then you need to use a tool called objcopy which will take all the sections from the executable file and create a binary file with no file format. This binary file can be loaded into memory and executed or written to a specific address (specific to the architecture) in ROM which will be executed by the cpu when power is applied to the board.

Suppose based on U-boot configuration all files are compiled and object files are created. The U-boot makefile uses the following linker script (architecture specific) to create the executable file.

File: cpu/arm920t/

32 OUTPUT_FORMAT(“elf32-littlearm”, “elf32-littlearm”, “elf32-littlearm”)


34 access(_begin)

35 sections


37. = 0x00000000;


39. = ALIGN(4);

40. Text:


42 cpu/arm920t/start.o (.text)

43 *(.text)


4546. = ALIGN(4);

47.rodata: *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))


49. = ALIGN(4); *(.data)


52. = ALIGN(4); *(.got)


55. =.;

56 __u_boot_cmd_start =.;

57.u_boot_cmd: *(.u_boot_cmd)

58 __u_boot_cmd_end =.;


60. = ALIGN(4);

61 __bss_start =.;

62.bss (NOLOAD): *(.bss). = align(4);

63 _end =.;


Specify the file format of the executable file in OUTPUT_FORMAT line # 32. Here the executable file format is elf32 and endianness is little endian. Specify the architecture on which this code runs in OUTPUT_ARCH line #33. ENTRY in line #34 specifies the start function (entry point) of the u-boot program. The entry point here is _start.

SECTIONS in line #35 defines how different sections are mapped in the executable file. The loader uses the addresses mentioned in this section to load different sections of the program into memory.

‘.’ Line #37 specifies the starting address where the following sections should be loaded. In this case the starting address is 0x00000000. After this the memory is aligned by 4 bytes in line #39 and the text section comes in line #40.

40. Text:


42 cpu/arm920t/start.o (.text)

43 *(.text)


Here ‘.’ The code in position (0x00000000) cpu/arm920t/start.o is mapped and follows the code in the text sections of all other object (.o) files. cpu/arm920t/start.o contains the _start() function (in assembly language) which is the entry point to this program.

Now ‘.’ will be at 0x00000000 + sizeof (.text). Again the memory is aligned by 4 bytes and the .rodata section comes in line #47.

. = align(4);

47.rodata: *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))

The .rodata sections in all object files are mapped to this address. The Data and Git section follows.

49. = ALIGN(4); *(.data)


52. = ALIGN(4); *(.got)

Each U-boot command is an object of type ‘cmd_tbl_t’ containing the command name, a help string, and a function pointer when the command is run. All these command objects are stored sequentially in memory. Each of these command objects is created in the U-boot defined section of the object file. u_boot_cmd. All these .u_boot_cmd sections are placed in memory after the above sections (.data and.git).

. =.;

56 __u_boot_cmd_start =.;

57.u_boot_cmd: *(.u_boot_cmd)

58 __u_boot_cmd_end =.;

__u_boot_cmd_start contains the start of command objects and __u_boot_cmd_end contains the end of command objects.

And then follows the.bss (uninitialized global variables) sections.

60. = ALIGN(4);

61 __bss_start =.;

62.bss (NOLOAD): *(.bss). = align(4);

63 _end =.;

__bss_start points to the starting address of .bss and _end contains the end of all sections.

Using this linker script linker will create an executable file called u-boot. Objcopy tool is used to create binary file from u-boot executable file.

u-boot.bin: u-boot


Video about All Of The Above Are Flow Variables Previous Next

You can see more content about All Of The Above Are Flow Variables Previous Next on our youtube channel: Click Here

Question about All Of The Above Are Flow Variables Previous Next

If you have any questions about All Of The Above Are Flow Variables Previous Next, please let us know, all your questions or suggestions will help us improve in the following articles!

The article All Of The Above Are Flow Variables Previous Next was compiled by me and my team from many sources. If you find the article All Of The Above Are Flow Variables Previous Next helpful to you, please support the team Like or Share!

Rate Articles All Of The Above Are Flow Variables Previous Next

Rate: 4-5 stars
Ratings: 1194
Views: 36275914

Search keywords All Of The Above Are Flow Variables Previous Next

All Of The Above Are Flow Variables Previous Next
way All Of The Above Are Flow Variables Previous Next
tutorial All Of The Above Are Flow Variables Previous Next
All Of The Above Are Flow Variables Previous Next free
#ARM #Linux #Booting #Process


Related Posts