Skip to content
Snippets Groups Projects
  1. Oct 16, 2024
  2. Oct 15, 2024
    • Tom Rini's avatar
      83362ce1
    • Tom Rini's avatar
      Merge patch series "Make EFI memory allocations synchronous with LMB" · 77072f9e
      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
      77072f9e
    • Sughosh Ganu's avatar
      lmb: replace the double-underscore with single-underscore for all functions · 8d0df5fd
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      Suggested-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      8d0df5fd
    • Sughosh Ganu's avatar
      efi_memory: rename variable to highlight overlap with free memory · f3fe3232
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      Reviewed-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      f3fe3232
    • Sughosh Ganu's avatar
      lmb: remove call to efi_lmb_reserve() · 596516d3
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      Reviewed-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      596516d3
    • Sughosh Ganu's avatar
      efi_memory: do not add RAM memory to the memory map · e1b6822d
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
      e1b6822d
    • Sughosh Ganu's avatar
      x86: e820: use the lmb API for adding RAM memory · ad33ce2e
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      ad33ce2e
    • Sughosh Ganu's avatar
      layerscape: use the lmb API's to add RAM memory · 9ec40655
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      9ec40655
    • Sughosh Ganu's avatar
      lmb: allow for boards to specify memory map · 497da0c5
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      497da0c5
    • Sughosh Ganu's avatar
      stm32mp: remove efi_add_known_memory() function definition · 695dbd5f
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      Reviewed-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      695dbd5f
    • Sughosh Ganu's avatar
      ti: k3: remove efi_add_known_memory() function definition · d83a7637
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      Reviewed-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      d83a7637
    • Sughosh Ganu's avatar
      efi_memory: do not add U-Boot memory to the memory map · a68c9ac5
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      Reviewed-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
      a68c9ac5
    • Sughosh Ganu's avatar
      lmb: notify of any changes to the LMB memory map · 2f619152
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      2f619152
    • Sughosh Ganu's avatar
      efi: memory: use the lmb API's for allocating and freeing memory · 22f2c9ed
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      22f2c9ed
    • Sughosh Ganu's avatar
      lmb: add and reserve memory above ram_top · eb052cbb
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      Suggested-by: default avatarMark Kettenis <kettenis@openbsd.org>
      eb052cbb
    • Sughosh Ganu's avatar
      lmb: add a flag to allow suppressing memory map change notification · 3c6896ad
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      3c6896ad
    • Sughosh Ganu's avatar
      lmb: add versions of the lmb API with flags · c8a8f019
      Sughosh Ganu authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarSughosh Ganu <sughosh.ganu@linaro.org>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      c8a8f019
    • Simon Glass's avatar
      test: Drop mention of old flags in a comment · 29502f6a
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      
      A comment in test-main.c was not updated with the recent rename. Fix it.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarMattijs Korpershoek <mkorpershoek@baylibre.com>
      29502f6a
    • Marek Vasut's avatar
      Makefile: Drop SPL_FIT_GENERATOR support · 5b9261fb
      Marek Vasut authored and Tom Rini's avatar Tom Rini committed
      
      The SPL_FIT_GENERATOR is long superseded by binman, drop SPL_FIT_GENERATOR
      support as there are no more users.
      
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Reviewed-by: default avatarPeter Robinson <pbrobinson@gmail.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      5b9261fb
    • Marek Vasut's avatar
      Makefile: Drop SPL_FIT_SOURCE support · 099b6df5
      Marek Vasut authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarMarek Vasut <marex@denx.de>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarPeter Robinson <pbrobinson@gmail.com>
      099b6df5
    • Andrew Goodbody's avatar
      test: Fix skip check for sleep command test · 24382037
      Andrew Goodbody authored and Tom Rini's avatar Tom Rini committed
      
      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: default avatarAndrew Goodbody <andrew.goodbody@linaro.org>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      24382037
    • Tom Rini's avatar
      CI: Do not test "sleep" in QEMU · 08128f05
      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: default avatarTom Rini <trini@konsulko.com>
      08128f05
Loading