summaryrefslogtreecommitdiff
path: root/boot/image-fdt.c
AgeCommit message (Collapse)Author
2025-07-09Merge patch series "Improve Verdin AM62P thermal setup by generalizing ↵Tom Rini
ft_board_setup_ex()" João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com> says: In some use cases, board-specific device tree changes must not be overwritten by system fixups. Although U-Boot provides ft_board_setup_ex() for this purpose, it is currently only used on TI Keystone. This series makes ft_board_setup_ex() a generic option, allowing its use by other architectures and boards. Additionally, considering that Toradex Verdin-AM62P hardware lifetime guarantees are based on a 105°C junction temperature (while TI AM62Px supports up to 125°C), this series implements necessary changes within TI K3 AM62P and Toradex board code. These changes include exporting common fixup device Tree functions used in TI K3 for board-code access and also fixup for AM62P thermal zones to correctly reflect the number of CPU nodes according to the SoC part number. Link: https://lore.kernel.org/r/20250623-am62p-fdt-fixup-trip-points-v1-0-12355eb6a72f@toradex.com
2025-07-09boot: Make ft_board_setup_ex() genericJoão Paulo Gonçalves
In some use cases, board-specific device tree changes must not be overwritten by system fixups. Although U-Boot provides ft_board_setup_ex() for this purpose, it is currently only used on TI Keystone. Make ft_board_setup_ex() to be a generic option, allowing its use by other architectures/boards. To maintain backward compatibility, enable it by default on TI Keystone. Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com>
2025-06-25lmb: use a single function to free up memorySughosh Ganu
There is no need to have two separate API's for freeing up memory. Use a single API lmb_free() to achieve this. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2025-06-25lmb: replace the lmb_alloc() and lmb_alloc_base() API'sSughosh Ganu
There currently are two API's for requesting memory from the LMB module, lmb_alloc() and lmb_alloc_base(). The function which does the actual allocation is the same. Use the earlier introduced API lmb_alloc_mem() for both types of allocation requests. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2025-06-25lmb: replace lmb_reserve() and lmb_alloc_addr() API'sSughosh Ganu
There currently are multiple allocation API's in the LMB module. There are a couple of API's for allocating memory(lmb_alloc() and lmb_alloc_base()), and then there are two for requesting a reservation for a particular memory region (lmb_reserve() and lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will cater to all types of allocation requests and replace lmb_reserve() and lmb_alloc_addr() with the new API. Moreover, the lmb_reserve() API is pretty similar to the lmb_alloc_addr() API, with the one difference being that the lmb_reserve() API allows for reserving any address passed to it -- the address need not be part of the LMB memory map. The lmb_alloc_addr() does check that the address being requested is actually part of the LMB memory map. There is no need to support reserving memory regions which are outside the LMB memory map. Remove the lmb_reserve() API functionality and use the functionality provided by lmb_alloc_addr() instead. The lmb_alloc_addr() will check if the requested address is part of the LMB memory map and return an error if not. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2025-03-26blkmap: pass information on ISO image to the OSSughosh Ganu
The EFI HTTP boot puts the ISO installer image at some location in memory. Information about this image has to be passed on to the OS kernel, which is done by adding a persistent memory(pmem) node to the devicetree(DT) that is passed to the OS. The OS kernel then gets information about the presence of this ISO image and proceeds with the installation. In U-Boot, this ISO image gets mounted as a memory mapped blkmap device slice, with the 'preserve' attribute. Add a helper function which iterates through all such slices, and invokes a callback. The callback adds the pmem node to the DT and removes the corresponding memory region from the EFI memory map. Invoke this helper function as part of the DT fixup which happens before booting the OS. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-12-30lmb: Remove lmb_alloc_base_flags()Ilias Apalodimas
lmb_alloc_base() is just calling lmb_alloc_base_flags() with LMB_NONE. There's not much we gain from this abstraction, so let's remove the former add the flags argument to lmb_alloc_base() and make the code a bit easier to follow. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Tested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-12-30lmb: Remove lmb_reserve_flags()Ilias Apalodimas
lmb_reserve() is just calling lmb_reserve_flags() with LMB_NONE. There's not much we gain from this abstraction. So let's remove the latter, add the flags argument to lmb_reserve() and make the code a bit easier to follow. Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Tested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-12-30lmb: Move enum lmb_flags to a u32Ilias Apalodimas
LMB flags is not an enum anymore. It's currently used as a bitmask in various places of our code. So make it a u32 which is more appropriate when dealing with masks. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Tested-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-12-12boot: fdt: Handle already reserved memory in boot_fdt_reserve_region()Sam Protsenko
The boot_fdt_add_mem_rsv_regions() function can be called twice, e.g. first time during the board init (as a part of LMB init), and then when booting the OS with 'booti' command: lmb_add_region_flags lmb_reserve_flags boot_fdt_reserve_region boot_fdt_add_mem_rsv_regions ^ | +-----------------------+ | (1) | (2) lmb_reserve_common image_setup_linux lmb_init ... initr_lmb do_booti board_init_r 'booti' That consequently leads to the attempt of reserving the same memory areas (described in the 'reserved-memory' dts node) in LMB. The lmb_add_region_flags() returns -EEXIST error code in such cases, but boot_fdt_reserve_region() handles all negative error codes as a failure to reserve fdt memory region, printing corresponding error messages, which are essentially harmless, but misleading. For example, this is the output of 'booti' command on E850-96 board: => booti $loadaddr - $fdtaddr ... ERROR: reserving fdt memory region failed (addr=bab00000 size=5500000 flags=2) ERROR: reserving fdt memory region failed (addr=f0000000 size=200000 flags=4) ... Starting kernel ... The mentioned false positive error messages are observed starting with commit 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE"), which removes the check for the already added memory regions in lmb_add_region_flags(), making it return -1 for !LMB_NONE cases. Another commit 827dee587b75 ("fdt: lmb: add reserved regions as no-overwrite") changes flags used for reserving memory in boot_fdt_add_mem_rsv_regions() from LMB_NONE to LMB_NOOVERWRITE. So together with the patch mentioned earlier, it makes lmb_add_region_flags() return -1 when called from boot_fdt_reserve_region(). Since then, the different patch was implemented, returning -EEXIST error code in described cases, which is: lmb: Return -EEXIST in lmb_add_region_flags() if region already added Handle -EEXIST error code as a normal (successful) case in lmb_reserve_flags() and don't print any messages. Fixes: 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
2024-10-29lmb: Fix lmb_add_region_flags() return codes and testingIlias Apalodimas
The function description says this should return 0 or -1 on failures. When regions coalesce though this returns the number of coalescedregions which is confusing and requires special handling of the return code. On top of that no one is using the number of coalesced regions. So let's just return 0 on success and adjust our selftests accordingly Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
2024-10-29fdt: lmb: add reserved regions as no-overwriteSughosh Ganu
The boot_fdt_add_mem_rsv_regions() function reserves the memreserve and reserved-memory regions. These regions are being set with the LMB_NONE flag which allows overwriting and re-using the regions. This was fine earlier when the LMB memory map was local and not enforced globally. But that is no longer the case. Mark these regions as LMB_NOOVERWRITE so that they cannot be used. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reported-by: Vaishnav Achath <vaishnav.a@ti.com>
2024-09-03lmb: make LMB memory map persistent and globalSughosh Ganu
The current LMB API's for allocating and reserving memory use a per-caller based memory view. Memory allocated by a caller can then be overwritten by another caller. Make these allocations and reservations persistent using the alloced list data structure. Two alloced lists are declared -- one for the available(free) memory, and one for the used memory. Once full, the list can then be extended at runtime. [sjg: Use a stack to store pointer of lmb struct when running lmb tests] Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Signed-off-by: Simon Glass <sjg@chromium.org> [sjg: Optimise the logic to add a region in lmb_add_region_flags()]
2024-07-18boot: android: Provide vendor_bootimg_addr in boot_get_fdt()Mattijs Korpershoek
When calling android_image_get_dtb_by_index() using boot image v3+, we should also pass the vendor_boot ramdisk address. Use get_avendor_bootimg_addr() to do so. Notes: on boot image v2, this is harmless since get_avendor_bootimg_addr() returns -1. for legacy implementations that don't have CMD_ABOOTIMG, add a weak implementation to avoid linking errors. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Julien Masson <jmasson@baylibre.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com> Reviewed-by: Guillaume La Roque <glaroque@baylibre.com> Tested-by: Guillaume La Roque <glaroque@baylibre.com> Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-05-20Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"Tom Rini
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-19Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""Tom Rini
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-06boot: Remove <common.h> and add needed includesTom Rini
Remove <common.h> from all "boot/" files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-04-18boot: fdt: Turn all addresses and sizes into u64Marek Vasut
In case of systems where DRAM bank ends at the edge of 32bit boundary, start + size calculations would overflow. This happens on STM32MP15xx with 1 DRAM bank starting at 0xc0000000 and 1 GiB of DRAM. This is a usual 32bit system DRAM size overflow, fix it by doing all DRAM size and offset calculations using u64 types. This also covers a case where a 32bit PAE system might be able to address up to 36bits of DRAM. Fixes: a4df06e41fa2 ("boot: fdt: Change type of env_get_bootm_low() to phys_addr_t") Signed-off-by: Marek Vasut <marex@denx.de>
2024-04-11boot: fdt: Move usable variable below updated commentMarek Vasut
Move the variable below comment which explains what the variable means. Update the comment. No functional change. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2024-04-11boot: fdt: Drop lmb_alloc*() typecastsMarek Vasut
The lmb_alloc_base() returns phys_addr_t , map_sysmem() accepts phys_addr_t as first parameter. Declare 'addr' as phys_addr_t and get rid of the casts. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2024-04-11boot: fdt: Change type of env_get_bootm_low() to phys_addr_tMarek Vasut
Change type of ulong env_get_bootm_low() to phys_addr_t env_get_bootm_low(). The PPC/LS systems already treat env_get_bootm_low() result as phys_addr_t, while the function itself still returns ulong. This is potentially dangerous on 64bit systems, where ulong might not be large enough to hold the content of "bootm_low" environment variable. Fix it by using phys_addr_t, similar to what env_get_bootm_size() does, which returns phys_size_t . Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2024-03-13fdt: Fix bootm_low handlingMarek Vasut
According to README CFG_SYS_BOOTMAPSZ section, in case both "bootm_low" and "bootm_size" variables are defined, "bootm_mapsize" variable is not defined and CFG_SYS_BOOTMAPSZ macro is not defined, all data for the Linux kernel must be between "bootm_low" and "bootm_low" + "bootm_size". Currently, for systems with DRAM between 0x4000_0000..0x7fff_ffff and with e.g. bootm_low=0x60000000 and bootm_size=0x10000000, the code will attempt to reserve memory from 0x4000_0000..0x4fff_ffff, which is incorrect. This is because "bootm_low" is not taken into consideration correctly. The last parameter of lmb_alloc_base() is the maximum physical address of the to be reserved LMB area. Currently this is the start of DRAM bank that is considered for LMB area reservation + min(DRAM bank size, bootm_size). In case bootm_low is set to non-zero, this maximum physical address has to be shifted upward, to min(DRAM bank start + size, bootm_low + bootm_size), otherwise the reserved memory may be below bootm_low address. In case of multiple DRAM banks, the current change reserves top part of the first bank, and reserves the rest of memory in the follow up banks. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-12-21boot: add support for fdt_fixup command in environmentMatthias Schiffer
The "fdt" command is convenient for making small changes to the OS FDT, especially during development. This is easy when the kernel and FDT are loaded separately, but can be cumbersome for FIT images, requiring to unpack the image, manually apply overlays, etc. Add an option to execute a command "fdt_fixup" from the environment at the beginning of image_setup_libfdt() (after overlays are applied, and before the other fixups). Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-12-13fdt: Move ft_verify_fdt() before the final fixupsSimon Glass
Move this check before the FDT fixups so that we can use a livetree after this point. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-12-13fdt: Drop the confusing casts in lmb_free()Simon Glass
Just use map_to_sysmem() instead of all the casting. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-12-13boot: Move adding initrd earlier in image_setup_libfdt()Simon Glass
This may as well happen before the general event is emitted, so move it. This will allow us to use the livetree for the event part, but the flattree for the earlier part. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-12-13fdt: ppc: Drop extra size for ramdiskSimon Glass
This code dates from around 2008: 56844a22b76 powerpc: Fix bootm to boot up again with a Ramdisk Since then we have added FDT relocation which provides enough space for expansion. We have also added all sorts of fixups earlier in image_setup_libfdt() which require more space, with ramdisk being the least of them. Therefore this extra hack for ramdisk seems unnecessary. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2023-12-13boot: Drop size parameter from image_setup_libfdt()Simon Glass
The of_size parameter is not used, so remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2023-12-13bootm: Reduce arguments to boot_get_fdt()Simon Glass
This function only uses one argument from bootm (argv[2]) so pass it in directly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2023-12-13bootm: Pass image buffer to boot_get_fdt()Simon Glass
Rather than having boot_get_fdt() calculate this, move the calculation into the caller. This removes the access to argv[0] in this function, so we can later refactor it to just accept argv[2] instead of the whole argv[]. Move the function comment to the header file and fix the u8 argument, while we are here. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2023-04-04android: boot: support boot image header version 3 and 4Safae Ouajih
Enable the support for boot image header version 3 and 4 using abootimg command. In order to use version 3 or 4: 1- Vendor boot image address should be given to abootimg cmd. abootimg addr $1 $vendor_boot_load_addr 2- "ramdisk_addr_r" env variable (ramdisk address) should be set to host the ramdisk : generic ramdisk + vendor ramdisk Replace "struct andr_boot_img_hdr_v0*" by "void *" in some functions since v3 and v4 are now supported as well. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2023-04-04android: boot: add vendor boot image to prepare for v3, v4 supportSafae Ouajih
Introduce vendor boot image for version 3 and 4 of boot image header. The vendor boot image will hold extra information about kernel, dtb and ramdisk. This is done to prepare for boot image version 3 and 4 support. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2023-04-04android: boot: rename andr_img_hdr -> andr_boot_img_hdr_v0Safae Ouajih
Android introduced boot header version 3 or 4. The header structure change with version 3 and 4 to support the new updates such as: - Introducing Vendor boot image: with a vendor ramdisk - Bootconfig feature (v4) Change andr_img_hdr struct name to maintain support for version v0, v1 and v2 while introducing version 3 and 4. Signed-off-by: Safae Ouajih <souajih@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2023-02-09Correct SPL use of CMD_PSTORESimon Glass
This converts 1 usage of this option to the non-SPL form, since there is no SPL_CMD_PSTORE defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
2023-02-09Correct SPL uses of CMD_FDTSimon Glass
This converts 2 usages of this option to the non-SPL form, since there is no SPL_CMD_FDT defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-17boot: Pass the correct FDT to the EVT_FT_FIXUP eventSimon Glass
Now that we support multiple device trees with the ofnode interface, we can pass the correct FDT to this event. This allows the 'working' FDT to be fixed up, as expected, so long as OFNODE_MULTI_TREE is enabled. Also make sure we don't try to do this with livetree, which does not support fixups yet. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-17boot: Correct handling of addresses in boot_relocate_fdt()Simon Glass
This code uses casts between addresses and pointers, so does not work with sandbox. Update it so we can allow sandbox to do device tree fixups. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-09-29event: Pass the images to EVT_FT_FIXUPSimon Glass
Pass the boot images along as well, in case the fixups need to look at them. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-09-29treewide: Drop image_header_t typedefSimon Glass
This is not needed and we should avoid typedefs. Use the struct instead and rename it to indicate that it really is a legacy struct. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-09-29treewide: Drop bootm_headers_t typedefSimon Glass
This is not needed and we should avoid typedefs. Use the struct instead. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-08-12Convert CONFIG_SYS_FDT_PAD to KconfigTom Rini
This converts the following to Kconfig: CONFIG_SYS_FDT_PAD Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-08-12event: Add an event for device tree fixupsSimon Glass
At present there is a confusing array of functions that handle the device tree fix-ups needed for booting an OS. We should be able to switch to using events to clean this up. As a first step, create a new event type and call it from the standard place. Note that this event uses the ofnode interface only, since this can support live tree which is more efficient when making lots of updates. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-04-20image: fdt: Fix DT relocation handling with multiple DRAM banks with gapMarek Vasut
The current implementation of boot_relocate_fdt() places DT at the highest usable DRAM address, which is calculated as: env_get_bootm_low() + env_get_bootm_mapsize() which by default becomes gd->ram_base + gd->ram_size. Systems like i.MX53 can have multiple DRAM banks with gap between them, e.g. have DRAM at 0x70000000-0x8fffffff and 0xb0000000-0xcfffffff , so for them the calculated highest DRAM address is 0xafffffff, which is exactly in the gap and thus not usable. Fix this by iterating over all DRAM banks and tracking the remaining amount of the total mapping size obtained from env_get_bootm_mapsize(). Limit the maximum LMB area size to each bank, to avoid using nonexistent DRAM. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
2022-04-19image-fdt: save name of FIT configuration in '/chosen' nodeDaniel Golle
It can be useful for the OS (Linux) to know which configuration has been chosen by U-Boot when launching a FIT image. Store the name of the FIT configuration node used in a new string property called 'u-boot,bootconf' in the '/chosen' node in device tree. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-01-19doc: replace @return by Return:Heinrich Schuchardt
Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-11-11Create a new boot/ directorySimon Glass
Quite a lot of the code in common/relates to booting and images. Before adding more it seems like a good time to move the code into its own directory. Most files with 'boot' or 'image' in them are moved, except: - autoboot.c which relates to U-Boot automatically running a script - bootstage.c which relates to U-Boot timing Drop the removal of boot* files from the output directory, since this interfers with the symlinks created by tools and there does not appear to be any such file from my brief testing. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Artem Lapkin <email2tema@gmail.com> Tested-by: Artem Lapkin <email2tema@gmail.com>