[PATCH] ARM: dts: imx6q-dhcom: Use 1G ethernet on the PDK2 board
From: Christoph Niedermaier
The PDK2 board is capable of running both 100M and 1G ethernet. However,
the i.MX6 has only one ethernet MAC, so it is possible to configure
either 100M or 1G Ethernet. In case of 100M option, the PHY is on the
SoM and the signals are routed to a RJ45 port. For 1G the PHY is on
the PDK2 board with another RJ45 port. 100M and 1G ethernet use
different signal pins from the i.MX6, but share the MDIO bus.
This SoM board combination is used to demonstrate how to enable 1G
ethernet configuration.
Signed-off-by: Christoph Niedermaier
Signed-off-by: Marek Vasut
Cc: Christoph Niedermaier
Cc: Stefano Babic
---
NOTE: Adapted from Linux 298591bf725a ("ARM: dts: imx6q-dhcom: Use 1G ethernet
on the PDK2 board")
---
arch/arm/dts/imx6qdl-dhcom-pdk2-u-boot.dtsi | 2 +-
arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi| 50 +++--
include/configs/dh_imx6.h | 4 +-
3 files changed, 50 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/imx6qdl-dhcom-pdk2-u-boot.dtsi
b/arch/arm/dts/imx6qdl-dhcom-pdk2-u-boot.dtsi
index 32128d4d2ab..a1ffb1d6fc5 100644
--- a/arch/arm/dts/imx6qdl-dhcom-pdk2-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-dhcom-pdk2-u-boot.dtsi
@@ -15,7 +15,7 @@
};
{
- phy-reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+ phy-reset-gpios = < 29 GPIO_ACTIVE_LOW>;
phy-reset-duration = <1>;
phy-reset-post-delay = <10>;
diff --git a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi
b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi
index af4719aaeba..d8772a98966 100644
--- a/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi
+++ b/arch/arm/dts/imx6qdl-dhcom-pdk2.dtsi
@@ -38,6 +38,45 @@
status = "okay";
};
+/* 1G ethernet */
+/delete-node/
+ {
+ phy-mode = "rgmii";
+ phy-handle = <>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_enet_1G>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy7: ethernet-phy@7 { /* KSZ 9021 */
+ compatible = "ethernet-phy-ieee802.3-c22";
+ interrupt-parent = <>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <_ethphy7>;
+ pinctrl-names = "default";
+ reg = <7>;
+ reset-gpios = < 29 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1000>;
+ reset-deassert-us = <1000>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ txc-skew-ps = <3000>;
+ txd0-skew-ps = <0>;
+ txd1-skew-ps = <0>;
+ txd2-skew-ps = <0>;
+ txd3-skew-ps = <0>;
+ rxdv-skew-ps = <0>;
+ txen-skew-ps = <0>;
+ };
+ };
+};
+
{
ddc-i2c-bus = <>;
status = "okay";
@@ -113,9 +152,14 @@
MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
- MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x000b0
- MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x000b1
- MX6QDL_PAD_EIM_D26__GPIO3_IO26 0x000b1
+ >;
+ };
+
+ pinctrl_ethphy7: ethphy7-grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D29__GPIO3_IO29 0xb0 /* Reset */
+ MX6QDL_PAD_GPIO_0__GPIO1_IO00 0xb1 /* Int */
+ MX6QDL_PAD_EIM_D26__GPIO3_IO26 0xb1 /* WOL */
>;
};
diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h
index 8183e7debd4..3cf0578b5e1 100644
--- a/include/configs/dh_imx6.h
+++ b/include/configs/dh_imx6.h
@@ -32,9 +32,9 @@
/* FEC ethernet */
#define IMX_FEC_BASE ENET_BASE_ADDR
-#define CONFIG_FEC_XCV_TYPERMII
+#define CONFIG_FEC_XCV_TYPERGMII
#define CONFIG_ETHPRIME"FEC"
-#define CONFIG_FEC_MXC_PHYADDR 0
+#define CONFIG_FEC_MXC_PHYADDR 7
#define CONFIG_ARP_TIMEOUT 200UL
/* MMC Configs */
--
2.33.0
[PATCH] ARM: imx6: dh-imx6: Add update_sf script to install U-Boot into SF
Add script to read U-Boot from SD card and write it to matching
locations in the SPI NOR, thus making the SPI NOR bootable.
Signed-off-by: Marek Vasut
Cc: Christoph Niedermaier
Cc: Stefano Babic
---
include/configs/dh_imx6.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h
index ee56eb691ad..8183e7debd4 100644
--- a/include/configs/dh_imx6.h
+++ b/include/configs/dh_imx6.h
@@ -82,6 +82,10 @@
"ramdisk_addr_r=0x1800\0" \
"scriptaddr=0x1400\0" \
"fdtfile=imx6q-dhcom-pdk2.dtb\0"\
+ "update_sf=" /* Erase SPI NOR and install U-Boot from SD */ \
+ "load mmc 0:1 ${loadaddr} /boot/u-boot-with-spl.imx && "\
+ "sf probe && sf erase 0x0 0xa && " \
+ "sf write ${loadaddr} 0x400 ${filesize}\0" \
BOOTENV
#define CONFIG_BOOTCOMMAND "run distro_bootcmd"
--
2.33.0
Re: [PATCHv3] net: uclass: Save generated ethernet MAC addresses to the environment
On Mon, Nov 22, 2021 at 3:45 PM Tom Rini wrote:
>
> From: Michal Simek
>
> When a MAC address is randomly generated we currently only update the
> appropriate data structure. For consistency and to re-align with
> historic usage, it should be also saved to the appropriate environment
> variable as well.
>
> Cc: Wolfgang Denk
> Signed-off-by: Michal Simek
> Reviewed-by: Ramon Fried
> [trini: Update Kconfig, handle legacy networking case as well]
> Signed-off-by: Tom Rini
> ---
> Changes in v3:
> - Update Kconfig help text with Wolfgang's suggestion
> - Reword the commit message to hopefully be clearer
>
> Changes in v2:
> - Update Kconfig help text to reflect this change.
> - Update the legacy path to match.
> ---
> net/Kconfig | 9 +
> net/eth-uclass.c | 2 ++
> net/eth_legacy.c | 2 ++
> 3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/net/Kconfig b/net/Kconfig
> index 7a2d14501881..cabe93c6bd29 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -27,10 +27,11 @@ config BOOTP_SEND_HOSTNAME
> config NET_RANDOM_ETHADDR
> bool "Random ethaddr if unset"
> help
> - Selecting this will allow the Ethernet interface to function
> - even when the ethaddr variable for that interface is unset.
> - A new MAC address will be generated on every boot and it will
> - not be added to the environment.
> + Selecting this will allow the Ethernet interface to function even
> + when the ethaddr variable for that interface is unset. In this
> case,
> + a random MAC address in the locally administered address space is
> + generated. It will be saved to the appropriate environment variable,
> + too.
>
> config NETCONSOLE
> bool "NetConsole support"
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index 0da0e85be031..58c308f33276 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -583,6 +583,8 @@ static int eth_post_probe(struct udevice *dev)
> net_random_ethaddr(pdata->enetaddr);
> printf("\nWarning: %s (eth%d) using random MAC address -
> %pM\n",
>dev->name, dev_seq(dev), pdata->enetaddr);
> + eth_env_set_enetaddr_by_index("eth", dev_seq(dev),
> + pdata->enetaddr);
> #else
> printf("\nError: %s address not set.\n",
>dev->name);
> diff --git a/net/eth_legacy.c b/net/eth_legacy.c
> index f383ccce0b92..e7f53b958b2e 100644
> --- a/net/eth_legacy.c
> +++ b/net/eth_legacy.c
> @@ -164,6 +164,8 @@ int eth_write_hwaddr(struct eth_device *dev, const char
> *base_name,
> net_random_ethaddr(dev->enetaddr);
> printf("\nWarning: %s (eth%d) using random MAC address -
> %pM\n",
>dev->name, eth_number, dev->enetaddr);
> + eth_env_set_enetaddr_by_index("eth", dev_seq(dev),
> + pdata->enetaddr);
> #else
> printf("\nError: %s address not set.\n",
>dev->name);
> --
> 2.25.1
>
Acked-by: Ramon Fried
Re: [PATCH] drivers: net: Soft reset felix switch core
On Sat, Nov 27, 2021 at 5:06 PM Vladimir Oltean wrote: > > On Sat, Nov 27, 2021 at 02:52:35PM +0200, Radu Bulie wrote: > > It turns out that in custom designs if the system is reset > > multiple times in conjunction with a slight increase in external > > temperature, the felix switch starts to behave in a strange way: > > packets are no longer received on the ENECT interface connected > > to the L2switch internal port (the TX side of internal port stops working > > or the packets do not reach there. It is not very clear where > > the packets remain blocked. None of the counters points to a disruption > > in the L2switch) > > The issue is not reproducible on NXP reference designs. > > > > It was observed that by adding the switch core reset, the problem > > goes aways, even if intensive testing in temperature chambers > > is applied. > > > > The current patch performs soft reset on the switch core to ensure proper > > operation of the L2switch. > > > > Signed-off-by: Radu Bulie > > --- > > Reviewed-by: Vladimir Oltean > > Thanks! Reviewed-by: Ramon Fried
[PATCH] drivers: net: Soft reset felix switch core
It turns out that in custom designs if the system is reset multiple times in conjunction with a slight increase in external temperature, the felix switch starts to behave in a strange way: packets are no longer received on the ENECT interface connected to the L2switch internal port (the TX side of internal port stops working or the packets do not reach there. It is not very clear where the packets remain blocked. None of the counters points to a disruption in the L2switch) The issue is not reproducible on NXP reference designs. It was observed that by adding the switch core reset, the problem goes aways, even if intensive testing in temperature chambers is applied. The current patch performs soft reset on the switch core to ensure proper operation of the L2switch. Signed-off-by: Radu Bulie --- drivers/net/mscc_eswitch/felix_switch.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/net/mscc_eswitch/felix_switch.c b/drivers/net/mscc_eswitch/felix_switch.c index 2df8dde55f..60b2e8f32d 100644 --- a/drivers/net/mscc_eswitch/felix_switch.c +++ b/drivers/net/mscc_eswitch/felix_switch.c @@ -40,7 +40,9 @@ #define FELIX_IS2 0x06 #define FELIX_GMII(port) (0x10 + (port) * 0x1) #define FELIX_QSYS 0x20 - +#define FELIX_DEVCPU_GCB 0x07 +#define FELIX_DEVCPU_GCB_SOFT_RST (FELIX_DEVCPU_GCB + 0x0004) +#define SOFT_SWC_RST BIT(0) #define FELIX_SYS_SYSTEM (FELIX_SYS + 0x0E00) #define FELIX_SYS_SYSTEM_EN BIT(0) #define FELIX_SYS_RAM_CTRL (FELIX_SYS + 0x0F24) @@ -237,6 +239,15 @@ static void felix_init(struct udevice *dev) void *base = priv->regs_base; int timeout = 100; + /* Switch core reset */ + out_le32(base + FELIX_DEVCPU_GCB_SOFT_RST, SOFT_SWC_RST); + while (in_le32(base + FELIX_DEVCPU_GCB_SOFT_RST) & SOFT_SWC_RST && + --timeout) + udelay(10); + if (in_le32(base + FELIX_DEVCPU_GCB_SOFT_RST) & SOFT_SWC_RST) + dev_err(dev, "Timeout waiting for switch core reset\n"); + timeout = 100; + /* Init core memories */ out_le32(base + FELIX_SYS_RAM_CTRL, FELIX_SYS_RAM_CTRL_INIT); while (in_le32(base + FELIX_SYS_RAM_CTRL) & FELIX_SYS_RAM_CTRL_INIT && -- 2.17.1
Re: [PATCH] drivers: net: Soft reset felix switch core
On Sat, Nov 27, 2021 at 02:52:35PM +0200, Radu Bulie wrote: > It turns out that in custom designs if the system is reset > multiple times in conjunction with a slight increase in external > temperature, the felix switch starts to behave in a strange way: > packets are no longer received on the ENECT interface connected > to the L2switch internal port (the TX side of internal port stops working > or the packets do not reach there. It is not very clear where > the packets remain blocked. None of the counters points to a disruption > in the L2switch) > The issue is not reproducible on NXP reference designs. > > It was observed that by adding the switch core reset, the problem > goes aways, even if intensive testing in temperature chambers > is applied. > > The current patch performs soft reset on the switch core to ensure proper > operation of the L2switch. > > Signed-off-by: Radu Bulie > --- Reviewed-by: Vladimir Oltean Thanks!
Re: [u-boot-test-hooks] writer: Add imx_raw variant
On Thu, Nov 11, 2021 at 12:42:29PM -0500, Tom Rini wrote: > When flashing the SD card for an imx platform, we need to use > u-boot-with-spl.imx at an offset of 1024 bytes in to the device. > > Signed-off-by: Tom Rini Applied to u-boot-test-hooks/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/1] Enable TPMv2 emulation
On Wed, Nov 24, 2021 at 09:12:51AM +0100, Heinrich Schuchardt wrote: > Provide a QEMU helper script to launch swtpm and add extra parameters to > conf.qemu_arm64_na and conf.qemu_arm_na to provide an emulated TPMv2. > > Reviewed-by: Ilias Apalodimas > Signed-off-by: Heinrich Schuchardt Applied to u-boot-test-hooks/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] tpm: avoid NULL pointer dereference in tpm_tis_send()
On Sat, Nov 27, 2021 at 11:57:42AM +0100, Heinrich Schuchardt wrote:
>
>
> On 11/27/21 00:38, Ilias Apalodimas wrote:
> > Hi Heinrich,
> >
> > On Fri, Nov 26, 2021 at 11:54:52PM +0100, Heinrich Schuchardt wrote:
> > > You should not dereference a pointer before checking if it is NULL.
> > >
> > > Signed-off-by: Heinrich Schuchardt
> > > ---
> > > drivers/tpm/tpm2_tis_core.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/tpm/tpm2_tis_core.c b/drivers/tpm/tpm2_tis_core.c
> > > index ec8c730fe9..0ff21a1ef7 100644
> > > --- a/drivers/tpm/tpm2_tis_core.c
> > > +++ b/drivers/tpm/tpm2_tis_core.c
> > > @@ -218,7 +218,7 @@ static int tpm_tis_ready(struct udevice *dev)
> > > int tpm_tis_send(struct udevice *dev, const u8 *buf, size_t len)
> > > {
> > > struct tpm_chip *chip = dev_get_priv(dev);
> > > - struct tpm_tis_phy_ops *phy_ops = chip->phy_ops;
> > > + struct tpm_tis_phy_ops *phy_ops;
> > > size_t burstcnt, wr_size, sent = 0;
> > > u8 data = TPM_STS_GO;
> > > u8 status;
> > > @@ -227,6 +227,8 @@ int tpm_tis_send(struct udevice *dev, const u8 *buf,
> > > size_t len)
> > > if (!chip)
> > > return -ENODEV;
> > > + phy_ops = chip->phy_ops;
> > > +
> >
> > At this point I believe dev_get_priv() wont fail, since the device is
> > opened and running. We can remove the if check though.
>
> What happens if the user issues the 'efidebug' command followed by the
> 'unbind' command to remove the TPM before launching an image?
>
These functions are called as part of the tpm-uclass. The current TPM uclass
code is looking for priv and tries to derive the device ops. So if anything
goes wrong, that will happen way before this even gets invoked.
I'd much rather prefer doing the checks for that there instead of the API code.
It makes more sense to me to have the DM code provide an assurance the ptr is
always present instead of checking the pointers on every function.
Thanks
/Ilias
> Best regards
>
> Heinrich
>
> >
> > > ret = tpm_tis_request_locality(dev, 0);
> > > if (ret < 0)
> > > return -EBUSY;
> > > --
> > > 2.32.0
> > >
> >
> >
> > Thanks!
> > /Ilias
> >
Re: [PATCH] tpm: avoid NULL pointer dereference in tpm_tis_send()
On 11/27/21 00:38, Ilias Apalodimas wrote:
Hi Heinrich,
On Fri, Nov 26, 2021 at 11:54:52PM +0100, Heinrich Schuchardt wrote:
You should not dereference a pointer before checking if it is NULL.
Signed-off-by: Heinrich Schuchardt
---
drivers/tpm/tpm2_tis_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tpm/tpm2_tis_core.c b/drivers/tpm/tpm2_tis_core.c
index ec8c730fe9..0ff21a1ef7 100644
--- a/drivers/tpm/tpm2_tis_core.c
+++ b/drivers/tpm/tpm2_tis_core.c
@@ -218,7 +218,7 @@ static int tpm_tis_ready(struct udevice *dev)
int tpm_tis_send(struct udevice *dev, const u8 *buf, size_t len)
{
struct tpm_chip *chip = dev_get_priv(dev);
- struct tpm_tis_phy_ops *phy_ops = chip->phy_ops;
+ struct tpm_tis_phy_ops *phy_ops;
size_t burstcnt, wr_size, sent = 0;
u8 data = TPM_STS_GO;
u8 status;
@@ -227,6 +227,8 @@ int tpm_tis_send(struct udevice *dev, const u8 *buf, size_t
len)
if (!chip)
return -ENODEV;
+ phy_ops = chip->phy_ops;
+
At this point I believe dev_get_priv() wont fail, since the device is
opened and running. We can remove the if check though.
What happens if the user issues the 'efidebug' command followed by the
'unbind' command to remove the TPM before launching an image?
Best regards
Heinrich
ret = tpm_tis_request_locality(dev, 0);
if (ret < 0)
return -EBUSY;
--
2.32.0
Thanks!
/Ilias
Re: [U-BOOT-TEST-HOOKS PATCH 1/1] Enable TPMv2 emulation
On 11/27/21 02:38, Tom Rini wrote:
On Wed, Nov 24, 2021 at 08:33:42AM +0100, Heinrich Schuchardt wrote:
On 11/24/21 08:23, Ilias Apalodimas wrote:
Hi Heinrich,
On Mon, 15 Nov 2021 at 12:11, Heinrich Schuchardt
wrote:
Provide a QEMU helper script to launch swtpm and add extra parameters to
conf.qemu_arm64_na and conf.qemu_arm_na to provide an emulated TPMv2.
Signed-off-by: Heinrich Schuchardt
---
bin/qemu.swtpm | 19 +++
bin/travis-ci/conf.qemu_arm64_na | 3 ++-
bin/travis-ci/conf.qemu_arm_na | 3 ++-
3 files changed, 23 insertions(+), 2 deletions(-)
create mode 100755 bin/qemu.swtpm
diff --git a/bin/qemu.swtpm b/bin/qemu.swtpm
new file mode 100755
index 000..089feba
--- /dev/null
+++ b/bin/qemu.swtpm
@@ -0,0 +1,19 @@
+#!/bin/sh
+# SPDX-License-Identifier: BSD-2
+#
+# This script launches swtpm to emulate a TPMv2. The parameter -t makes it
+# unload when the connection to QEMU is terminated. To make use of it add
+#
+# qemu_helper_script="swtpm"
+#
+# to the board script and the following arguments to qemu_extra_args
+#
+# -chardev socket,id=chrtpm,path=/tmp/tpm/swtpm-sock \
+# -tpmdev emulator,id=tpm0,chardev=chrtpm \
+# -device tpm-tis-device,tpmdev=tpm0
+#
+# U-Boot must be built with CONFIG_TPM2_MMIO=y.
+
+mkdir -p /tmp/tpm
+swtpm socket -t --tpmstate dir=/tmp/tpm --tpm2 \
+--ctrl type=unixio,path=/tmp/tpm/swtpm-sock &
Nit pick the & can be '-d'
Daemonizing will ensure that we don't get console output. I will change
this.
diff --git a/bin/travis-ci/conf.qemu_arm64_na b/bin/travis-ci/conf.qemu_arm64_na
index e7c9426..14577d8 100644
--- a/bin/travis-ci/conf.qemu_arm64_na
+++ b/bin/travis-ci/conf.qemu_arm64_na
@@ -22,8 +22,9 @@
console_impl=qemu
qemu_machine="virt"
+qemu_helper_script="swtpm"
qemu_binary="qemu-system-aarch64"
-qemu_extra_args="-cpu cortex-a57 -nographic -netdev
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device e1000,netdev=net0 -device
virtio-rng-pci"
+qemu_extra_args="-cpu cortex-a57 -nographic -netdev
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device e1000,netdev=net0 -device
virtio-rng-pci -chardev socket,id=chrtpm,path=/tmp/tpm/swtpm-sock -tpmdev
emulator,id=tpm0,chardev=chrtpm -device tpm-tis-device,tpmdev=tpm0"
qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/u-boot.bin"
reset_impl=none
flash_impl=none
diff --git a/bin/travis-ci/conf.qemu_arm_na b/bin/travis-ci/conf.qemu_arm_na
index 0f07c80..de0694d 100644
--- a/bin/travis-ci/conf.qemu_arm_na
+++ b/bin/travis-ci/conf.qemu_arm_na
@@ -22,8 +22,9 @@
console_impl=qemu
qemu_machine="virt"
+qemu_helper_script="swtpm"
qemu_binary="qemu-system-arm"
-qemu_extra_args="-nographic -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR}
-device e1000,netdev=net0 -device virtio-rng-pci"
+qemu_extra_args="-nographic -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR}
-device e1000,netdev=net0 -device virtio-rng-pci -chardev
socket,id=chrtpm,path=/tmp/tpm/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device
tpm-tis-device,tpmdev=tpm0"
Just a note here 'tpm-tis-device' works for arm. If we evenr need
this on x86 it's 'tpm-tis'
This file is ARM specific.
Sure, but it's worth noting since if we can also use these features and
tests on qemu-x86_64 we should. Doesn't need to be to start with tho.
And I will apply this shortly.
The current version of this patch is:
[v2,1/1] Enable TPMv2 emulation
https://patchwork.ozlabs.org/project/uboot/patch/20211124081251.59511-1-heinrich.schucha...@canonical.com/
On x86 we don't have support for the emulated TPM in U-Boot. According
to the QEMU documentation you would have to parse ACPI tables to detect
if a TPM is made available by QEMU. Maybe you could instead define it in
arch/x86/dts/qemu-x86_i440fx.dts.
Cf. https://qemu-project.gitlab.io/qemu/specs/tpm.html#acpi-interface
Once that work is done we should enable the TPM emulation on x86 in the
U-Boot test hooks.
This will be the required settings:
qemu_helper_script="swtpm"
qemu_extra_args="-nographic -cpu qemu64 -netdev
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device e1000,netdev=net0
-chardev socket,id=chrtpm,path=/tmp/tpm/swtpm-sock -tpmdev
emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0"
Best regards
Heinrich
