Re: [PATCH] xilinx: Enable SIMPLE_PM_BUS

On 9/3/24 09:48, Michal Simek wrote: Enable simple-pm-bus driver to handle case where axi bus coming between PS (fixed) part to PL (programmable) part has own clock or power domain. That's why enable driver to be ready for this configuration. Signed-off-by: Michal Simek --- configs/amd_ve

Re: [PATCH] arm64: zynqmp: Add u-boot command to boot into recovery image

On 8/27/24 13:55, Prasad Kummari wrote: To boot into the firmware recovery tool, the user currently needs to press a button on the board while powering the system up. To simplify this process, a U-Boot command was added to allow booting directly into the recovery tool. For example: ZynqMP> zy

Re: [PATCH] xilinx: versal-net: fix no previous prototype for function warning.

On 9/5/24 13:57, Prasad Kummari wrote: Included the SPI header to resolve the no previous prototypes for function. Removed unused mode variable. sparse warnings warning: no previous prototype for 'spi_get_env_dev' [-Wmissing-prototypes] warning: variable 'mode' set but not used [-Wunused-but-s

Re: [PATCH 0/6] Miscellaneous FWU fixes

On 9/6/24 08:35, Michal Simek wrote: On 9/5/24 11:17, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 14:07, Michal Simek wrote: On 9/5/24 10:12, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 13:20, Michal Simek wrote: On 9/5/24 09:43, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 13:09, M

Re: [PATCH 0/6] Miscellaneous FWU fixes

On 9/5/24 11:17, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 14:07, Michal Simek wrote: On 9/5/24 10:12, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 13:20, Michal Simek wrote: On 9/5/24 09:43, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 13:09, Michal Simek wrote: On 9/5/24 09:38,

Re: [PATCH v3 2/3] efi: Allow use of malloc() for the EFI pool

On Mon, 2 Sept 2024 at 03:53, Simon Glass wrote: > > This API call is intended for allocating small amounts of memory, > similar to malloc(). The current implementation rounds up to whole pages > which can waste large amounts of memory. It also implements its own > malloc()-style header on each bl

Re: [PATCH] power: regulator: Fix error code in regulator_list_autoset()

On Wed, Jan 31, 2024 at 10:09:41AM +0300, Dan Carpenter wrote: > This condition has a bitwise & vs logical && typo so it only preserves > odd number error codes. > > Fixes: 3b880757abca ("dm: regulator: uclass driver code cleanup") > Signed-off-by: Dan Carpenter > Reviewed-by: Patrice Chotard >

RE: [PATCH v2] ARM: imx: Enable MMU and dcache very early on i.MX8M

> Subject: [PATCH v2] ARM: imx: Enable MMU and dcache very early on > i.MX8M > > Enable MMU and caches very early on in the boot process on i.MX8M > in U-Boot proper. This allows board_init_f to run with icache and > dcache enabled, which saves some 700 milliseconds of boot time on > i.MX8M Plus b

Re: [PATCH v2] mmc: sdhci-cadence: Add support for Cadence sdmmc v6

On Tue, Nov 28, 2023 at 02:38:30PM +0800, Kuan Lim Lee wrote: > Cadence SDMMC v6 controller has a lot of changes on initialize > compared to v4 controller. PHY is needed by v6 controller. > > Signed-off-by: Kuan Lim Lee > Co-developed-by: Alex Soo > Signed-off-by: Wei Liang Lim > Reviewed-by:

Re: [PATCH v2 1/1] mmc: consider cd-gpios in Synopsys DesignWare driver

On Sun, 21 Jul 2024 08:59:07 +0200, Heinrich Schuchardt wrote: > The JH7110 SoC uses a GPIO for card detect. > > * In the of_to_plat function check if a cd-gpios definition exists and > request the GPIO. > * In the getcd function return the GPIO value in this case. > > > [...] Applied to u-b

Re: [PATCH] mmc: msm_sdhci: program core_vendor_spec

On Fri, 21 Jun 2024 03:53:09 +0200, Caleb Connolly wrote: > After resetting the host controller, program in the POR val for this > register just like the Linux driver does. > > This seems to help with initialization when running U-Boot as the primary > bootloader on some boards. > > > [...] Ap

Re: [PATCH] mmc: Change the frequency to MMC_HS_52 when selecting hs400

On Tue, 23 Apr 2024 11:00:57 +0530, Venkatesh Yadav Abbarapu wrote: > Per JESD84-B51 P47, host need to change frequency to <=52MHz > after setting HS_TIMING to 0x1, and host need to set the > 8-bit DDR buswidth. Currently setting the frequency to 26MHz > and trying to switch 8-bit DDR buswidth res

Re: [PATCH v3 1/3] buildman: Support building within a Python venv

Hi Tom, On Thu, 15 Aug 2024 at 13:57, Simon Glass wrote: > > The Python virtualenv tool sets up a few things in the environment, > putting its path first in the PATH environment variable and setting up > a sys.prefix different from the sys.base_prefix value. > > At present buildman puts the toolc

Re: [PATCH v5 17/20] test: Try to shut down the lab console gracefully

Hi Tom, On Tue, 3 Sept 2024 at 12:48, Tom Rini wrote: > > On Sun, Sep 01, 2024 at 02:09:58PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 30 Aug 2024 at 08:26, Tom Rini wrote: > > > > > > On Thu, Aug 29, 2024 at 07:04:36PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu

Re: [PATCH v6 00/28] Integrate MbedTLS v3.6 LTS with U-Boot

Hi, On Wed, 4 Sept 2024 at 06:48, Peter Robinson wrote: > > Hi Simon, > > > I wonder if we could leave out the SHA stuff? The algorithms are > > One of the big advantages of the mbedtls when it comes to all things > security is that it's seen a wide audit of it's code which for a lot > of usecase

Re: [PATCH v6 00/28] Integrate MbedTLS v3.6 LTS with U-Boot

Hi Raymond, On Tue, 3 Sept 2024 at 08:59, Raymond Mao wrote: > > Hi Simon, > > On Sat, 17 Aug 2024 at 11:58, Simon Glass wrote: >> >> Hi Raymond, >> >> On Fri, 16 Aug 2024 at 15:44, Raymond Mao wrote: >> > >> > Integrate MbedTLS v3.6 LTS (currently v3.6.0) with U-Boot. >> > >> > Motivations: >>

Re: [Binman] Question regarding SPL symbol offsets generation

Hi Lukasz, On Thu, 5 Sept 2024 at 07:54, Lukasz Majewski wrote: > > Hi Adam, > > > On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski wrote: > > > > > > Hi Simon, > > > > > > > Hi, > > > > > > > > On Tue, 27 Aug 2024 at 12:47, Fabio Estevam > > > > wrote: > > > > > > > > > > Hi Lukasz, > > > > > >

Re: [PATCH v3 0/3] efi: Start tidying up memory management

Hi Vincent, On Thu, 5 Sept 2024 at 01:47, Vincent Stehlé wrote: > > On Sun, Sep 01, 2024 at 04:22:56PM -0600, Simon Glass wrote: > > We have been discussing the state of EFI memory management for some > > years so I thought it might be best to send a short series showing some > > of the issues we

Re: [PATCH v5] mmc: Poll CD in case cyclic framework is enabled

On Sun, Jun 16, 2024 at 04:58:49PM +0200, Marek Vasut wrote: > In case the cyclic framework is enabled, poll the card detect of already > initialized cards and deinitialize them in case they are removed. Since > the card initialization is a longer process and card initialization is > done on first

Re: [RESEND PATCH v4 0/3] provide names for emmc hardware partitions

On Fri, 31 May 2024 08:36:32 -0700, Tim Harvey wrote: > Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC > specification described as: > Boot Area Partition 1 > Boot Area Partition 2 > RPMB Partition > General Purpose Partition 1 > General Purpose Partition 2 > General

[PATCH] configs: venice: enable DM_RNG

Enable DM_RNG so that the kaslr-seed property is set in the dt allowing Linux KASLR. Signed-off-by: Tim Harvey --- configs/imx8mm_venice_defconfig | 1 - configs/imx8mn_venice_defconfig | 1 - configs/imx8mp_venice_defconfig | 1 - 3 files changed, 3 deletions(-) diff --git a/configs/imx8mm_ven

Re: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled

On 4/30/24 3:48 AM, Marek Vasut wrote: On 4/30/24 12:36 AM, Jaehoon Chung wrote: -Original Message- From: Marek Vasut Sent: Friday, April 26, 2024 8:41 PM To: Jaehoon Chung ; u-boot@lists.denx.de Cc: 'Peng Fan' ; 'Simon Glass' Subject: Re: [PATCH v4] mmc: Poll CD in case cyclic fram

Re: [PATCH] ARM: imx: Enable MMU and dcache very early on i.MX8M

On 8/31/24 1:16 PM, Fabio Estevam wrote: Hi Marek, On Tue, Aug 27, 2024 at 5:04 PM Marek Vasut wrote: +/* + * Place early TLB into the .data section so that it will not + * get cleared, use 16 kiB alignment. + */ +#define EARLY_TLB_SIZE SZ_64K +u8 early_tlb[EARLY_TLB_SIZE] __section(".data")

Re: [RESEND PATCH v4 0/3] provide names for emmc hardware partitions

On Thu, Sep 05, 2024 at 11:11:10AM -0700, Tim Harvey wrote: > On Mon, Aug 12, 2024 at 12:25 PM Tim Harvey wrote: > > > > On Tue, Jul 2, 2024 at 12:23 PM Tom Rini wrote: > > > > > > On Tue, Jul 02, 2024 at 11:14:15AM -0700, Tim Harvey wrote: > > > > On Fri, May 31, 2024 at 8:36 AM Tim Harvey > >

Re: [RESEND PATCH v4 0/3] provide names for emmc hardware partitions

On Mon, Aug 12, 2024 at 12:25 PM Tim Harvey wrote: > > On Tue, Jul 2, 2024 at 12:23 PM Tom Rini wrote: > > > > On Tue, Jul 02, 2024 at 11:14:15AM -0700, Tim Harvey wrote: > > > On Fri, May 31, 2024 at 8:36 AM Tim Harvey wrote: > > > > > > > > Modern eMMC v4+ devices have multiple hardware partit

[PATCH v2 2/2] arm: zynqmp: Enable non-invasive CCI-400 PMU debug

Set NIDEN, enabling non-invasive debug for the CCI-400 PMU. Otherwise, the PMU is effectively disabled. Signed-off-by: Sean Anderson Reviewed-by: Michal Simek --- (no changes since v1) arch/arm/mach-zynqmp/include/mach/hardware.h | 3 +++ board/xilinx/zynqmp/zynqmp.c | 4

[PATCH v2 1/2] zynqmp: Disable secure access for boot devices

Boot devices (QSPI, MMC, NAND, and Ethernet) use secure access for DMA by default. As this causes problems when using the SMMU [1], configure them for normal access instead. [1] https://support.xilinx.com/s/article/72164 Signed-off-by: Sean Anderson --- Changes in v2: - Don't set reserved bits

[PATCH v2 0/2] arm: zynqmp: Initialize some registers at boot

These patches are independent in intent, but they modify adjacent lines so I have sent them as a series. Changes in v2: - Don't set reserved bits in AXI_RPRTCN, since QSPI doesn't use ARPROT Sean Anderson (2): zynqmp: Disable secure access for boot devices arm: zynqmp: Enable non-invasive CCI

[PATCH v2] ARM: imx: Enable MMU and dcache very early on i.MX8M

Enable MMU and caches very early on in the boot process on i.MX8M in U-Boot proper. This allows board_init_f to run with icache and dcache enabled, which saves some 700 milliseconds of boot time on i.MX8M Plus based device. The 'bootstage report' output is below: Before: ``` Timer summary in micr

[PATCH v6 5/6] rockchip: rock5b-rk3588: Enable USB-C PD support

Now that all code has been prepared update the default configuration to make use of it. Reviewed-by: Kever Yang Tested-by: Soeren Moch Signed-off-by: Sebastian Reichel --- configs/rock5b-rk3588_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/rock5b-rk3588_defconfig b/

[PATCH v6 2/6] usb: tcpm: fusb302: add driver

Now that the TCPM framework exists we can introduce fusb302 driver using it. This chip is a very common USB-C controller chip with PD support, which can be found in the Radxa Rock 5B among many other boards. Apart from Power Delivery, it also handles detection of the cable orientation. That can be

[PATCH v6 6/6] MAINTAINERS: add TCPM section

Add new section for USB TypeC Port Manager (TCPM) support, which is needed to figure out cable orientation of USB-C plus and to do USB PD communication. Signed-off-by: Sebastian Reichel --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2

[PATCH v6 1/6] usb: tcpm: add core framework

This adds TCPM framework in preparation for fusb302 support, which can handle USB power delivery messages. This is needed to solve issues with devices, that are running from a USB-C port supporting USB-PD, but not having a battery. Such a device currently boots to the kernel without interacting wi

[PATCH v6 0/6] FUSB302 USB-C controller support

Hi, On ROCK 5B power is usually supplied via it's USB-C port. This port has the data lines connected to RK3588, VBUS connected to the input regulator and CC pins connected to FUSB302. FUSB302 is a USB-C controller, which can be accessed via I2C from RK3588. The USB-C controller is needed to figure

[PATCH v6 4/6] rockchip: rk3588-rock-5b: Add USB-C controller to u-boot.dtsi

Add USB-C controller (fusb302), which will be used by U-Boot to initialize USB-PD. This is needed, because USB-PD communication must happen within 5 seconds after the USB-C connector got plugged. On my Rock 5B it often takes 5 seconds to jump to the Linux binary, so it must happen before Linux is i

[PATCH v6 3/6] board: rock5b-rk3588: enable USB-C in operating system

Since older U-Boot releases do not negotiate USB PD, the kernel DT may not enable the USB-C controller by default to avoid a regression. The plan is to upstream it with 'status = "fail";' instead. U-Boot should then mark it as 'status = "okay";' if it negotiated USB PD. Currently existing upstream

Re: [PATCH] fs: Fix SPL build if SPL_FS_LOADER is enabled and FS_LOADER is disabled

On Thu, Sep 05, 2024 at 01:44:37AM +0200, Francesco Dolcini wrote: > Hello Tom, > > On Wed, Sep 04, 2024 at 03:27:21PM -0600, Tom Rini wrote: > > On Sat, Aug 31, 2024 at 03:49:11PM +0200, Francesco Dolcini wrote: > > > On Fri, Aug 30, 2024 at 02:51:19PM -0600, Tom Rini wrote: > > > > On Mon, Aug 2

Re: [Binman] Question regarding SPL symbol offsets generation

Hi Adam, > On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski wrote: > > > > Hi Simon, > > > > > Hi, > > > > > > On Tue, 27 Aug 2024 at 12:47, Fabio Estevam > > > wrote: > > > > > > > > Hi Lukasz, > > > > > > > > On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski > > > > wrote: > > > > > Unfort

Re: [RFC PATCH 4/6] drivers: misc: k3_bist: Add K3 BIST driver

On 9/5/2024 3:11 PM, Neha Malcom Francis wrote: On 04/09/24 10:35, Kumar, Udit wrote: On 9/3/2024 5:14 PM, Neha Malcom Francis wrote: Add a driver for the BIST module which currently includes support for BIST IPs that trigger PBIST (Memory BIST). Signed-off-by: Neha Malcom Francis ---   dr

[U-Boot] [PATCH 10/37] Blackfin: bf548-ezkit: video: convert from old style MMR macros

Sent from my T-Mobile 5G Device Get Outlook for Android

Re: [PATCH 2/2] net: phy: add Qualcomm QCA807x driver

Hi all, Not sure what the status of this series is, seems like it slipped by my inbox. Both patches are assigned to me on patchwork but they only affect the phy subsystem... At least for this one: Acked-by: Caleb Connolly On 22/05/2024 12:06, Robert Marko wrote: > This adds driver for the Qu

Re: [PATCH 0/4] clk/qcom: implement clk dump callback

Hi Lukasz, Could you take a quick look at this? Thanks and kind regards, On 19/08/2024 21:34, Caleb Connolly wrote: > Add support for dumping a few of the clocks used on Qualcomm platforms. > Naming the Global PLL's, Root Clock Generators, and gate clocks. > > This helps a lot with platform bri

[PATCH] xilinx: versal-net: fix no previous prototype for function warning.

Included the SPI header to resolve the no previous prototypes for function. Removed unused mode variable. sparse warnings warning: no previous prototype for 'spi_get_env_dev' [-Wmissing-prototypes] warning: variable 'mode' set but not used [-Wunused-but-set-variable] Signed-off-by: Prasad Kummari

Re: [PATCH 0/2] regulators: qcom-rpmh: support SM8550 and SM8650 platforms

On Tue, 03 Sep 2024 18:13:29 +0200, Neil Armstrong wrote: > Fix the RSC and add the tables for the PM8550 and related regulators. > > Applied, thanks! [1/2] soc: qcom: rpmh-rsc: add back __tcs_set_trigger() for SM8550/SM8650 commit: 0fa4617861299b42effb5faf4afafd6fe1a79192 [2/2] regulat

Re: [PATCH 0/2] regulators: qcom-rpmh: support SM8550 and SM8650 platforms

On 03/09/2024 18:13, Neil Armstrong wrote: > Fix the RSC and add the tables for the PM8550 and related regulators. Thanks Neil > > Signed-off-by: Neil Armstrong Tested-by: Caleb Connolly # sm8250 rb5 Reviewed-by: Caleb Connolly > --- > Neil Armstrong (2): > soc: qcom: rpmh-rsc: add b

Re: [PATCH v3] cmd: mmc: Allow using partition name in mmc erase command

Hi Tomas, On 9/3/24 12:14 PM, Tomas Paukrt wrote: Same question as for v1, are we sure that the partition block size is the same as the MMC erase block size? Is this guaranteed by all standards (all MMC standards, and all partition table standards)? Otherwise I assume we should do some maths her

Re: [RFC PATCH 4/6] drivers: misc: k3_bist: Add K3 BIST driver

On 04/09/24 10:35, Kumar, Udit wrote: On 9/3/2024 5:14 PM, Neha Malcom Francis wrote: Add a driver for the BIST module which currently includes support for BIST IPs that trigger PBIST (Memory BIST). Signed-off-by: Neha Malcom Francis ---   drivers/misc/Kconfig   |   8 +   drivers/

Re: [RFC PATCH 3/6] arm: dts: k3-j784s4-main: Add clock and power domains for MAIN_R5_2_x

On 04/09/24 09:55, Kumar, Udit wrote: On 9/3/2024 5:13 PM, Neha Malcom Francis wrote: Add bootph-pre-ram as well as the clocks and power-domains for MAIN_R5_2_x. This ensures that LPSC sets the appropriate power and clock and allows for BIST to turn the cores on and off for running the self-tes

Re: [RFC PATCH 2/6] arm: dts: k3-j784s4-main: Add PBIST_14 node

Hi Udit On 04/09/24 09:52, Kumar, Udit wrote: On 9/3/2024 5:13 PM, Neha Malcom Francis wrote: Add DT node for PBIST_14 that is responsible for triggering the BIST self-tests for the MAIN_R5_2_x cores. Signed-off-by: Neha Malcom Francis ---   dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi | 10

Re: [PATCH 0/6] Miscellaneous FWU fixes

On Thu, 5 Sept 2024 at 14:07, Michal Simek wrote: > > > > On 9/5/24 10:12, Sughosh Ganu wrote: > > On Thu, 5 Sept 2024 at 13:20, Michal Simek wrote: > >> > >> > >> > >> On 9/5/24 09:43, Sughosh Ganu wrote: > >>> On Thu, 5 Sept 2024 at 13:09, Michal Simek wrote: > > > > On 9/5

Re: [RFC PATCH 1/6] arm: mach-k3: j784s4: Add clk and power support for MAIN_R5_2_x PBIST

Hi Udit, On 04/09/24 09:49, Kumar, Udit wrote: On 9/3/2024 5:13 PM, Neha Malcom Francis wrote: Add clock and power domains for MAIN_R5_2_0, MAIN_R5_2_1 and PBIST_14. Please keep provision for other R core as well, BIST may be needed in future on those I was thinking of having this in a "

Re: [PATCH 0/6] Miscellaneous FWU fixes

On 9/5/24 10:12, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 13:20, Michal Simek wrote: On 9/5/24 09:43, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 13:09, Michal Simek wrote: On 9/5/24 09:38, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 13:03, Michal Simek wrote: On 9/5/24 08:24,

[PATCH 16/16] test: event: update the expected event dump output

With the addition of two events for notification of any changes to memory that is occupied and is free, the output of the event_dump.py script has changed. Update the expected event log to incorporate this change. Signed-off-by: Sughosh Ganu --- test/py/tests/test_event_dump.py | 1 + 1 file cha

[PATCH 15/16] lmb: remove call to efi_lmb_reserve()

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: Sughosh Ganu --- lib/lmb.c | 36 1 file changed, 36 deletions(-) diff --git

[PATCH 14/16] efi_memory: do not add RAM memory to the memory map

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: Sughosh Ganu

[PATCH 13/16] x86: e820: use the lmb API for adding RAM memory

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: Sughosh G

[PATCH 12/16] layerscape: use the lmb API's to add RAM memory

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: Sughosh Ganu --- arch/arm/cpu/armv8/fsl-layerscape/cpu.c

[PATCH 11/16] lmb: allow for boards to specify memory map

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: Sughosh Ganu --- include/lmb.h | 2 +

[PATCH 10/16] stm32mp: remove efi_add_known_memory() function definition

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.

[PATCH 08/16] efi_memory: add an event handler to update memory map

There are events that would be used to notify other interested modules of any changes in available and occupied memory. This would happen when a module allocates or reserves memory, or frees up memory. These changes in memory map should be notified to other interested modules so that the allocated

[PATCH 09/16] ti: k3: remove efi_add_known_memory() function definition

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.

[PATCH 07/16] lmb: notify of any changes to the LMB memory map

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 b

[PATCH 06/16] add a function to check if an address is in RAM memory

Add a function to check if a given address falls within the RAM address used by U-Boot. This will be used to notify other modules if the address gets allocated, so as to not get re-allocated by some other module. Signed-off-by: Sughosh Ganu --- common/board_r.c | 5 + 1 file changed, 5 inser

[PATCH 05/16] lib: Kconfig: add a config symbol for getting lmb memory map updates

Add a Kconfig symbol to enable getting updates on any memory map changes that might be done by the LMB module. This notification mechanism can then be used to have a synchronous view of allocated and free memory. Signed-off-by: Sughosh Ganu --- lib/Kconfig | 11 +++ 1 file changed, 11 in

[PATCH 04/16] event: add event to notify lmb memory map changes

Add an event which would be used for notifying changes in the LMB modules' memory map. This is to be used for having a synchronous view of the memory that is currently in use, and that is available for allocations. Signed-off-by: Sughosh Ganu --- common/event.c | 2 ++ include/event.h | 14 +++

[PATCH 03/16] efi: memory: use the lmb API's for allocating and freeing memory

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: Sughosh Ganu --- lib/efi_loader/Kconfig | 1 + lib/efi_loader/efi_memory.c | 74 +++

[PATCH 02/16] lmb: add a flag to allow suppressing memory map change notification

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. Signed-off-by: Sughosh Ganu --- include/lmb.h | 1 + lib/lmb.c | 2 +- 2 files changed, 2 inserti

[PATCH 01/16] lmb: add versions of the lmb API with flags

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 f

[PATCH 00/16] Make EFI memory allocations synchronous with LMB

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 allocati

Re: [PATCH 0/6] Miscellaneous FWU fixes

On Thu, 5 Sept 2024 at 13:20, Michal Simek wrote: > > > > On 9/5/24 09:43, Sughosh Ganu wrote: > > On Thu, 5 Sept 2024 at 13:09, Michal Simek wrote: > >> > >> > >> > >> On 9/5/24 09:38, Sughosh Ganu wrote: > >>> On Thu, 5 Sept 2024 at 13:03, Michal Simek wrote: > > > > On 9/5

Re: [PATCH 0/6] Miscellaneous FWU fixes

On 9/5/24 09:43, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 13:09, Michal Simek wrote: On 9/5/24 09:38, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 13:03, Michal Simek wrote: On 9/5/24 08:24, Sughosh Ganu wrote: On Wed, 4 Sept 2024 at 17:30, Michal Simek wrote: On 8/30/24 13:40

Re: [PATCH v3 0/3] efi: Start tidying up memory management

On Sun, Sep 01, 2024 at 04:22:56PM -0600, Simon Glass wrote: > We have been discussing the state of EFI memory management for some > years so I thought it might be best to send a short series showing some > of the issues we have talked about. > > This one just deals with memory allocation. It prov

Re: [PATCH 0/6] Miscellaneous FWU fixes

On Thu, 5 Sept 2024 at 13:09, Michal Simek wrote: > > > > On 9/5/24 09:38, Sughosh Ganu wrote: > > On Thu, 5 Sept 2024 at 13:03, Michal Simek wrote: > >> > >> > >> > >> On 9/5/24 08:24, Sughosh Ganu wrote: > >>> On Wed, 4 Sept 2024 at 17:30, Michal Simek wrote: > > > > On 8/3

Re: [PATCH 0/6] Miscellaneous FWU fixes

On 9/5/24 09:38, Sughosh Ganu wrote: On Thu, 5 Sept 2024 at 13:03, Michal Simek wrote: On 9/5/24 08:24, Sughosh Ganu wrote: On Wed, 4 Sept 2024 at 17:30, Michal Simek wrote: On 8/30/24 13:40, Sughosh Ganu wrote: The following set of patches are miscellaneous fixes and some hardeni

Re: [PATCH 0/6] Miscellaneous FWU fixes

On Thu, 5 Sept 2024 at 13:03, Michal Simek wrote: > > > > On 9/5/24 08:24, Sughosh Ganu wrote: > > On Wed, 4 Sept 2024 at 17:30, Michal Simek wrote: > >> > >> > >> > >> On 8/30/24 13:40, Sughosh Ganu wrote: > >>> > >>> The following set of patches are miscellaneous fixes and some > >>> hardening

Re: [PATCH 0/6] Miscellaneous FWU fixes

On 9/5/24 08:24, Sughosh Ganu wrote: On Wed, 4 Sept 2024 at 17:30, Michal Simek wrote: On 8/30/24 13:40, Sughosh Ganu wrote: The following set of patches are miscellaneous fixes and some hardening of the FWU update logic. Sughosh Ganu (6): fwu: v2: perform some checks before readin