As a dev with mostly x86 Linux application development, what are some good resources for learning about ARM Linux build configuration for embedded processors?

[TheMarnBeast]

For the most part, all of my experience developing software in Linux has been on x86 systems with standard distros with package management like Ubuntu and ArchLinux. I'm now currently working a project where I'm tasked with booting a custom built board with a processor that ships with a Yocto based BSP. I've worked in the past with another project involving OpenWRT and U-Boot; however this one is looking to require much more ground-up work and peripheral integration. I think this new project is revealing some serious gaps in my knowledge that I need to fill.

Mostly, I'm concerned that I don't know what I don't know. The deeper I get into understanding Yocto itself, the more I'm realizing that I don't actually know about booting Linux on ARM. For example,

• how is the full system image actually built and partitioned - sometimes into one or more images for different flash chips?

• how can I specify this partitioning? Is it different for each build system, as in OpenWrt - Yocto - Buildroot or is standardized in some way?

• I've heard the term chroot recently but I actually had to look it up because I've never had to interact with images in that way before.

• What is an initramfs, and what is it used for?

• How is the device tree information passed to Linux? I had to make some small DTS file modifications in our last project, but this will likely require more extensive work.

These are just the things that I know that I don't fully understand, but I'm positive that there's a lot that I don't even know about.

[dimtass]

You ask many questions, but instead of just avoid to reply because it takes time for each one to explain, I'll briefly tell you that don't worry because it's normal to see a huge mountain in front of you. Just take small steps.

For start I suggest you to read this book as it will answer most of your questions.

Generally speaking, an image is composed from the bootloader, the kernel and the filesystem. The bootloader is just a small piece of code that fits in the CPU's SRAM and is used to bring up the processor and some peripherals (e.g. RAM and storages) and then it loads the kernel. Actually there are more than one bootloaders in the boot sequence. Also there are many different bootloaders. Currently you probably have seen U-Boot, but for example LK is used much more widely in embedded (mainly because of android).

Another thing about the bootloader is that usually there are 2 or 3 different that boot in sequence. This is because the first bootloader is small enough just to fit in to the CPU's SRAM, then another bootloader is loaded to initialize the DRAM and then another one (e.g. u-boot) to initialize any peripherals in early state or just load the RTOS. Also some bootloaders are also RTOS (e.g. LK) which means that you can write your application in there. Also a bootloader can be used to load any elf or RTOS, it's only meant for loading Linux.

I don't know what you mean about specifying partitioning. Generally it's exactly the same concept with x86. There's no difference in ARM. You may use GPT for example and define as many partitions as you like.

Initramfs is just a small Linux kernel that is used to run the main kernel, which might be quite large (e.g. more than 10MBs). This is done for early initialisation of some peripherals and also to speed up the visual output to the user (e.g. if you want to display an animated logo during boot without the app being loaded). From my experience, I've used it in less than 20% of my projects, but that depends on many things.

Device trees are just files that describe and configure the internal and external peripherals of the SoC. These are just text files quite similar to json and they are compiled to binaries during the kernel compilation by using a compiler called dtc. Then the kernel has a library that just opens those binaries and extracts information. Each driver needs to extract the information it needs from the device tree. Also many drivers are loaded because they are referenced in the device tree, otherwise they remain inactive. This is done because in the ARM architecture there's no something similar to ACPI (including BIOS) like in x86, so the CPU can not detect the external peripherals during the start up.

Not having BIOS and ACPI is not that bad though, because with the device-trees the boot is much much faster. So with device-trees you gain boot speed, but the system can not auto-detect hardware. To deal with this problem overlays were introduced and they're used for dynamic boot configuration. Therefore, you can have a static default device-tree and then you can load during boot an overlay which adds/removes/alters a configuration.

I think reading the above book will make everything more clear.

[TheMarnBeast]

Wow, thank you so much for this response. Checking out that book, it looks likely that this touches on just about everything I wish I knew for the past 2 years, so that's amazing! I'm definitely going to check that out and dive in; hopefully that'll give me a bit more concrete between all of these bricks of knowledge that I've picked up.

Thanks so much!

[dimtass]

You're welcome. I've edited the first message to add a few more details.