Re: [PATCH 3/9] ARM: socfpga: add Enclustra AA1 SoM support

On Thu, Sep 12, 2024 at 7:45 PM Tom Rini wrote: > > On Thu, Sep 12, 2024 at 06:06:43AM +, Lothar Rubusch wrote: > > > Introduce initial support for the Enclustra SoMs: > > > > - Mercury AA1 > > > > Cover general board files for SD/MMC and QSPI boot modes. Integrate the > > boards to kconfig. A

Re: [PATCH 2/9] ARM: dts: socfpga: add Enclustra Intel AA1

On Fri, Sep 13, 2024 at 1:11 AM Marek Vasut wrote: > > On 9/12/24 8:06 AM, Lothar Rubusch wrote: > > Introduce device-tree files for Enclustra Intel AA1 SoMs and related > > support. > > > > - Mercury AA1 > > > > The setup depends on a selected boot mode. Various fragments for SD/MMC > > and QSPI

Re: [PATCH 1/9] doc: board: enclustra: add Enclustra Intel AA1 SoM

On Fri, Sep 13, 2024 at 1:11 AM Marek Vasut wrote: > > On 9/12/24 8:06 AM, Lothar Rubusch wrote: > [...] > > > +Mercury AA1 Module (Arria1 10) > > +== > > + > > +- SoM: > > https://www.enclustra.com/en/products/system-on-chip-modules/mercury-aa1/ > > +- Carrier board M

Re: [PATCH 8/9] ARM: socfpga: add si5338 clock generator support

On Fri, Sep 13, 2024 at 1:12 AM Marek Vasut wrote: > > On 9/12/24 8:06 AM, Lothar Rubusch wrote: > > The si5338 clock generator is needed on some Enclustra Socfpga SoMs. > > Introduce minimal support of this device. > > > > Signed-off-by: Lothar Rubusch > > --- > > drivers/clk/Kconfig

Re: [PATCH 3/8] clk: imx8mp: Add media related clocks

On Tue, Sep 10, 2024 at 5:14 AM Miquel Raynal wrote: > > These are all the clocks needed to get an LCD panel working, going > through one of the LCDIF and the LDB. The media AXI and APB clocks are > also described. Are these clocks going to be enumerated in SPL? I am concerned it might bloat the

[PATCH v2 1/1] efi_leader: delete rng-seed if having EFI RNG protocol

For measured be boot we must avoid any volatile values in the device-tree. We already delete /chosen/kaslr-seed if we provide and EFI RNG protocol. Additionally remove /chosen/rng-seed provided by QEMU or U-Boot. Signed-off-by: Heinrich Schuchardt --- v2: put log_debug() in else branch -

[PATCH 1/1] efi_leader: delete rng-seed if having EFI RNG protocol

For measured be boot we must avoid any volatile values in the device-tree. We already delete /chosen/kaslr-seed if we provide and EFI RNG protocol. Additionally remove /chosen/rng-seed provided by QEMU or U-Boot. Signed-off-by: Heinrich Schuchardt --- include/efi_loader.h | 2 +- lib/

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

On 9/5/24 10:27, Sughosh Ganu wrote: 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. We should h

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

On 9/5/24 10:28, Sughosh Ganu wrote: 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

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

On 9/5/24 10:27, Sughosh Ganu wrote: 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. The synchronous view problem only exists be

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

On 9/5/24 10:27, Sughosh Ganu wrote: 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 +

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

On 9/5/24 10:27, Sughosh Ganu wrote: 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. You seem to be using this in patch 3 and 7. Please, describe i

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

On 9/5/24 10:27, Sughosh Ganu wrote: 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-r

Re: [PATCH v1 00/12] Bind Syscon driver with OF_REAL

Hi Anand, On 2024/8/6 12:38, Anand Moon wrote: Bind syscon driver with dm_scan_fdt_dev As OF_PLATDATA is no longer enabled, the related code is removed. The OF_PLATDATA is no removed, basically it's use in TPL/SPL for code size, and the SPL_OF_PLATDATA and TPL_PLATDAT still available, The OF

Re: [PATCH v3 1/3] efi: Drop the memset() from efi_alloc()

On 02.09.24 00:22, Simon Glass wrote: From my inspection none of the users need the memory to be zeroed. It is somewhat unexpected that it does so, since the name gives no clue to this. Though the UEFI specification does not require it, EDK II uses AllocateZeroPool() to implement EFI_DEVICE_PA

Re: persistent environment

Hello again, just after sending the last message I continued testing, and went have a look at the various CONFIG options I used, especially their help text... The problem was PEBKAC, I RTFM'ed myself with: CONFIG_SYS_MMC_ENV_PART: MMC hardware partition device number on the platform where the e

Re: persistent environment

Hello Simon, On Thu, Sep 12, 2024 at 1:02 AM Simon Glass wrote: > Looking at env_erase() > It calls drv->erase() which for mmc is: > .erase = ENV_ERASE_PTR(env_mmc_erase) > > I see this: > > if (IS_ENABLED(CONFIG_SYS_REDUNDAND_ENVIRONMENT)) { >copy = 1; > >if (IS_ENABLED(ENV_MMC_HWPART_RE