ens/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
configs: iot2050: Enable watchdog support, but do not a
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
---
configs/iot2050_defconfig | 6 ++
1 file changed, 6 insertions(+)
diff --git a/configs/iot2050_defconfig b/configs
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 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
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
On 11.06.21 16:53, Tom Rini wrote:
> On Fri, Jun 11, 2021 at 08:00:17PM +0530, Lokesh Vutla wrote:
>>
>>
>> On 02/06/21 3:07 pm, Jan Kiszka wrote:
>>> This is the baseline support for the SIMATIC IOT2050 devices.
>>>
>>> Changes in v2:
>
On 07.06.21 13:44, Jan Kiszka wrote:
> On 07.06.21 13:40, Tom Rini wrote:
>> On Mon, Jun 07, 2021 at 03:33:52PM +0530, Lokesh Vutla wrote:
>>> +Tom,
>>>
>>> Hi Tom,
>>>
>>> On 02/06/21 3:07 pm, Jan Kiszka wrote:
>>>> From: Jan Ki
On 07.06.21 13:40, Tom Rini wrote:
> On Mon, Jun 07, 2021 at 03:33:52PM +0530, Lokesh Vutla wrote:
>> +Tom,
>>
>> Hi Tom,
>>
>> On 02/06/21 3:07 pm, Jan Kiszka wrote:
>>> From: Jan Kiszka
>>>
>>> To avoid the need of extra boot
On 07.06.21 12:03, Lokesh Vutla wrote:
> +Tom,
>
> Hi Tom,
>
> On 02/06/21 3:07 pm, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> To avoid the need of extra boot scripting on AM65x for loading a
>> watchdog firmware, add the required rproc init and
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
-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
configs: iot2050: Enable watchdog support, but do not auto-start
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
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
---
configs/iot2050_defconfig | 6 ++
1 file changed, 6 insertions(+)
diff --git a/configs/iot2050_defconfig b/configs
On 27.05.21 15:19, Jan Kiszka wrote:
> From: Jan Kiszka
>
> dev_read_addr_size() is inconsistent in too many ways. In particular,
> it does not retrieve the correct address/size cell number from the DT.
> dev_read_addr_size_index() does the right thing, so use that for now.
From: Jan Kiszka
dev_read_addr_size() is inconsistent in too many ways. In particular,
it does not retrieve the correct address/size cell number from the DT.
dev_read_addr_size_index() does the right thing, so use that for now.
This fixes reading the address size e.g. on boards with the 64-bit
On 04.05.21 22:01, Dario Binacchi wrote:
> Hi Jan,
>
>> Il 04/05/2021 17:26 Simon Glass ha scritto:
>>
>>
>> Hi Jan,
>>
>> On Sun, 2 May 2021 at 01:53, Jan Kiszka wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to make some s
On 02.05.21 09:53, Jan Kiszka wrote:
> Hi,
>
> I'm trying to make some sense of ofnode_get_addr_size() in order to fix
> [1] properly.
>
> First, the documentation if this functions says "This does no address
> translation". But the node-pointer path happi
Hi,
I'm trying to make some sense of ofnode_get_addr_size() in order to fix
[1] properly.
First, the documentation if this functions says "This does no address
translation". But the node-pointer path happily calls
of_translate_address(), as the result of a6a45cd32539. For not
offset-bases path,
On 01.05.21 17:39, Dario Binacchi wrote:
> Hi Jan,
>
>> Il 01/05/2021 14:29 Jan Kiszka ha scritto:
>>
>>
>> On 11.04.21 09:39, Dario Binacchi wrote:
>>> Use dev_read_addr_size to get size of the controller's register area.
>>>
>>> Signe
On 11.04.21 09:39, Dario Binacchi wrote:
> Use dev_read_addr_size to get size of the controller's register area.
>
> Signed-off-by: Dario Binacchi
> Reviewed-by: Pratyush Yadav
>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Added Pratyush Yadav review tag.
>
> Changes in v2:
> - Check
On 23.12.20 09:18, Lokesh Vutla wrote:
>
>
> On 18/12/20 11:43 am, Jan Kiszka wrote:
>> On 18.12.20 07:04, Jan Kiszka wrote:
>>> On 18.12.20 05:46, Lokesh Vutla wrote:
>>>> Hi Jan,
>>>>Sorry for the delayed response.
>>>>
>>&g
On 18.12.20 07:04, Jan Kiszka wrote:
> On 18.12.20 05:46, Lokesh Vutla wrote:
>> Hi Jan,
>> Sorry for the delayed response.
>>
>> On 04/12/20 1:29 pm, Jan Kiszka wrote:
>>> This is the baseline support for the SIMATIC IOT2050 devices.
>>
On 18.12.20 05:46, Lokesh Vutla wrote:
> Hi Jan,
> Sorry for the delayed response.
>
> On 04/12/20 1:29 pm, Jan Kiszka wrote:
>> This is the baseline support for the SIMATIC IOT2050 devices.
>>
>> Allows to boot mainline 5.10 kernels, but not the original BSP-
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
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
image integration is available via [3].
Jan
[1]
https://patchwork.ozlabs.org/project/uboot/patch/a42ab2dde9a588a8efc186474becd837f2e470c5.1592910910.git.jan.kis...@siemens.com/
[2] https://github.com/siemens/u-boot/commits/jan/iot2050
[3] https://github.com/siemens/meta-iot2050
Jan Kiszka (2):
arm
On 22.11.20 00:08, Simon Glass wrote:
> Hi Jan,
>
> On Sat, 21 Nov 2020 at 07:28, Jan Kiszka wrote:
>>
>> Hi,
>>
>> I stumbled over README.entries claiming
>>
>> Entry: u-boot-dtb: U-Boot device tree
>> -
&g
Hi,
I stumbled over README.entries claiming
Entry: u-boot-dtb: U-Boot device tree
-
Properties / Entry arguments:
- filename: Filename of u-boot.dtb (default 'u-boot.dtb')
However,
u-boot-dtb {
filename = "foo.dtb"
}
On 13.10.20 16:26, Jan Kiszka wrote:
> On 13.10.20 13:06, Patrick DELAUNAY wrote:
>> Hi Jan,
>>
>>> From: Jan Kiszka
>>> Sent: mardi 13 octobre 2020 00:02
>>>
>>> On 05.10.20 08:07, Jan Kiszka wrote:
>>>> On 01.10.20 11:
On 13.10.20 13:06, Patrick DELAUNAY wrote:
> Hi Jan,
>
>> From: Jan Kiszka
>> Sent: mardi 13 octobre 2020 00:02
>>
>> On 05.10.20 08:07, Jan Kiszka wrote:
>>> On 01.10.20 11:52, Jan Kiszka wrote:
>>>> On 30.09.20 11:51, Jan Kiszka wrote:
>
On 05.10.20 08:07, Jan Kiszka wrote:
> On 01.10.20 11:52, Jan Kiszka wrote:
>> On 30.09.20 11:51, Jan Kiszka wrote:
>>> [BCC'ed TF-A only, migrating to u-boot, including folks involved there]
>>>
>>> On 30.09.20 11:20, Yann GAUTIER wrote:
>>>> Hi Ja
On 01.10.20 11:52, Jan Kiszka wrote:
> On 30.09.20 11:51, Jan Kiszka wrote:
>> [BCC'ed TF-A only, migrating to u-boot, including folks involved there]
>>
>> On 30.09.20 11:20, Yann GAUTIER wrote:
>>> Hi Jan,
>>>
>>> After discussing with my collea
On 30.09.20 11:51, Jan Kiszka wrote:
> [BCC'ed TF-A only, migrating to u-boot, including folks involved there]
>
> On 30.09.20 11:20, Yann GAUTIER wrote:
>> Hi Jan,
>>
>> After discussing with my colleagues, it seems there are 2 issues there.
>> One pa
On 30.09.20 12:03, Marek Vasut wrote:
> On 9/30/20 11:51 AM, Jan Kiszka wrote:
>> [BCC'ed TF-A only, migrating to u-boot, including folks involved there]
>>
>> On 30.09.20 11:20, Yann GAUTIER wrote:
>>> Hi Jan,
>>>
>>> After discussing with my collea
2f7-i2c 5c002000.i2c: can't request DMA tx channel
[3.572312] stm32f7-i2c 5c002000.i2c: can't use DMA
But those would be a kernel topic, I suppose.
Thanks for the quick resolution,
Jan
>
> Regards,
> Yann
>
> On 9/30/20 11:18 AM, Jan Kiszka wrote:
>> On 30.09.20 10:40, Yann
On 13.08.20 14:12, Jan Kiszka wrote:
> On 11.08.20 20:01, Lokesh Vutla wrote:
>>
>>
>> On 11/08/20 8:28 pm, Jan Kiszka wrote:
>>> On 11.08.20 16:36, Lokesh Vutla wrote:
>>>> Hi Jan,
>>>>
>>>> On 11/08/20 6:07
Hi Simon,
studying the binman integration, some questions/issues popped up:
# Timestamp file to make sure that binman always runs
.binman_stamp: FORCE
@touch $@
A reason is not provided, neither here nor in the commit log. Is it
because external blobs may have changed? I suppose the
Hi,
despite some futile attempts (arch/arm/mach-rmobile/Makefile,
board/imgtec/boston/config.mk), CLEAN_FILES cannot be extended outside
of the top-level Makefile as clean is in no-dot-config-targets, and the
arch and board specific config.mk files are not evaluated then.
How to clean extra
Hi all,
enabling binman pulls in libfdt, and that seems to have a lot of issues
with comparing signed with unsigned values. Those are present upstream
as well (dtc in general doesn't build with -Wsign-compare).
Is anyone looking into this already? Fix upstream? Can we ignore this
downstream
On 11.08.20 20:01, Lokesh Vutla wrote:
On 11/08/20 8:28 pm, Jan Kiszka wrote:
On 11.08.20 16:36, Lokesh Vutla wrote:
Hi Jan,
On 11/08/20 6:07 pm, Jan Kiszka wrote:
On 11.08.20 12:46, Lokesh Vutla wrote:
On 11/08/20 4:12 pm, Jan Kiszka wrote:
On 11.08.20 12:33, Lokesh Vutla wrote
On 23.07.20 06:14, Faiz Abbas wrote:
Jan,
On 23/07/20 8:55 am, Faiz Abbas wrote:
Jan,
On 21/07/20 10:52 pm, Jan Kiszka wrote:
On 21.07.20 19:03, Faiz Abbas wrote:
Jan,
On 21/07/20 12:06 pm, Jan Kiszka wrote:
On 21.07.20 01:23, Jaehoon Chung wrote:
On 7/20/20 10:21 AM, Peng Fan wrote:
Hi
Kiszka (3):
watchdog: Add support for K3 RTI watchdog
arm: dts: k3: Add RTI watchdogs
am654_sdhci: mmc fail to send stop cmd
OK, so the last change from Jan here is:
commit 6bc290047b6e0209dd8183ce78be2f9297feb3c6
Author: Jan Kiszka
Date: Sat Jul 18 16:47:04 2020 +0200
On 11.08.20 16:36, Lokesh Vutla wrote:
Hi Jan,
On 11/08/20 6:07 pm, Jan Kiszka wrote:
On 11.08.20 12:46, Lokesh Vutla wrote:
On 11/08/20 4:12 pm, Jan Kiszka wrote:
On 11.08.20 12:33, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
This brings watchdog support for the TI K3
On 11.08.20 12:46, Lokesh Vutla wrote:
On 11/08/20 4:12 pm, Jan Kiszka wrote:
On 11.08.20 12:33, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
This brings watchdog support for the TI K3 SoCs, derived from the Linux
kernel, augmented with firmware loading as needed
On 11.08.20 12:33, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
This brings watchdog support for the TI K3 SoCs, derived from the Linux
kernel, augmented with firmware loading as needed on the AM65x.
Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream
support
On 23.07.20 07:25, Jan Kiszka wrote:
On 23.07.20 05:25, Faiz Abbas wrote:
Jan,
On 21/07/20 10:52 pm, Jan Kiszka wrote:
On 21.07.20 19:03, Faiz Abbas wrote:
Jan,
On 21/07/20 12:06 pm, Jan Kiszka wrote:
On 21.07.20 01:23, Jaehoon Chung wrote:
On 7/20/20 10:21 AM, Peng Fan wrote:
Hi Jan
On 23.07.20 05:25, Faiz Abbas wrote:
Jan,
On 21/07/20 10:52 pm, Jan Kiszka wrote:
On 21.07.20 19:03, Faiz Abbas wrote:
Jan,
On 21/07/20 12:06 pm, Jan Kiszka wrote:
On 21.07.20 01:23, Jaehoon Chung wrote:
On 7/20/20 10:21 AM, Peng Fan wrote:
Hi Jan,
Subject: am654_sdhci: mmc fail to send
On 21.07.20 19:03, Faiz Abbas wrote:
> Jan,
>
> On 21/07/20 12:06 pm, Jan Kiszka wrote:
>> On 21.07.20 01:23, Jaehoon Chung wrote:
>>> On 7/20/20 10:21 AM, Peng Fan wrote:
>>>> Hi Jan,
>>>>
>>>>> Subject: am654_sdhci: mmc fail to send
On 21.07.20 01:23, Jaehoon Chung wrote:
On 7/20/20 10:21 AM, Peng Fan wrote:
Hi Jan,
Subject: am654_sdhci: mmc fail to send stop cmd
Hi all,
on one device with one specific SD-card (possibly an aging one), I'm seeing
frequent "mmc fail to send stop cmd" messages, followed by read errors
On 21.07.20 07:27, Lokesh Vutla wrote:
Hi Jan,
On 20/07/20 3:06 pm, Jan Kiszka wrote:
On 29.06.20 20:44, Jan Kiszka wrote:
On 29.06.20 14:37, Tom Rini wrote:
On Mon, Jun 29, 2020 at 07:56:53AM +0530, Lokesh Vutla wrote:
+Tom
On 23/06/20 8:11 pm, Jan Kiszka wrote:
On 23.06.20 14:37, Jan
On 29.06.20 20:44, Jan Kiszka wrote:
On 29.06.20 14:37, Tom Rini wrote:
On Mon, Jun 29, 2020 at 07:56:53AM +0530, Lokesh Vutla wrote:
+Tom
On 23/06/20 8:11 pm, Jan Kiszka wrote:
On 23.06.20 14:37, Jan Kiszka wrote:
On 23.06.20 13:50, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka
On 20.07.20 03:21, Peng Fan wrote:
Hi Jan,
Subject: am654_sdhci: mmc fail to send stop cmd
Hi all,
on one device with one specific SD-card (possibly an aging one), I'm seeing
frequent "mmc fail to send stop cmd" messages, followed by read errors
when loading kernel and dtb. -ETIMEDOUT is
Hi all,
on one device with one specific SD-card (possibly an aging one), I'm
seeing frequent "mmc fail to send stop cmd" messages, followed by read
errors when loading kernel and dtb. -ETIMEDOUT is returned by
mmd_send_cmd. However, I can always resolve this by simply retrying the
stop command
From: Jan Kiszka
Buiding u-boot-spl-k3[_HS].its is currently unconditionally verbose
about what it does. Change that by wrapping the call to k3_fit_atf.sh
into a cmd, also using that chance to reduce duplicate lines of makefile
code - only IS_HS=1 is different when CONFIG_TI_SECURE_DEVICE
On 29.06.20 14:37, Tom Rini wrote:
On Mon, Jun 29, 2020 at 07:56:53AM +0530, Lokesh Vutla wrote:
+Tom
On 23/06/20 8:11 pm, Jan Kiszka wrote:
On 23.06.20 14:37, Jan Kiszka wrote:
On 23.06.20 13:50, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
From: Jan Kiszka
To avoid
On 29.06.20 06:54, Lokesh Vutla wrote:
On 29/06/20 10:20 am, Jan Kiszka wrote:
On 29.06.20 04:26, Lokesh Vutla wrote:
+Tom
On 23/06/20 8:11 pm, Jan Kiszka wrote:
On 23.06.20 14:37, Jan Kiszka wrote:
On 23.06.20 13:50, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
From
On 29.06.20 04:26, Lokesh Vutla wrote:
+Tom
On 23/06/20 8:11 pm, Jan Kiszka wrote:
On 23.06.20 14:37, Jan Kiszka wrote:
On 23.06.20 13:50, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading
From: Jan Kiszka
Signed-off-by: Jan Kiszka
---
arch/arm/mach-k3/config.mk | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index f6b63db349..f7afef610c 100644
--- a/arch/arm/mach-k3/config.mk
+++ b
From: Jan Kiszka
Signed-off-by: Jan Kiszka
---
Makefile | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index e3c18d8c39..6d2f5bc091 100644
--- a/Makefile
+++ b/Makefile
@@ -872,12 +872,14 @@ endif
# do the relocation).
ifneq
On 23.06.20 14:37, Jan Kiszka wrote:
On 23.06.20 13:50, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
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
On 23.06.20 13:50, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
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. The firmware
On 23.06.20 13:47, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
From: Jan Kiszka
This is based on the Linux kernel driver for the RTI watchdog.
To actually reset the system on an AM65x, it requires firmware running
on the R5 that accepts the NMI and issues the actual system
From: Jan Kiszka
Add DT entries for main domain watchdog0 and 1 instances on the J721e
well as RTI1-based watchdog on the AM65x. RTI0 does not work for this
purpose on the AM65x, so leave it out.
On AM65x, we mark the power-domain as shared because RTI firmware such
as https://github.com
to Linux
- drop unneeded explicit power-on
- account for RTI firmware locking the power domain
Jan
Jan Kiszka (3):
watchdog: Add support for K3 RTI watchdog
watchdog: rti_wdt: Add support for loading firmware
arm: dts: k3: Add RTI watchdogs
arch/arm/dts/k3-am65-mcu.dtsi | 9 ++
arch/arm
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. The firmware itself is
embedded into U-Boot binary.
One possible firmware source is https
From: Jan Kiszka
This is based on the Linux kernel driver for the RTI watchdog.
To actually reset the system on an AM65x, it requires firmware running
on the R5 that accepts the NMI and issues the actual system reset via
TISCI. Kind of an iTCO, except that this watchdog hardware has support
From: Jan Kiszka
Add DT entries for main domain watchdog0 and 1 instances on the J721e
well as RTI1-based watchdog on the AM65x. RTI0 does not work for this
purpose on the AM65x, so leave it out.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-mcu.dtsi | 9 +
arch/arm/dts/k3
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. The firmware itself is
embedded into U-Boot binary.
One possible firmware source is https
This brings watchdog support for the TI K3 SoCs, derived from the Linux
kernel, augmented with firmware loading as needed on the AM65x.
Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream
support will be posted soon).
Jan
Jan Kiszka (3):
watchdog: Add support for K3 RTI
From: Jan Kiszka
This is based on the Linux kernel driver for the RTI watchdog.
To actually reset the system on an AM65x, it requires firmware running
on the R5 that accepts the NMI and issues the actual system reset via
TISCI. Kind of an iTCO, except that this watchdog hardware has support
On 31.05.20 17:34, Heinrich Schuchardt wrote:
> On 5/22/20 8:12 PM, Heinrich Schuchardt wrote:
>> On 5/22/20 5:21 PM, Jan Kiszka wrote:
>>> On 22.05.20 16:55, Heinrich Schuchardt wrote:
>>>> On 22.05.20 14:21, Jan Kiszka wrote:
>>>>> On 22.05.20 13:38
On 22.05.20 16:55, Heinrich Schuchardt wrote:
> On 22.05.20 14:21, Jan Kiszka wrote:
>> On 22.05.20 13:38, Heinrich Schuchardt wrote:
>>> Am May 22, 2020 10:50:29 AM UTC schrieb Jan Kiszka :
>>>> On 22.05.20 12:42, Heinrich Schuchardt wrote:
>>>>> On 5
On 22.05.20 13:38, Heinrich Schuchardt wrote:
> Am May 22, 2020 10:50:29 AM UTC schrieb Jan Kiszka :
>> On 22.05.20 12:42, Heinrich Schuchardt wrote:
>>> On 5/20/20 2:22 PM, Tom Rini wrote:
>>>> On Thu, May 07, 2020 at 08:36:03PM +0200, Jan Kiszka wrot
On 22.05.20 12:42, Heinrich Schuchardt wrote:
> On 5/20/20 2:22 PM, Tom Rini wrote:
>> On Thu, May 07, 2020 at 08:36:03PM +0200, Jan Kiszka wrote:
>>
>>> From: Jan Kiszka
>>>
>>> This driver is safe to use in SPL without relocation. Denying
&g
On 21.05.20 19:05, Lokesh Vutla wrote:
> +Tom
>
> Hi Jan,
>
> On 19/05/20 1:05 pm, Jan Kiszka wrote:
>> Hi Lokesh,
>>
>> seems like all boards including include/environment/ti/mmc.h will only search
>> for ${boot_scripts} in the root of the target
Hi Lokesh,
seems like all boards including include/environment/ti/mmc.h will only
search for ${boot_scripts} in the root of the target fs, not in
${boot_prefixes}. Known bug? Used to work fine with your downstream
U-Boot some years ago. Just updated an SD card, only replacing the
bootloader
On 19.05.20 08:24, Jan Kiszka wrote:
On 19.05.20 08:18, Lokesh Vutla wrote:
Hi Jan,
On 18/05/20 11:27 am, Jan Kiszka wrote:
From: Jan Kiszka
Add support for enabling dcache already in SPL. It accelerates the boot
and resolves the risk to run into unaligned 64-bit accesses.
Based
On 19.05.20 08:18, Lokesh Vutla wrote:
Hi Jan,
On 18/05/20 11:27 am, Jan Kiszka wrote:
From: Jan Kiszka
Add support for enabling dcache already in SPL. It accelerates the boot
and resolves the risk to run into unaligned 64-bit accesses.
Based on original patch by Lokesh Vulta.
Signed-off
On 18.05.20 18:26, Andrew F. Davis wrote:
On 5/8/20 11:54 AM, Jan Kiszka wrote:
On 08.05.20 17:40, Andrew F. Davis wrote:
On 5/4/20 8:38 AM, Jan Kiszka wrote:
From: Jan Kiszka
Build the secured board dtbs (.dtb_HS) as part of the regular dtb build
on CONFIG_TI_SECURE_DEVICE targets
From: Jan Kiszka
Add support for enabling dcache already in SPL. It accelerates the boot
and resolves the risk to run into unaligned 64-bit accesses.
Based on original patch by Lokesh Vulta.
Signed-off-by: Jan Kiszka
---
arch/arm/mach-k3/am6_init.c | 1 +
arch/arm/mach-k3/common.c
On 08.05.20 17:40, Andrew F. Davis wrote:
On 5/4/20 8:38 AM, Jan Kiszka wrote:
From: Jan Kiszka
Build the secured board dtbs (.dtb_HS) as part of the regular dtb build
on CONFIG_TI_SECURE_DEVICE targets. This avoids rebuilding them,
possibly overwriting artifacts that are in use
From: Jan Kiszka
This driver is safe to use in SPL without relocation. Denying
DM_FLAG_PRE_RELOC prevents its usability for verifying the main U-Boot
or other artifacts from the SPL unless needless enabling the full driver
set (SPL_OF_PLATDATA).
Fixes: 17e117408571 ("drivers: c
From: Jan Kiszka
Better than crashing later if it is missing.
Signed-off-by: Jan Kiszka
---
lib/rsa/rsa-verify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 80e817314b..f7ae174cb0 100644
--- a/lib/rsa/rsa-verify.c
+++ b
else
- key.exponent =
- fdt64_to_cpu(*((uint64_t *)(prop->public_exponent)));
+ rsa_convert_big_endian((uint32_t *),
+ prop->public_exponent, 2);
if (!key.len || !prop->modulus || !prop->rr) {
debug("%s
On 06.05.20 22:00, Tom Rini wrote:
On Wed, May 06, 2020 at 06:32:03PM +0200, Jan Kiszka wrote:
From: Jan Kiszka
The fdt only provides 32-bit alignment of data. If the public_exponent
happens to be not 64-bit aligned, we can trigger an exception on certain
architectures. Seen on TI AM64x
From: Jan Kiszka
The fdt only provides 32-bit alignment of data. If the public_exponent
happens to be not 64-bit aligned, we can trigger an exception on certain
architectures. Seen on TI AM64x.
Note that the normal way of accessing such a number would be
fdtdec_get_number. However
From: Jan Kiszka
The dts dir must exists when running this rule.
That missing dependency broke e.g. "make -j" for the am65x targets.
Fixes: 2f57c95100f2 ("spl: dm: Make it possible for the SPL to pick its own DTB
from a FIT")
CC: Jean-Jacques Hiblot
Signed-off-by: Jan
See patches for details.
Jan
CC: Andrew F. Davis
CC: Heinrich Schuchardt
CC: Jan Kiszka
CC: Jean-Jacques Hiblot
Jan Kiszka (4):
kbuild: efi: Avoid rebuilding efi targets
kbuild: spl: Fix parallel build
kbuild: spl: Add shrunk arch-dtbs to targets list
kbuild: arm: Fix duplicate
From: Jan Kiszka
Build the secured board dtbs (.dtb_HS) as part of the regular dtb build
on CONFIG_TI_SECURE_DEVICE targets. This avoids rebuilding them,
possibly overwriting artifacts that are in use, as it is done so far.
In the same run, fix needless rebuilding of the secured spl dtb.
Fixes
From: Jan Kiszka
This avoids needless rebuilding.
Fixes: 2f57c95100f2 ("spl: dm: Make it possible for the SPL to pick its own DTB
from a FIT")
CC: Jean-Jacques Hiblot
Signed-off-by: Jan Kiszka
---
scripts/Makefile.spl | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
From: Jan Kiszka
Add a couple of missing targets so that helloworld and other efi targets
are not needlessly rebuilt.
CC: Heinrich Schuchardt
Signed-off-by: Jan Kiszka
---
lib/efi_loader/Makefile | 1 +
scripts/Makefile.lib| 2 ++
2 files changed, 3 insertions(+)
diff --git a/lib
From: Jan Kiszka
This driver is safe to use in SPL without relocation. Denying
DM_FLAG_PRE_RELOC prevents its usability for verifying the main U-Boot
or other artifacts from the SPL unless needless enabling the full driver
set (SPL_OF_PLATDATA).
Fixes: 17e117408571 ("drivers: c
On 30.04.20 23:16, Andrew F. Davis wrote:
On 4/30/20 3:03 PM, Jan Kiszka wrote:
Hi all,
I've noticed that building am65x_evm_a53_defconfig causes the dtbs to be
built twice, once for the main u-boot and once for the spl. This is
because of an extra dependency in mach-k3/config_secure.mk added
Hi all,
I've noticed that building am65x_evm_a53_defconfig causes the dtbs to be
built twice, once for the main u-boot and once for the spl. This is
because of an extra dependency in mach-k3/config_secure.mk added by
508369672ca3. Why should the produced dtbs depend on the target that
produces
On 30.04.20 12:06, Harald Seiler wrote:
Hello Jan,
On Wed, 2020-04-29 at 19:23 +0200, Jan Kiszka wrote:
From: Jan Kiszka
This was already changed in 0c3a9ed409a5 but apparently missed when
adding 9d86dbd9cf9d.
I sent a very similar patch [1] as part of my "Fix spl_mmc_boot
From: Jan Kiszka
This was already changed in 0c3a9ed409a5 but apparently missed when
adding 9d86dbd9cf9d.
Signed-off-by: Jan Kiszka
---
Found by chance while working on other code. Not tested.
arch/arm/mach-imx/spl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Jan Kiszka
We need to align the cache buffer to ARCH_DMA_MINALIGN in order to avoid
access errors like
CACHE: Misaligned operation at range [be0231e0, be0235e0]
seen on the MCIMX7SABRE.
Fixes: d5aee659f217 ("fs: ext4: cache extent data")
Signed-off-by: Jan Kiszka
---
fs/ext
401 - 500 of 705 matches
Mail list logo
