gt; > > [1]
> > > > https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf
> > > >
> > > > Signed-off-by: Tim Harvey
> > >
> > > Looks way cleaner, thanks.
> > >
> &
4, DeviceID 0x3205, RevisionID 0x01 [open]
> > - board with a reset gpio
> > u-boot=> tpm init && tpm info
> > tpm@1: TPM gpio reset should not be used on secure production devices
> > tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
> >
> > [1]
> > https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf
> >
> > Signed-off-by: Tim Harvey
>
> Looks way cleaner, thanks.
>
> Reviewed-by: Miquel Raynal
>
> Miquèl
nice. if needed
Signed-off-by: Jorge Ramirez-Ortiz
On 03/02/24 17:45:42, Yang Xiwen wrote:
> On 2/3/2024 4:32 PM, Jorge Ramirez-Ortiz, Gmail wrote:
> > On 03/02/24 07:54:22, Shawn Guo wrote:
> > > On Sat, Feb 3, 2024 at 5:44 AM Igor Opaniuk
> > > wrote:
> > > >
> > > > Add myself
On 03/02/24 07:54:22, Shawn Guo wrote:
> On Sat, Feb 3, 2024 at 5:44 AM Igor Opaniuk wrote:
> >
> > Add myself as co-maintainer for Poplar board, as I'm currently
> > working on it (re-testing releases, addressing issues etc).
> >
> > CC: Jorge Ramirez-Ortiz
Fix and document the Secure Channel Protocol03 emulator.
Fixes: 5a8783c80c39 ("drivers: tee: sandbox: SCP03 control emulator")
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Simon Glass
Reviewed-by: Ilias Apalodimas
---
drivers/tee/sandbox.c | 15 +++
1 file c
Fix and document the Secure Channel Protocol03 emulator.
Fixes: 5a8783c80c39 ("drivers: tee: sandbox: SCP03 control emulator")
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/tee/sandbox.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/tee/s
sorry i am out of the office for a couple of days but that commit looks
horrible. not sure what happened there.
i'll propose something before thursday.
> On 2 Apr 2023, at 04:41, Simon Glass wrote:
>
> Hi Heinrich,
>
>> On Sat, 1 Apr 2023 at 20:58, Heinrich Schuchardt <
>> heinrich.schucha.
Fix AUTH_BOOT message identifier (s/IMIAGE/IMAGE)
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Oleksandr Suvorov
Acked-by: Andrew Davis
---
drivers/firmware/ti_sci.c | 2 +-
drivers/firmware/ti_sci.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware
On 10/01/23, Andrew Davis wrote:
> On 1/10/23 6:30 AM, Jorge Ramirez-Ortiz wrote:
> > Fix AUTH_BOOT message identifier (s/IMIAGE/IMAGE)
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
>
> Looks like this typo got copy/pasted over to ATF also[0]..
> I&#
Fix AUTH_BOOT message identifier (s/IMIAGE/IMAGE)
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/firmware/ti_sci.c | 2 +-
drivers/firmware/ti_sci.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 727e090e8a
On 14/09/22, Tom Rini wrote:
> On Tue, Aug 30, 2022 at 09:56:45PM +0200, Jorge Ramirez-Ortiz wrote:
>
> > Early instantiation of this I2C device would lock up when being
> > probed.
> >
> > https://www.nxp.com/docs/en/errata/SE050_Erratasheet.pdf
> > 3.2.2
ontroller itself is already
> > sending automatically a STOP when a NACK is generated.
> >
> > Thanks to Jorge Ramirez-Ortiz for diagnosing and proposing a first
> > fix for this. [1]
> >
> > [1]
> > https://lore.kernel.org/u-boot/20220815145211.31342-2-jo.
lots
> > > of debug messages), ending up send 2 STOP (one automatically by the
> > > controller and a 2nd one at the end of the stm32_i2c_message_xfer
> > > function).
> > >
> > > Thanks to Jorge Ramirez-Ortiz for diagnosing and proposing a first
>
the stm32_i2c_message_xfer
> > function).
> >
Cmon no need to thank me, that is kind of excessive :)
Just the sign-off or codevelop tags for reference
if you can wait before merging I will test the series before monday
thanks
Jorge
> > Thanks to Jorge Ramirez-Ortiz for diagnosin
On 08/09/22, Alain Volmat wrote:
> Current function stm32_i2c_message_xfer is sending a STOP
> whatever the result of the transaction is. This can cause issues
> such as making the bus busy since the controller itself is already
> sending automatically a STOP when a NACK is generated. This can
>
On 06/09/22, Patrick DELAUNAY wrote:
> Hi,
>
> On 9/5/22 19:33, Jorge Ramirez-Ortiz wrote:
> > Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI
> > from executing.
> >
> > The side effect observed are I2C devices no longer being
> > ac
s dependency on
CONFIG_TFABOOT")
Signed-off-by: Jorge Ramirez-Ortiz
---
configs/stm32mp13_defconfig | 1 -
configs/stm32mp15_defconfig | 1 -
configs/stm32mp15_trusted_defconfig | 1 -
3 files changed, 3 deletions(-)
diff --git a/configs/stm32mp13
On 30/08/22, Jorge Ramirez-Ortiz wrote:
> Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI
> from executing.
>
> The side effect observed are I2C devices no longer being
> accessible from U-boot after a soft reset.
I think this PR should get a bit more of attention.
Th
Signed-off-by: Jorge Ramirez-Ortiz
Acked-by: Oleksandr Suvorov
---
v5: address Kconfig issue with select (remove)
v4: address build issue when feature not enabled
v3,2,1: no changes (were part of a patchset)
drivers/tee/optee/Kconfig | 13
drivers/tee/optee/i2c.c | 44
Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI
from executing.
The side effect observed are I2C devices no longer being
accessible from U-boot after a soft reset.
Signed-off-by: Jorge Ramirez-Ortiz
---
configs/stm32mp13_defconfig | 1 -
configs/stm32mp15_defconfig | 1
Signed-off-by: Jorge Ramirez-Ortiz
Acked-by: Oleksandr Suvorov
---
drivers/tee/optee/Kconfig | 14 +
drivers/tee/optee/i2c.c | 44 +++
2 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee
Bits should be set to 0, not 1.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Patrice Chotard
---
drivers/i2c/stm32f7_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index bf2a6c9b4b..3a727e68ac 100644
--- a
Signed-off-by: Jorge Ramirez-Ortiz
Acked-by: Oleksandr Suvorov
---
drivers/tee/optee/Kconfig | 14 +
drivers/tee/optee/i2c.c | 44 +++
2 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee
On 16/08/22, Oleksandr Suvorov wrote:
> Hi Jorge,
>
> On Tue, Aug 16, 2022 at 2:28 PM Jorge Ramirez-Ortiz
> wrote:
> >
> > Early instantiation of this I2C device would lock up when being
> > probed.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
>
>
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/tee/optee/Kconfig | 14 +
drivers/tee/optee/i2c.c | 44 +++
2 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
index d03028070b
Early instantiation of this I2C device would lock up when being
probed.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/tee/optee/Kconfig | 14 +
drivers/tee/optee/i2c.c | 44 +++
2 files changed, 54 insertions(+), 4 deletions(-)
diff --git a
Sending the stop condition without waiting for transfer complete
has been found to lock the bus (BUSY) when NACKF is raised.
Tested accessing the NXP SE05X I2C device.
https://www.nxp.com/docs/en/application-note/AN12399.pdf
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Oleksandr Suvorov
Bits should be set to 0, not 1.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/i2c/stm32f7_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index bf2a6c9b4b..3a727e68ac 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b
Sending the stop condition without waiting for TC has been
found to lock the bus.
Tested accessing the the NXP SE05X I2C device.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/i2c/stm32f7_i2c.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c
Bits should be set to 0, not 1.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/i2c/stm32f7_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index bf2a6c9b4b..3a727e68ac 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b
On 16/04/22, Jorge Ramirez-Ortiz wrote:
> The call to xilinx_pm_request requires an array of a larger size.
>
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> drivers/soc/soc_xilinx_versal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/s
The call to xilinx_pm_request requires an array of a larger size.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/soc/soc_xilinx_versal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/soc_xilinx_versal.c b/drivers/soc/soc_xilinx_versal.c
index f8bcd9ab40
The call to xilinx_pm_request requires an array of a larger size.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/soc/soc_xilinx_versal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/soc_xilinx_versal.c b/drivers/soc/soc_xilinx_versal.c
index f8bcd9ab40
On 24/03/22, Michal Simek wrote:
>
>
> On 3/23/22 15:04, Jorge Ramirez-Ortiz wrote:
> > From 528b3117a36b7b4eea1839afbea7191d60638b0c Mon Sep 17 00:00:00 2001
> > From: Jorge Ramirez-Ortiz
> > Date: Wed, 23 Mar 2022 14:41:15 +0100
> > Subject: [PATCH] arm64:
On 23/03/22, Jorge Ramirez-Ortiz wrote:
> From 528b3117a36b7b4eea1839afbea7191d60638b0c Mon Sep 17 00:00:00 2001
> From: Jorge Ramirez-Ortiz
> Date: Wed, 23 Mar 2022 14:41:15 +0100
> Subject: [PATCH] arm64: zynqmp: enable the PMUFW watchdog
um, seems my sendpatch script is a bit off
>From 528b3117a36b7b4eea1839afbea7191d60638b0c Mon Sep 17 00:00:00 2001
From: Jorge Ramirez-Ortiz
Date: Wed, 23 Mar 2022 14:41:15 +0100
Subject: [PATCH] arm64: zynqmp: enable the PMUFW watchdog
If the PMUFW was built with support for the CSU watchdog we must let the
firmware know that it can
On 15/02/22, Michal Simek wrote:
> Hi,
>
> On 2/14/22 21:10, Ricardo Salveti wrote:
> > Hi Michal,
> >
> > This is a bit similar to the issue raised on iMX8-based targets a few
> > days ago, which is forcing the environment location based on the boot
> > mode and not allowing the user to use a di
ian,
> >
> > On Wed, Jan 19, 2022 at 7:23 PM Jorge Ramirez-Ortiz, Foundries
> > wrote:
> > > On 19/01/22, Jorge Ramirez-Ortiz, Foundries wrote:
> > > > On 19/01/22, Jorge Ramirez-Ortiz, Foundries wrote:
> > > > > On 19/01/22, Adrian Fiergo
On 04/02/22, Michal Simek wrote:
> Hi,
>
> pá 4. 2. 2022 v 8:47 odesílatel Jorge Ramirez-Ortiz, Foundries
> napsal:
> >
> > On 13/10/21, Jorge Ramirez-Ortiz wrote:
> > > Output the secure boot configuration to the console.
> >
> >
> > Hi, M
On 13/10/21, Jorge Ramirez-Ortiz wrote:
> Output the secure boot configuration to the console.
Hi, Michal
was there any reason for not merging this patch?
thanks
Jorge
>
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
>
> v2:
>Michal review 12 Aug 2021
> prin
On 19/01/22, Jorge Ramirez-Ortiz, Foundries wrote:
> On 19/01/22, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 19/01/22, Adrian Fiergolski wrote:
> > > Hi Jorge,
> >
> > hi Adrian,
> >
> > >
> > > Have you succeeded to enable secure bo
On 19/01/22, Jorge Ramirez-Ortiz, Foundries wrote:
> On 19/01/22, Adrian Fiergolski wrote:
> > Hi Jorge,
>
> hi Adrian,
>
> >
> > Have you succeeded to enable secure boot on ZynqMP with SPL (not Xilinx's
> > FSBL)? Is it documented somewhe
On 19/01/22, Adrian Fiergolski wrote:
> Hi Jorge,
hi Adrian,
>
> Have you succeeded to enable secure boot on ZynqMP with SPL (not Xilinx's
> FSBL)? Is it documented somewhere? Any configuration files/yocto recipes?
somewhere there:
https://github.com/foundriesio/meta-lmp
> Have you managed to
Instead of ignoring the mandatory fpga compatible string, let the
different implementations decide how to handle it
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Simon Glass
---
RFC v1->v2:
added function comment
cmd/fpga.c | 8
common/image.c |
On 14/10/21, Simon Glass wrote:
> Hi Jorge,
>
> On Tue, 5 Oct 2021 at 05:13, Jorge Ramirez-Ortiz wrote:
> >
> > Instead of ignoring the mandatory fpga compatible string, let the
> > different implementations decide how to handle it
> >
> > Signed-off-by
On 14/10/21, Michal Simek wrote:
>
>
> On 10/13/21 15:48, Jorge Ramirez-Ortiz wrote:
> > When boot.bin is configured for secure boot the CSU will disable the
> > JTAG interface on all cases.
> >
> > Some boards might rely on this interface for flashing to QSP
Output the secure boot configuration to the console.
Signed-off-by: Jorge Ramirez-Ortiz
---
v2:
Michal review 12 Aug 2021
print information on SPL and UBOOT
improve the print command
add macros to mask the status
arch/arm/mach-zynqmp/include/mach/hardware.h | 6
On 13/10/21, Michal Simek wrote:
>
>
> On 10/13/21 13:40, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 13/10/21, Michal Simek wrote:
> > >
> > >
> > > On 10/13/21 10:25, Jorge Ramirez-Ortiz wrote:
> > > > When boot.bin is configured
-off-by: Jorge Ramirez-Ortiz
---
v3: delete unvalid removal of empty line
arch/arm/mach-zynqmp/Kconfig | 8 +
arch/arm/mach-zynqmp/include/mach/hardware.h | 31 +++-
board/xilinx/zynqmp/zynqmp.c | 19
3 files changed, 51 insertions
On 13/10/21, Michal Simek wrote:
>
>
> On 10/13/21 10:25, Jorge Ramirez-Ortiz wrote:
> > When boot.bin is configured for secure boot the CSU will disable the
> > JTAG interface on all cases.
> >
> > Some boards might rely on this interface for flashing to QSP
-off-by: Jorge Ramirez-Ortiz
---
arch/arm/mach-zynqmp/Kconfig | 8 +
arch/arm/mach-zynqmp/include/mach/hardware.h | 31 +++-
board/xilinx/zynqmp/zynqmp.c | 20 -
3 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/arch/arm
-off-by: Jorge Ramirez-Ortiz
---
arch/arm/mach-zynqmp/Kconfig | 8 +
arch/arm/mach-zynqmp/include/mach/hardware.h | 31 +++-
board/xilinx/zynqmp/zynqmp.c | 20 -
3 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/arch/arm
On 05/10/21, Michal Simek wrote:
>
>
> On 10/5/21 1:13 PM, Jorge Ramirez-Ortiz wrote:
> > Add new compatible string u-boot,zynqmp-fpga-ddrauth to handle this
> > use case.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> >
Add new compatible string u-boot,zynqmp-fpga-ddrauth to handle this
use case.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/fpga/xilinx.c | 29 +
drivers/fpga/zynqmppl.c | 4 ++--
include/xilinx.h| 2 +-
3 files changed, 28 insertions(+), 7 deletions
Instead of ignoring the mandatory fpga compatible string, let the
different implementations decide how to handle it
Signed-off-by: Jorge Ramirez-Ortiz
---
cmd/fpga.c | 8
common/image.c | 4 ++--
common/spl/spl_fit.c | 4 +---
drivers/fpga/fpga.c | 11
Confirm the secure boot configuration on the console.
Signed-off-by: Jorge Ramirez-Ortiz
---
arch/arm/mach-zynqmp/include/mach/hardware.h | 3 ++-
board/xilinx/zynqmp/zynqmp.c | 16 +++-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach
On 05/10/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 04/10/21, Alex G. wrote:
> > On 10/4/21 3:32 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > Hello,
> > >
>
> hi Alex,
>
> > > We are enabling secure boot on Zynqmp with SPL.
> > >
&
On 04/10/21, Alex G. wrote:
> On 10/4/21 3:32 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > Hello,
> >
hi Alex,
> > We are enabling secure boot on Zynqmp with SPL.
> >
> > The issue however is that during secure boot, the bootrom not only
> > validates the
Hello,
We are enabling secure boot on Zynqmp with SPL.
The issue however is that during secure boot, the bootrom not only
validates the first loader (SPL and PMUFW combo) but it will also
expect a signed bitstream during load(FPGA).
Since currently the SPL load of an FPGA image from FIT does not
On 10/09/21, Michal Simek wrote:
> Hi,
>
> On 9/8/21 5:39 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > Hi Michal
> >
> > The *linux* cadence_wdt driver for the watchdog enables the clock that
> > controls its behaviour. However this is not done in the U-boot
&g
Hi Michal
The *linux* cadence_wdt driver for the watchdog enables the clock that
controls its behaviour. However this is not done in the U-boot
driver; I dont think it is safe to assume that the clock will be active.
do you know why is the driver making that assumption? and how to
enable the cloc
On 12/08/21, Michal Simek wrote:
>
>
> On 7/22/21 1:19 PM, Jorge Ramirez-Ortiz wrote:
> > Confirm the secure boot configuration on the console.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
> > arch/arm/mach-zynqmp/include/mach/hardware.h |
On 12/08/21, Michal Simek wrote:
>
>
> On 7/16/21 7:16 PM, Jorge Ramirez-Ortiz wrote:
> > As a security feature, if boot.bin was configured for secure boot the
> > CSU will disable the JTAG interface on all cases.
> >
> > Some boards might rely on this interf
On 16/07/21, Jorge Ramirez-Ortiz wrote:
reminder
> As a security feature, if boot.bin was configured for secure boot the
> CSU will disable the JTAG interface on all cases.
>
> Some boards might rely on this interface for flashing to QSPI in which
> case those systems might
On 22/07/21, Jorge Ramirez-Ortiz wrote:
reminder
> Confirm the secure boot configuration on the console.
>
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> arch/arm/mach-zynqmp/include/mach/hardware.h | 3 ++-
> board/xilinx/zynqmp/zynqmp.c | 16 +
Confirm the secure boot configuration on the console.
Signed-off-by: Jorge Ramirez-Ortiz
---
arch/arm/mach-zynqmp/include/mach/hardware.h | 3 ++-
board/xilinx/zynqmp/zynqmp.c | 16 +++-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach
- if the CSU allows for it.
Signed-off-by: Jorge Ramirez-Ortiz
---
arch/arm/mach-zynqmp/Kconfig | 9
arch/arm/mach-zynqmp/include/mach/hardware.h | 23 +--
board/xilinx/zynqmp/zynqmp.c | 24
3 files changed, 49
On 15/07/21, Jorge Ramirez-Ortiz, Gmail wrote:
> On 06/07/21, Ramon Fried wrote:
> > On Mon, Jul 5, 2021 at 3:19 PM Stephan Gerhold wrote:
> > >
> > > According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE"
> > > and uninitialized
On 06/07/21, Ramon Fried wrote:
> On Mon, Jul 5, 2021 at 3:19 PM Stephan Gerhold wrote:
> >
> > According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE"
> > and uninitialized before relocation. Also, it overlaps with the
> > appended DTB before relocation, so writing data into a varia
On 14/07/21, Michal Simek wrote:
> Hi,
>
> On 7/14/21 9:37 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> >> On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> >>> On 13/07/21, Jorge Ramirez-Ortiz, Foundri
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> > > On 13/07/21, Michal Simek wrote:
> > > >
> > > >
> > > > On 7/13/21 11:25 AM,
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 13/07/21, Michal Simek wrote:
> > >
> > >
> > > On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > > On 13/07/21, Jorge R
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 13/07/21, Michal Simek wrote:
> >
> >
> > On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> > >> On 13/07/21, Michal Simek wrote
On 13/07/21, Michal Simek wrote:
>
>
> On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> >> On 13/07/21, Michal Simek wrote:
> >>> Hi,
> >>>
> >>> On 7/12/21 7:4
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 13/07/21, Michal Simek wrote:
> > Hi,
> >
> > On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > hi Michal,
> > >
> > > Would you have some sample/reference code to generate a
On 13/07/21, Michal Simek wrote:
> Hi,
>
> On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > hi Michal,
> >
> > Would you have some sample/reference code to generate a SPL boot image
> > using zynqmpbif instead of zynqmpimage? I cant find any documen
hi Michal,
Would you have some sample/reference code to generate a SPL boot image
using zynqmpbif instead of zynqmpimage? I cant find any documentation
and I see no option to enable it (I was expecting to find some config
in Makefile.spl but I see none).
What is the expected way of building these
On 22/06/21, Michal Simek wrote:
> Hi,
>
> On 6/21/21 7:27 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > hi Michal,
> >
> > Is secure boot supported using SPL? or is there a plan for it (maybe a
> > branch somewhere that I can work from and contribute to?).
>
hi Michal,
Is secure boot supported using SPL? or is there a plan for it (maybe a
branch somewhere that I can work from and contribute to?).
ATM looking into how to write the key sha to the fuses without Vivado.
thanks for any information that you might have,
jorge
initialize
SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex)
SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex)
Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action.
Signed-off-by: Jorge Ramirez-Ortiz
---
v2
On 11/06/21, Michal Simek wrote:
> Hi,
>
> On 6/11/21 12:09 PM, Jorge Ramirez-Ortiz wrote:
> > Use the ZDMA channel 0 to initialize the DRAM banks.
>
> A little bit short. Can you please extend it?
ok
>
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
>
Use the ZDMA channel 0 to initialize the DRAM banks.
Signed-off-by: Jorge Ramirez-Ortiz
---
arch/arm/mach-zynqmp/Kconfig| 35 +++
arch/arm/mach-zynqmp/Makefile | 1 +
arch/arm/mach-zynqmp/ecc_spl_init.c | 139
arch/arm/mach-zynqmp/spl.c
On 08/06/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 08/06/21, Michal Simek wrote:
> > Hi,
> >
> > On 6/7/21 8:41 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > On 07/06/21, Jorge Ramirez-Ortiz, Foundries wrote:
> > >> hi Michal
> > >>
On 08/06/21, Michal Simek wrote:
> Hi,
>
> On 6/7/21 8:41 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 07/06/21, Jorge Ramirez-Ortiz, Foundries wrote:
> >> hi Michal
> >>
> >> um, when we exchanged emails about enabling ECC support for MPSoC, I
&
On 07/06/21, Jorge Ramirez-Ortiz, Foundries wrote:
> hi Michal
>
> um, when we exchanged emails about enabling ECC support for MPSoC, I
> left with the understanding that there already was a DMA driver
> available in u-boot that I could use to initialize the memory.
>
> do
hi Michal
um, when we exchanged emails about enabling ECC support for MPSoC, I
left with the understanding that there already was a DMA driver
available in u-boot that I could use to initialize the memory.
do you have something in the works or will I have to write such a
driver? compatible would
Use the more generic reset-gpios property name.
Signed-off-by: Jorge Ramirez-Ortiz
Acked-by: Michal Simek
---
v5: added Acked-by: Michal Simek
.../tpm2/tis-tpm2-spi.txt | 3 ++-
drivers/tpm/tpm2_tis_spi.c| 23 ---
2 files changed, 17
Use the more generic reset-gpios property name.
Signed-off-by: Jorge Ramirez-Ortiz
---
v4: s/will be deprecated/is deprecated
.../tpm2/tis-tpm2-spi.txt | 3 ++-
drivers/tpm/tpm2_tis_spi.c| 23 ---
2 files changed, 17 insertions(+), 9
Use the more generic reset-gpios property name.
Signed-off-by: Jorge Ramirez-Ortiz
---
v3: maintained the legacy property in the docs
.../tpm2/tis-tpm2-spi.txt | 3 ++-
drivers/tpm/tpm2_tis_spi.c| 23 ---
2 files changed, 17 insertions
On 01/06/21, Michal Simek wrote:
>
>
> On 6/1/21 9:35 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 01/06/21, Michal Simek wrote:
> >>
> >>
> >> On 6/1/21 8:09 AM, Jorge Ramirez-Ortiz wrote:
> >>> Use the more generic reset-gpios proper
On 01/06/21, Michal Simek wrote:
>
>
> On 6/1/21 8:09 AM, Jorge Ramirez-Ortiz wrote:
> > Use the more generic reset-gpios propery name.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
> > v2: kept gpio-reset as legacy
> >
> >
Use the more generic reset-gpios propery name.
Signed-off-by: Jorge Ramirez-Ortiz
---
v2: kept gpio-reset as legacy
.../tpm2/tis-tpm2-spi.txt | 2 +-
drivers/tpm/tpm2_tis_spi.c| 21 ---
2 files changed, 14 insertions(+), 9 deletions
On 31/05/21, Michal Simek wrote:
>
>
> On 5/28/21 6:18 PM, Bruno Thomsen wrote:
> > Den tor. 27. maj 2021 kl. 09.15 skrev Michal Simek
> > :
> >>
> >>
> >>
> >> On 5/26/21 9:57 PM, Jorge Ramirez-Ortiz wrote:
> >>> Use the mo
On 27/05/21, Simon Glass wrote:
> On Wed, 26 May 2021 at 13:57, Jorge Ramirez-Ortiz wrote:
> >
> > Use the more generic reset-gpios propery name.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
> > doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
Use the more generic reset-gpios propery name.
Signed-off-by: Jorge Ramirez-Ortiz
---
doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt | 2 +-
drivers/tpm/tpm2_tis_spi.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/device-tree-bindings/tpm2/tis
On 14/05/21, Michal Simek wrote:
>
>
> On 5/14/21 9:38 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 13/05/21, Michal Simek wrote:
> >> Hi,
> >>
> >> On 5/13/21 9:24 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> >>> On 13/05/21, Michal Sim
On 13/05/21, Michal Simek wrote:
> Hi,
>
> On 5/13/21 9:24 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 13/05/21, Michal Simek wrote:
> >> Hi Jorge,
> >>
> >> On 5/12/21 11:21 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> >>> Hi Micha
On 13/05/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 13/05/21, Michal Simek wrote:
> > Hi Jorge,
> >
> > On 5/12/21 11:21 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > Hi Michal
> > >
> > > We are doing some work on an MPSoC UZ3EG platform
On 13/05/21, Michal Simek wrote:
> Hi Jorge,
>
> On 5/12/21 11:21 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > Hi Michal
> >
> > We are doing some work on an MPSoC UZ3EG platform part of which
> > requires us to replace FSBL with SPL.
>
> Just f
Hi Michal
We are doing some work on an MPSoC UZ3EG platform part of which
requires us to replace FSBL with SPL.
It seems the actual boot process is becoming an issue on these SoCs;
currently, 1) we embed the PMU firmware on SPL so the bootrom can
extract it and program it; 2) then SPL configures
1 - 100 of 316 matches
Mail list logo
