[PATCH 1/4] README.hardware.md: add genericarm64 maintainers

[PATCH 1/4] README.hardware.md: add genericarm64 maintainers

[Mikko Rapeli]

Add maintainers section to genericarm64 machine documentation.

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta-yocto-bsp/README.hardware.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-yocto-bsp/README.hardware.md b/meta-yocto-bsp/README.hardware.md
index 6045c3d867..0c460ef669 100644
--- a/meta-yocto-bsp/README.hardware.md
+++ b/meta-yocto-bsp/README.hardware.md
@@ -145,6 +145,8 @@ building the image also build the `u-boot` recipe to build the required
 firmware (note that this firmware will _not_ boot on real hardware), then use
 `runqemu` as usual.
 
+Maintainers:
+* Ross Burton <Ross.Burton@arm.com>
 
 Texas Instruments Beaglebone (beaglebone-yocto)
 -----------------------------------------------
-- 
2.34.1

[PATCH 2/4] genericarm64.conf: add AMD Kria KV260 serial consoles

[Mikko Rapeli]

Current practice is to add new device serial devices to
SERIAL_CONSOLES. Enables testing and test automation with
the board. Note that SERIAL_CONSOLES get added to /etc/inittab
and missing physical serial consoles causes respawn warnings
at runtime:

INIT: Id "S0" respawning too fast: disabled for 5 minutes
INIT: Id "S1" respawning too fast: disabled for 5 minutes

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta-yocto-bsp/conf/machine/genericarm64.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-yocto-bsp/conf/machine/genericarm64.conf b/meta-yocto-bsp/conf/machine/genericarm64.conf
index b6dfb8042d..a77ffb0431 100644
--- a/meta-yocto-bsp/conf/machine/genericarm64.conf
+++ b/meta-yocto-bsp/conf/machine/genericarm64.conf
@@ -28,7 +28,7 @@ WKS_FILE ?= "genericarm64.wks.in"
 EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", "systemd-boot", "grub-efi", d)}"
 
 # Try to bring up a selection of physical or virtual serial consoles
-SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0 115200;ttyS0 115200;ttyS1 115200;ttyS2"
+SERIAL_CONSOLES ?= "115200;ttyPS0 115200;ttyPS1 115200;ttyAMA0 115200;hvc0 115200;ttyS0 115200;ttyS1 115200;ttyS2"
 
 # Allow u-boot to be built for use with qemu-system-aarch64.
 # This u-boot is _not_ suitable for use with real hardware, and the expectation
-- 
2.34.1

Re: [poky] [PATCH 2/4] genericarm64.conf: add AMD Kria KV260 serial consoles

[Ross Burton]

On 29 Oct 2024, at 08:05, Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> wrote:
> 
> Current practice is to add new device serial devices to
> SERIAL_CONSOLES. Enables testing and test automation with
> the board. Note that SERIAL_CONSOLES get added to /etc/inittab
> and missing physical serial consoles causes respawn warnings
> at runtime:
> 
> INIT: Id "S0" respawning too fast: disabled for 5 minutes
> INIT: Id "S1" respawning too fast: disabled for 5 minutes

The use of ttyrun should avoid the respawning issue, have you confirmed this still happens? If so, any idea why?

Ross

Re: [poky] [PATCH 2/4] genericarm64.conf: add AMD Kria KV260 serial consoles

[Mikko Rapeli]

On Tue, Oct 29, 2024 at 11:58:09AM +0000, Ross Burton wrote:
> On 29 Oct 2024, at 08:05, Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> wrote:
> > 
> > Current practice is to add new device serial devices to
> > SERIAL_CONSOLES. Enables testing and test automation with
> > the board. Note that SERIAL_CONSOLES get added to /etc/inittab
> > and missing physical serial consoles causes respawn warnings
> > at runtime:
> > 
> > INIT: Id "S0" respawning too fast: disabled for 5 minutes
> > INIT: Id "S1" respawning too fast: disabled for 5 minutes
> 
> The use of ttyrun should avoid the respawning issue, have you confirmed this still happens? If so, any idea why?

This is happening with very recent poky master builds with sysvinit, the default.

https://ledge.validation.linaro.org/scheduler/job/95628

    Starting syslogd/klogd: done
    
    INIT: Id "S1" respawning too fast: disabled for 5 minutes
    
    INIT: Id "S0" respawning too fast: disabled for 5 minutes
    Poky (Yocto Project Reference Distro) 5.1 genericarm64 /dev/ttyPS1

Alternatively testing could focus on systemd init, or the issue is just ignored.
Or udev based agetty starter is developed. For generic images, it should not be
necessary to define all serial consoles via SERIAL_CONSOLES at build time.
Kernel has a lot more drivers enabled.

Cheers,

-Mikko

Re: [poky] [PATCH 2/4] genericarm64.conf: add AMD Kria KV260 serial consoles

[Ross Burton]

On 29 Oct 2024, at 12:10, Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
> 
> On Tue, Oct 29, 2024 at 11:58:09AM +0000, Ross Burton wrote:
>> On 29 Oct 2024, at 08:05, Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> wrote:
>>> 
>>> Current practice is to add new device serial devices to
>>> SERIAL_CONSOLES. Enables testing and test automation with
>>> the board. Note that SERIAL_CONSOLES get added to /etc/inittab
>>> and missing physical serial consoles causes respawn warnings
>>> at runtime:
>>> 
>>> INIT: Id "S0" respawning too fast: disabled for 5 minutes
>>> INIT: Id "S1" respawning too fast: disabled for 5 minutes
>> 
>> The use of ttyrun should avoid the respawning issue, have you confirmed this still happens? If so, any idea why?
> 
> This is happening with very recent poky master builds with sysvinit, the default.
> 
> https://ledge.validation.linaro.org/scheduler/job/95628
> 
>    Starting syslogd/klogd: done
> 
>    INIT: Id "S1" respawning too fast: disabled for 5 minutes
> 
>    INIT: Id "S0" respawning too fast: disabled for 5 minutes
>    Poky (Yocto Project Reference Distro) 5.1 genericarm64 /dev/ttyPS1
> 
> Alternatively testing could focus on systemd init, or the issue is just ignored.
> Or udev based agetty starter is developed. For generic images, it should not be
> necessary to define all serial consoles via SERIAL_CONSOLES at build time.
> Kernel has a lot more drivers enabled.

Better solutions for sysv appreciated: hardcoding the list at boot time _is_ madness.  Something involving a udev triggers sounds like a better solution long term, for sure.

However, ttyrun really should be stopping this, so I’m curious what the problem is and whether the xilinx tty driver is a bit broken.

Ross

[PATCH 3/4] genericarm64.conf: add "testimage" and "testexport" to default IMAGE_CLASSES

[Mikko Rapeli]

They export oeqa runtime tests from build environment so that
they can be run in test environment with real HW. Once device has
been flashed and booted so that SSH is available and tmp/testimage
is available on the test worker, then tests can be run with:

$ ./oe-test runtime --target-type simpleremote \
  --target-ip 10.0.0.2

Sample test run log from AMD Kria KV260 board managed by Linaro Automated Validation
Architecture (LAVA, https://www.lavasoftware.org/ ) lab:

https://ledge.validation.linaro.org/scheduler/job/95628

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta-yocto-bsp/conf/machine/genericarm64.conf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta-yocto-bsp/conf/machine/genericarm64.conf b/meta-yocto-bsp/conf/machine/genericarm64.conf
index a77ffb0431..a81e4e2689 100644
--- a/meta-yocto-bsp/conf/machine/genericarm64.conf
+++ b/meta-yocto-bsp/conf/machine/genericarm64.conf
@@ -35,6 +35,9 @@ SERIAL_CONSOLES ?= "115200;ttyPS0 115200;ttyPS1 115200;ttyAMA0 115200;hvc0 11520
 # of this machine is that real hardware comes with the firmware pre-loaded.
 UBOOT_MACHINE = "qemu_arm64_defconfig"
 
+# Run oeqa runtime tests outside of the build environment
+IMAGE_CLASSES += "testimage testexport"
+
 # runqemu configuration to run a genericarm64 image inside a qemu-system-aarch64. You will need
 # to build u-boot explicitly.
 IMAGE_CLASSES += "qemuboot"
-- 
2.34.1

Re: [poky] [PATCH 3/4] genericarm64.conf: add "testimage" and "testexport" to default IMAGE_CLASSES

[Ross Burton]

On 29 Oct 2024, at 08:05, Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> wrote:
> +# Run oeqa runtime tests outside of the build environment
> +IMAGE_CLASSES += "testimage testexport"

Sorry, but this isn’t appropriate for the machine configuration.  The build configuration or distro can add these classes as needed.

Ross

Re: [poky] [PATCH 3/4] genericarm64.conf: add "testimage" and "testexport" to default IMAGE_CLASSES

[Mikko Rapeli]

Hi,

On Tue, Oct 29, 2024 at 11:57:28AM +0000, Ross Burton wrote:
> On 29 Oct 2024, at 08:05, Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> wrote:
> > +# Run oeqa runtime tests outside of the build environment
> > +IMAGE_CLASSES += "testimage testexport"
> 
> Sorry, but this isn’t appropriate for the machine configuration.  The build configuration or distro can add these classes as needed.

Ok but where do we do this for genericarm64 images? Somewhere in yocto-autobuilder2
or yocto-autobuilder-helper repos? I presume poky distro will not set these.

Cheers,

-Mikko

Re: [poky] [PATCH 3/4] genericarm64.conf: add "testimage" and "testexport" to default IMAGE_CLASSES

[Ross Burton]

On 29 Oct 2024, at 12:05, Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> wrote:
> On Tue, Oct 29, 2024 at 11:57:28AM +0000, Ross Burton wrote:
>> On 29 Oct 2024, at 08:05, Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> wrote:
>>> +# Run oeqa runtime tests outside of the build environment
>>> +IMAGE_CLASSES += "testimage testexport"
>> 
>> Sorry, but this isn’t appropriate for the machine configuration.  The build configuration or distro can add these classes as needed.
> 
> Ok but where do we do this for genericarm64 images? Somewhere in yocto-autobuilder2
> or yocto-autobuilder-helper repos? I presume poky distro will not set these.

Is your intention to run testing over images generated by the autobuilder itself?  Arguably, we should add these to poky.conf as poky is explicitly for testing purposes.

Ross

Re: [poky] [PATCH 3/4] genericarm64.conf: add "testimage" and "testexport" to default IMAGE_CLASSES

[Mikko Rapeli]

Hi,

On Tue, Oct 29, 2024 at 12:10:29PM +0000, Ross Burton wrote:
> On 29 Oct 2024, at 12:05, Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> wrote:
> > On Tue, Oct 29, 2024 at 11:57:28AM +0000, Ross Burton wrote:
> >> On 29 Oct 2024, at 08:05, Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> wrote:
> >>> +# Run oeqa runtime tests outside of the build environment
> >>> +IMAGE_CLASSES += "testimage testexport"
> >> 
> >> Sorry, but this isn’t appropriate for the machine configuration.  The build configuration or distro can add these classes as needed.
> > 
> > Ok but where do we do this for genericarm64 images? Somewhere in yocto-autobuilder2
> > or yocto-autobuilder-helper repos? I presume poky distro will not set these.
> 
> Is your intention to run testing over images generated by the autobuilder itself?  Arguably, we should add these to poky.conf as poky is explicitly for testing purposes.

If these are enabled, then we could take the images and exported tests and run
them directly in Lava lab devices. Another alternative is a different build with them
enabled but then maybe limiting the amount of images would make sense.

If you are ok with this, then I can propose this to poky defaults.

Cheers,

-Mikko

[PATCH 4/4] README.hardware.md: add myself to genericarm64 maintainers

[Mikko Rapeli]

I will be testing genericarm64 images on AMD Kria KV260 devices.

Cc: Bill Mills <bill.mills@linaro.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta-yocto-bsp/README.hardware.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-yocto-bsp/README.hardware.md b/meta-yocto-bsp/README.hardware.md
index 0c460ef669..d2cc05f909 100644
--- a/meta-yocto-bsp/README.hardware.md
+++ b/meta-yocto-bsp/README.hardware.md
@@ -136,6 +136,7 @@ compliant boards with preinstalled firmware.
 The genericarm64 MACHINE is currently tested on the following platforms:
 
   * Texas Instruments BeaglePlay
+  * AMD Kria KV260
 
 The images built are EFI bootable disk images and can be written directly to a
 SD card for booting, for example.
@@ -147,6 +148,7 @@ firmware (note that this firmware will _not_ boot on real hardware), then use
 
 Maintainers:
 * Ross Burton <Ross.Burton@arm.com>
+* Mikko Rapeli <mikko.rapeli@linaro.org>
 
 Texas Instruments Beaglebone (beaglebone-yocto)
 -----------------------------------------------
-- 
2.34.1