I will end up creating a do_configure_append task where I will merge the _defconfig files through the use of scripts/kconfig/merge_config.sh if no one will come with a better solution. The problem was that, for example, ARM is defined as a config inside a choice so cannot be selected from inside a Kconf file. I also tried to create a generic fconfig to select some configurations. Like pointed out by and as I was suspecting, there is no way to include different _defconfig one in another. Similarly to what happens with dts files.īoard_hw1_defconfig: #include "common_defconfig"īoard_hw2_defconfig: #include "common_defconfig" So I was wondering if there could be the possibility of including a common_defconfig in the _defconfig to not duplicate all the configuration files. If you wanted to make a change to the overall U-boot configuration, you can use the configuration menu.I was in the middle of adding a new board to Yocto while I noticed that a lot of the configuration could be inherited from the previous hw revision. This file is combined with a number of other binary firmware files and is stored into raw block space in the EMMC or microSD card. On the 64-bit SOCs, the resulting u-boot binary is named u-boot.bin. (NOTE: this is likely going to change because we want to use the method to load U-boot from all of our SOC types). This file is loaded by the SPL from the boot partition, which is a FAT filesystem in the first partition. On the 32-bit SOCs, the resulting u-boot binary (the main u-boot image) is a file named "u-boot.img". The SOC expects to find the SPL located at that specific location in the boot media. i.MX8M, i.MX8M-MINI), this is 33KB into the boot media. On 32-bit processors, this starts at 1KB into the storage device (or 2 512-byte blocks) in).
The SPL is loaded into the boot media (in our case, this is always EMMC or microSD card) at a specific location. There is an SPL (which means Secondary Program Loader) and a U-boot binary image. The U-Boot environment is a little read/write persistent space that stores variables needed by the bootloader to configure itself properly and to adapt to its. The resulting binary images are placed in the project directory. If you have 4 CPUs available, then you can do the following: $ make -j 4 If you have multiple CPU cores available, you can use the "-j" switch to increase the number of parallel threads used and speed up the build. U-boot is not a very large project to build, so this usually doesn't take very long on most computers. This depends on the board, based on the following table: BoardĮDM1-IMX6 Solo, EDM1-IMX6 Dual Lite, EDM1-IMX6 Quadįor example, if you were using PICO-IMX8M-MINI: $ make pico-imx8mm_defconfig Now configure u-boot for the target platform you are using. (Or whichever branch you wish to use) Configure U-boot for your target platform $ git clone Ĭheckout the stable branch: $ git checkout tn-imx_v2018.03_4.14.98_2.0.0_ga-stable If you want to work with the latest code, some of which might not be completely tested, you can use the branch ending in -next. Here we are checking out the latest stable branch. Warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
U boot configuration software#
This is free software see the source for copying conditions.
Once you have the toolchain installed, make sure that the ARCH and CROSS_COMPILE environment variables are set correctly so that these are used to build U-boot.įor 32-bit ARM targets (i.MX6UL/ULL, i.MX6, i.MX7): $ echo $gcc -versionĪrm-linux-gnueabihf-gcc (Linaro GCC 6.4-2018.05) 6.4.1 20180425 Ĭopyright (C) 2017 Free Software Foundation, Inc. For this, please refer to the following article.
We use different toolchains depending on the processor architecture (32-bit or 64-bit ARM). You need to set up a toolchain to use to build U-boot. This article assumes that you are building U-boot from the TechNexion u-boot repository. This article takes you through the process of downloading and building U-boot yourself for your target platform. Customizing U-boot for your platform is sometimes necessary in order to add features, change the boot splash screen, and enable new hardware.
0 kommentar(er)
