From: Jan Kiszka
Otherwise the updated image will end up in the temporary folder that is
purged after completion.
Signed-off-by: Jan Kiszka
---
tools/binman/control.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/binman/control.py b/tools/binman/control.py
index 8b5085152a
From: Jan Kiszka
Fix some copy artifacts.
Signed-off-by: Jan Kiszka
---
tools/binman/cmdline.py | 4 ++--
tools/binman/control.py | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/binman/cmdline.py b/tools/binman/cmdline.py
index d6156df408..d053d1be90 100644
On 08.11.21 16:28, Roman Kopytin wrote:
> Having to use the -K option to mkimage to populate U-Boot's .dtb with the
> public key while signing the kernel FIT image is often a little
> awkward. In particular, when using a meta-build system such as
> bitbake/Yocto, having the tasks of the kernel and
From: Jan Kiszka
Fix some copy artifacts:
Signed-off-by: Jan Kiszka
---
tools/binman/cmdline.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/binman/cmdline.py b/tools/binman/cmdline.py
index d6156df408..e1a4cea961 100644
--- a/tools/binman/cmdline.py
+++ b
On 10.11.21 20:36, Simon Glass wrote:
> Hi Jan,
>
> On Wed, 10 Nov 2021 at 09:49, Jan Kiszka wrote:
>>
>> On 10.11.21 17:31, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Wed, 10 Nov 2021 at 00:20, Jan Kiszka wrote:
>>>>
>>>> O
On 10.11.21 20:36, Simon Glass wrote:
> Hi Jan,
>
> On Wed, 10 Nov 2021 at 09:48, Jan Kiszka wrote:
>>
>> On 10.11.21 17:31, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Tue, 9 Nov 2021 at 23:44, Jan Kiszka wrote:
>>>>
>>>> O
On 10.11.21 08:20, Jan Kiszka wrote:
> On 10.11.21 07:55, Jan Kiszka wrote:
>> On 10.11.21 01:58, Simon Glass wrote:
>>> Hi,
>>>
>>> On Tue, 9 Nov 2021 at 02:17, Jan Kiszka wrote:
>>>>
>>>> On 08.11.21 16:28, Roman Kopytin wrote:
>&
On 10.11.21 09:26, Roman Kopytin wrote:
> Could you please provide good example with needed style for helper?
> In tools I saw a lot of programs w/o help.
>
Have a look at binman to see this full-blown - not a completely fair
comparison as it benefits from Python argparse.
Jan
--
Siemens AG,
On 10.11.21 18:29, François Ozog wrote:
>
> Hi Jan
>
> Le mer. 10 nov. 2021 à 17:48, Jan Kiszka <mailto:jan.kis...@siemens.com>> a écrit :
>
> On 10.11.21 17:31, Simon Glass wrote:
> > Hi Jan,
> >
> > On Tue, 9 Nov 2021 at 23:44, J
On 10.11.21 17:31, Simon Glass wrote:
> Hi Jan,
>
> On Wed, 10 Nov 2021 at 00:20, Jan Kiszka wrote:
>>
>> On 10.11.21 07:55, Jan Kiszka wrote:
>>> On 10.11.21 01:58, Simon Glass wrote:
>>>> Hi,
>>>>
>>>> On Tue, 9 Nov 2021 at 02:1
On 10.11.21 17:31, Simon Glass wrote:
> Hi Jan,
>
> On Tue, 9 Nov 2021 at 23:44, Jan Kiszka wrote:
>>
>> On 10.11.21 01:58, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Tue, 9 Nov 2021 at 03:07, Jan Kiszka wrote:
>>>>
>>>&
[no top-posting please]
On 10.11.21 08:03, Roman Kopytin wrote:
> Hi, Simon
> I have question about:
> Some of these are not optional so should not have [] around them.
>
> As I see we have defaults for:
> static const char *algo_name = "sha1,rsa2048"; /* -a */
> static const char *keydir =
On 08.11.21 16:28, Roman Kopytin wrote:
> Having to use the -K option to mkimage to populate U-Boot's .dtb with the
> public key while signing the kernel FIT image is often a little
> awkward. In particular, when using a meta-build system such as
> bitbake/Yocto, having the tasks of the kernel and
On 10.11.21 07:55, Jan Kiszka wrote:
> On 10.11.21 01:58, Simon Glass wrote:
>> Hi,
>>
>> On Tue, 9 Nov 2021 at 02:17, Jan Kiszka wrote:
>>>
>>> On 08.11.21 16:28, Roman Kopytin wrote:
>>>> In order to reduce the coupling between building the k
On 10.11.21 01:58, Simon Glass wrote:
> Hi,
>
> On Tue, 9 Nov 2021 at 02:17, Jan Kiszka wrote:
>>
>> On 08.11.21 16:28, Roman Kopytin wrote:
>>> In order to reduce the coupling between building the kernel and
>>> U-Boot, I'd like a tool that can add a
On 10.11.21 01:58, Simon Glass wrote:
> Hi Jan,
>
> On Tue, 9 Nov 2021 at 03:07, Jan Kiszka wrote:
>>
>> On 09.11.21 10:37, Roman Kopytin wrote:
>>> Can we have discussion with code lines? For me it is not very clear,
>>> because it isn't my
On 08.11.21 16:28, Roman Kopytin wrote:
> Having to use the -K option to mkimage to populate U-Boot's .dtb with the
> public key while signing the kernel FIT image is often a little
> awkward. In particular, when using a meta-build system such as
> bitbake/Yocto, having the tasks of the kernel and
On 09.11.21 14:16, François Ozog wrote:
> Hi Jan
>
> On Tue, 9 Nov 2021 at 13:58, Jan Kiszka <mailto:jan.kis...@siemens.com>> wrote:
>
> On 09.11.21 13:43, François Ozog wrote:
> > Hi
> >
> > as we are in design discussions, I w
e currently massaging board/siemens/iot2050 to close
its static chain of trust between SPL and U-Boot main, using software
means (vendor means do not work because FSBL key != TF-A/TEE/U-Boot key).
Jan
>
> On Tue, 9 Nov 2021 at 11:07, Jan Kiszka <mailto:jan.kis...@siemens.com>&g
On 09.11.21 10:37, Roman Kopytin wrote:
> Can we have discussion with code lines? For me it is not very clear, because
> it isn't my code.
>
Please do not top-post.
> -Original Message-----
> From: Jan Kiszka
> Sent: Tuesday, November 9, 2021 12:17 PM
> To: R
On 08.11.21 16:28, Roman Kopytin wrote:
> In order to reduce the coupling between building the kernel and
> U-Boot, I'd like a tool that can add a public key to U-Boot's dtb
> without simultaneously signing a FIT image. That tool doesn't seem to
> exist, so I stole the necessary pieces from
On 05.11.21 13:42, Jan Kiszka wrote:
> On 05.11.21 11:28, Rasmus Villemoes wrote:
>> On 05/11/2021 11.16, Jan Kiszka wrote:
>>> Hi all,
>>>
>>> in order to use CONFIG_FIT_SIGNATURE and also
>>> CONFIG_SPL_FIT_SIGNATURE, a public key needs to be placed i
On 05.11.21 11:28, Rasmus Villemoes wrote:
> On 05/11/2021 11.16, Jan Kiszka wrote:
>> Hi all,
>>
>> in order to use CONFIG_FIT_SIGNATURE and also
>> CONFIG_SPL_FIT_SIGNATURE, a public key needs to be placed into the
>> control FDT. So far, I only found mkimage be
Hi all,
in order to use CONFIG_FIT_SIGNATURE and also
CONFIG_SPL_FIT_SIGNATURE, a public key needs to be placed into the
control FDT. So far, I only found mkimage being able to do that during
FIT image signing. That is fairly unhandy and often incompatible with
how firmware is built & signed vs.
From: Jan Kiszka
We need to filter out NET_ETH_START errors because we have to enable
networking in order to propagate the MAC addresses to the DT while there
is no network driver for the prueth in U-Boot yet.
Signed-off-by: Jan Kiszka
---
board/siemens/iot2050/board.c | 3 ++-
1 file changed
From: Jan Kiszka
This got lost while fixing up the condition in
board/siemens/iot2050/board.c
Fixes: b55881dd ("bootstage: Add SPL support")
Signed-off-by: Jan Kiszka
---
configs/iot2050_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configs/iot2050_defconfig
From: Jan Kiszka
Both U-Boot proper and SPL entries were using the same description.
Fixes: b55881dd ("bootstage: Add SPL support")
Signed-off-by: Jan Kiszka
---
common/Kconfig.boot | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/Kconfig.boot b/common/Kc
On 03.11.21 12:59, Jan Kiszka wrote:
> On 23.10.21 03:06, Marek Vasut wrote:
>> Allow usage of the bootstage facilities in SPL.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Simon Glass
>> ---
>> V2: Fix multiple misuses of BOOTSTAGE vs SHOW_BOOT_PROGRESS
>&
On 04.10.21 15:36, Jan Kiszka wrote:
> On 13.09.21 09:48, Jan Kiszka wrote:
>> Hi all,
>>
>> Chao, please no top-post on mailing list. Also check your mail client,
>> it seems to inject a lot of bogus newlines.
>>
>> On 08.09.21 06:55, chaochao
On 23.10.21 03:06, Marek Vasut wrote:
> Allow usage of the bootstage facilities in SPL.
>
> Signed-off-by: Marek Vasut
> Cc: Simon Glass
> ---
> V2: Fix multiple misuses of BOOTSTAGE vs SHOW_BOOT_PROGRESS
> ---
> arch/x86/cpu/cpu.c| 2 +-
> board/siemens/iot2050/board.c | 2 +-
>
On 15.10.21 19:06, Tim Harvey wrote:
> A grep for SERIAL_SUPPORT (which was renamed to SERIAL) shows all the
> boards in your master-next that got merged like mine that currently
> likely need fixups:
> $ git grep SERIAL_SUPPORT configs/
>
On 05.10.21 13:37, Tom Rini wrote:
> On Tue, Oct 05, 2021 at 12:04:49PM +0200, Jan Kiszka wrote:
>
>> From: Jan Kiszka
>>
>> Account for the changes done between merge proposal and the final merge.
>>
>> Signed-off-by: Jan Kiszka
>
> Ah, the
From: Jan Kiszka
This fixes the usage of the USB 3.0-capable port under U-Boot as USB
2.0-only port.
Original patch by Chao Zeng.
Signed-off-by: Jan Kiszka
---
.../k3-am65-iot2050-common-pg2-u-boot.dtsi| 27 +++
arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi | 4 ++-
2
This fixes the freshly merged IOT2050 board and also enables the usage
of the USB 3.0 port under U-Boot (as USB 2.0).
Jan
Jan Kiszka (2):
board: siemens: iot2050: Adjust to changes in DT and configuration
arm: dts: Update IOT2050 device tree files
.../k3-am65-iot2050-common-pg2-u-boot.dtsi
From: Jan Kiszka
Account for the changes done between merge proposal and the final merge.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi | 2 +-
configs/iot2050_defconfig | 6 --
include/configs/iot2050.h | 2 --
3
On 04.10.21 18:02, Tom Rini wrote:
> On Mon, Oct 04, 2021 at 05:54:46PM +0200, Jan Kiszka wrote:
>> On 04.10.21 01:34, Tom Rini wrote:
>>> On Sat, Sep 18, 2021 at 08:17:53AM +0200, Jan Kiszka wrote:
>>>
>>>> From: Jan Kiszka
>>>>
>>>&g
On 04.10.21 01:34, Tom Rini wrote:
> On Sat, Sep 18, 2021 at 08:17:53AM +0200, Jan Kiszka wrote:
>
>> From: Jan Kiszka
>>
>> This adds support for the IOT2050 Basic and Advanced devices. The Basic
>> used the dual-core AM6528 GP processor, the Advanced one the
On 13.09.21 09:48, Jan Kiszka wrote:
> Hi all,
>
> Chao, please no top-post on mailing list. Also check your mail client,
> it seems to inject a lot of bogus newlines.
>
> On 08.09.21 06:55, chaochao2021666 wrote:
>>
>>
>>
>> HI Jagan
>>
>>
&
On 03.10.21 20:40, Tom Rini wrote:
> On Sat, Sep 18, 2021 at 08:17:54AM +0200, Jan Kiszka wrote:
>
>> From: Jan Kiszka
>>
>> Add the DT entry for a watchdog based on RTI1. It requires additional
>> firmware on the MCU R5F cores to handle the expiry, e.g.
>> h
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. In case the R5F cluster is
in lock-step mode, also initialize the second core. The firmware
From: Jan Kiszka
This allows to use the watchdog in custom scripts but does not enforce
that the OS has to support it as well.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 25
configs/iot2050_defconfig| 6 +
tools
From: Jan Kiszka
Add the DT entry for a watchdog based on RTI1. It requires additional
firmware on the MCU R5F cores to handle the expiry, e.g.
https://github.com/siemens/k3-rti-wdt. As this firmware will also lock
the power domain to protect it against premature shutdown, mark it
shared
From: Jan Kiszka
Prepares for the addition of the IOT2050 board which is based on the TI
AM65x. The board comes in four variants, Basic and Advanced, each as
product generation 1 (SR1.0) and 2 (SR2.x), so there are separate dts
files needed. Furthermore, the SPL has its own device tree.
Based
From: Jan Kiszka
This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.
Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support
/siemens/meta-iot2050
Jan Kiszka (5):
arm: dts: Add IOT2050 device tree files
board: siemens: Add support for SIMATIC IOT2050 devices
arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry
watchdog: rti_wdt: Add support for loading firmware
iot2050: Enable watchdog support, but do not auto-st
On 13.09.21 17:36, Tom Rini wrote:
> On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote:
>> On 13.09.21 16:56, Tom Rini wrote:
>>> On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote:
>>>> On 13.09.21 14:34, Tom Rini wrote:
>>>>> On Mon,
On 13.09.21 16:56, Tom Rini wrote:
> On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote:
>> On 13.09.21 14:34, Tom Rini wrote:
>>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
>>>> On 11.09.21 02:10, Tom Rini wrote:
>>>>> On Tue,
On 13.09.21 14:34, Tom Rini wrote:
> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
>> On 11.09.21 02:10, Tom Rini wrote:
>>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
>>>
>>>> From: Jan Kiszka
>>>>
>>>
On 11.09.21 02:10, Tom Rini wrote:
> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
>
>> From: Jan Kiszka
>>
>> This allows to use the watchdog in custom scripts but does not enforce
>> that the OS has to support it as well.
>>
>> Signed-o
Hi all,
Chao, please no top-post on mailing list. Also check your mail client,
it seems to inject a lot of bogus newlines.
On 08.09.21 06:55, chaochao2021666 wrote:
>
>
>
> HI Jagan
>
>
>
> sorry for the delay response.
>
>
> And I have checked the maser. There is still a problem with
On 08.09.21 06:22, Nishanth Menon wrote:
> On 16:27-20210907, Tom Rini wrote:
>> On Tue, Sep 07, 2021 at 09:41:23PM +0200, Jan Kiszka wrote:
>>> On 02.09.21 08:36, Jan Kiszka wrote:
>>>> On 28.07.21 11:10, Jan Kiszka wrote:
>>>>> On 30.01.20 09:05, Roge
On 02.09.21 08:36, Jan Kiszka wrote:
> On 28.07.21 11:10, Jan Kiszka wrote:
>> On 30.01.20 09:05, Roger Quadros wrote:
>>> NB0 is bridge to SRAM and NB1 is bridge to DDR.
>>>
>>> To ensure that SRAM transfers are not stalled due to
>>> delays during
On 28.07.21 11:10, Jan Kiszka wrote:
> On 30.01.20 09:05, Roger Quadros wrote:
>> NB0 is bridge to SRAM and NB1 is bridge to DDR.
>>
>> To ensure that SRAM transfers are not stalled due to
>> delays during DDR refreshes, SRAM traffic should be higher
>> priori
From: Jan Kiszka
Prepares for the addition of the IOT2050 board which is based on the TI
AM65x. The board comes in two variants, Basic and Advanced, so there are
separate dts files. Furthermore, the SPL has its own device tree.
Based on original board support by Le Jin, Gao Nian and Chao Zeng
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. In case the R5F cluster is
in lock-step mode, also initialize the second core. The firmware
From: Jan Kiszka
This allows to use the watchdog in custom scripts but does not enforce
that the OS has to support it as well.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 16
configs/iot2050_defconfig| 6 ++
2 files
From: Jan Kiszka
Add the DT entry for a watchdog based on RTI1. It requires additional
firmware on the MCU R5F cores to handle the expiry, e.g.
https://github.com/siemens/k3-rti-wdt. As this firmware will also lock
the power domain to protect it against premature shutdown, mark it
shared
From: Jan Kiszka
This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.
Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support
AM65x silicon as well as with SR1.0 which
is used in the currently shipped IOT2050 devices.
A staging tree for complete IOT2050 support can be found at [1]. Full
image integration is available via [2].
Jan
[1] https://github.com/siemens/u-boot/commits/jan/iot2050
[2] https://github.com/siemens/meta
On 03.08.21 16:14, Jan Kiszka wrote:
> On 03.08.21 15:45, Tom Rini wrote:
>> On Tue, Aug 03, 2021 at 03:42:30PM +0200, Jan Kiszka wrote:
>>> On 03.08.21 15:27, Tom Rini wrote:
>>>> On Tue, Aug 03, 2021 at 11:26:55AM +0200, Jan Kiszka wrote:
>>>>
>
On 03.08.21 15:45, Tom Rini wrote:
> On Tue, Aug 03, 2021 at 03:42:30PM +0200, Jan Kiszka wrote:
>> On 03.08.21 15:27, Tom Rini wrote:
>>> On Tue, Aug 03, 2021 at 11:26:55AM +0200, Jan Kiszka wrote:
>>>
>>>> From: Jan Kiszka
>>>>
>>>&g
On 03.08.21 15:27, Tom Rini wrote:
> On Tue, Aug 03, 2021 at 11:26:55AM +0200, Jan Kiszka wrote:
>
>> From: Jan Kiszka
>>
>> This adds support for the IOT2050 Basic and Advanced devices. The Basic
>> used the dual-core AM6528 GP processor, the Advanced one the
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. In case the R5F cluster is
in lock-step mode, also initialize the second core. The firmware
From: Jan Kiszka
This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.
Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support
From: Jan Kiszka
Add the DT entry for a watchdog based on RTI1. It requires additional
firmware on the MCU R5F cores to handle the expiry, e.g.
https://github.com/siemens/k3-rti-wdt. As this firmware will also lock
the power domain to protect it against premature shutdown, mark it
shared
From: Jan Kiszka
This allows to use the watchdog in custom scripts but does not enforce
that the OS has to support it as well.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 16
configs/iot2050_defconfig| 6 ++
2 files
From: Jan Kiszka
Prepares for the addition of the IOT2050 board which is based on the TI
AM65x. The board comes in two variants, Basic and Advanced, so there are
separate dts files. Furthermore, the SPL has its own device tree.
Based on original board support by Le Jin, Gao Nian and Chao Zeng
ipped IOT2050 devices.
A staging tree for complete IOT2050 support can be found at [1]. Full
image integration is available via [2].
Jan
[1] https://github.com/siemens/u-boot/commits/jan/iot2050
[2] https://github.com/siemens/meta-iot2050
Jan Kiszka (5):
arm: dts: Add IOT2050 device tree
On 02.08.21 17:47, Tom Rini wrote:
> On Mon, Aug 02, 2021 at 05:21:13PM +0200, Jan Kiszka wrote:
>
>> From: Jan Kiszka
>>
>> This adds support for the IOT2050 Basic and Advanced devices. The Basic
>> used the dual-core AM6528 GP processor, the Advanced one the
From: Jan Kiszka
This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.
Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. In case the R5F cluster is
in lock-step mode, also initialize the second core. The firmware
From: Jan Kiszka
This allows to use the watchdog in custom scripts but does not enforce
that the OS has to support it as well.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 16
configs/iot2050_defconfig| 6 ++
2 files
From: Jan Kiszka
Add the DT entry for a watchdog based on RTI1. It requires additional
firmware on the MCU R5F cores to handle the expiry, e.g.
https://github.com/siemens/k3-rti-wdt. As this firmware will also lock
the power domain to protect it against premature shutdown, mark it
shared
From: Jan Kiszka
Prepares for the addition of the IOT2050 board which is based on the TI
AM65x. The board comes in two variants, Basic and Advanced, so there are
separate dts files. Furthermore, the SPL has its own device tree.
Based on original board support by Le Jin, Gao Nian and Chao Zeng
]. Full
image integration is available via [2].
Jan
[1] https://github.com/siemens/u-boot/commits/jan/iot2050
[2] https://github.com/siemens/meta-iot2050
Jan Kiszka (5):
arm: dts: Add IOT2050 device tree files
board: siemens: Add support for SIMATIC IOT2050 devices
arm64: dts: ti: k3-am65
On 02.08.21 16:27, Tom Rini wrote:
> On Mon, Aug 02, 2021 at 04:03:01PM +0200, Jan Kiszka wrote:
>> On 02.08.21 15:04, Tom Rini wrote:
>>> On Mon, Aug 02, 2021 at 01:54:57PM +0200, Jan Kiszka wrote:
>>>> On 02.08.21 13:38, Marek Vasut wrote:
>>>
On 02.08.21 15:04, Tom Rini wrote:
> On Mon, Aug 02, 2021 at 01:54:57PM +0200, Jan Kiszka wrote:
>> On 02.08.21 13:38, Marek Vasut wrote:
>>> On 8/2/21 1:36 PM, Jan Kiszka wrote:
>>>> On 02.08.21 12:48, Marek Vasut wrote:
>>>>> On 8/2/21 11:37 AM, Jan
On 02.08.21 13:38, Marek Vasut wrote:
> On 8/2/21 1:36 PM, Jan Kiszka wrote:
>> On 02.08.21 12:48, Marek Vasut wrote:
>>> On 8/2/21 11:37 AM, Jan Kiszka wrote:
>>>> On 02.08.21 02:54, Marek Vasut wrote:
>>>>> On 7/29/21 6:58 PM, Tom Rini wrote:
>&
On 02.08.21 12:48, Marek Vasut wrote:
> On 8/2/21 11:37 AM, Jan Kiszka wrote:
>> On 02.08.21 02:54, Marek Vasut wrote:
>>> On 7/29/21 6:58 PM, Tom Rini wrote:
>>>
>>> [...]
>>>
>>>>>> so when did rcar3 introduce something there tha
On 02.08.21 02:54, Marek Vasut wrote:
> On 7/29/21 6:58 PM, Tom Rini wrote:
>
> [...]
>
so when did rcar3 introduce something there that shouldn't be
reserved? And you had phrased this to me on IRC as about reserving
spot
for ATAGS, and that not being needed of course on
From: Jan Kiszka
Prepares for the addition of the IOT2050 board which is based on the TI
AM65x. The board comes in two variants, Basic and Advanced, so there are
separate dts files. Furthermore, the SPL has its own device tree.
Based on original board support by Le Jin, Gao Nian and Chao Zeng
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. In case the R5F cluster is
in lock-step mode, also initialize the second core. The firmware
From: Jan Kiszka
Add the DT entry for a watchdog based on RTI1. It requires additional
firmware on the MCU R5F cores to handle the expiry, e.g.
https://github.com/siemens/k3-rti-wdt. As this firmware will also lock
the power domain to protect it against premature shutdown, mark it
shared
From: Jan Kiszka
This allows to use the watchdog in custom scripts but does not enforce
that the OS has to support it as well.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 16
configs/iot2050_defconfig| 6 ++
2 files
From: Jan Kiszka
This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.
Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support
ently shipped IOT2050 devices.
A staging tree for complete IOT2050 support can be found at [1]. Full
image integration is available via [2].
Jan
[1] https://github.com/siemens/u-boot/commits/jan/iot2050
[2] https://github.com/siemens/meta-iot2050
Jan Kiszka (5):
arm: dts: Add IOT2050 device tree
From: Jan Kiszka
This reverts commit 2359fa7a87848626bcbd3399e92c657595880cd7.
While the goal is valid and there is surely unused memory in that area,
we also have a lot of crucial things still located at the top-of-memory
while running lmb_alloc_base. Such things are the page table (tlb_addr
On 21.07.21 08:08, Jan Kiszka wrote:
> On 21.07.21 01:34, Marek Vasut wrote:
>> On 7/20/21 11:08 AM, Jan Kiszka wrote:
>> [...]
>>>> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
>>>> index f60ee3a7e6..23b99a541c 100644
>>>> --- a/a
On 30.01.20 09:05, Roger Quadros wrote:
> NB0 is bridge to SRAM and NB1 is bridge to DDR.
>
> To ensure that SRAM transfers are not stalled due to
> delays during DDR refreshes, SRAM traffic should be higher
> priority (threadmap=2) than DDR traffic (threadmap=0).
>
> This patch does just that.
On 21.07.21 01:34, Marek Vasut wrote:
> On 7/20/21 11:08 AM, Jan Kiszka wrote:
> [...]
>>> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
>>> index f60ee3a7e6..23b99a541c 100644
>>> --- a/arch/arm/lib/bootm.c
>>> +++ b/arch/arm/lib/bootm.c
>
On 20.07.21 14:57, Jan Kiszka wrote:
> On 14.07.21 16:15, Simon Glass wrote:
>> Hi Jan,
>>
>> On Wed, 14 Jul 2021 at 03:53, Jan Kiszka wrote:
>>>
>>> On 05.07.21 17:29, Simon Glass wrote:
>>>> Hi Jan,
>>>>
>>>> On Sun, 27
On 14.07.21 16:15, Simon Glass wrote:
> Hi Jan,
>
> On Wed, 14 Jul 2021 at 03:53, Jan Kiszka wrote:
>>
>> On 05.07.21 17:29, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Sun, 27 Jun 2021 at 23:40, Jan Kiszka wrote:
>>>>
>>>>
On 29.05.21 13:34, Marek Vasut wrote:
> On arm64, board info is not applicable and kernel command line patched into
> the DT, so the LMB reservation here makes no sense anymore. On legacy arm32,
> this might still be necessary on systems which do not use DT or use legacy
> ATAGS. Disable this LMB
On 15.07.21 08:35, Lokesh Vutla wrote:
> Hi Jan,
>
> On 14/07/21 3:09 pm, Jan Kiszka wrote:
>> On 14.07.21 11:29, Lokesh Vutla wrote:
>>> Hi Jan,
>>>
>>> On 12/06/21 1:12 am, Jan Kiszka wrote:
>>>> This is the baseline support fo
On 05.07.21 17:29, Simon Glass wrote:
> Hi Jan,
>
> On Sun, 27 Jun 2021 at 23:40, Jan Kiszka wrote:
>>
>> On 27.06.21 20:18, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Sun, 27 Jun 2021 at 12:01, Jan Kiszka wrote:
>>>>
>>>>
On 14.07.21 11:29, Lokesh Vutla wrote:
> Hi Jan,
>
> On 12/06/21 1:12 am, Jan Kiszka wrote:
>> This is the baseline support for the SIMATIC IOT2050 devices.
>>
>> Changes in v3:
>> - rebased
>> - addressed several checkpatch warnings
>>
On 27.06.21 20:18, Simon Glass wrote:
> Hi Jan,
>
> On Sun, 27 Jun 2021 at 12:01, Jan Kiszka wrote:
>>
>> On 26.06.21 20:29, Simon Glass wrote:
>>> Hi,
>>>
>>> On Fri, 11 Jun 2021 at 08:08, Tom Rini wrote:
>>>>
>>>> On
On 26.06.21 20:29, Simon Glass wrote:
> Hi,
>
> On Fri, 11 Jun 2021 at 08:08, Tom Rini wrote:
>>
>> On Fri, Jun 11, 2021 at 07:14:21PM +0530, Lokesh Vutla wrote:
>>> Hi Tom,
>>>
>>> On 09/06/21 6:47 pm, Jan Kiszka wrote:
>>>> On 07.06.2
From: Jan Kiszka
The column width for a command name is 8.
Signed-off-by: Jan Kiszka
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a73481d18c..71cf6f72b0 100644
--- a/Makefile
+++ b/Makefile
@@ -2279,7 +2279,7 @@ endif
Hi all,
commit 958f2e57 ("build: use thin archives instead of incremental
linking") broke scripts/get_default_envs.sh:
aarch64-linux-gnu-objcopy:copy_built-in.o: sorry: copying thin archives
is not currently supported: invalid operation
I know (by now) that there is a u-boot-initial-env target
301 - 400 of 705 matches
Mail list logo
