Re: [U-BOOT TEST HOOKS PATCH] travis-ci: Do not run TPM tests on Versal QEMU target

[Tom Rini]

On Mon, 28 Aug 2023 16:29:53 +0200, Michal Simek wrote:
> TPM is going to be enabled by default but QEMU doesn't model it over SPI
> that's why disable it for xilinx_versal_virt_qemu target.
> 
> 

Applied, thanks!

[1/1] travis-ci: Do not run TPM tests on Versal QEMU target
  commit: 3c736fb3a2c81d3ffc2ae22d3ee264651ad6a7f9

Best regards,
-- 
Tom

[U-BOOT TEST HOOKS PATCH] travis-ci: Do not run TPM tests on Versal QEMU target

[Michal Simek]

TPM is going to be enabled by default but QEMU doesn't model it over SPI
that's why disable it for xilinx_versal_virt_qemu target.

Signed-off-by: Michal Simek 
---

 py/travis-ci/u_boot_boardenv_xilinx_versal_virt_qemu.py | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 py/travis-ci/u_boot_boardenv_xilinx_versal_virt_qemu.py

diff --git a/py/travis-ci/u_boot_boardenv_xilinx_versal_virt_qemu.py 
b/py/travis-ci/u_boot_boardenv_xilinx_versal_virt_qemu.py
new file mode 100644
index ..6fd75071ce0c
--- /dev/null
+++ b/py/travis-ci/u_boot_boardenv_xilinx_versal_virt_qemu.py
@@ -0,0 +1 @@
+env__tpm_device_test_skip=True
-- 
2.36.1

Re: [U-BOOT-TEST-HOOKS][PATCH v2 1/1] qemu-riscv: enable virtio-rng-device

[Tom Rini]

On Mon, 31 Jul 2023 11:05:06 +0200, Heinrich Schuchardt wrote:
> Linux' KASLR uses the EFI_RNG_PROTOCOL as entropy source. We should
> enable CONFIG_DM_RNG in U-Boot. For the EFI unit test for the protocol to
> succeed a virtio RNG device has to be provided when invoking QEMU.
> 
> 

Applied, thanks!

[1/1] qemu-riscv: enable virtio-rng-device
  commit: 2d8182047358fee6f36ebb887c19e573396cd23a

Best regards,
-- 
Tom

Re: [u-boot-test-hooks 1/4] bin/flash.sdwire_common_mount: Switch to sourcing the next writer script

[Tom Rini]

On Tue, 25 Jul 2023 17:08:44 -0400, Tom Rini wrote:
> Rather than invoking the script that will write to the mounted directory
> as a binary, source it as a script so that it has access to more than
> just two parameters.  This will allow us to have the same flexibility in
> our writers that other flash methods have.
> 
> 

Applied, thanks!

[1/4] bin/flash.sdwire_common_mount: Switch to sourcing the next writer script
  commit: 6fcab91ee4cc7d25ccc6452ab8e0b6c64e326e16
[2/4] bin/writer.rpi*mount: Rework to support all current Pi platforms
  commit: 0242dc8b81dc5bb7d86dfeaf8a0ebc02f7cc0f71
[3/4] bin/writer.ti-omap_mount: Add support for TI OMAP-style platforms via 
mount
  commit: 0c0184ee0e5cecc08a9e60d39d0664f41e41af6e
[4/4] bin/writer.ti-k3_mount: Add support for TI K3 platforms via mount
  commit: bbe462eb91981e266b2980e217fd5a0349acba63

Best regards,
-- 
Tom

Re: [U-BOOT-TEST-HOOKS][PATCH v2 1/1] qemu-riscv: enable virtio-rng-device

[Bin Meng]

On Mon, Jul 31, 2023 at 5:04 PM Heinrich Schuchardt
 wrote:
>
> Linux' KASLR uses the EFI_RNG_PROTOCOL as entropy source. We should
> enable CONFIG_DM_RNG in U-Boot. For the EFI unit test for the protocol to
> succeed a virtio RNG device has to be provided when invoking QEMU.
>
> Reported-by: Leo Liang 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
> use virtio-rng-device instead of virtio-rng-pci
> (virtio-rng-device does not require calling 'virtio scan')
>
> See related patch
> [PATCH 1/1] riscv: qemu: imply CONFIG_DM_RNG
> https://lists.denx.de/pipermail/u-boot/2023-July/525293.html
> ---
>  bin/travis-ci/conf.qemu-riscv32_na | 2 +-
>  bin/travis-ci/conf.qemu-riscv32_spl_na | 2 +-
>  bin/travis-ci/conf.qemu-riscv64_na | 2 +-
>  bin/travis-ci/conf.qemu-riscv64_spl_na | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>

Reviewed-by: Bin Meng 

[U-BOOT-TEST-HOOKS][PATCH v2 1/1] qemu-riscv: enable virtio-rng-device

[Heinrich Schuchardt]

Linux' KASLR uses the EFI_RNG_PROTOCOL as entropy source. We should
enable CONFIG_DM_RNG in U-Boot. For the EFI unit test for the protocol to
succeed a virtio RNG device has to be provided when invoking QEMU.

Reported-by: Leo Liang 
Signed-off-by: Heinrich Schuchardt 
---
v2:
use virtio-rng-device instead of virtio-rng-pci
(virtio-rng-device does not require calling 'virtio scan')

See related patch
[PATCH 1/1] riscv: qemu: imply CONFIG_DM_RNG
https://lists.denx.de/pipermail/u-boot/2023-July/525293.html
---
 bin/travis-ci/conf.qemu-riscv32_na | 2 +-
 bin/travis-ci/conf.qemu-riscv32_spl_na | 2 +-
 bin/travis-ci/conf.qemu-riscv64_na | 2 +-
 bin/travis-ci/conf.qemu-riscv64_spl_na | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/bin/travis-ci/conf.qemu-riscv32_na 
b/bin/travis-ci/conf.qemu-riscv32_na
index 5aa25e3..8163754 100644
--- a/bin/travis-ci/conf.qemu-riscv32_na
+++ b/bin/travis-ci/conf.qemu-riscv32_na
@@ -5,7 +5,7 @@
 console_impl=qemu
 qemu_machine="virt"
 qemu_binary="qemu-system-riscv32"
-qemu_extra_args="-m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0"
+qemu_extra_args="-m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0 -device virtio-rng-device"
 qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/u-boot"
 reset_impl=none
 flash_impl=none
diff --git a/bin/travis-ci/conf.qemu-riscv32_spl_na 
b/bin/travis-ci/conf.qemu-riscv32_spl_na
index c1419c2..254ae18 100644
--- a/bin/travis-ci/conf.qemu-riscv32_spl_na
+++ b/bin/travis-ci/conf.qemu-riscv32_spl_na
@@ -5,7 +5,7 @@
 console_impl=qemu
 qemu_machine="virt"
 qemu_binary="qemu-system-riscv32"
-qemu_extra_args="-smp 4 -m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0"
+qemu_extra_args="-smp 4 -m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0 -device virtio-rng-device"
 qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/spl/u-boot-spl -device 
loader,file=${U_BOOT_BUILD_DIR}/u-boot.itb,addr=0x8020"
 reset_impl=none
 flash_impl=none
diff --git a/bin/travis-ci/conf.qemu-riscv64_na 
b/bin/travis-ci/conf.qemu-riscv64_na
index 90ab820..7c96dc2 100644
--- a/bin/travis-ci/conf.qemu-riscv64_na
+++ b/bin/travis-ci/conf.qemu-riscv64_na
@@ -5,7 +5,7 @@
 console_impl=qemu
 qemu_machine="virt"
 qemu_binary="qemu-system-riscv64"
-qemu_extra_args="-m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0"
+qemu_extra_args="-m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0 -device virtio-rng-device"
 qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/u-boot"
 reset_impl=none
 flash_impl=none
diff --git a/bin/travis-ci/conf.qemu-riscv64_spl_na 
b/bin/travis-ci/conf.qemu-riscv64_spl_na
index c3d3dac..693fdf3 100644
--- a/bin/travis-ci/conf.qemu-riscv64_spl_na
+++ b/bin/travis-ci/conf.qemu-riscv64_spl_na
@@ -5,7 +5,7 @@
 console_impl=qemu
 qemu_machine="virt"
 qemu_binary="qemu-system-riscv64"
-qemu_extra_args="-smp 4 -m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0"
+qemu_extra_args="-smp 4 -m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0 -device virtio-rng-device"
 qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/spl/u-boot-spl -device 
loader,file=${U_BOOT_BUILD_DIR}/u-boot.itb,addr=0x8020"
 reset_impl=none
 flash_impl=none
-- 
2.40.1

Re: [U-BOOT TEST HOOKS][PATCH 1/1] qemu-riscv: enable virtio-rng-pci

[Heinrich Schuchardt]

On 7/31/23 10:48, Bin Meng wrote:

On Mon, Jul 31, 2023 at 4:00 PM Leo Liang  wrote:


On Mon, Jul 31, 2023 at 09:25:07AM +0200, Heinrich Schuchardt wrote:

Linux' KASLR uses the EFI_RNG_PROTOCOL as entropy source. We should
enable CONFIG_DM_RNG in U-Boot. For the EFI unit test for the protocol to
succeed a virtio-rng-pci device has to be provided when invoking QEMU.

Reported-by: Leo Liang 
Signed-off-by: Heinrich Schuchardt 
---
See related patch
[PATCH 1/1] riscv: qemu: imply CONFIG_DM_RNG
https://lists.denx.de/pipermail/u-boot/2023-July/525293.html

The non-spl defconfigs still don't scan virtio devices automatically. This
also needs to be addressed.
---
  bin/travis-ci/conf.qemu-riscv32_na | 2 +-
  bin/travis-ci/conf.qemu-riscv32_spl_na | 2 +-
  bin/travis-ci/conf.qemu-riscv64_na | 2 +-
  bin/travis-ci/conf.qemu-riscv64_spl_na | 2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)


LGTM!
Reviewed-by: Leo Yu-Chi Liang 



NAK!

It should be "virtio-rng-device"


Thanks. That resolves the issue with virtio scanning.

Best regards

Heinrich

Re: [U-BOOT TEST HOOKS][PATCH 1/1] qemu-riscv: enable virtio-rng-pci

[Bin Meng]

On Mon, Jul 31, 2023 at 4:00 PM Leo Liang  wrote:
>
> On Mon, Jul 31, 2023 at 09:25:07AM +0200, Heinrich Schuchardt wrote:
> > Linux' KASLR uses the EFI_RNG_PROTOCOL as entropy source. We should
> > enable CONFIG_DM_RNG in U-Boot. For the EFI unit test for the protocol to
> > succeed a virtio-rng-pci device has to be provided when invoking QEMU.
> >
> > Reported-by: Leo Liang 
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> > See related patch
> > [PATCH 1/1] riscv: qemu: imply CONFIG_DM_RNG
> > https://lists.denx.de/pipermail/u-boot/2023-July/525293.html
> >
> > The non-spl defconfigs still don't scan virtio devices automatically. This
> > also needs to be addressed.
> > ---
> >  bin/travis-ci/conf.qemu-riscv32_na | 2 +-
> >  bin/travis-ci/conf.qemu-riscv32_spl_na | 2 +-
> >  bin/travis-ci/conf.qemu-riscv64_na | 2 +-
> >  bin/travis-ci/conf.qemu-riscv64_spl_na | 2 +-
> >  4 files changed, 4 insertions(+), 4 deletions(-)
>
> LGTM!
> Reviewed-by: Leo Yu-Chi Liang 
>

NAK!

It should be "virtio-rng-device"

Regards,
Bin

Re: [U-BOOT TEST HOOKS][PATCH 1/1] qemu-riscv: enable virtio-rng-pci

[Leo Liang]

On Mon, Jul 31, 2023 at 09:25:07AM +0200, Heinrich Schuchardt wrote:
> Linux' KASLR uses the EFI_RNG_PROTOCOL as entropy source. We should
> enable CONFIG_DM_RNG in U-Boot. For the EFI unit test for the protocol to
> succeed a virtio-rng-pci device has to be provided when invoking QEMU.
> 
> Reported-by: Leo Liang 
> Signed-off-by: Heinrich Schuchardt 
> ---
> See related patch
> [PATCH 1/1] riscv: qemu: imply CONFIG_DM_RNG
> https://lists.denx.de/pipermail/u-boot/2023-July/525293.html
> 
> The non-spl defconfigs still don't scan virtio devices automatically. This
> also needs to be addressed.
> ---
>  bin/travis-ci/conf.qemu-riscv32_na | 2 +-
>  bin/travis-ci/conf.qemu-riscv32_spl_na | 2 +-
>  bin/travis-ci/conf.qemu-riscv64_na | 2 +-
>  bin/travis-ci/conf.qemu-riscv64_spl_na | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)

LGTM!
Reviewed-by: Leo Yu-Chi Liang 

Best regards,
Leo

[U-BOOT TEST HOOKS][PATCH 1/1] qemu-riscv: enable virtio-rng-pci

[Heinrich Schuchardt]

Linux' KASLR uses the EFI_RNG_PROTOCOL as entropy source. We should
enable CONFIG_DM_RNG in U-Boot. For the EFI unit test for the protocol to
succeed a virtio-rng-pci device has to be provided when invoking QEMU.

Reported-by: Leo Liang 
Signed-off-by: Heinrich Schuchardt 
---
See related patch
[PATCH 1/1] riscv: qemu: imply CONFIG_DM_RNG
https://lists.denx.de/pipermail/u-boot/2023-July/525293.html

The non-spl defconfigs still don't scan virtio devices automatically. This
also needs to be addressed.
---
 bin/travis-ci/conf.qemu-riscv32_na | 2 +-
 bin/travis-ci/conf.qemu-riscv32_spl_na | 2 +-
 bin/travis-ci/conf.qemu-riscv64_na | 2 +-
 bin/travis-ci/conf.qemu-riscv64_spl_na | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/bin/travis-ci/conf.qemu-riscv32_na 
b/bin/travis-ci/conf.qemu-riscv32_na
index 5aa25e3..8163754 100644
--- a/bin/travis-ci/conf.qemu-riscv32_na
+++ b/bin/travis-ci/conf.qemu-riscv32_na
@@ -5,7 +5,7 @@
 console_impl=qemu
 qemu_machine="virt"
 qemu_binary="qemu-system-riscv32"
-qemu_extra_args="-m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0"
+qemu_extra_args="-m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0 -device virtio-rng-pci"
 qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/u-boot"
 reset_impl=none
 flash_impl=none
diff --git a/bin/travis-ci/conf.qemu-riscv32_spl_na 
b/bin/travis-ci/conf.qemu-riscv32_spl_na
index c1419c2..254ae18 100644
--- a/bin/travis-ci/conf.qemu-riscv32_spl_na
+++ b/bin/travis-ci/conf.qemu-riscv32_spl_na
@@ -5,7 +5,7 @@
 console_impl=qemu
 qemu_machine="virt"
 qemu_binary="qemu-system-riscv32"
-qemu_extra_args="-smp 4 -m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0"
+qemu_extra_args="-smp 4 -m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0 -device virtio-rng-pci"
 qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/spl/u-boot-spl -device 
loader,file=${U_BOOT_BUILD_DIR}/u-boot.itb,addr=0x8020"
 reset_impl=none
 flash_impl=none
diff --git a/bin/travis-ci/conf.qemu-riscv64_na 
b/bin/travis-ci/conf.qemu-riscv64_na
index 90ab820..7c96dc2 100644
--- a/bin/travis-ci/conf.qemu-riscv64_na
+++ b/bin/travis-ci/conf.qemu-riscv64_na
@@ -5,7 +5,7 @@
 console_impl=qemu
 qemu_machine="virt"
 qemu_binary="qemu-system-riscv64"
-qemu_extra_args="-m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0"
+qemu_extra_args="-m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0 -device virtio-rng-pci"
 qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/u-boot"
 reset_impl=none
 flash_impl=none
diff --git a/bin/travis-ci/conf.qemu-riscv64_spl_na 
b/bin/travis-ci/conf.qemu-riscv64_spl_na
index c3d3dac..693fdf3 100644
--- a/bin/travis-ci/conf.qemu-riscv64_spl_na
+++ b/bin/travis-ci/conf.qemu-riscv64_spl_na
@@ -5,7 +5,7 @@
 console_impl=qemu
 qemu_machine="virt"
 qemu_binary="qemu-system-riscv64"
-qemu_extra_args="-smp 4 -m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0"
+qemu_extra_args="-smp 4 -m 1G -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device 
virtio-net-device,netdev=net0 -device virtio-rng-pci"
 qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/spl/u-boot-spl -device 
loader,file=${U_BOOT_BUILD_DIR}/u-boot.itb,addr=0x8020"
 reset_impl=none
 flash_impl=none
-- 
2.40.1

Re: [u-boot-test-hooks 1/4] bin/flash.sdwire_common_mount: Switch to sourcing the next writer script

[Simon Glass]

On Tue, 25 Jul 2023 at 15:09, Tom Rini  wrote:
>
> Rather than invoking the script that will write to the mounted directory
> as a binary, source it as a script so that it has access to more than
> just two parameters.  This will allow us to have the same flexibility in
> our writers that other flash methods have.
>
> Signed-off-by: Tom Rini 
> ---
>  bin/flash.sdwire_common_mount |  3 ++-
>  bin/writer.rpi3_mount | 19 +++
>  bin/writer.zynq_mount | 15 +--
>  3 files changed, 14 insertions(+), 23 deletions(-)

Reviewed-by: Simon Glass 

Re: [u-boot-test-hooks 4/4] bin/writer.ti-k3_mount: Add support for TI K3 platforms via mount

[Simon Glass]

On Tue, 25 Jul 2023 at 15:09, Tom Rini  wrote:
>
> The TI K3 platforms require a number of things in order to boot. We must
> have built both the Cortex-R and Cortex-A configurations (following
> their board documents and requirements as these need additional tooling
> and binaries). Further, depending on the specific SoC and variant we
> need three or four files to be copied to the mount point, with specific
> names.  The least fragile way to handle this is that each board conf
> file must define the name of the input files to copy (the outputs have
> static names).
>
> Signed-off-by: Tom Rini 
> ---
>  bin/writer.ti-k3_mount | 36 
>  1 file changed, 36 insertions(+)
>  create mode 100755 bin/writer.ti-k3_mount

Reviewed-by: Simon Glass 

Re: [u-boot-test-hooks 3/4] bin/writer.ti-omap_mount: Add support for TI OMAP-style platforms via mount

[Simon Glass]

On Tue, 25 Jul 2023 at 15:09, Tom Rini  wrote:
>
> In the case of TI OMAP (and similar) platforms, the SD card needs MLO
> and u-boot.img to boot, always.  Copy these files over.
>
> Signed-off-by: Tom Rini 
> ---
>  bin/writer.ti-omap_mount | 29 +
>  1 file changed, 29 insertions(+)
>  create mode 100755 bin/writer.ti-omap_mount

Reviewed-by: Simon Glass 

Re: [u-boot-test-hooks 2/4] bin/writer.rpi*mount: Rework to support all current Pi platforms

[Simon Glass]

On Tue, 25 Jul 2023 at 15:08, Tom Rini  wrote:
>
> Now that we have access to more variables in our "mount" writer scripts,
> we can have a single one that covers all Pi variants.
>
> Signed-off-by: Tom Rini 
> ---
> I use this locally to test a Pi 3 in both 32, 64 and "arm64" mode.
>
> Cc: Simon Glass 
> ---
>  bin/kea/conf.rpi_3_32b_sjg-rpi_3b   |  2 +-
>  bin/kea/conf.rpi_3_sjg-rpi_3b   |  2 +-
>  bin/{writer.rpi3_mount => writer.rpi_mount} | 46 +
>  3 files changed, 31 insertions(+), 19 deletions(-)
>  rename bin/{writer.rpi3_mount => writer.rpi_mount} (63%)

Reviewed-by: Simon Glass 

[u-boot-test-hooks 3/4] bin/writer.ti-omap_mount: Add support for TI OMAP-style platforms via mount

[Tom Rini]

In the case of TI OMAP (and similar) platforms, the SD card needs MLO
and u-boot.img to boot, always.  Copy these files over.

Signed-off-by: Tom Rini 
---
 bin/writer.ti-omap_mount | 29 +
 1 file changed, 29 insertions(+)
 create mode 100755 bin/writer.ti-omap_mount

diff --git a/bin/writer.ti-omap_mount b/bin/writer.ti-omap_mount
new file mode 100755
index ..7d1dbee8f65f
--- /dev/null
+++ b/bin/writer.ti-omap_mount
@@ -0,0 +1,29 @@
+# Copyright 2022 Konsulko Group. All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+# Copies MLO to the filesystem
+
+set -e
+
+build=${U_BOOT_BUILD_DIR}
+
+echo "Writing to ${mount_dir} from build at ${build}"
+
+sudo cp ${build}/MLO ${build}/u-boot.img ${mount_dir}/
-- 
2.34.1

[u-boot-test-hooks 4/4] bin/writer.ti-k3_mount: Add support for TI K3 platforms via mount

[Tom Rini]

The TI K3 platforms require a number of things in order to boot. We must
have built both the Cortex-R and Cortex-A configurations (following
their board documents and requirements as these need additional tooling
and binaries). Further, depending on the specific SoC and variant we
need three or four files to be copied to the mount point, with specific
names.  The least fragile way to handle this is that each board conf
file must define the name of the input files to copy (the outputs have
static names).

Signed-off-by: Tom Rini 
---
 bin/writer.ti-k3_mount | 36 
 1 file changed, 36 insertions(+)
 create mode 100755 bin/writer.ti-k3_mount

diff --git a/bin/writer.ti-k3_mount b/bin/writer.ti-k3_mount
new file mode 100755
index ..e22a2a50de78
--- /dev/null
+++ b/bin/writer.ti-k3_mount
@@ -0,0 +1,36 @@
+# Copyright 2022 Konsulko Group. All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+# Copies MLO to the filesystem
+
+set -e
+
+build=${U_BOOT_BUILD_DIR}
+
+if [ -z "${tispl}" -o -z "${uboot}" -o -z "${tiboot3}" ]; then
+echo "Must configure tispl, uboot, tiboot3 and optionally sysfw"
+echo "per the board documentation."
+exit 1
+fi
+echo "Writing to ${mount_dir} from build at ${build}"
+sudo cp -v ${build}/${tispl} ${mount_dir}/tispl.bin
+sudo cp -v ${build}/${uboot} ${mount_dir}/u-boot.img.bin
+sudo cp -v ${build/_a??/_r5}/${tiboot3} ${mount_dir}/tiboot3.bin
+[ ! -z "${sysfw}" ] && sudo cp -v ${build/_a??/_r5}/${sysfw} 
${mount_dir}/sysfw.itb
-- 
2.34.1

[u-boot-test-hooks 2/4] bin/writer.rpi*mount: Rework to support all current Pi platforms

[Tom Rini]

Now that we have access to more variables in our "mount" writer scripts,
we can have a single one that covers all Pi variants.

Signed-off-by: Tom Rini 
---
I use this locally to test a Pi 3 in both 32, 64 and "arm64" mode.

Cc: Simon Glass 
---
 bin/kea/conf.rpi_3_32b_sjg-rpi_3b   |  2 +-
 bin/kea/conf.rpi_3_sjg-rpi_3b   |  2 +-
 bin/{writer.rpi3_mount => writer.rpi_mount} | 46 +
 3 files changed, 31 insertions(+), 19 deletions(-)
 rename bin/{writer.rpi3_mount => writer.rpi_mount} (63%)

diff --git a/bin/kea/conf.rpi_3_32b_sjg-rpi_3b 
b/bin/kea/conf.rpi_3_32b_sjg-rpi_3b
index 5fe98687221d..020eca2404d8 100644
--- a/bin/kea/conf.rpi_3_32b_sjg-rpi_3b
+++ b/bin/kea/conf.rpi_3_32b_sjg-rpi_3b
@@ -23,7 +23,7 @@ reset_impl=ykush
 flash_impl=sdwire_poweroff_mount
 power_impl=ykush
 
-flash_writer=rpi3_mount
+flash_writer=rpi_mount
 
 ykush_serial=YK17698
 ykush_port=1
diff --git a/bin/kea/conf.rpi_3_sjg-rpi_3b b/bin/kea/conf.rpi_3_sjg-rpi_3b
index 6401737f..d8d2a94f036a 100644
--- a/bin/kea/conf.rpi_3_sjg-rpi_3b
+++ b/bin/kea/conf.rpi_3_sjg-rpi_3b
@@ -23,7 +23,7 @@ reset_impl=ykush
 flash_impl=sdwire_ykush_mount
 power_impl=ykush
 
-flash_writer=rpi3_mount
+flash_writer=rpi_mount
 
 ykush_serial=YK17698
 ykush_port=1
diff --git a/bin/writer.rpi3_mount b/bin/writer.rpi_mount
similarity index 63%
rename from bin/writer.rpi3_mount
rename to bin/writer.rpi_mount
index a63e7999e57b..73fb8bf6af04 100755
--- a/bin/writer.rpi3_mount
+++ b/bin/writer.rpi_mount
@@ -1,4 +1,5 @@
 # Copyright 2019 Google LLC. All rights reserved.
+# Copyright 2024 Konsulko Group. All rights reserved.
 #
 # Permission is hereby granted, free of charge, to any person obtaining a
 # copy of this software and associated documentation files (the "Software"),
@@ -18,27 +19,38 @@
 # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 # DEALINGS IN THE SOFTWARE.
 
-# Writes rpi3_b to the board
-
-set -ex
+set -e
 
 build=${U_BOOT_BUILD_DIR}
 
 echo "Writing to ${mount_dir} from build at ${build}"
 
-# First make a copy of the original files if we haven't already
-if [[ ! -e ${mount_dir}/config.orig ]]; then
-cp ${mount_dir}/config.txt ${mount_dir}/config.orig
-fi
-if [[ ! -e ${mount_dir}/rpi3-u-boot.bin.orig ]]; then
-cp ${mount_dir}/rpi3-u-boot.bin ${mount_dir}/rpi3-u-boot.bin.orig
-fi
+case "${board_type}" in
+rpi)
+kernel_dst=kernel.img
+;;
+rpi_2)
+kernel_dst=kernel7.img
+;;
+rpi_3|rpi_3b|rpi_3_b_plus|rpi_4|rpi_arm64)
+kernel_dst=kernel8.img
+;;
+rpi_3_32b|rpi_4_32b)
+kernel_dst=kernel8-32.img
+;;
+*)
+echo Unknown Pi \""${board_type}"\"
+exit 1
+;;
+esac
+
+sudo rm -f ${mount_dir}/kernel*img
+sudo cp -v ${build}/u-boot.bin ${mount_dir}/${kernel_dst}
 
-# Enable the UART and fix the GPU frequency so it works correctly
-sed -i '/enable_uart/c\enable_uart = 1' /media/rpi3_b_boot/config.txt
-if ! grep -q "^gpu_freq=250" /media/rpi3_b_boot/config.txt; then
-echo 'gpu_freq=250' >>/media/rpi3_b_boot/config.txt
-fi
+echo "enable_uart=1" | sudo tee ${mount_dir}/config.txt
 
-# Copy U-Boot over from the build directory
-cp ${build}/u-boot.bin ${mount_dir}/rpi3-u-boot.bin
+case "${board_ident}" in
+3-32-pl011)
+echo "dtoverlay=pi3-miniuart-bt" | sudo tee -a ${mount_dir}/config.txt
+;;
+esac
-- 
2.34.1

[u-boot-test-hooks 1/4] bin/flash.sdwire_common_mount: Switch to sourcing the next writer script

[Tom Rini]

Rather than invoking the script that will write to the mounted directory
as a binary, source it as a script so that it has access to more than
just two parameters.  This will allow us to have the same flexibility in
our writers that other flash methods have.

Signed-off-by: Tom Rini 
---
 bin/flash.sdwire_common_mount |  3 ++-
 bin/writer.rpi3_mount | 19 +++
 bin/writer.zynq_mount | 15 +--
 3 files changed, 14 insertions(+), 23 deletions(-)

diff --git a/bin/flash.sdwire_common_mount b/bin/flash.sdwire_common_mount
index 6c763e62f47d..b76add064fb0 100644
--- a/bin/flash.sdwire_common_mount
+++ b/bin/flash.sdwire_common_mount
@@ -52,7 +52,8 @@ if ! mountpoint -q ${mount_dir}; then
 exit 1
 fi
 
-writer.${flash_writer} ${mount_dir} ${U_BOOT_BUILD_DIR}
+# Perform the write, pass along as much environment as possible
+. writer.${flash_writer}
 
 complete=false
 for i in {0..9}; do
diff --git a/bin/writer.rpi3_mount b/bin/writer.rpi3_mount
index 97f24a5ac694..a63e7999e57b 100755
--- a/bin/writer.rpi3_mount
+++ b/bin/writer.rpi3_mount
@@ -20,23 +20,18 @@
 
 # Writes rpi3_b to the board
 
-# Args:
-#  $1: Mount point of the sdcard when board is off
-#  $2: U-Boot build directory
-
 set -ex
 
-mount=$1
-build=$2
+build=${U_BOOT_BUILD_DIR}
 
-echo "Writing to ${mount} from build at ${build}"
+echo "Writing to ${mount_dir} from build at ${build}"
 
 # First make a copy of the original files if we haven't already
-if [[ ! -e ${mount}/config.orig ]]; then
-cp ${mount}/config.txt ${mount}/config.orig
+if [[ ! -e ${mount_dir}/config.orig ]]; then
+cp ${mount_dir}/config.txt ${mount_dir}/config.orig
 fi
-if [[ ! -e ${mount}/rpi3-u-boot.bin.orig ]]; then
-cp ${mount}/rpi3-u-boot.bin ${mount}/rpi3-u-boot.bin.orig
+if [[ ! -e ${mount_dir}/rpi3-u-boot.bin.orig ]]; then
+cp ${mount_dir}/rpi3-u-boot.bin ${mount_dir}/rpi3-u-boot.bin.orig
 fi
 
 # Enable the UART and fix the GPU frequency so it works correctly
@@ -46,4 +41,4 @@ if ! grep -q "^gpu_freq=250" /media/rpi3_b_boot/config.txt; 
then
 fi
 
 # Copy U-Boot over from the build directory
-cp ${build}/u-boot.bin ${mount}/rpi3-u-boot.bin
+cp ${build}/u-boot.bin ${mount_dir}/rpi3-u-boot.bin
diff --git a/bin/writer.zynq_mount b/bin/writer.zynq_mount
index 9d0958880422..c8395a40680e 100755
--- a/bin/writer.zynq_mount
+++ b/bin/writer.zynq_mount
@@ -20,22 +20,17 @@
 
 # Writes zynq images to the board
 
-# Args:
-#  $1: Mount point of the sdcard when board is off
-#  $2: U-Boot build directory
-
 set -ex
 
 tmp=$(mktemp -d)
 
-mount=$1
-build=$2
+build=${U_BOOT_BUILD_DIR}
 
-echo "Writing to ${mount} from build at ${build}"
+echo "Writing to ${mount_dir} from build at ${build}"
 
 # Copy U-Boot over from the build directory
-cp ${build}/u-boot.bin ${mount}/rpi3-u-boot.bin
+cp ${build}/u-boot.bin ${mount_dir}/rpi3-u-boot.bin
 zynq-boot-bin.py -o ${tmp}/boot.bin -u ${build}/spl/u-boot-spl-dtb.bin
-cp ${tmp}/boot.bin ${mount}/BOOT.bin
-cp ${build}/u-boot.img ${mount}/.
+cp ${tmp}/boot.bin ${mount_dir}/BOOT.bin
+cp ${build}/u-boot.img ${mount_dir}/.
 rm -rf ${tmp}
-- 
2.34.1

Re: [u-boot-test-hooks PATCH 1/1] qemu_arm64_na: enable semihosting

[Tom Rini]

On Sat, 13 May 2023 00:59:30 +0200, Heinrich Schuchardt wrote:
> For testing semihosting we need to pass parameter -semihosting.
> 
> 

Applied, thanks!

[1/1] qemu_arm64_na: enable semihosting
  commit: 610263e34c6ceba0de5cd69a7c4e5a6205b886f9

Best regards,
-- 
Tom

[u-boot-test-hooks PATCH 1/1] qemu_arm64_na: enable semihosting

[Heinrich Schuchardt]

For testing semihosting we need to pass parameter -semihosting.

Signed-off-by: Heinrich Schuchardt 
---
 bin/travis-ci/conf.qemu_arm64_na | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/travis-ci/conf.qemu_arm64_na b/bin/travis-ci/conf.qemu_arm64_na
index 14577d8..e195b5e 100644
--- a/bin/travis-ci/conf.qemu_arm64_na
+++ b/bin/travis-ci/conf.qemu_arm64_na
@@ -24,7 +24,7 @@ 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 -chardev socket,id=chrtpm,path=/tmp/tpm/swtpm-sock -tpmdev 
emulator,id=tpm0,chardev=chrtpm -device tpm-tis-device,tpmdev=tpm0"
+qemu_extra_args="-cpu cortex-a57 -nographic -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device e1000,netdev=net0 -device 
virtio-rng-pci -semihosting -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
-- 
2.39.2

Re: [u-boot-test-hooks PATCH 0/2] Aspeed updates

[Tom Rini]

On Fri, 24 Jun 2022 12:04:18 +0930, Joel Stanley wrote:
> This updates the configuration for the aspeed machines, adding support
> for the ast2600.
> 
> Joel Stanley (2):
>   ast2500: Simplify Qemu command line
>   travis-ci: Add Aspeed AST2600 Qemu configuration
> 
> [...]

Applied, thanks!

[1/2] ast2500: Simplify Qemu command line
  commit: 0a7395692b6f7e8ca4afc49b570e730a0d288646
[2/2] travis-ci: Add Aspeed AST2600 Qemu configuration
  commit: 457656fc43140eab1aab1380427a48ca89d6d462

Best regards,
-- 
Tom

Re: [u-boot-test-hooks PATCH 0/2] Aspeed updates

[Tom Rini]

On Fri, Jun 24, 2022 at 12:04:18PM +0930, Joel Stanley wrote:

> Hi Tom,
> 
> This updates the configuration for the aspeed machines, adding support
> for the ast2600.
> 
> Joel Stanley (2):
>   ast2500: Simplify Qemu command line
>   travis-ci: Add Aspeed AST2600 Qemu configuration
> 
>  bin/travis-ci/conf.evb-ast2500_qemu  |  2 +-
>  bin/travis-ci/conf.evb-ast2600_qemu  | 13 +
>  py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py |  4 
>  3 files changed, 18 insertions(+), 1 deletion(-)
>  create mode 100644 bin/travis-ci/conf.evb-ast2600_qemu
>  create mode 100644 py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py

Thanks, I'll pick these up soon.

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 2/2] travis-ci: Add Aspeed AST2600 Qemu configuration

[Cédric Le Goater]

On 6/24/22 04:34, Joel Stanley wrote:

Similar to the AST2500 this machine is emulated by Qemu. It boots from
a 64MB SPI NOR flash device by default.

Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 

Thanks,

C.


---
  bin/travis-ci/conf.evb-ast2600_qemu  | 13 +
  py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py |  4 
  2 files changed, 17 insertions(+)
  create mode 100644 bin/travis-ci/conf.evb-ast2600_qemu
  create mode 100644 py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py

diff --git a/bin/travis-ci/conf.evb-ast2600_qemu 
b/bin/travis-ci/conf.evb-ast2600_qemu
new file mode 100644
index ..386ff7d25774
--- /dev/null
+++ b/bin/travis-ci/conf.evb-ast2600_qemu
@@ -0,0 +1,13 @@
+# Copyright 2022 IBM Corp.
+# Joel Stanley 
+# SPDX-License-Identifier: GPL-2.0+
+
+console_impl=qemu
+qemu_machine="ast2600-evb"
+qemu_binary="qemu-system-arm"
+qemu_extra_args="-nographic -nic user,tftp=${UBOOT_TRAVIS_BUILD_DIR}"
+qemu_kernel_args="-drive file=${U_BOOT_BUILD_DIR}/flash.img,format=raw,if=mtd"
+flash_u_boot_bin="u-boot-with-spl.bin"
+reset_impl=none
+flash_impl=qemu_gen_padded_image
+flash_size=64
diff --git a/py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py 
b/py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py
new file mode 100644
index ..396261efa3a3
--- /dev/null
+++ b/py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py
@@ -0,0 +1,4 @@
+import travis_tftp
+
+env__net_dhcp_server = True
+env__net_tftp_readable_file = travis_tftp.file2env('u-boot')

Re: [u-boot-test-hooks PATCH 1/2] ast2500: Simplify Qemu command line

[Cédric Le Goater]

On 6/24/22 04:34, Joel Stanley wrote:

The Aspeed machine in Qemu has appropriate defaults so we don't need to
specify these options.

Signed-off-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 

Thanks,

C.


---
  bin/travis-ci/conf.evb-ast2500_qemu | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/travis-ci/conf.evb-ast2500_qemu 
b/bin/travis-ci/conf.evb-ast2500_qemu
index 7f0f3c56e006..2e9adc6af9b0 100644
--- a/bin/travis-ci/conf.evb-ast2500_qemu
+++ b/bin/travis-ci/conf.evb-ast2500_qemu
@@ -5,7 +5,7 @@
  console_impl=qemu
  qemu_machine="ast2500-evb"
  qemu_binary="qemu-system-arm"
-qemu_extra_args="-nographic -m 512M -serial mon:stdio -net nic,model=ftgmac100 -net 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR}"
+qemu_extra_args="-nographic -nic user,tftp=${UBOOT_TRAVIS_BUILD_DIR}"
  qemu_kernel_args="-drive file=${U_BOOT_BUILD_DIR}/flash.img,format=raw,if=mtd"
  reset_impl=none
  flash_impl=qemu_gen_padded_image

[u-boot-test-hooks PATCH 2/2] travis-ci: Add Aspeed AST2600 Qemu configuration

[Joel Stanley]

Similar to the AST2500 this machine is emulated by Qemu. It boots from
a 64MB SPI NOR flash device by default.

Signed-off-by: Joel Stanley 
---
 bin/travis-ci/conf.evb-ast2600_qemu  | 13 +
 py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py |  4 
 2 files changed, 17 insertions(+)
 create mode 100644 bin/travis-ci/conf.evb-ast2600_qemu
 create mode 100644 py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py

diff --git a/bin/travis-ci/conf.evb-ast2600_qemu 
b/bin/travis-ci/conf.evb-ast2600_qemu
new file mode 100644
index ..386ff7d25774
--- /dev/null
+++ b/bin/travis-ci/conf.evb-ast2600_qemu
@@ -0,0 +1,13 @@
+# Copyright 2022 IBM Corp.
+# Joel Stanley 
+# SPDX-License-Identifier: GPL-2.0+
+
+console_impl=qemu
+qemu_machine="ast2600-evb"
+qemu_binary="qemu-system-arm"
+qemu_extra_args="-nographic -nic user,tftp=${UBOOT_TRAVIS_BUILD_DIR}"
+qemu_kernel_args="-drive file=${U_BOOT_BUILD_DIR}/flash.img,format=raw,if=mtd"
+flash_u_boot_bin="u-boot-with-spl.bin"
+reset_impl=none
+flash_impl=qemu_gen_padded_image
+flash_size=64
diff --git a/py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py 
b/py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py
new file mode 100644
index ..396261efa3a3
--- /dev/null
+++ b/py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py
@@ -0,0 +1,4 @@
+import travis_tftp
+
+env__net_dhcp_server = True
+env__net_tftp_readable_file = travis_tftp.file2env('u-boot')
-- 
2.35.1

[u-boot-test-hooks PATCH 1/2] ast2500: Simplify Qemu command line

[Joel Stanley]

The Aspeed machine in Qemu has appropriate defaults so we don't need to
specify these options.

Signed-off-by: Joel Stanley 
---
 bin/travis-ci/conf.evb-ast2500_qemu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/travis-ci/conf.evb-ast2500_qemu 
b/bin/travis-ci/conf.evb-ast2500_qemu
index 7f0f3c56e006..2e9adc6af9b0 100644
--- a/bin/travis-ci/conf.evb-ast2500_qemu
+++ b/bin/travis-ci/conf.evb-ast2500_qemu
@@ -5,7 +5,7 @@
 console_impl=qemu
 qemu_machine="ast2500-evb"
 qemu_binary="qemu-system-arm"
-qemu_extra_args="-nographic -m 512M -serial mon:stdio -net nic,model=ftgmac100 
-net user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR}"
+qemu_extra_args="-nographic -nic user,tftp=${UBOOT_TRAVIS_BUILD_DIR}"
 qemu_kernel_args="-drive file=${U_BOOT_BUILD_DIR}/flash.img,format=raw,if=mtd"
 reset_impl=none
 flash_impl=qemu_gen_padded_image
-- 
2.35.1

[u-boot-test-hooks PATCH 0/2] Aspeed updates

[Joel Stanley]

Hi Tom,

This updates the configuration for the aspeed machines, adding support
for the ast2600.

Joel Stanley (2):
  ast2500: Simplify Qemu command line
  travis-ci: Add Aspeed AST2600 Qemu configuration

 bin/travis-ci/conf.evb-ast2500_qemu  |  2 +-
 bin/travis-ci/conf.evb-ast2600_qemu  | 13 +
 py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py |  4 
 3 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 bin/travis-ci/conf.evb-ast2600_qemu
 create mode 100644 py/travis-ci/u_boot_boardenv_evb-ast2600_qemu.py

-- 
2.35.1

Re: root access and u-boot-test-hooks scripts

[Tom Rini]

On Fri, Apr 29, 2022 at 03:19:00PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi Tom
> 
> On Fri, Apr 29, 2022 at 3:04 PM Tom Rini  wrote:
> >
> > Hey all,
> >
> > I'm looking for some feedback and ideas.  Today, in our
> > u-boot-test-hooks repository we have 2 cases that use sudo, imx_usb and
> 
> I'm not a super expert but is it sufficient to use udev and insert the right
> on a group for a particular vendor and product id?

You can do some mount-based rules there as well, but that gets trickier
still to document / make portable.

> > L4T-based flashing.  Other places that may require root access, such as
> > mounting a filesystem instead assume an /etc/fstab entry exists and has
> > "user" as one of the attributes.
> 
> If you have a docker container --previlege should not be possible to mount
> but stay in a different name space?

I honestly don't know how well all of the tooling would work
containerized, especially since we're talking about dynamically
appearing/disappearing devices (ie we run sd-mux-ctrl to tell the sd-mux
board via USB to present the SD card to us as a mass storage device,
mount it via UUID, copy things, unmount, tell the sd-mux board to
present it to the device under test now instead).

-- 
Tom


signature.asc
Description: PGP signature

Re: root access and u-boot-test-hooks scripts

[Michael Nazzareno Trimarchi]

Hi Tom

On Fri, Apr 29, 2022 at 3:04 PM Tom Rini  wrote:
>
> Hey all,
>
> I'm looking for some feedback and ideas.  Today, in our
> u-boot-test-hooks repository we have 2 cases that use sudo, imx_usb and

I'm not a super expert but is it sufficient to use udev and insert the right
on a group for a particular vendor and product id?

> L4T-based flashing.  Other places that may require root access, such as
> mounting a filesystem instead assume an /etc/fstab entry exists and has
> "user" as one of the attributes.

If you have a docker container --previlege should not be possible to mount
but stay in a different name space?

Michael
>
> Locally, I've extended using "sudo" instead for further access, and so
> far have updated the rpi3_mount script to be like the flashair one and
> support all of the platforms (by naming u-boot.bin correctly for the
> platform) and I've got an easily re-usable ti-omap writer as well (ti-k3
> is harder since you need to build two distinct U-Boots).
>
> Would people rather see more sudo use, or more /etc/fstab setup
> required?  I'm happy to adjust what I've done to not use sudo and post
> that.
>
> --
> Tom



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com

root access and u-boot-test-hooks scripts

[Tom Rini]

Hey all,

I'm looking for some feedback and ideas.  Today, in our
u-boot-test-hooks repository we have 2 cases that use sudo, imx_usb and
L4T-based flashing.  Other places that may require root access, such as
mounting a filesystem instead assume an /etc/fstab entry exists and has
"user" as one of the attributes.

Locally, I've extended using "sudo" instead for further access, and so
far have updated the rpi3_mount script to be like the flashair one and
support all of the platforms (by naming u-boot.bin correctly for the
platform) and I've got an easily re-usable ti-omap writer as well (ti-k3
is harder since you need to build two distinct U-Boots).

Would people rather see more sudo use, or more /etc/fstab setup
required?  I'm happy to adjust what I've done to not use sudo and post
that.

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH v2] travis-ci: Add tests for booting from coreboot

[Tom Rini]

On Fri, Dec 03, 2021 at 08:52:38AM -0700, Simon Glass wrote:

> Add a means of testing a coreboot + U-Boot build using qemu.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH v2] travis-ci: Add tests for booting from coreboot

[Tom Rini]

On Fri, Dec 03, 2021 at 09:17:20AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 3 Dec 2021 at 09:02, Tom Rini  wrote:
> >
> > On Fri, Dec 03, 2021 at 08:52:38AM -0700, Simon Glass wrote:
> >
> > > Add a means of testing a coreboot + U-Boot build using qemu.
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > > As to what to do with people's labs, I think applying these patches does
> > > encourage them and provide people with examples. Having 'no mainline' for
> > > these is going to be an impediment I think.
> > >
> > > Changes in v2:
> > > - Drop the ellesmere symlink
> > >
> > >  bin/travis-ci/conf.coreboot_qemu | 28 
> > >  1 file changed, 28 insertions(+)
> > >  create mode 100644 bin/travis-ci/conf.coreboot_qemu
> >
> > So, now we have the conf, for something 100% virtual, in bin/travis-ci
> > (which yes, ugh, bad name).  If we had a top-level README.rst how would
> > it be unclear that this is a functional example?  In fact, maybe we
> > should clear something up.  How does the network test work for you?  I
> > have to modify them to pass -tftp=/tftpboot so that I can then give it
> > things like helloworld.efi and appropriate grub.efi.  Are you using some
> > wrapper to make things look more like what CI does?
> 
> I haven't tried the network tests, actually. Mostly I run individual
> tests or just boot to a prompt and try things out. One day I would
> like to get labman closer to making this automatic.

Ah.  I have a wrapper to activate a virtualenv for the pytest stuff,
then set PYTHONPATH / UBOOT_TRAVIS_BUILD_DIR and it all just works.
Except since I want to test the network a bit more heavily, I pass in my
own tftpboot dir, with a larger test file.  I could possibly change
things to wrap up and look more like CI does, and require less tweaking.

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH v2] travis-ci: Add tests for booting from coreboot

[Simon Glass]

Hi Tom,

On Fri, 3 Dec 2021 at 09:02, Tom Rini  wrote:
>
> On Fri, Dec 03, 2021 at 08:52:38AM -0700, Simon Glass wrote:
>
> > Add a means of testing a coreboot + U-Boot build using qemu.
> >
> > Signed-off-by: Simon Glass 
> > ---
> > As to what to do with people's labs, I think applying these patches does
> > encourage them and provide people with examples. Having 'no mainline' for
> > these is going to be an impediment I think.
> >
> > Changes in v2:
> > - Drop the ellesmere symlink
> >
> >  bin/travis-ci/conf.coreboot_qemu | 28 
> >  1 file changed, 28 insertions(+)
> >  create mode 100644 bin/travis-ci/conf.coreboot_qemu
>
> So, now we have the conf, for something 100% virtual, in bin/travis-ci
> (which yes, ugh, bad name).  If we had a top-level README.rst how would
> it be unclear that this is a functional example?  In fact, maybe we
> should clear something up.  How does the network test work for you?  I
> have to modify them to pass -tftp=/tftpboot so that I can then give it
> things like helloworld.efi and appropriate grub.efi.  Are you using some
> wrapper to make things look more like what CI does?

I haven't tried the network tests, actually. Mostly I run individual
tests or just boot to a prompt and try things out. One day I would
like to get labman closer to making this automatic.

Regards,
Simon

Re: [u-boot-test-hooks PATCH v2] travis-ci: Add tests for booting from coreboot

[Tom Rini]

On Fri, Dec 03, 2021 at 08:52:38AM -0700, Simon Glass wrote:

> Add a means of testing a coreboot + U-Boot build using qemu.
> 
> Signed-off-by: Simon Glass 
> ---
> As to what to do with people's labs, I think applying these patches does
> encourage them and provide people with examples. Having 'no mainline' for
> these is going to be an impediment I think.
> 
> Changes in v2:
> - Drop the ellesmere symlink
> 
>  bin/travis-ci/conf.coreboot_qemu | 28 
>  1 file changed, 28 insertions(+)
>  create mode 100644 bin/travis-ci/conf.coreboot_qemu

So, now we have the conf, for something 100% virtual, in bin/travis-ci
(which yes, ugh, bad name).  If we had a top-level README.rst how would
it be unclear that this is a functional example?  In fact, maybe we
should clear something up.  How does the network test work for you?  I
have to modify them to pass -tftp=/tftpboot so that I can then give it
things like helloworld.efi and appropriate grub.efi.  Are you using some
wrapper to make things look more like what CI does?

-- 
Tom


signature.asc
Description: PGP signature

[u-boot-test-hooks PATCH v2] travis-ci: Add tests for booting from coreboot

[Simon Glass]

Add a means of testing a coreboot + U-Boot build using qemu.

Signed-off-by: Simon Glass 
---
As to what to do with people's labs, I think applying these patches does
encourage them and provide people with examples. Having 'no mainline' for
these is going to be an impediment I think.

Changes in v2:
- Drop the ellesmere symlink

 bin/travis-ci/conf.coreboot_qemu | 28 
 1 file changed, 28 insertions(+)
 create mode 100644 bin/travis-ci/conf.coreboot_qemu

diff --git a/bin/travis-ci/conf.coreboot_qemu b/bin/travis-ci/conf.coreboot_qemu
new file mode 100644
index 000..76d6927
--- /dev/null
+++ b/bin/travis-ci/conf.coreboot_qemu
@@ -0,0 +1,28 @@
+# Copyright (c) 2016 Konsulko Group. All rights reserved.
+# Copyright 2021 Google LLC
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+console_impl=qemu
+qemu_machine="pc"
+qemu_binary="qemu-system-i386"
+qemu_extra_args="-nographic -cpu qemu32 -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device e1000,netdev=net0"
+qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/coreboot.rom"
+reset_impl=none
+flash_impl=none
-- 
2.34.0.384.gca35af8252-goog

Re: [u-boot-test-hooks PATCH] travis-ci: Add tests for booting from coreboot

[Tom Rini]

On Thu, Dec 02, 2021 at 07:05:47PM -0700, Simon Glass wrote:

> Add a means of testing a coreboot + U-Boot build using qemu.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  bin/ellesmere/conf.coreboot_qemu |  1 +
>  bin/travis-ci/conf.coreboot_qemu | 28 
>  2 files changed, 29 insertions(+)
>  create mode 12 bin/ellesmere/conf.coreboot_qemu
>  create mode 100644 bin/travis-ci/conf.coreboot_qemu

Please just include this in travis-ci.  I'm not exactly sure of the best
way to handle the existing deployment dirs and turn them in to examples
for others, without breaking existing deployments, but I don't want to
add to this problem.

-- 
Tom


signature.asc
Description: PGP signature

[u-boot-test-hooks PATCH] travis-ci: Add tests for booting from coreboot

[Simon Glass]

Add a means of testing a coreboot + U-Boot build using qemu.

Signed-off-by: Simon Glass 
---

 bin/ellesmere/conf.coreboot_qemu |  1 +
 bin/travis-ci/conf.coreboot_qemu | 28 
 2 files changed, 29 insertions(+)
 create mode 12 bin/ellesmere/conf.coreboot_qemu
 create mode 100644 bin/travis-ci/conf.coreboot_qemu

diff --git a/bin/ellesmere/conf.coreboot_qemu b/bin/ellesmere/conf.coreboot_qemu
new file mode 12
index 000..c81eb3f
--- /dev/null
+++ b/bin/ellesmere/conf.coreboot_qemu
@@ -0,0 +1 @@
+../travis-ci/conf.coreboot_qemu
\ No newline at end of file
diff --git a/bin/travis-ci/conf.coreboot_qemu b/bin/travis-ci/conf.coreboot_qemu
new file mode 100644
index 000..76d6927
--- /dev/null
+++ b/bin/travis-ci/conf.coreboot_qemu
@@ -0,0 +1,28 @@
+# Copyright (c) 2016 Konsulko Group. All rights reserved.
+# Copyright 2021 Google LLC
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+console_impl=qemu
+qemu_machine="pc"
+qemu_binary="qemu-system-i386"
+qemu_extra_args="-nographic -cpu qemu32 -netdev 
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device e1000,netdev=net0"
+qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/coreboot.rom"
+reset_impl=none
+flash_impl=none
-- 
2.34.0.384.gca35af8252-goog

Re: [u-boot-test-hooks] writer: Add imx_raw variant

[Tom Rini]

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: [U-BOOT-TEST-HOOKS PATCH 1/1] Enable TPMv2 emulation

[Heinrich Schuchardt]

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

Re: [U-BOOT-TEST-HOOKS PATCH 1/1] Enable TPMv2 emulation

[Tom Rini]

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.

-- 
Tom


signature.asc
Description: PGP signature

Re: [U-BOOT-TEST-HOOKS PATCH 1/1] Enable TPMv2 emulation

[Heinrich Schuchardt]

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.

Best regards

Heinrich




  qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/u-boot.bin"
  reset_impl=none
  flash_impl=none
--
2.32.0



Other than that
Reviewed-by: Ilias Apalodimas 

Re: [U-BOOT-TEST-HOOKS PATCH 1/1] Enable TPMv2 emulation

[Ilias Apalodimas]

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'

> 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' 

>  qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/u-boot.bin"
>  reset_impl=none
>  flash_impl=none
> --
> 2.32.0
>

Other than that
Reviewed-by: Ilias Apalodimas 

[U-BOOT-TEST-HOOKS PATCH 1/1] Enable TPMv2 emulation

[Heinrich Schuchardt]

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 &
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"
 qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/u-boot.bin"
 reset_impl=none
 flash_impl=none
-- 
2.32.0

[u-boot-test-hooks] writer: Add imx_raw variant

[Tom Rini]

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 
---
 bin/writer.imx_raw | 39 +++
 1 file changed, 39 insertions(+)
 create mode 100755 bin/writer.imx_raw

diff --git a/bin/writer.imx_raw b/bin/writer.imx_raw
new file mode 100755
index ..4708bab3ca28
--- /dev/null
+++ b/bin/writer.imx_raw
@@ -0,0 +1,39 @@
+# Copyright 2021 Konsulko Group, All rights reserved.
+# Based on writer.sunxi_raw which is
+# Copyright 2019 Google LLC. All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+# Writes raw imx images to the board
+
+# Args:
+#  $1: Device path of the sdcard when board is off (e.g. /dev/sdcard0)
+#  $2: U-Boot build directory
+
+set -e
+
+device=$1
+build=$2
+
+echo "Writing to ${device} from build at ${build}"
+
+# At least partially zero out the previous image
+dd if=/dev/zero of=$device bs=1k seek=1 count=128
+dd if=${build}/u-boot-with-spl.imx of=$device bs=1024 seek=1
+sync $device
-- 
2.25.1

Re: [u-boot-test-hooks PATCH 6/7] kea: Add samus

[Tom Rini]

On Sat, Oct 30, 2021 at 12:25:38PM -0600, Simon Glass wrote:

> Add a config for samus, the Chromebook Pixel 2.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 5/7] Update sdwire script to wait for umount

[Tom Rini]

On Sat, Oct 30, 2021 at 12:25:37PM -0600, Simon Glass wrote:

> Sometimes the umount takes a while. Add the same wait loop as is used for
> mount. Also rename the 'done' variable to 'complete' to void confusing it
> with the end of the for loop.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 4/7] Add wait_raw_device for common code

[Tom Rini]

On Sat, Oct 30, 2021 at 12:25:36PM -0600, Simon Glass wrote:

> This code is duplicated in two scripts. Put it into a new wait_raw_device
> to avoid this. Also rename the 'done' variable to 'complete' to void
> confusing it with the end of the for loop.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 3/7] rpi3: Tweak the grep pattern

[Tom Rini]

On Sat, Oct 30, 2021 at 12:25:35PM -0600, Simon Glass wrote:

> Just to be safe, check for the pattern only at the start of a line, since
> it is possible to add a comment with this in it.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 2/7] sdwire: Tidy up the mount script

[Tom Rini]

On Sat, Oct 30, 2021 at 12:25:34PM -0600, Simon Glass wrote:

> Add a comment about the tools and drop the debugging, since this seems
> reliable now.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 1/7] travis-ci: Add qemu_arm_spl board

[Tom Rini]

On Sat, Oct 30, 2021 at 12:25:33PM -0600, Simon Glass wrote:

> From: Tuomas Tynkkynen 
> 
> This is similar to the existing qemu_arm target, except that the 'bios' is
> image.bin (containing both SPL and U-Boot) rather than in u-boot.bin
> 
> Signed-off-by: Simon Glass 

Aside from the wrong-From, for a v2 in the future, I'm holding off on
this until the passage stuff which makes use of this, is closer to going
in.

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 1/7] travis-ci: Add qemu_arm_spl board

[Tuomas Tynkkynen]

Hi,

On 30.10.2021 21.25, Simon Glass wrote:

From: Tuomas Tynkkynen 


^ Some mishap with the From: line here, since I did not write the patch?



This is similar to the existing qemu_arm target, except that the 'bios' is
image.bin (containing both SPL and U-Boot) rather than in u-boot.bin

Signed-off-by: Simon Glass 
---

Re: [u-boot-test-hooks PATCH 7/7] ellesmere: Add qemu rules

[Tom Rini]

On Sun, Oct 31, 2021 at 12:22:48PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, 31 Oct 2021 at 10:57, Tom Rini  wrote:
> >
> > On Sat, Oct 30, 2021 at 12:25:39PM -0600, Simon Glass wrote:
> >
> > > Add some symlinks so that qemu can be used on ellesmere.
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > >
> > >  bin/ellesmere/conf.qemu_arm_na | 1 +
> > >  bin/ellesmere/conf.qemu_arm_spl_na | 1 +
> > >  2 files changed, 2 insertions(+)
> > >  create mode 12 bin/ellesmere/conf.qemu_arm_na
> > >  create mode 12 bin/ellesmere/conf.qemu_arm_spl_na
> >
> > Alright, so I think the best use of the public u-boot-test-hooks is to
> > have first public CI used scripts (aka everything in {bin,py}/travis-ci)
> > and then we should move to having a reference directory.  It's not
> > useful to everyone for example to have symlinks like these here, for
> > your lab.  But it is very useful to have things like
> > bin/kea/conf.orangepi_pc_sjg-opi_pc which I used locally the other day
> > to make bin/bill-the-cat/conf.pine64_plus_na and I think everyone would
> > benefit from something like
> > bin/references/conf.sunxi_with_sdwire_and_digital-loggers so that anyone
> > else can figure out how to plumb in their own sunxi platform with sdwire
> > and then whatever reference they also need for power control, if not a
> > digital-loggers type "curl" solution.
> 
> OK. Can you apply the other patches? Then I'll check and try some renames.

I'll review the rest of the series soon, yes.

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 7/7] ellesmere: Add qemu rules

[Simon Glass]

Hi Tom,

On Sun, 31 Oct 2021 at 10:57, Tom Rini  wrote:
>
> On Sat, Oct 30, 2021 at 12:25:39PM -0600, Simon Glass wrote:
>
> > Add some symlinks so that qemu can be used on ellesmere.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  bin/ellesmere/conf.qemu_arm_na | 1 +
> >  bin/ellesmere/conf.qemu_arm_spl_na | 1 +
> >  2 files changed, 2 insertions(+)
> >  create mode 12 bin/ellesmere/conf.qemu_arm_na
> >  create mode 12 bin/ellesmere/conf.qemu_arm_spl_na
>
> Alright, so I think the best use of the public u-boot-test-hooks is to
> have first public CI used scripts (aka everything in {bin,py}/travis-ci)
> and then we should move to having a reference directory.  It's not
> useful to everyone for example to have symlinks like these here, for
> your lab.  But it is very useful to have things like
> bin/kea/conf.orangepi_pc_sjg-opi_pc which I used locally the other day
> to make bin/bill-the-cat/conf.pine64_plus_na and I think everyone would
> benefit from something like
> bin/references/conf.sunxi_with_sdwire_and_digital-loggers so that anyone
> else can figure out how to plumb in their own sunxi platform with sdwire
> and then whatever reference they also need for power control, if not a
> digital-loggers type "curl" solution.

OK. Can you apply the other patches? Then I'll check and try some renames.

Regards,
Simon

Re: [u-boot-test-hooks PATCH 7/7] ellesmere: Add qemu rules

[Tom Rini]

On Sat, Oct 30, 2021 at 12:25:39PM -0600, Simon Glass wrote:

> Add some symlinks so that qemu can be used on ellesmere.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  bin/ellesmere/conf.qemu_arm_na | 1 +
>  bin/ellesmere/conf.qemu_arm_spl_na | 1 +
>  2 files changed, 2 insertions(+)
>  create mode 12 bin/ellesmere/conf.qemu_arm_na
>  create mode 12 bin/ellesmere/conf.qemu_arm_spl_na

Alright, so I think the best use of the public u-boot-test-hooks is to
have first public CI used scripts (aka everything in {bin,py}/travis-ci)
and then we should move to having a reference directory.  It's not
useful to everyone for example to have symlinks like these here, for
your lab.  But it is very useful to have things like
bin/kea/conf.orangepi_pc_sjg-opi_pc which I used locally the other day
to make bin/bill-the-cat/conf.pine64_plus_na and I think everyone would
benefit from something like
bin/references/conf.sunxi_with_sdwire_and_digital-loggers so that anyone
else can figure out how to plumb in their own sunxi platform with sdwire
and then whatever reference they also need for power control, if not a
digital-loggers type "curl" solution.

-- 
Tom


signature.asc
Description: PGP signature

[u-boot-test-hooks PATCH 3/7] rpi3: Tweak the grep pattern

[Simon Glass]

Just to be safe, check for the pattern only at the start of a line, since
it is possible to add a comment with this in it.

Signed-off-by: Simon Glass 
---

 bin/writer.rpi3_mount | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/writer.rpi3_mount b/bin/writer.rpi3_mount
index 7b078a1..97f24a5 100755
--- a/bin/writer.rpi3_mount
+++ b/bin/writer.rpi3_mount
@@ -41,7 +41,7 @@ fi
 
 # Enable the UART and fix the GPU frequency so it works correctly
 sed -i '/enable_uart/c\enable_uart = 1' /media/rpi3_b_boot/config.txt
-if ! grep -q gpu_freq=250 /media/rpi3_b_boot/config.txt; then
+if ! grep -q "^gpu_freq=250" /media/rpi3_b_boot/config.txt; then
 echo 'gpu_freq=250' >>/media/rpi3_b_boot/config.txt
 fi
 
-- 
2.33.1.1089.g2158813163f-goog

[u-boot-test-hooks PATCH 7/7] ellesmere: Add qemu rules

[Simon Glass]

Add some symlinks so that qemu can be used on ellesmere.

Signed-off-by: Simon Glass 
---

 bin/ellesmere/conf.qemu_arm_na | 1 +
 bin/ellesmere/conf.qemu_arm_spl_na | 1 +
 2 files changed, 2 insertions(+)
 create mode 12 bin/ellesmere/conf.qemu_arm_na
 create mode 12 bin/ellesmere/conf.qemu_arm_spl_na

diff --git a/bin/ellesmere/conf.qemu_arm_na b/bin/ellesmere/conf.qemu_arm_na
new file mode 12
index 000..aa91a9f
--- /dev/null
+++ b/bin/ellesmere/conf.qemu_arm_na
@@ -0,0 +1 @@
+../travis-ci/conf.qemu_arm_na
\ No newline at end of file
diff --git a/bin/ellesmere/conf.qemu_arm_spl_na 
b/bin/ellesmere/conf.qemu_arm_spl_na
new file mode 12
index 000..e171c5a
--- /dev/null
+++ b/bin/ellesmere/conf.qemu_arm_spl_na
@@ -0,0 +1 @@
+../travis-ci/conf.qemu_arm_spl_na
\ No newline at end of file
-- 
2.33.1.1089.g2158813163f-goog

[u-boot-test-hooks PATCH 5/7] Update sdwire script to wait for umount

[Simon Glass]

Sometimes the umount takes a while. Add the same wait loop as is used for
mount. Also rename the 'done' variable to 'complete' to void confusing it
with the end of the for loop.

Signed-off-by: Simon Glass 
---

 bin/flash.sdwire_common_mount | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/bin/flash.sdwire_common_mount b/bin/flash.sdwire_common_mount
index d696abb..6c763e6 100644
--- a/bin/flash.sdwire_common_mount
+++ b/bin/flash.sdwire_common_mount
@@ -25,10 +25,10 @@ mount_dir=/media/${mount_point}
 # Switch over to get USB card access
 sd-mux-ctrl --device-serial ${sdwire_serial} --ts
 
-done=false
+complete=false
 for i in {0..9}; do
 if out="$(mount UUID=${mount_uuid} 2>&1)"; then
-done=true
+complete=true
 break
 fi
 echo $out
@@ -41,7 +41,7 @@ for i in {0..9}; do
 fi
 sleep 1
 done
-if [[ $done = false ]]; then
+if [[ $complete = false ]]; then
 echo "Failed to mount UUID ${mount_uuid} after 10 tries"
 exit 1
 fi
@@ -53,7 +53,27 @@ if ! mountpoint -q ${mount_dir}; then
 fi
 
 writer.${flash_writer} ${mount_dir} ${U_BOOT_BUILD_DIR}
-umount ${mount_dir}
+
+complete=false
+for i in {0..9}; do
+if out="$(umount ${mount_dir} 2>&1)"; then
+complete=true
+break
+fi
+echo $out
+sleep 1
+done
+
+if [[ $complete = false ]]; then
+echo "Failed to umount UUID ${mount_uuid} after 10 tries"
+exit 1
+fi
+
+# Sanity check
+if mountpoint -q ${mount_dir}; then
+echo "Mount ${mount_dir} still available after 'umount'"
+exit 1
+fi
 
 # Back to card access for the DUT
 sd-mux-ctrl --device-serial ${sdwire_serial} --dut
-- 
2.33.1.1089.g2158813163f-goog

[u-boot-test-hooks PATCH 4/7] Add wait_raw_device for common code

[Simon Glass]

This code is duplicated in two scripts. Put it into a new wait_raw_device
to avoid this. Also rename the 'done' variable to 'complete' to void
confusing it with the end of the for loop.

Signed-off-by: Simon Glass 
---

 bin/flash.sdwire_digital-loggers_raw | 15 +---
 bin/flash.sdwire_poweroff_raw| 15 +---
 bin/wait_raw_device  | 34 
 3 files changed, 36 insertions(+), 28 deletions(-)
 create mode 100644 bin/wait_raw_device

diff --git a/bin/flash.sdwire_digital-loggers_raw 
b/bin/flash.sdwire_digital-loggers_raw
index 7d5fbc9..f9956f7 100644
--- a/bin/flash.sdwire_digital-loggers_raw
+++ b/bin/flash.sdwire_digital-loggers_raw
@@ -33,20 +33,7 @@ curl --data ${power_port}=OFF -o /dev/null --silent \
 # Switch over to get USB card access
 sd-mux-ctrl --device-serial ${sdwire_serial} --ts
 
-# Wait for the device to become available
-done=false
-for i in {0..9}; do
-if dd if=${raw_device} of=/dev/null count=1 >/dev/null 2>&1; then
-done=true
-break
-fi
-
-sleep 1
-done
-if [[ $done = false ]]; then
-echo "Failed to access ${raw_device} after 10 tries"
-exit 1
-fi
+. wait_raw_device
 
 writer.${flash_writer} ${raw_device} ${U_BOOT_BUILD_DIR}
 
diff --git a/bin/flash.sdwire_poweroff_raw b/bin/flash.sdwire_poweroff_raw
index 28fa096..d82a3ef 100644
--- a/bin/flash.sdwire_poweroff_raw
+++ b/bin/flash.sdwire_poweroff_raw
@@ -34,20 +34,7 @@ mount_dir=/media/${mount_point}
 # Switch over to get USB card access
 sd-mux-ctrl --device-serial ${sdwire_serial} --ts
 
-# Wait for the device to become available
-done=false
-for i in {0..9}; do
-if dd if=${raw_device} of=/dev/null count=1 >/dev/null 2>&1; then
-done=true
-break
-fi
-
-sleep 1
-done
-if [[ $done = false ]]; then
-echo "Failed to access ${raw_device} after 10 tries"
-exit 1
-fi
+. wait_raw_device
 
 writer.${flash_writer} ${raw_device} ${U_BOOT_BUILD_DIR}
 
diff --git a/bin/wait_raw_device b/bin/wait_raw_device
new file mode 100644
index 000..c292114
--- /dev/null
+++ b/bin/wait_raw_device
@@ -0,0 +1,34 @@
+# Copyright 2021 Google LLC
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+# Wait for the device ${raw_device} to become available
+complete=false
+for i in {0..9}; do
+if dd if=${raw_device} of=/dev/null count=1 >/dev/null 2>&1; then
+complete=true
+break
+fi
+
+sleep 1
+done
+if [[ $complete = false ]]; then
+echo "Failed to access ${raw_device} after 10 tries"
+exit 1
+fi
-- 
2.33.1.1089.g2158813163f-goog

[u-boot-test-hooks PATCH 6/7] kea: Add samus

[Simon Glass]

Add a config for samus, the Chromebook Pixel 2.

Signed-off-by: Simon Glass 
---

 bin/kea/conf.chromebook_samus_sjg-samus | 30 +
 1 file changed, 30 insertions(+)
 create mode 100644 bin/kea/conf.chromebook_samus_sjg-samus

diff --git a/bin/kea/conf.chromebook_samus_sjg-samus 
b/bin/kea/conf.chromebook_samus_sjg-samus
new file mode 100644
index 000..0e7db49
--- /dev/null
+++ b/bin/kea/conf.chromebook_samus_sjg-samus
@@ -0,0 +1,30 @@
+# Copyright 2021 Google LLC
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+reset_impl=servo
+flash_impl=em100
+power_impl=servo
+
+em100_chip=W25Q64FV
+em100_serial=DP033694
+
+servo_name=samus
+
+. ubtest_common
-- 
2.33.1.1089.g2158813163f-goog

[u-boot-test-hooks PATCH 2/7] sdwire: Tidy up the mount script

[Simon Glass]

Add a comment about the tools and drop the debugging, since this seems
reliable now.

Signed-off-by: Simon Glass 
---

 bin/flash.sdwire_relay_mount | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/bin/flash.sdwire_relay_mount b/bin/flash.sdwire_relay_mount
index 4713c2f..f75d33f 100644
--- a/bin/flash.sdwire_relay_mount
+++ b/bin/flash.sdwire_relay_mount
@@ -21,12 +21,14 @@
 # Designed for using SDwire uSD mux and selected power control:
 # https://wiki.tizen.org/SDWire
 
+# It requires these tools:
+# sd-mux-ctrl at https://git.tizen.org/cgit/tools/testlab/sd-mux/
+# usbrelay
+
 . poweroff.${power_impl}
 
 sleep 0.1
-echo common
 
 . flash.sdwire_common_mount
 
 . poweron.${power_impl}
-echo flash done
-- 
2.33.1.1089.g2158813163f-goog

[u-boot-test-hooks PATCH 1/7] travis-ci: Add qemu_arm_spl board

[Simon Glass]

From: Tuomas Tynkkynen 

This is similar to the existing qemu_arm target, except that the 'bios' is
image.bin (containing both SPL and U-Boot) rather than in u-boot.bin

Signed-off-by: Simon Glass 
---

 bin/travis-ci/conf.qemu_arm_spl_na | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 bin/travis-ci/conf.qemu_arm_spl_na

diff --git a/bin/travis-ci/conf.qemu_arm_spl_na 
b/bin/travis-ci/conf.qemu_arm_spl_na
new file mode 100644
index 000..18c7fe5
--- /dev/null
+++ b/bin/travis-ci/conf.qemu_arm_spl_na
@@ -0,0 +1,31 @@
+# Copyright 2021 Google LLC
+# Based on conf.vexpress_ca15_tc2_qemu which is:
+# Copyright (c) 2016 Konsulko Group. All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+console_impl=qemu
+qemu_machine="virt"
+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"
+
+# Uses image.bin which contains SPL and U-Boot
+qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/image.bin"
+reset_impl=none
+flash_impl=none
-- 
2.33.1.1089.g2158813163f-goog

Re: [u-boot-test-hooks PATCH] travis-ci: Add SiFive Unleashed QEMU targets

[Tom Rini]

On Sun, Aug 22, 2021 at 01:01:23PM +0800, Bin Meng wrote:

> Add support for testing sifive_unleashed_defconfig via QEMU.
> QEMU supports booting exact the same images as used on the real
> hardware out of the box, that U-Boot SPL loads U-Boot proper
> from either an SD card or the SPI NOR flash, hence we can easily
> set up CI to cover these 2 boot flows of SiFive Unleashed board.
> 
> Signed-off-by: Bin Meng 
> 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH] travis-ci: Correct the memory size for Xilinx Zynq QEMU

[Tom Rini]

On Sat, Aug 21, 2021 at 11:01:51PM +0800, Bin Meng wrote:

> Currently the memory is specified to be an insane size of about 38TB.
> This happens to be not an issue with QEMU 4.2.0 which is what U-Boot
> CI is currently using, but it does not make newer QEMU (e.g.: 6.0.0)
> happy. Change it to use a 1G memory size.
> 
> Fixes: 4fcc1d95a39f ("Add support for Xilinx Zynq Virtual platform")
> Signed-off-by: Bin Meng 
> 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH] Update Contributing.md with up-to-date information

[Tom Rini]

On Sat, Aug 21, 2021 at 05:45:08PM +0800, Bin Meng wrote:

> As Stephen is no longer actively maintaining the uboot-test-hooks,
> and the repo itself has been moved to source.denx.de, update the
> Contributing.md with up-to-date information on how patches should
> be sent against this repo.
> 
> Signed-off-by: Bin Meng 
> 

Applied to u-boot-test-hooks/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[u-boot-test-hooks PATCH] travis-ci: Add SiFive Unleashed QEMU targets

[Bin Meng]

Add support for testing sifive_unleashed_defconfig via QEMU.
QEMU supports booting exact the same images as used on the real
hardware out of the box, that U-Boot SPL loads U-Boot proper
from either an SD card or the SPI NOR flash, hence we can easily
set up CI to cover these 2 boot flows of SiFive Unleashed board.

Signed-off-by: Bin Meng 

---

 bin/travis-ci/conf.sifive_unleashed_sdcard_qemu   | 11 +++
 bin/travis-ci/conf.sifive_unleashed_spi-nor_qemu  | 11 +++
 .../u_boot_boardenv_sifive_unleashed_sdcard_qemu.py   | 10 ++
 .../u_boot_boardenv_sifive_unleashed_spi-nor_qemu.py  | 10 ++
 4 files changed, 42 insertions(+)
 create mode 100644 bin/travis-ci/conf.sifive_unleashed_sdcard_qemu
 create mode 100644 bin/travis-ci/conf.sifive_unleashed_spi-nor_qemu
 create mode 100644 py/travis-ci/u_boot_boardenv_sifive_unleashed_sdcard_qemu.py
 create mode 100644 
py/travis-ci/u_boot_boardenv_sifive_unleashed_spi-nor_qemu.py

diff --git a/bin/travis-ci/conf.sifive_unleashed_sdcard_qemu 
b/bin/travis-ci/conf.sifive_unleashed_sdcard_qemu
new file mode 100644
index 000..f3c3da1
--- /dev/null
+++ b/bin/travis-ci/conf.sifive_unleashed_sdcard_qemu
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright (c) 2021 Bin Meng 
+
+console_impl=qemu
+qemu_machine="sifive_u,msel=11"
+qemu_binary="qemu-system-riscv64"
+qemu_extra_args="-smp 5 -m 8G -nographic -nic 
user,tftp=${UBOOT_TRAVIS_BUILD_DIR}"
+qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/spl/u-boot-spl.bin -drive 
file=${U_BOOT_BUILD_DIR}/sdcard.img,if=sd"
+reset_impl=none
+flash_impl=none
diff --git a/bin/travis-ci/conf.sifive_unleashed_spi-nor_qemu 
b/bin/travis-ci/conf.sifive_unleashed_spi-nor_qemu
new file mode 100644
index 000..e28bfc4
--- /dev/null
+++ b/bin/travis-ci/conf.sifive_unleashed_spi-nor_qemu
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright (c) 2021 Bin Meng 
+
+console_impl=qemu
+qemu_machine="sifive_u,msel=6"
+qemu_binary="qemu-system-riscv64"
+qemu_extra_args="-smp 5 -m 8G -nographic -nic 
user,tftp=${UBOOT_TRAVIS_BUILD_DIR}"
+qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/spl/u-boot-spl.bin -drive 
file=${U_BOOT_BUILD_DIR}/spi-nor.img,if=mtd"
+reset_impl=none
+flash_impl=none
diff --git a/py/travis-ci/u_boot_boardenv_sifive_unleashed_sdcard_qemu.py 
b/py/travis-ci/u_boot_boardenv_sifive_unleashed_sdcard_qemu.py
new file mode 100644
index 000..a86e0bd
--- /dev/null
+++ b/py/travis-ci/u_boot_boardenv_sifive_unleashed_sdcard_qemu.py
@@ -0,0 +1,10 @@
+import os
+import travis_tftp
+
+env__net_dhcp_server = True
+env__net_tftp_readable_file = travis_tftp.file2env('u-boot')
+env__efi_loader_helloworld_file = 
travis_tftp.file2env('lib/efi_loader/helloworld.efi')
+env__efi_loader_grub_file = travis_tftp.file2env('grub_riscv64.efi')
+env__efi_fit_tftp_file = {
+"dn" : os.environ['UBOOT_TRAVIS_BUILD_DIR'],
+}
diff --git a/py/travis-ci/u_boot_boardenv_sifive_unleashed_spi-nor_qemu.py 
b/py/travis-ci/u_boot_boardenv_sifive_unleashed_spi-nor_qemu.py
new file mode 100644
index 000..a86e0bd
--- /dev/null
+++ b/py/travis-ci/u_boot_boardenv_sifive_unleashed_spi-nor_qemu.py
@@ -0,0 +1,10 @@
+import os
+import travis_tftp
+
+env__net_dhcp_server = True
+env__net_tftp_readable_file = travis_tftp.file2env('u-boot')
+env__efi_loader_helloworld_file = 
travis_tftp.file2env('lib/efi_loader/helloworld.efi')
+env__efi_loader_grub_file = travis_tftp.file2env('grub_riscv64.efi')
+env__efi_fit_tftp_file = {
+"dn" : os.environ['UBOOT_TRAVIS_BUILD_DIR'],
+}
-- 
2.25.1

[u-boot-test-hooks PATCH] travis-ci: Correct the memory size for Xilinx Zynq QEMU

[Bin Meng]

Currently the memory is specified to be an insane size of about 38TB.
This happens to be not an issue with QEMU 4.2.0 which is what U-Boot
CI is currently using, but it does not make newer QEMU (e.g.: 6.0.0)
happy. Change it to use a 1G memory size.

Fixes: 4fcc1d95a39f ("Add support for Xilinx Zynq Virtual platform")
Signed-off-by: Bin Meng 

---

 bin/travis-ci/conf.xilinx_zynq_virt_qemu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/travis-ci/conf.xilinx_zynq_virt_qemu 
b/bin/travis-ci/conf.xilinx_zynq_virt_qemu
index eef7904..a6af659 100644
--- a/bin/travis-ci/conf.xilinx_zynq_virt_qemu
+++ b/bin/travis-ci/conf.xilinx_zynq_virt_qemu
@@ -21,7 +21,7 @@
 console_impl=qemu
 qemu_machine="xilinx-zynq-a9"
 qemu_binary="qemu-system-arm"
-qemu_extra_args="-display none -m 4000 -nographic -serial /dev/null 
-serial mon:stdio -monitor null"
+qemu_extra_args="-display none -m 1G -nographic -serial /dev/null -serial 
mon:stdio -monitor null"
 qemu_kernel_args="-device 
loader,file=${U_BOOT_BUILD_DIR}/u-boot-dtb.bin,addr=0x400,cpu-num=0"
 reset_impl=none
 flash_impl=none
-- 
2.25.1

[u-boot-test-hooks PATCH] Update Contributing.md with up-to-date information

[Bin Meng]

As Stephen is no longer actively maintaining the uboot-test-hooks,
and the repo itself has been moved to source.denx.de, update the
Contributing.md with up-to-date information on how patches should
be sent against this repo.

Signed-off-by: Bin Meng 

---

 Contributing.md | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/Contributing.md b/Contributing.md
index e8bcfc4..b1f78a8 100644
--- a/Contributing.md
+++ b/Contributing.md
@@ -1,16 +1,14 @@
-To add patches to this repo, please either:
+To add patches to this repo, please send the patch via email, at least:
 
-a) Submit a github pull request.
-
-b) Send the patch via email, at least:
-
-To: swar...@nvidia.com
+To: "Tom Rini "
 
 Cc: u-boot@lists.denx.de
 
-With a subject prefix of "[PATCH test hooks]", i.e.:
+With a subject prefix of "[u-boot-test-hooks PATCH]", i.e.:
+
+git format-patch --subject-prefix='u-boot-test-hooks PATCH' ...
 
-git format-patch --subject-prefix='PATCH test hooks' ...
+or using patman with "Series-prefix: u-boot-test-hooks" to generate the patch.
 
 You will need to include a signed-off-by line in your patch. See
 https://developercertificate.org/ for the meaning of this.
-- 
2.25.1

Re: [U-Boot] test: Coverage error tools/binman/etype/cbfs.py 97% on i686

[Simon Glass]

Hi Heinrich,

On Thu, 7 Nov 2019 at 23:27, Heinrich Schuchardt  wrote:
>
> Hello Simon,
>
> make tests produces an error on i686
>
> NameStmts   Miss  Cover
> 
> tools/binman/etype/cbfs.py 90  397%
> 
> TOTAL2639 1199%
>
> Type 'python3-coverage html' to get a report in htmlcov/index.html

Can you try running that? I am not sure what is actually wrong here.

> Coverage error: 99%, but should be 100%
> ValueError: Test coverage failure
> dtoc code coverage: 
> 100%
> fdt code coverage: 
> 100%
> Tests FAILED
> make: *** [Makefile:2043: tests] Error 1

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] test: Coverage error tools/binman/etype/cbfs.py 97% on i686

[Heinrich Schuchardt]

Hello Simon,

make tests produces an error on i686

NameStmts   Miss  Cover

tools/binman/etype/cbfs.py 90  397%

TOTAL2639 1199%

Type 'python3-coverage html' to get a report in htmlcov/index.html
Coverage error: 99%, but should be 100%
ValueError: Test coverage failure
dtoc code coverage: 
100%
fdt code coverage: 
100%
Tests FAILED
make: *** [Makefile:2043: tests] Error 1

Best regards

Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: dm_mdio: avoid out of bounds access

[Joe Hershberger]

Hi Heinrich,

https://patchwork.ozlabs.org/patch/1139392/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: dm_mdio: add a 2nd register to the emulated PHY

[Joe Hershberger]

Hi Alex,

https://patchwork.ozlabs.org/patch/1131183/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: dm: add a test for MDIO MUX DM uclass

[Joe Hershberger]

Hi Alex,

https://patchwork.ozlabs.org/patch/1131184/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: dm: add MDIO test

[Joe Hershberger]

Hi Alex,

https://patchwork.ozlabs.org/patch/1109369/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: Update test-imagetools.sh to match new syntax

[Tom Rini]

On Thu, Feb 14, 2019 at 01:11:35PM +, Martyn Welch wrote:

> The syntax of dumpimage was simplified in commit 12b831879a76 ("tools:
> dumpimage: Simplify arguments"), but the test
> (test/image/test-imagetools.sh) was not updated and is now failing.
> 
> Update the test to use the new syntax.
> 
> Reported-by: Vagrant Cascadian 
> Signed-off-by: Martyn Welch 
> Tested-by: Vagrant Cascadian 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push

[Simon Goldschmidt]

Am Mi., 23. Jan. 2019, 19:20 hat Stephen Warren 
geschrieben:

> On 1/22/19 1:12 AM, Simon Goldschmidt wrote:
> > Hi Stephen,
> > On Fri, Jan 18, 2019 at 7:29 AM Stephen Warren 
> wrote:
> >>
> >> On 1/17/19 6:15 PM, Tom Rini wrote:
> >>> On Thu, Jan 17, 2019 at 05:50:27PM -0700, Stephen Warren wrote:
>  On 1/17/19 5:42 PM, Tom Rini wrote:
> > On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote:
> >
> >> Tom,
> >>
> >> The recent set of patches pushed to u-boot/master cause DFU
> failures on both
> >> Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU
> test) with
> >> the following in the log:
> >>
> >> host:
> >> dfu-util -a 0 -U
> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin
> >> -p 3-2.3
> >>
> >> target:
> >> ** Reading file would overwrite reserved memory **
> >> dfu: Read error!
> >> dfu_read: Failed to fill buffer
> >> Tegra124 (Jetson TK1) #
> >>
> >> I noticed some lmb fixes in the list, so I guess it's due to that.
> >
> > So.. intentional!  Adding in Simon here, but I think the short
> answer is
> > that you need to change where you're saying the file goes in memory.
> > FWIW I run the DFU test on my dra7xx_evm and it's passing.
> 
>  You applied a change which intentionally broke functionality??? That
> sounds
>  pretty bad...
> >>>
> >>> So, yes.  A design decision / feature of "don't check where we're
> >>> loading payloads to" is also a security vulnerability to bypass secure
> >>> boot.  So we now have changes in that make a good attempt at keeping us
> >>> from loading a payload that can in turn overwrite ourself.  And I
> merged
> >>> it super early in the merge window to try and catch the unintended
> >>> consequences.
> >>>
>  Looking at the precise test that failed, we don't actually specify
> where the
>  data goes in memory; it's written to the filesystem and all memmory
>  locations are internally allocated by U-Boot. So when you say "you
> need to
>  change where you're saying the file goes in memory", do you mean via
> the DFU
>  altinfo variable (which does not specify a memory location in this
> case, so
>  I can't), or by modifying some board-/SoC-specific config file or
> code to
>  specify where DFU buffers data (in which case, I'd argue that a
>  backwards-compatible default should have been put in place to prevent
>  breaking functionality)?
> 
>  The DFU altinfo values that are tested on both boards are:
> 
>  Fails:
> 
>  Device mmc 1 (which is an SD card):
>  "alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1",
> >>
> >>  "test_sizes": (
> >>  64 - 1,
> >>  64,
> >>  64 + 1,
> >>  4096 - 1,
> >>  ),
> >>  },
> >>
>  All pass:
> 
>  Device mmc 1 (which is an SD card):
>  "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1",
> >>
> >>  "test_sizes": (
> >>  128 - 1,
> >>  128,
> >>  128 + 1,
> >>  4096,
> >>  ),
> >>
>  Device mmc 1 (which is an SD card):
>  "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1",
> >>
> >>  "test_sizes": (
> >>  960 - 1,
> >>  960,
> >>  960 + 1,
> >>  4096 + 1,
> >>  ),
> >>
>  Device ram
>  "alt_info": "alt0 ram 8000 0100;alt1 ram 8100 0100",
> >>
> >>  "test_sizes": (
> >>  1024 * 1024 - 1,
> >>  1024 * 1024,
> >>  8 * 1024 * 1024,
> >>  ),
> >>
> >>> So that's interesting.  How big is dfu_test.bin?  Checking my config, I
> >>> don't have SD card only RAM.  If you do RAM only tests does it pass (as
> >>> that might narrow down where maybe something is wrong) ?
> >>
> >> Yes, that RAM-only test passes. The tests are run in the order listed
> above.
> >>
> >> test_dfu.py iterates over a bunch of different file sizes; I listed them
> >> below the DFU configs above.
> >
> > OK, I have absolutely no experience with DFU, so please be patient with
> me
> > when interpreting this wrong...
> >
> > Is it correct that the files above differ in that the one failing is
> > read via the ext4 fs
>
> Yes.
>
> Note that not all reads via ext4 fail, just in the case where *both* of
> the two DFU-accessible storage regions are on ext4.
>

Yeah, I didn't really get it why the other tests work...


> > driver? In that case, I guess it might be the ext4 fs driver trying to
> > load something into a buffer on the stack?
>
> I don't know the ext4 code well enough, but in general yes it might be
> using stack rather than malloc/similar buffers.
>

Checking that again, it's the buffer allocated by dfu via malloc that
doesn't work and it has nothing to do with ext4.

Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push

[Stephen Warren]

On 1/22/19 1:12 AM, Simon Goldschmidt wrote:

Hi Stephen,
On Fri, Jan 18, 2019 at 7:29 AM Stephen Warren  wrote:


On 1/17/19 6:15 PM, Tom Rini wrote:

On Thu, Jan 17, 2019 at 05:50:27PM -0700, Stephen Warren wrote:

On 1/17/19 5:42 PM, Tom Rini wrote:

On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote:


Tom,

The recent set of patches pushed to u-boot/master cause DFU failures on both
Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) with
the following in the log:

host:
dfu-util -a 0 -U 
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin
-p 3-2.3

target:
** Reading file would overwrite reserved memory **
dfu: Read error!
dfu_read: Failed to fill buffer
Tegra124 (Jetson TK1) #

I noticed some lmb fixes in the list, so I guess it's due to that.


So.. intentional!  Adding in Simon here, but I think the short answer is
that you need to change where you're saying the file goes in memory.
FWIW I run the DFU test on my dra7xx_evm and it's passing.


You applied a change which intentionally broke functionality??? That sounds
pretty bad...


So, yes.  A design decision / feature of "don't check where we're
loading payloads to" is also a security vulnerability to bypass secure
boot.  So we now have changes in that make a good attempt at keeping us
from loading a payload that can in turn overwrite ourself.  And I merged
it super early in the merge window to try and catch the unintended
consequences.


Looking at the precise test that failed, we don't actually specify where the
data goes in memory; it's written to the filesystem and all memmory
locations are internally allocated by U-Boot. So when you say "you need to
change where you're saying the file goes in memory", do you mean via the DFU
altinfo variable (which does not specify a memory location in this case, so
I can't), or by modifying some board-/SoC-specific config file or code to
specify where DFU buffers data (in which case, I'd argue that a
backwards-compatible default should have been put in place to prevent
breaking functionality)?

The DFU altinfo values that are tested on both boards are:

Fails:

Device mmc 1 (which is an SD card):
"alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1",


 "test_sizes": (
 64 - 1,
 64,
 64 + 1,
 4096 - 1,
 ),
 },


All pass:

Device mmc 1 (which is an SD card):
"alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1",


 "test_sizes": (
 128 - 1,
 128,
 128 + 1,
 4096,
 ),


Device mmc 1 (which is an SD card):
"alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1",


 "test_sizes": (
 960 - 1,
 960,
 960 + 1,
 4096 + 1,
 ),


Device ram
"alt_info": "alt0 ram 8000 0100;alt1 ram 8100 0100",


 "test_sizes": (
 1024 * 1024 - 1,
 1024 * 1024,
 8 * 1024 * 1024,
 ),


So that's interesting.  How big is dfu_test.bin?  Checking my config, I
don't have SD card only RAM.  If you do RAM only tests does it pass (as
that might narrow down where maybe something is wrong) ?


Yes, that RAM-only test passes. The tests are run in the order listed above.

test_dfu.py iterates over a bunch of different file sizes; I listed them
below the DFU configs above.


OK, I have absolutely no experience with DFU, so please be patient with me
when interpreting this wrong...

Is it correct that the files above differ in that the one failing is
read via the ext4 fs


Yes.

Note that not all reads via ext4 fail, just in the case where *both* of 
the two DFU-accessible storage regions are on ext4.



driver? In that case, I guess it might be the ext4 fs driver trying to
load something into a buffer on the stack?


I don't know the ext4 code well enough, but in general yes it might be 
using stack rather than malloc/similar buffers.



Could you try the attached patch where I added more debugging output? Maybe
I can read something from its output.


Target:

setenv "dfu_alt_info" "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1"

dfu 0 mmc 1

Host:

dfu-util -a 0 -D 
/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-p2371-2180/persistent-data/dfu_dummy.bin 
-p 3-13


Target:

mmc_file_op: ext4write mmc 1:1 dda3eb40 /dfu_test.bin 400 
0xdda26210


Host:

dfu-util -a 0 -D 
/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-p2371-2180/persistent-data/dfu_63.bin 
-p 3-13


Target:

mmc_file_op: ext4write mmc 1:1 dda3eb40 /dfu_test.bin 3f 
0xdda26210


Host:

dfu-util -a 1 -D 
/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-p2371-2180/persistent-data/dfu_dummy.bin 
-p 3-13


Target:

mmc_file_op: ext4write mmc 1:1 dda3eb40 /dfu_dummy.bin 400 
0xdda26210


Host:

dfu-util -a 0 -U 

Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push

[Simon Goldschmidt]

Hi Stephen,
On Fri, Jan 18, 2019 at 7:29 AM Stephen Warren  wrote:
>
> On 1/17/19 6:15 PM, Tom Rini wrote:
> > On Thu, Jan 17, 2019 at 05:50:27PM -0700, Stephen Warren wrote:
> >> On 1/17/19 5:42 PM, Tom Rini wrote:
> >>> On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote:
> >>>
>  Tom,
> 
>  The recent set of patches pushed to u-boot/master cause DFU failures on 
>  both
>  Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) 
>  with
>  the following in the log:
> 
>  host:
>  dfu-util -a 0 -U 
>  /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin
>  -p 3-2.3
> 
>  target:
>  ** Reading file would overwrite reserved memory **
>  dfu: Read error!
>  dfu_read: Failed to fill buffer
>  Tegra124 (Jetson TK1) #
> 
>  I noticed some lmb fixes in the list, so I guess it's due to that.
> >>>
> >>> So.. intentional!  Adding in Simon here, but I think the short answer is
> >>> that you need to change where you're saying the file goes in memory.
> >>> FWIW I run the DFU test on my dra7xx_evm and it's passing.
> >>
> >> You applied a change which intentionally broke functionality??? That sounds
> >> pretty bad...
> >
> > So, yes.  A design decision / feature of "don't check where we're
> > loading payloads to" is also a security vulnerability to bypass secure
> > boot.  So we now have changes in that make a good attempt at keeping us
> > from loading a payload that can in turn overwrite ourself.  And I merged
> > it super early in the merge window to try and catch the unintended
> > consequences.
> >
> >> Looking at the precise test that failed, we don't actually specify where 
> >> the
> >> data goes in memory; it's written to the filesystem and all memmory
> >> locations are internally allocated by U-Boot. So when you say "you need to
> >> change where you're saying the file goes in memory", do you mean via the 
> >> DFU
> >> altinfo variable (which does not specify a memory location in this case, so
> >> I can't), or by modifying some board-/SoC-specific config file or code to
> >> specify where DFU buffers data (in which case, I'd argue that a
> >> backwards-compatible default should have been put in place to prevent
> >> breaking functionality)?
> >>
> >> The DFU altinfo values that are tested on both boards are:
> >>
> >> Fails:
> >>
> >> Device mmc 1 (which is an SD card):
> >> "alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1",
>
> "test_sizes": (
> 64 - 1,
> 64,
> 64 + 1,
> 4096 - 1,
> ),
> },
>
> >> All pass:
> >>
> >> Device mmc 1 (which is an SD card):
> >> "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1",
>
> "test_sizes": (
> 128 - 1,
> 128,
> 128 + 1,
> 4096,
> ),
>
> >> Device mmc 1 (which is an SD card):
> >> "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1",
>
> "test_sizes": (
> 960 - 1,
> 960,
> 960 + 1,
> 4096 + 1,
> ),
>
> >> Device ram
> >> "alt_info": "alt0 ram 8000 0100;alt1 ram 8100 0100",
>
> "test_sizes": (
> 1024 * 1024 - 1,
> 1024 * 1024,
> 8 * 1024 * 1024,
> ),
>
> > So that's interesting.  How big is dfu_test.bin?  Checking my config, I
> > don't have SD card only RAM.  If you do RAM only tests does it pass (as
> > that might narrow down where maybe something is wrong) ?
>
> Yes, that RAM-only test passes. The tests are run in the order listed above.
>
> test_dfu.py iterates over a bunch of different file sizes; I listed them
> below the DFU configs above.

OK, I have absolutely no experience with DFU, so please be patient with me
when interpreting this wrong...

Is it correct that the files above differ in that the one failing is
read via the ext4 fs
driver? In that case, I guess it might be the ext4 fs driver trying to
load something
into a buffer on the stack?

Could you try the attached patch where I added more debugging output? Maybe
I can read something from its output.

Thanks,
Simon


0001-lmb-debug-dfu-failure.patch
Description: Binary data
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] test vs itest command confusion when using setexpr

[Jörg Krause]

Hi,

I noticed a difference between the `test` and the `itest` command when
using `setexpr`:

Running the test vs the itest command in the shell:

```
=> setexpr i 0xf; while test ${i} -gt 0; do echo $i; setexpr i ${i} - 1; done
=> setexpr i 0xf; while itest ${i} -gt 0; do echo $i; setexpr i ${i} - 1; done
f
e
d
c
b
a
9
8
7
6
5
4
3
2
1
=>
```

The difference between the test and the itest command is that the
integer operations for the test command is done using the base of 10
while for the itest command the operations are done using a base of 16.

lib/test.c
```
simple_strtol(ap[0], NULL, 10) > simple_strtol(ap[2], NULL, 10);
```

lib/itest.c
```
simple_strtol(s, NULL, 16) > simple_strtol(t, NULL, 16);
```

As setexpr stores the variables as hex values, it becomes obvious why
`itest` works, but `test` does not. Is this different behaviour
intended?

Best regards
Jörg Krause

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push

[Simon Goldschmidt]

Hi,

Am Fr., 18. Jan. 2019, 07:29 hat Stephen Warren 
geschrieben:

> On 1/17/19 6:15 PM, Tom Rini wrote:
> > On Thu, Jan 17, 2019 at 05:50:27PM -0700, Stephen Warren wrote:
> >> On 1/17/19 5:42 PM, Tom Rini wrote:
> >>> On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote:
> >>>
>  Tom,
> 
>  The recent set of patches pushed to u-boot/master cause DFU failures
> on both
>  Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU
> test) with
>  the following in the log:
> 
>  host:
>  dfu-util -a 0 -U
> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin
>  -p 3-2.3
> 
>  target:
>  ** Reading file would overwrite reserved memory **
>  dfu: Read error!
>  dfu_read: Failed to fill buffer
>  Tegra124 (Jetson TK1) #
> 
>  I noticed some lmb fixes in the list, so I guess it's due to that.
> >>>
> >>> So.. intentional!  Adding in Simon here, but I think the short answer
> is
> >>> that you need to change where you're saying the file goes in memory.
> >>> FWIW I run the DFU test on my dra7xx_evm and it's passing.
>

I'll try to help clarifying this, but I won't have access to a PC until
Monday.

Regards,
Simon

>>
> >> You applied a change which intentionally broke functionality??? That
> sounds
> >> pretty bad...
> >
> > So, yes.  A design decision / feature of "don't check where we're
> > loading payloads to" is also a security vulnerability to bypass secure
> > boot.  So we now have changes in that make a good attempt at keeping us
> > from loading a payload that can in turn overwrite ourself.  And I merged
> > it super early in the merge window to try and catch the unintended
> > consequences.
> >
> >> Looking at the precise test that failed, we don't actually specify
> where the
> >> data goes in memory; it's written to the filesystem and all memmory
> >> locations are internally allocated by U-Boot. So when you say "you need
> to
> >> change where you're saying the file goes in memory", do you mean via
> the DFU
> >> altinfo variable (which does not specify a memory location in this
> case, so
> >> I can't), or by modifying some board-/SoC-specific config file or code
> to
> >> specify where DFU buffers data (in which case, I'd argue that a
> >> backwards-compatible default should have been put in place to prevent
> >> breaking functionality)?
> >>
> >> The DFU altinfo values that are tested on both boards are:
> >>
> >> Fails:
> >>
> >> Device mmc 1 (which is an SD card):
> >> "alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1",
>
> "test_sizes": (
> 64 - 1,
> 64,
> 64 + 1,
> 4096 - 1,
> ),
> },
>
> >> All pass:
> >>
> >> Device mmc 1 (which is an SD card):
> >> "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1",
>
> "test_sizes": (
> 128 - 1,
> 128,
> 128 + 1,
> 4096,
> ),
>
> >> Device mmc 1 (which is an SD card):
> >> "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1",
>
> "test_sizes": (
> 960 - 1,
> 960,
> 960 + 1,
> 4096 + 1,
> ),
>
> >> Device ram
> >> "alt_info": "alt0 ram 8000 0100;alt1 ram 8100 0100",
>
> "test_sizes": (
> 1024 * 1024 - 1,
> 1024 * 1024,
> 8 * 1024 * 1024,
> ),
>
> > So that's interesting.  How big is dfu_test.bin?  Checking my config, I
> > don't have SD card only RAM.  If you do RAM only tests does it pass (as
> > that might narrow down where maybe something is wrong) ?
>
> Yes, that RAM-only test passes. The tests are run in the order listed
> above.
>
> test_dfu.py iterates over a bunch of different file sizes; I listed them
> below the DFU configs above.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push

[Stephen Warren]

On 1/17/19 6:15 PM, Tom Rini wrote:
> On Thu, Jan 17, 2019 at 05:50:27PM -0700, Stephen Warren wrote:
>> On 1/17/19 5:42 PM, Tom Rini wrote:
>>> On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote:
>>>
 Tom,

 The recent set of patches pushed to u-boot/master cause DFU failures on 
 both
 Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) 
 with
 the following in the log:

 host:
 dfu-util -a 0 -U 
 /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin
 -p 3-2.3

 target:
 ** Reading file would overwrite reserved memory **
 dfu: Read error!
 dfu_read: Failed to fill buffer
 Tegra124 (Jetson TK1) #

 I noticed some lmb fixes in the list, so I guess it's due to that.
>>>
>>> So.. intentional!  Adding in Simon here, but I think the short answer is
>>> that you need to change where you're saying the file goes in memory.
>>> FWIW I run the DFU test on my dra7xx_evm and it's passing.
>>
>> You applied a change which intentionally broke functionality??? That sounds
>> pretty bad...
> 
> So, yes.  A design decision / feature of "don't check where we're
> loading payloads to" is also a security vulnerability to bypass secure
> boot.  So we now have changes in that make a good attempt at keeping us
> from loading a payload that can in turn overwrite ourself.  And I merged
> it super early in the merge window to try and catch the unintended
> consequences.
> 
>> Looking at the precise test that failed, we don't actually specify where the
>> data goes in memory; it's written to the filesystem and all memmory
>> locations are internally allocated by U-Boot. So when you say "you need to
>> change where you're saying the file goes in memory", do you mean via the DFU
>> altinfo variable (which does not specify a memory location in this case, so
>> I can't), or by modifying some board-/SoC-specific config file or code to
>> specify where DFU buffers data (in which case, I'd argue that a
>> backwards-compatible default should have been put in place to prevent
>> breaking functionality)?
>>
>> The DFU altinfo values that are tested on both boards are:
>>
>> Fails:
>>
>> Device mmc 1 (which is an SD card):
>> "alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1",

"test_sizes": (
64 - 1,
64,
64 + 1,
4096 - 1,
),
},

>> All pass:
>>
>> Device mmc 1 (which is an SD card):
>> "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1",

"test_sizes": (
128 - 1,
128,
128 + 1,
4096,
),

>> Device mmc 1 (which is an SD card):
>> "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1",

"test_sizes": (
960 - 1,
960,
960 + 1,
4096 + 1,
),

>> Device ram
>> "alt_info": "alt0 ram 8000 0100;alt1 ram 8100 0100",

"test_sizes": (
1024 * 1024 - 1,
1024 * 1024,
8 * 1024 * 1024,
),

> So that's interesting.  How big is dfu_test.bin?  Checking my config, I
> don't have SD card only RAM.  If you do RAM only tests does it pass (as
> that might narrow down where maybe something is wrong) ?

Yes, that RAM-only test passes. The tests are run in the order listed above.

test_dfu.py iterates over a bunch of different file sizes; I listed them
below the DFU configs above.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push

[Tom Rini]

On Thu, Jan 17, 2019 at 05:50:27PM -0700, Stephen Warren wrote:
> On 1/17/19 5:42 PM, Tom Rini wrote:
> >On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote:
> >
> >>Tom,
> >>
> >>The recent set of patches pushed to u-boot/master cause DFU failures on both
> >>Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) with
> >>the following in the log:
> >>
> >>host:
> >>dfu-util -a 0 -U 
> >>/var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin
> >>-p 3-2.3
> >>
> >>target:
> >>** Reading file would overwrite reserved memory **
> >>dfu: Read error!
> >>dfu_read: Failed to fill buffer
> >>Tegra124 (Jetson TK1) #
> >>
> >>I noticed some lmb fixes in the list, so I guess it's due to that.
> >
> >So.. intentional!  Adding in Simon here, but I think the short answer is
> >that you need to change where you're saying the file goes in memory.
> >FWIW I run the DFU test on my dra7xx_evm and it's passing.
> 
> You applied a change which intentionally broke functionality??? That sounds
> pretty bad...

So, yes.  A design decision / feature of "don't check where we're
loading payloads to" is also a security vulnerability to bypass secure
boot.  So we now have changes in that make a good attempt at keeping us
from loading a payload that can in turn overwrite ourself.  And I merged
it super early in the merge window to try and catch the unintended
consequences.

> Looking at the precise test that failed, we don't actually specify where the
> data goes in memory; it's written to the filesystem and all memmory
> locations are internally allocated by U-Boot. So when you say "you need to
> change where you're saying the file goes in memory", do you mean via the DFU
> altinfo variable (which does not specify a memory location in this case, so
> I can't), or by modifying some board-/SoC-specific config file or code to
> specify where DFU buffers data (in which case, I'd argue that a
> backwards-compatible default should have been put in place to prevent
> breaking functionality)?
> 
> The DFU altinfo values that are tested on both boards are:
> 
> Fails:
> 
> Device mmc 1 (which is an SD card):
> "alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1",
> 
> All pass:
> 
> Device mmc 1 (which is an SD card):
> "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1",
> 
> Device mmc 1 (which is an SD card):
> "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1",
> 
> Device ram
> "alt_info": "alt0 ram 8000 0100;alt1 ram 8100 0100",

So that's interesting.  How big is dfu_test.bin?  Checking my config, I
don't have SD card only RAM.  If you do RAM only tests does it pass (as
that might narrow down where maybe something is wrong) ?

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push

[Stephen Warren]

On 1/17/19 5:42 PM, Tom Rini wrote:

On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote:


Tom,

The recent set of patches pushed to u-boot/master cause DFU failures on both
Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) with
the following in the log:

host:
dfu-util -a 0 -U 
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin
-p 3-2.3

target:
** Reading file would overwrite reserved memory **
dfu: Read error!
dfu_read: Failed to fill buffer
Tegra124 (Jetson TK1) #

I noticed some lmb fixes in the list, so I guess it's due to that.


So.. intentional!  Adding in Simon here, but I think the short answer is
that you need to change where you're saying the file goes in memory.
FWIW I run the DFU test on my dra7xx_evm and it's passing.


You applied a change which intentionally broke functionality??? That 
sounds pretty bad...


Looking at the precise test that failed, we don't actually specify where 
the data goes in memory; it's written to the filesystem and all memmory 
locations are internally allocated by U-Boot. So when you say "you need 
to change where you're saying the file goes in memory", do you mean via 
the DFU altinfo variable (which does not specify a memory location in 
this case, so I can't), or by modifying some board-/SoC-specific config 
file or code to specify where DFU buffers data (in which case, I'd argue 
that a backwards-compatible default should have been put in place to 
prevent breaking functionality)?


The DFU altinfo values that are tested on both boards are:

Fails:

Device mmc 1 (which is an SD card):
"alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1",

All pass:

Device mmc 1 (which is an SD card):
"alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1",

Device mmc 1 (which is an SD card):
"alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1",

Device ram
"alt_info": "alt0 ram 8000 0100;alt1 ram 8100 0100",
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push

[Tom Rini]

On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote:

> Tom,
> 
> The recent set of patches pushed to u-boot/master cause DFU failures on both
> Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) with
> the following in the log:
> 
> host:
> dfu-util -a 0 -U 
> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin
> -p 3-2.3
> 
> target:
> ** Reading file would overwrite reserved memory **
> dfu: Read error!
> dfu_read: Failed to fill buffer
> Tegra124 (Jetson TK1) #
> 
> I noticed some lmb fixes in the list, so I guess it's due to that.

So.. intentional!  Adding in Simon here, but I think the short answer is
that you need to change where you're saying the file goes in memory.
FWIW I run the DFU test on my dra7xx_evm and it's passing.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push

[Stephen Warren]

Tom,

The recent set of patches pushed to u-boot/master cause DFU failures on 
both Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU 
test) with the following in the log:


host:
dfu-util -a 0 -U 
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin 
-p 3-2.3


target:
** Reading file would overwrite reserved memory **
dfu: Read error!
dfu_read: Failed to fill buffer
Tegra124 (Jetson TK1) #

I noticed some lmb fixes in the list, so I guess it's due to that.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: Use single quote consistently

[Tom Rini]

On Thu, Dec 27, 2018 at 08:11:13AM -0700, Simon Glass wrote:

> Some tests have ended up using double quotes where single quotes could be
> used. Adjust this for consistency with the rest of U-Boot's Python code.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: bootcount: add bootcount-uclass test

[Tom Rini]

On Fri, Dec 14, 2018 at 09:14:29PM +0100, Philipp Tomsich wrote:

> Add a test for the bootcount uclass, which uses the RTC bootcount backend
> (i.e. drivers/bootcount/rtc.c is implictly also tested).
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] U-Boot test failures; rebase on master

[Anatolij Gustschin]

On Fri, 14 Dec 2018 09:44:41 -0700
Stephen Warren swar...@wwwdotorg.org wrote:
...
> u-boot-video.git master

Synced with u-boot.git master now, thanks!

--
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] U-Boot test failures; rebase on master

[Marek Vasut]

On 12/14/2018 05:44 PM, Stephen Warren wrote:
> The following U-Boot repos have recently rebased on u-boot.git master
> branch, and picked up some changes that cause test failures on one/both
> of NVIDIA Jetson TX2 and sandbox. That potentially prevents any testing
> from finding any additional issues that are introduced in these repos.
> If you rebase on the latest u-boot.git master branch you'll pick up
> fixes that solve these failures, and make all of test/py pass on all the
> boards I test...
> 
> u-boot-usb.git master
> u-boot-video.git master
> u-boot-dfu.git master
> u-boot-spi.git master

Updated, thanks

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] U-Boot test failures; rebase on master

[Stephen Warren]

The following U-Boot repos have recently rebased on u-boot.git master 
branch, and picked up some changes that cause test failures on one/both 
of NVIDIA Jetson TX2 and sandbox. That potentially prevents any testing 
from finding any additional issues that are introduced in these repos. 
If you rebase on the latest u-boot.git master branch you'll pick up 
fixes that solve these failures, and make all of test/py pass on all the 
boards I test...


u-boot-usb.git master
u-boot-video.git master
u-boot-dfu.git master
u-boot-spi.git master

Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: hexdump: fix misplaced return

[Tom Rini]

On Tue, Dec 04, 2018 at 09:30:08PM +0100, Simon Goldschmidt wrote:

> One of the hexdump tests in test/lib/hexdump.c returns right at the
> start of the function without testing anything.
> 
> Fix this by moving the 'return 0;' statement to the end of the function.
> 
> Signed-off-by: Simon Goldschmidt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: tee: fix resource leak in dm_test_tee()

[Tom Rini]

On Mon, Oct 29, 2018 at 11:41:35AM +0100, Jens Wiklander wrote:

> Fixes possible resource leak in dm_test_tee() reported by Coverity.
> 
> Reported-by: Coverity (CID: 184175)
> Signed-off-by: Jens Wiklander 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: eth: Add a test for ARP requests

[Joe Hershberger]

Hi Joe,

https://patchwork.ozlabs.org/patch/975412/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: eth: Add a test for the target being pinged

[Joe Hershberger]

Hi Joe,

https://patchwork.ozlabs.org/patch/975410/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: Add ut_assertnull macro

[Tom Rini]

On Thu, Jun 21, 2018 at 05:47:16PM +0300, Ramon Fried wrote:

> Add ut_assertnull macro to include/test/ut.h
> For testing of functions that returns NULL on errors.
> 
> Signed-off-by: Ramon Fried 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: regmap: test Linux-compatible syscon_node_to_regmap()

[Tom Rini]

On Mon, Apr 23, 2018 at 01:26:53PM +0900, Masahiro Yamada wrote:

> Like Linux, syscon_node_to_regmap() allows a node to work as a syscon
> provider without binding it to a syscon driver.  Test this.
> 
> Requested-by: Simon Glass 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: ofnode: test ofnode_device_is_compatible()

[Tom Rini]

On Fri, Apr 27, 2018 at 01:02:02AM +0900, Masahiro Yamada wrote:

> Test ofnode_device_is_compatible(), and also ofnode_path().
> 
> Requested-by: Simon Glass 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: dm: regmap: fix license header

[Tom Rini]

On Fri, Apr 27, 2018 at 01:07:21AM +0900, Masahiro Yamada wrote:

> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test/py: gpt: update size of gpt partition

[Tom Rini]

On Wed, Dec 06, 2017 at 06:08:20PM +0100, Patrick Delaunay wrote:

> - avoid disturbing 0MiB partition size (in fact < 1MiB)
> - test overlap limit between part1 and part2
> - test gpt write with data with modifier 'M' for MiB
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test/py: add timestamps to log

[Tom Rini]

On Fri, Oct 27, 2017 at 11:04:08AM -0600, Stephen Warren wrote:

> From: Stephen Warren 
> 
> It can be useful to record how long tests take; this can help debug slow
> running test systems or track changes in performance over time. Enhance
> the test system to record timestamps while running test:
> - Whenever a new log file section is started.
> - After U-Boot is started and communication has been established.
> - After each host or U-Boot command is executed.
> 
> Signed-off-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test/py: regenerate persistent GPT image if code changes

[Tom Rini]

On Thu, Oct 26, 2017 at 06:23:35PM -0600, Stephen Warren wrote:

> From: Stephen Warren 
> 
> test_gpt generates a persistent disk image which can be re-used across
> multiple test runs. Currently, if the Python code that generates the disk
> image change, the image is not regenerated, which could cause test
> failures e.g. if a test was updated to expect some new partition name or
> size, yet the persistent disk image contained the old name or size. This
> change introduces functionality to regenerate the disk image if the
> instructions to generate the image have changed.
> 
> Signed-off-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot