On 4/17/24 11:00, Patrick DELAUNAY wrote:
> Hi
>
> On 3/8/24 14:50, Patrice Chotard wrote:
>> Fix flash@0 partition node name with correct offset.
>>
>> Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand
>> node for
>> stm32mp15xx-dhcom/dhcor")
>>
>> Signed-off-by: Patric
On 4/17/24 13:10, Jaehoon Chung wrote:
> Hi
>
>> -Original Message-
>> From: Patrick DELAUNAY
>> Sent: Wednesday, April 17, 2024 6:02 PM
>> To: Patrice Chotard ; u-boot@lists.denx.de
>> Cc: U-Boot STM32 ; Jaehoon Chung
>> ;
>> Peng Fan ; Sean Anderson ; Simon Glass
>> ; Tom
>> Rini
On 4/17/24 13:11, Jaehoon Chung wrote:
>
>
>> -Original Message-
>> From: Patrick DELAUNAY
>> Sent: Wednesday, April 17, 2024 6:02 PM
>> To: Patrice Chotard ; u-boot@lists.denx.de
>> Cc: U-Boot STM32 ; Jaehoon Chung
>> ;
>> Peng Fan ; Sean Anderson ; Simon Glass
>> ; Tom
>> Rini
>>
On 4/17/24 11:28, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> The blue led is used to indicate U-Boot entering / exit indication
>> then Linux heartbeat.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 6 +
On 4/17/24 11:13, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> As indicated in kernel led dt-bindings, label is a deprecated
>> property, so remove it and use led node's name instead for
>> u-boot,error-led property.
>> Rename red led node's name to led-red.
>> R
On 4/17/24 11:13, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> red led and button dedicated to fastboot share the same gpio GPIOA13.
>> Led driver is probed early so the corresponding gpio is taken and
>> configured in output which forbid fastboot and stm32prog b
On 4/9/24 17:02, Patrice Chotard wrote:
> red led and button dedicated to fastboot share the same gpio GPIOA13.
> Led driver is probed early so the corresponding gpio is taken and
> configured in output which forbid fastboot and stm32prog button usage.
>
> To avoid this, remove the "default-sta
On 4/17/24 11:12, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> Add 2 gpio-keys :
>> _ button-user-1 for stm32prog mode activation.
>> _ button-user-2 for fastboot mode activation.
>>
>> Remove proprietary st,fastboot-gpios and st,stm32prog-gpios.
>>
>> Sign
On 4/17/24 11:11, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> The blue led is used to indicate U-Boot entering / exit indication
>> then Linux heartbeat.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 6 +-
>>
On 4/17/24 11:11, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> As indicated in kernel led dt-bindings, label is a deprecated
>> property, so remove it and use led node's name instead for
>> u-boot,error-led property.
>> Rename red led node's name to led-red.
>> R
On 4/17/24 11:11, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> red led and button dedicated to fastboot share the same gpio GPIOA13.
>> Led driver is probed early so the corresponding gpio is taken and
>> configured in output which forbid fastboot and stm32prog b
On 4/17/24 11:11, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> Add 2 gpio-keys :
>> _ button-user-1 for stm32prog mode activation.
>> _ button-user-2 for fastboot mode activation.
>>
>> Remove proprietary st,fastboot-gpios and st,stm32prog-gpios.
>>
>> Sign
On 4/17/24 11:10, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> As indicated in kernel led dt-bindings, label is a deprecated
>> property, so remove it and use blue led node's name instead
>> for u-boot,boot-led property.
>>
>> Signed-off-by: Patrice Chotard
>> -
On 4/17/24 11:10, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> As indicated in kernel led dt-bindings, label is a deprecated
>> property, so remove it and use red led node's name instead
>> for u-boot,error-led property.
>> Rename red led node's name to led-red.
On 4/17/24 11:09, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> red led and button dedicated to fastboot share the same gpio GPIOA13.
>> Led driver is probed early so the corresponding gpio is taken and
>> configured in output which forbid fastboot and stm32prog b
On 4/17/24 11:09, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
>> 2 gpio-keys.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 19 ++
On 4/17/24 11:09, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> As indicated in kernel led dt-bindings, label is a deprecated
>> property, so remove it and use blue led node's name instead
>> for u-boot,boot-led property.
>>
>> Signed-off-by: Patrice Chotard
>> -
On 4/17/24 11:08, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> As indicated in kernel led dt-bindings, label is a deprecated
>> property, so remove it and use red led node's name instead
>> for u-boot,error-led property.
>> Rename "red" led node's name to "led-re
On 4/17/24 11:07, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> red led and button dedicated to fastboot share the same gpio GPIOA13.
>> Led driver is probed early so the corresponding gpio is taken and
>> configured in output which forbid fastboot and stm32prog b
On 4/17/24 11:07, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
>> 2 gpio-keys.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 19 +
On 4/17/24 11:07, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:01, Patrice Chotard wrote:
>> Remove "color" property from led-red node which is not supported
>> by U-Boot.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 1 -
>> 1 file changed, 1
On 4/17/24 11:06, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:01, Patrice Chotard wrote:
>> led-red and button dedicated to fastboot share the same gpio GPIOA13.
>> led-blue and button dedicated to stm32prog share the same gpio GPIOA14.
>> Led driver is probed early so the corresponding gpio
On 4/17/24 11:05, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:01, Patrice Chotard wrote:
>> Instead of using gpio directly to detect key pressed on button
>> dedicated for fastboot and stm32mprog, make usage of BUTTON UCLASS.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> board/st/stm3
On 4/17/24 11:06, Patrick DELAUNAY wrote:
> Hi
>
> On 4/9/24 17:01, Patrice Chotard wrote:
>> Add 2 gpio-keys :
>> _ button-user-1 for stm32prog mode activation.
>> _ update button-user's label (defined in kernel DT) to match label
>> requested in board_key_check() for fastboot mode
On 4/18/24 13:48, Igor Opaniuk wrote:
> On Tue, Apr 9, 2024 at 5:05 PM Patrice Chotard
> wrote:
>>
>> Enable BUTTON_GPIO flag for STM32MP15.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> configs/stm32mp13_defconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/configs/stm3
On 4/17/24 11:04, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:01, Patrice Chotard wrote:
>> Enable BUTTON_GPIO flag for STM32MP15.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> configs/stm32mp15_basic_defconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/configs/stm
On 4/17/24 11:04, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:01, Patrice Chotard wrote:
>> Enable BUTTON_GPIO flag for STM32MP15.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> configs/stm32mp15_trusted_defconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/configs/s
On 4/17/24 11:03, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:01, Patrice Chotard wrote:
>> Enable BUTTON_GPIO flag for STM32MP15.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> configs/stm32mp15_defconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/configs/stm32mp15
On 4/18/24 13:48, Igor Opaniuk wrote:
> On Tue, Apr 9, 2024 at 5:19 PM Patrice Chotard
> wrote:
>>
>> Enable FASTBOOT relative flags for stm32mp13_defconfig.
>>
>> Signed-off-by: Patrice Chotard
>>
>> ---
>>
>> configs/stm32mp13_defconfig | 9 -
>> 1 file changed, 8 insertions(+), 1 d
On 2/7/24 16:59, Igor Opaniuk wrote:
> On Wed, Feb 7, 2024 at 2:12 PM Patrick Delaunay
> wrote:
>>
>> This patch avoids compilation issue when CONFIG_USB_GADGET is deactivated
>> in defconfig, with undefined reference to run_usb_dnl_gadget and to
>> g_dnl_set_product.
>>
>> Signed-off-by: Patri
On 3/4/24 19:25, Marek Vasut wrote:
> The OHCI HCD is mandatory for USB 1.1 FS/LS device support, enable it.
> This used to be enabled implicitly before, now that implicit dependency
> disappeared and this got disabled. Enable it manually.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Patrice Cho
On 3/6/24 10:54, Christophe Kerello wrote:
> FMC2 IP supports up to 4 chip select. On MP1 SoC, only 2 of them are
> available when on MP25 SoC, the 4 chip select are available.
>
> Let's use a platform data structure for parameters that will differ.
>
> Signed-off-by: Christophe Kerello
> ---
On 3/6/24 10:50, Christophe Kerello wrote:
> The FMC2 revision 2 supports security and isolation compliant with
> the Resource Isolation Framework (RIF). From RIF point of view,
> the FMC2 is composed of several independent resources, listed below,
> which can be assigned to different security a
On 3/6/24 10:50, Christophe Kerello wrote:
> Add the support of the revision 2 of FMC2 IP.
> - PCSCNTR register has been removed,
> - CFGR register has been added,
> - the bit used to enable the IP has moved from BCR1 to CFGR,
> - the timeout for CEx deassertion has moved fro
On 4/7/24 22:21, Marek Vasut wrote:
> In case the system has resumed successfully, the PSCI suspend resume
> code has to jump to the 'ep' successful resume entry point code path,
> otherwise the code has to jump to content of the LR register, which
> points to failed resume code path.
>
> To im
On 4/14/24 20:38, Marek Vasut wrote:
> The source file is in arch/arm/mach-stm32mp/ecdsa_romapi.c and not
> in arch/arm/mach-stm32mp/stm32mp1/ecdsa_romapi.c . There are two
> Makefile entries in each subdirectory. Drop the bogus one and keep
> only the correct one, the one in arch/arm/mach-stm32
On 4/14/24 20:39, Marek Vasut wrote:
> SoC revision is only accessible via DBUMCU IDC register,
> which requires BSEC.DENABLE DBGSWENABLE bit to be set to
> make the register accessible, otherwise an access to the
> register triggers bus fault. As BSEC.DBGSWENABLE is zero
> in case of an OTP-CLO
On 4/8/24 17:52, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:08 PM
>> To:u-boot@lists.denx.de
>> Cc: Marek Vasut; Christophe
>> ROULLIER; Joe
>> Hershberger; Patrice CHOTARD -
>> foss; Patrick DELAUNAY -
>> foss; Ramon
>>
On 4/8/24 17:50, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:08 PM
>> To:u-boot@lists.denx.de
>> Cc: Christophe ROULLIER; Marek
>> Vasut; Joe Hershberger; Patrice
>> CHOTARD - foss; Patrick DELAUNAY -
>> foss; Ramon
>> Frie
On 3/26/24 13:07, Marek Vasut wrote:
> Use const bool for the values parsed out of DT. Drop the duplicate
> assignment of false into those bool variables, assign them directly
> with the content parsed out of DT. Abbreviate the variable name too.
>
> Reviewed-by: Patrice Chotard
> Signed-off-b
On 4/8/24 17:51, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:08 PM
>> To:u-boot@lists.denx.de
>> Cc: Christophe ROULLIER; Patrice CHOTARD -
>> foss; Marek Vasut; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>> Frie
On 3/26/24 13:07, Marek Vasut wrote:
> Use dev_*() only to print all the logs from this glue code,
> instead of mixing dev_*(), log_*(), pr_*() all in one code.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice
On 3/26/24 13:07, Marek Vasut wrote:
> Move the log_debug() calls on top of the bit manipulation code.
> No functional change.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
>
On 3/26/24 13:07, Marek Vasut wrote:
> Use FIELD_PREP to configure content of ETH_SEL bitfield in SYSCFG_PMCSETR
> register. No functional change.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc:
On 4/8/24 09:27, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To: u-boot@lists.denx.de
>> Cc: Marek Vasut ; Patrice CHOTARD - foss
>> ; Christophe ROULLIER
>> ; Joe Hershberger ;
>> Patrick DELAUNAY - foss ; Ramon F
On 3/26/24 13:07, Marek Vasut wrote:
> Move board_interface_eth_init() into eqos_probe_syscfg_stm32() in STM32
> driver glue code. The eqos_probe_syscfg_stm32() parses STM32 specific DT
> properties of this MAC and configures SYSCFG registers accordingly, there
> is nothing board specific happen
On 4/8/24 09:26, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To:u-boot@lists.denx.de
>> Cc: Marek Vasut; Patrice CHOTARD -
>> foss; Christophe
>> ROULLIER; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>>
On 4/8/24 09:24, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To:u-boot@lists.denx.de
>> Cc: Marek Vasut; Patrice CHOTARD -
>> foss; Christophe
>> ROULLIER; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>>
On 4/19/24 11:36, Patrice CHOTARD wrote:
>
>
> On 4/19/24 05:59, Marek Vasut wrote:
>> In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be
>> released from endless loop in BootROM only by populating TAMP BKPxR 4
>> and 5 with magic and branch address and sending SGI0 interrup
On 4/8/24 09:24, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To:u-boot@lists.denx.de
>> Cc: Marek Vasut; Patrice CHOTARD -
>> foss; Christophe
>> ROULLIER; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>>
Hi Tom
Please pull the STM32 related patches for u-boot/master, v2024.07:
u-boot-stm32-20240419
CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/20430
The following changes since commit 97b34f6ace539c9c16eb8565f8b58730848ba97a:
env: mmc: print MMC device being
On Fri, 19 Apr 2024 at 17:23, Chintan Vankar wrote:
>
>
>
> On 19/04/24 17:04, Sughosh Ganu wrote:
> > On Fri, 19 Apr 2024 at 16:04, Chintan Vankar wrote:
> >>
> >>
> >>
> >> On 18/04/24 17:30, Sughosh Ganu wrote:
> >>> On Thu, 18 Apr 2024 at 16:08, Chintan Vankar wrote:
>
>
>
> >
On 19/04/24 17:04, Sughosh Ganu wrote:
On Fri, 19 Apr 2024 at 16:04, Chintan Vankar wrote:
On 18/04/24 17:30, Sughosh Ganu wrote:
On Thu, 18 Apr 2024 at 16:08, Chintan Vankar wrote:
On 17/04/24 21:34, Tom Rini wrote:
On Wed, Apr 17, 2024 at 05:48:31PM +0530, Sughosh Ganu wrote:
hi
Hi Neil,
On 18/04/2024 23:47, Neil Armstrong wrote:
> Enable the GENI I2C driver in the default Qualcomm defconfig.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Caleb Connolly
> ---
> configs/qcom_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/configs/qcom_defconfig b/c
Hi Neil,
On 18/04/2024 23:47, Neil Armstrong wrote:
> Add Support for the Qualcomm Generic Interface (GENI) I2C interface
> found on newer Qualcomm SoCs.
\o/
>
> The Generic Interface (GENI) is a firmware based Qualcomm Universal
> Peripherals (QUP) Serial Engine (SE) Wrapper which can support m
%s/arguemnts/arguments/
Signed-off-by: Heinrich Schuchardt
---
include/event.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/event.h b/include/event.h
index a8f046da3c3..fb353ad623e 100644
--- a/include/event.h
+++ b/include/event.h
@@ -316,7 +316,7 @@ static inline
%s/arguemnts/arguemnts/
Signed-off-by: Heinrich Schuchardt
---
tools/buildman/test.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/buildman/test.py b/tools/buildman/test.py
index bdd3d84158a..f92add7a7c5 100644
--- a/tools/buildman/test.py
+++ b/tools/buildman/test.p
On Fri, 19 Apr 2024 at 16:04, Chintan Vankar wrote:
>
>
>
> On 18/04/24 17:30, Sughosh Ganu wrote:
> > On Thu, 18 Apr 2024 at 16:08, Chintan Vankar wrote:
> >>
> >>
> >>
> >> On 17/04/24 21:34, Tom Rini wrote:
> >>> On Wed, Apr 17, 2024 at 05:48:31PM +0530, Sughosh Ganu wrote:
> hi Chintan,
Hello Tom! This patch set is hanging in patchwork for 3 month
without any comments. If no one has anything to say, may you
pick it into master?
Best regards,
Svyatoslav R.
вт, 23 січ. 2024 р. о 19:17 Svyatoslav Ryhel пише:
>
> T114 is not that different from T30 and all T30 drivers will work
> o
Hello Tom! This patch set is hanging in patchwork for 3 month
without any comments. If no one has anything to say, may you
pick it into master?
Best regards,
Svyatoslav R.
ср, 31 січ. 2024 р. о 08:57 Svyatoslav Ryhel пише:
>
> The current patch set improves the logic of existing panels and
> bri
Kojima-san
Apologies but for some reason we failed to pull this patch
In meantime some parts of the bootefi.c code -- specifically theinitrd
cleanup, have been moved to efi_helper.c
Any chance you can rebase this? If not I'll try to find some time to do it
/Ilias
On Mon, Dec 04, 2023 at 01:3
On 18/04/24 17:30, Sughosh Ganu wrote:
On Thu, 18 Apr 2024 at 16:08, Chintan Vankar wrote:
On 17/04/24 21:34, Tom Rini wrote:
On Wed, Apr 17, 2024 at 05:48:31PM +0530, Sughosh Ganu wrote:
hi Chintan,
On Wed, 17 Apr 2024 at 13:21, Chintan Vankar wrote:
On 16/04/24 22:30, Tom Rini w
EFI_CALL() invokes __efi_entry_check() which executes set_gd(efi_gd).
There is no need to execute set_gd(efi_gd) again via efi_restore_gd().
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c | 1 -
cmd/efidebug.c | 2 --
lib/efi_loader/efi_helper.c | 2 --
3 files c
Heinrich
Please ignore this, I missed that we already report that in
efi_set_blk_dev_to_system_partition()
Apologies for the noise
/Ilias
On Fri, Apr 19, 2024 at 12:45:45PM +0300, Ilias Apalodimas wrote:
> When we try to store EFI variables on a file, we need to use an ESP.
> if an ESP is not fou
don't call os_close with invalid file descriptor (2024-04-17
17:06:16 -0600)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-dfu.git
tags/u-boot-dfu-20240419
for you to fetch changes up to b2acf59baf917c3b4002c1b2094ddb46c03ab02e:
fastboot: intro
When we try to store EFI variables on a file, we need to use an ESP.
if an ESP is not found, variables will change in memory, but U-Boot
won't be able to restore them across reboots.
Adjust the error message so users can understand what's going on
Signed-off-by: Ilias Apalodimas
---
Changes sinc
On 4/19/24 05:59, Marek Vasut wrote:
> In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be
> released from endless loop in BootROM only by populating TAMP BKPxR 4
> and 5 with magic and branch address and sending SGI0 interrupt from
> core 0 to core 1 twice. TAMP_SMCR BKP..PROT
> From: Janne Grunau via B4 Relay
> Date: Thu, 18 Apr 2024 21:00:29 +0200
>
> From: Janne Grunau
>
> The bootflow list is only seen briefly and is probably more confusing
> than helpful.
To be honest, I think that applies to all boards using BOOTSSTD_FILL.
Which probably means the -l should be
> From: Janne Grunau via B4 Relay
> Date: Thu, 18 Apr 2024 21:00:28 +0200
>
> From: Janne Grunau
>
> Use standard boot instead of the distro boot scripts. Use
> BOOTSTD_FULL instead of BOOTSTD_DEFAULTS for easier interactive use.
>
> Signed-off-by: Janne Grunau
Reviewed-by: Mark Kettenis
>
Hi Heinrich
On Fri, 19 Apr 2024 at 10:51, Heinrich Schuchardt
wrote:
>
> On 19.04.24 09:42, Ilias Apalodimas wrote:
> > When we try to store EFI variables on a file, we need to use an ESP.
> > if an ESP is not found, variables will change in memory, but U-Boot
> > won't be able to restore them ac
On 19.04.24 09:42, Ilias Apalodimas wrote:
When we try to store EFI variables on a file, we need to use an ESP.
if an ESP is not found, variables will change in memory, but U-Boot
won't be able to restore them across reboots.
Adjust the error message so users can understand what's going on
Sign
On 4/17/24 09:45, Heinrich Schuchardt wrote:
> On 17.04.24 09:25, Patrick DELAUNAY wrote:
>> Hi,
>>
>> On 3/8/24 11:12, Patrice Chotard wrote:
>>> Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory")
>>> memory region above ram_top is tagged in EFI memory map as
>>> EFI_BOOT_SE
When we try to store EFI variables on a file, we need to use an ESP.
if an ESP is not found, variables will change in memory, but U-Boot
won't be able to restore them across reboots.
Adjust the error message so users can understand what's going on
Signed-off-by: Ilias Apalodimas
---
lib/efi_loa
On 19.04.24 08:55, Sughosh Ganu wrote:
The UEFI capsule can now be generated by specifying the capsule
parameters through a config file. Highlight these changes in the
documentation.
Signed-off-by: Sughosh Ganu
---
doc/develop/uefi/uefi.rst | 70 +++
1 fil
On 19.04.24 08:55, Sughosh Ganu wrote:
Add support for specifying the parameters needed for capsule
generation through a config file, instead of passing them through
command-line. Parameters for more than a single capsule file can be
specified, resulting in generation of multiple capsules through
101 - 175 of 175 matches
Mail list logo
