- Oct 16, 2024
-
-
The cpu0-opp-table {} node does not exist in upstream Linux stm32mp151.dtsi file, in order to enable conversion to OF_UPSTREAM, duplicate the node from current U-Boot stm32mp151.dtsi into stm32mp15-u-boot.dtsi. This makes STM32 DTs buildable even with OF_UPSTREAM enabled. No functional change, since the current U-Boot stm32mp151.dtsi already contains the cpu0-opp-table {} node, stm32mp15-u-boot.dtsi is applied at the end, and does not bring in any new content. Signed-off-by:Marek Vasut <marex@denx.de> Reviewed-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Update the MAINTAINERS file glob to cover all of STM32MP DHSOM related files. Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Tom Rini authored
:hile we had hoped to be able to remove these options finally, it was missed that zynq still requires these currently. This reverts commit 5b9261fb and commit 099b6df5. Reported-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
-
- Oct 15, 2024
-
-
-
Tom Rini authored
Sughosh Ganu <sughosh.ganu@linaro.org> says: This is part two of the series to have the EFI and LMB modules have a coherent view of memory. Part one of this goal was to change the LMB module to have a global and persistent memory map. Those patches have now been applied to the next branch. These patches are changing the EFI memory allocation API's such that they rely on the LMB module to allocate RAM memory. This fixes the current scenario where the EFI memory module has no visibility of the allocations/reservations made by the LMB module. One thing to note here is that this is limited to the RAM memory region, i.e. the EFI_CONVENTIONAL_MEMORY type. Any other memory type that is to be added to the EFI memory map, still gets handled by the EFI memory module. Changes since V3: * Add comments for the LMB_NOOVERWRITE and LMB_NONOTIFY flags * Drop use of is_addr_in_ram() function * Drop use of CONFIG_MEM_MAP_UPDATE_NOTIFY symbol to check if the notification needs to be sent. * s/lmb_notify/lmb_should_notify * Put a check for EFI_LOADER in the lmb_should_notify() function Some test logs to highlight the issue that is being fixed by the series. Without patch series -------------------- lmb_dump_all: memory.count = 0x1 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none reserved.count = 0x3 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map reserved[2] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite => efidebug memmap -- does not show regions allocated by lmb Missing TPMv2 device for EFI_TCG_PROTOCOL Type Start End Attributes ================ ================ ================ ========== CONVENTIONAL 0000000040000000-000000007f751000 WB BOOT DATA 000000007f751000-000000007f756000 WB RUNTIME DATA 000000007f756000-000000007f757000 WB|RT BOOT DATA 000000007f757000-000000007f758000 WB RUNTIME DATA 000000007f758000-000000007f77a000 WB|RT BOOT DATA 000000007f77a000-000000007f781000 WB BOOT CODE 000000007f781000-00000000807b5000 WB RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT BOOT CODE 00000000807b6000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT CODE 00000000817d0000-0000000082100000 WB => Trying to allocate EFI memory with already allocated region succeeds(should fail) --------------------------------------------------------------------------------- => efi_mem alloc 2000 42000000 Address returned 0x42000000 => efidebug memmap Type Start End Attributes ================ ================ ================ ========== CONVENTIONAL 0000000040000000-0000000042000000 WB BOOT DATA 0000000042000000-0000000042002000 WB CONVENTIONAL 0000000042002000-000000007f751000 WB BOOT DATA 000000007f751000-000000007f756000 WB RUNTIME DATA 000000007f756000-000000007f757000 WB|RT BOOT DATA 000000007f757000-000000007f758000 WB RUNTIME DATA 000000007f758000-000000007f77a000 WB|RT BOOT DATA 000000007f77a000-000000007f781000 WB BOOT CODE 000000007f781000-00000000807b5000 WB RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT BOOT CODE 00000000807b6000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT CODE 00000000817d0000-0000000082100000 WB => With patch series ----------------- lmb_dump_all: memory.count = 0x1 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none reserved.count = 0x4 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map reserved[2] [0x7f74f000-0x7f77dfff], 0x0002f000 bytes flags: no-notify, no-overwrite reserved[3] [0x7f77ea00-0x820fffff], 0x02981600 bytes flags: no-overwrite => efidebug memmap Type Start End Attributes ================ ================ ================ ========== BOOT DATA 000000000e100000-000000000f000000 WB CONVENTIONAL 0000000040000000-0000000042000000 WB BOOT DATA 0000000042000000-0000000042200000 WB CONVENTIONAL 0000000042200000-000000007f74e000 WB BOOT DATA 000000007f74e000-000000007f753000 WB RUNTIME DATA 000000007f753000-000000007f754000 WB|RT BOOT DATA 000000007f754000-000000007f755000 WB RUNTIME DATA 000000007f755000-000000007f777000 WB|RT BOOT DATA 000000007f777000-00000000807b6000 WB RUNTIME DATA 00000000807b6000-00000000807b7000 WB|RT BOOT DATA 00000000807b7000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT DATA 00000000817d0000-0000000082100000 WB Trying to allocate EFI memory with already allocated region fails ----------------------------------------------------------------- => efi_mem alloc 2000 42000000 efi_allocate_pages failed 800000000000000e => Trying to allocate EFI memory with non-allocated region succeeds ---------------------------------------------------------------- => efi_mem alloc 2000 42200000 Address returned 0x42200000 => efidebug memmap Type Start End Attributes ================ ================ ================ ========== BOOT DATA 000000000e100000-000000000f000000 WB CONVENTIONAL 0000000040000000-0000000042000000 WB BOOT DATA 0000000042000000-0000000042202000 WB CONVENTIONAL 0000000042202000-000000007f74d000 WB BOOT DATA 000000007f74d000-000000007f752000 WB RUNTIME DATA 000000007f752000-000000007f753000 WB|RT BOOT DATA 000000007f753000-000000007f754000 WB RUNTIME DATA 000000007f754000-000000007f776000 WB|RT BOOT DATA 000000007f776000-00000000807b5000 WB RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT BOOT DATA 00000000807b6000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT DATA 00000000817d0000-0000000082100000 WB => lmb_dump_all: memory.count = 0x1 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none reserved.count = 0x5 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map reserved[2] [0x42200000-0x42201fff], 0x00002000 bytes flags: no-notify, no-overwrite reserved[3] [0x7f74e000-0x7f77cfff], 0x0002f000 bytes flags: no-notify, no-overwrite reserved[4] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite Link: https://lore.kernel.org/r/20241015153717.401371-1-sughosh.ganu@linaro.org
-
A bunch of static functions in the LMB module have used a double-undersore for the function names. It was suggested to use a single-underscore instead, as the double-underscore is usually used by library functions. Replace the double-underscore with single-underscore for all functions. Signed-off-by:
Sughosh Ganu <sughosh.ganu@linaro.org> Suggested-by:
Simon Glass <sjg@chromium.org>
-
The variable overlap_only_ram is used to specify that the new memory region that is being created needs to come from the free memory pool -- this is done by carving out the memory region from the free memory. The name is a bit confusing though, as other allocated memory regions, like boot-services code and data are also part of the RAM memory. Rename the variable to overlap_conventional to highlight the fact that it is the free/conventional memory that is being referred to in this context. Signed-off-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by:
-
The EFI memory allocations are now being done through the LMB module. With this change, there is no need to get the EFI memory map and set aside EFI allocated memory. Signed-off-by:
-
The EFI_CONVENTIONAL_MEMORY type, which is the usable RAM memory is now being managed by the LMB module. Remove the addition of this memory type to the EFI memory map. This memory now gets added to the EFI memory map as part of the LMB memory map update event handler. Signed-off-by:
-
The EFI_CONVENTIONAL_MEMORY type is now being managed through the LMB module. Add a separate function, lmb_arch_add_memory() to add the RAM memory to the LMB memory map. The efi_add_known_memory() function is now used for adding any other memory type to the EFI memory map. Signed-off-by: -
The EFI memory allocations are now being done through the LMB module, and hence the memory map is maintained by the LMB module. Use the lmb_arch_add_memory() API function to add the usable RAM memory to the LMB's memory map. Signed-off-by: -
Some architectures have special or unique aspects which need consideration when adding memory ranges to the list of available memory map. Enable this config in such scenarios which allow architectures and boards to define their own memory map. Signed-off-by: -
The efi_add_known_memory() function for the stm32mp platforms is adding the EFI_CONVENTIONAL_MEMORY type. This memory is now being handled through the LMB module -- the lmb_add_memory() adds this memory to the memory map. Remove the definition of the now superfluous efi_add_known_memory() function. Signed-off-by:
-
The efi_add_known_memory() function for the TI K3 platforms is adding the EFI_CONVENTIONAL_MEMORY type. This memory is now being handled through the LMB module -- the lmb_add_memory() adds this memory to the memory map. Remove the definition of the now superfluous efi_add_known_memory() function. Signed-off-by:
-
The memory region occupied by U-Boot is reserved by LMB, and gets added to the EFI memory map through a call from the LMB module. Remove this superfluous addition to the EFI memory map. Signed-off-by:
-
In U-Boot, LMB and EFI are two primary modules who provide memory allocation and reservation API's. Both these modules operate with the same regions of memory for allocations. Use the LMB memory map update event to notify other interested listeners about a change in it's memory map. This can then be used by the other module to keep track of available and used memory. There is no need to send these notifications when the LMB module is being unit-tested. Add a flag to the lmb structure to indicate if the memory map is being used for tests, and suppress sending any notifications when running these unit tests. Signed-off-by: -
Use the LMB API's for allocating and freeing up memory. With this, the LMB module becomes the common backend for managing non U-Boot image memory that might be requested by other modules. Signed-off-by: -
U-Boot does not use memory above ram_top. However, this memory does need to get registered as part of the memory map, so that subsystems like EFI pass it on to the operating system as part of the EFI memory map. Add memory above ram_top and reserve it with the LMB_NOOVERWRITE flag so that it does not get allocated or re-used. Signed-off-by:
Mark Kettenis <kettenis@openbsd.org>
-
Add a flag LMB_NONOTIFY that can be passed to the LMB API's for reserving memory. This will then result in no notification being sent from the LMB module for the changes to the LMB's memory map. While here, also add a description of the memory attributes that the flags signify. Signed-off-by: -
The LMB module is to be used as a backend for allocating and freeing up memory requested from other modules like EFI. These memory requests are different from the typical LMB reservations in that memory required by the EFI module cannot be overwritten, or re-requested. Add versions of the LMB API functions with flags for allocating and freeing up memory. The caller can then use these API's for specifying the type of memory that is required. For now, these functions will be used by the EFI memory module. Signed-off-by:
-
A comment in test-main.c was not updated with the recent rename. Fix it. Signed-off-by:
Mattijs Korpershoek <mkorpershoek@baylibre.com>
-
The SPL_FIT_GENERATOR is long superseded by binman, drop SPL_FIT_GENERATOR support as there are no more users. Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> Reviewed-by:
-
The SPL_FIT_SOURCE is long superseded by SPL_FIT_GENERATOR which is long superseded by binman, drop SPL_FIT_SOURCE support as there are no more users. Signed-off-by:
-
When the config option CMD_MISC was renamed to CMD_SLEEP the check in the test for the sleep command was not updated. Do that now. Fixes: 16060854 ("cmd: Rename CMD_MISC to CMD_SLEEP") Signed-off-by:
Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by:
-
Tom Rini authored
When we have platforms being emulated by QEMU we cannot rely on the "sleep" command running for the expected wall-clock amount of time. Even with our current allowance for deviation from expected time, it will still fail from time to time. Exclude the sleep test here. Signed-off-by: -
* Remove duplicate debug message in wget_connected() * Correct typo 'Connctd' Signed-off-by:
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by:
-
After downloading a file with wget the file size may be needed in follow up actions, e.g. * write file to device * calculate hash Let wget set the environment variable filesize. Reviewed-by:
-
The commit 0252924a ("mmc: dw_mmc: Extract FIFO data transfer into a separate routine") unintentionally changed behavior of the FIFO data transfer routine. When data is read and size reaches 0 the original loop would wait on DWMCI_INTMSK_DTO or timeout. The remaining size to read and buf position is no longer tracked across dwmci_data_transfer_fifo() calls and because of this an extra call to fifo() and dwmci_fifo_ready() may now trigger a FIFO underflow timeout error and slows down FIFO reading. Buswidth = 4, clock: 50000000 Sending CMD16 Sending CMD17 dwmci_fifo_ready: FIFO underflow timeout Sending CMD16 Sending CMD18 dwmci_fifo_ready: FIFO underflow timeout Sending CMD12 ## Checking hash(es) for config config-1 ... OK This reverts commit 0252924a to restore the old working behavior. Fixes: 0252924a ("mmc: dw_mmc: Extract FIFO data transfer into a separate routine") Signed-off-by:
-
Tom Rini authored
Simon Glass <sjg@chromium.org> says: This series collects together the patches from the Labgrid series which are not related to Labgrid, or at least can be applied independently of using Labgrid to run the lab. Link: https://lore.kernel.org/r/20241010002907.19383-1-sjg@chromium.org
-
Tom Rini authored
This series from Martyn Welch <martyn.welch@collabora.com> adds the ability to have a "fallback" option in extlinux.conf parsing, which can be in turn used in A/B style update mechanisms. Link: https://lore.kernel.org/u-boot/20241009131548.929439-1-martyn.welch@collabora.com/
-
We have added a "set" sub command to bootmeth, add some tests to check it's operation. Signed-off-by:
Martyn Welch <martyn.welch@collabora.com> Reviewed-by:
-
Fix a typo in a comment. Signed-off-by: -
We have previously added logic to allow a "fallback" option to be specified in the extlinux configuration. Provide a command that allows us to set this as the preferred default option when booting. Combined with the bootcount functionality, this allows the "altbootcmd" to provide a means of falling back to a previously known good state after a failed update. For example, if "bootcmd" is set to: bootflow scan -lb We would set "altbootcmd" to: bootmeth set extlinux fallback 1; bootflow scan -lb Causing the boot process to boot from the fallback option. Reviewed-by: -
Use the new handle_exception() function from ConsoleBase also. Signed-off-by: -
The "fallback" extlinux config option allows us to set an alternative default boot option for when it has been detected that the default is failing. Implement the logic required to boot from this option when desired. Signed-off-by:
-
When the connection to a board dies, assume it is dead forever until some user action is taken. Skip all remaining tests. This avoids CI runs taking an hour, with hundreds of 30-second timeouts all to no avail. Signed-off-by: -
When configured correctly, we can detect when boot fails after the boot process has been handed over to the kernel through the use of U-Boot's bootcount support. In some instances, such as when we are performing atomic updates via a system such as OSTree, it is desirable to provide a fallback option so that we can return to a previous (hopefully working) state. Add a "fallback" option to the supported extlinux configuration options that points to a label like "default" so that we can utilise this in later commits. Signed-off-by:
-
The tests currently catch a very broad Exception in each case. This is thrown even in the event of a coding error. We want to handle exceptions differently depending on their severity, so that we can avoid hour-long delays waiting for a board that is clearly broken. As a first step, create some new exception types, separating out those which are simply an unexpected result from executed a command, from those which indicate some kind of hardware failure. Signed-off-by: -
There is quite a bit of code to deal with receiving data from the target so move it into its own receive() function. Signed-off-by: -
The settings are decoded in two places. Combine them into a new function, before (in a future patch) expanding the number of items. Signed-off-by:
-
