I’m trying to build my own toolchain for an Raspberry-Pi.
I know there are plenty of prebuilt Toolchains. This work is for educational reasons.
I’m following the embedded arm linux from scratch book.
And succeeded in building a gcc and uClib so far.
I’m building for the target arm-unknown-linux-eabi.
Now that it comes to preparing a bootable filesystem i’m questioning myself about the bootloader build.
The part about the bootloader for this System seems to be incomplete.
Now I’m questioning myself how do I build a uboot for this System with my arm-unknown-linux-eabi toolchain.
Do I need to build a toolchain which doesn’t depend on linux kernel calls.
My first reasearch lead me to the point that there are separate kind of tool chain
the OS dependent (linux kernel sys-calls etc…) and the ones which don’t need to have a kernel underneath. Sometimes refered to as “Bare-Metal” toolchain or “standalone” toolchain.
Some sources mention that it would be possible to build an U-Boot with the linux toolchain.
If this is true why and how should this work?
And if I have to build a second toolchain for “Bare Metal” Toolchain where can I find informations about the difference between these two. Do I need another libstdc?
You can built U-Boot with the same cross-toolchain used to build the kernel – and most probably the rest of the user-space of the system.
A bootloader is – by definition – self-contained and doesn’t care about your choice of C-runtime library because it doesn’t use it. Therefore the issue of sys-calls doesn’t come into it.
A toolchain is always going to need to be hosted by a fully functioning development system – invariably not your target system. Whatever references you see to a ‘bare-metal toolchain’ are not referring to the compiler’s use of sys-calls (it relies heavily on the operating system for I/O). What is important when building bootloaders and kernels is that compiler and linker are configured to produce statically linked code that can run at specific memory address.