1. cip-dev@lists.cip-project.org
  2. Messages
   Date   
[PATCH 3/3] ARM: dts: iwg22d-sodimm-dbhd-ca: Add can1 support to HDMI DB

Fabrizio Castro <fabrizio.castro@...>
 

CAN1 interface is exposed via connector J1 found on the HDMI daughter
board. This patch enables can1 DT node from within the daughter board
specific device tree.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit d6033e7c6589c74299635eb3d84c56ccac8db5e4)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
index fc0f559..654d28b 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts
@@ -54,6 +54,13 @@
};
};

+&can1 {
+ pinctrl-0 = <&can1_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
&hscif2 {
pinctrl-0 = <&hscif2_pins>;
pinctrl-names = "default";
@@ -103,6 +110,11 @@
};

&pfc {
+ can1_pins: can1 {
+ groups = "can1_data_b";
+ function = "can1";
+ };
+
du0_pins: du0 {
groups = "du0_rgb888", "du0_sync", "du0_disp", "du0_clk0_out";
function = "du0";
--
2.7.4

[PATCH 2/3] ARM: dts: iwg22d-sodimm: Add can0 support to carrier board

Fabrizio Castro <fabrizio.castro@...>
 

This patch enables CAN0 interface exposed through connector J15 on the
carrier board.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 805a5263f4212e431a44c4a04738022a2498f652)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
index bffe735..1486565 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
@@ -40,6 +40,13 @@
};
};

+&can0 {
+ pinctrl-0 = <&can0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
&hscif1 {
pinctrl-0 = <&hscif1_pins>;
pinctrl-names = "default";
@@ -49,6 +56,11 @@
};

&pfc {
+ can0_pins: can0 {
+ groups = "can0_data";
+ function = "can0";
+ };
+
hscif1_pins: hscif1 {
groups = "hscif1_data", "hscif1_ctrl";
function = "hscif1";
--
2.7.4

[PATCH 1/3] ARM: dts: r8a7745: Add CAN[01] SoC support

Fabrizio Castro <fabrizio.castro@...>
 

Add the definitions for can0 and can1 to the SoC .dtsi.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 85d3122659be310c632ef1908532157ce82900ee)
(moved nodes to a better location to allow for better sorting.
modified clocks and power-domains properties. removed resets
properties)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
arch/arm/boot/dts/r8a7745.dtsi | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 6fdd3c2..c2e38ae 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -32,6 +32,14 @@
spi3 = &msiof2;
};

+ /* External CAN clock */
+ can_clk: can {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -844,6 +852,32 @@
status = "disabled";
};

+ can0: can@e6e80000 {
+ compatible = "renesas,can-r8a7745",
+ "renesas,rcar-gen2-can";
+ reg = <0 0xe6e80000 0 0x1000>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7745_CLK_RCAN0>,
+ <&cpg_clocks R8A7745_CLK_RCAN>,
+ <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
+ can1: can@e6e88000 {
+ compatible = "renesas,can-r8a7745",
+ "renesas,rcar-gen2-can";
+ reg = <0 0xe6e88000 0 0x1000>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7745_CLK_RCAN1>,
+ <&cpg_clocks R8A7745_CLK_RCAN>,
+ <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
pci0: pci@ee090000 {
compatible = "renesas,pci-r8a7745",
"renesas,pci-rcar-gen2";
--
2.7.4

[PATCH 0/3] Add CAN support to iwg22d

Fabrizio Castro <fabrizio.castro@...>
 

Hello Ben,

this series backports CAN support for the iwg22d.
This series depends on series "Add PWM and TPU support":
https://lists.cip-project.org/pipermail/cip-dev/2018-July/001400.html

and it applies on top of branch linux-4.4.y-cip, commit
4d769b2b8749e89dfc7ea179a44f652dcfbedb37 ("PM / OPP: Move error
message to debug level").

Thanks,
Fab

Fabrizio Castro (3):
ARM: dts: r8a7745: Add CAN[01] SoC support
ARM: dts: iwg22d-sodimm: Add can0 support to carrier board
ARM: dts: iwg22d-sodimm-dbhd-ca: Add can1 support to HDMI DB

.../arm/boot/dts/r8a7745-iwg22d-sodimm-dbhd-ca.dts | 12 ++++++++
arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 12 ++++++++
arch/arm/boot/dts/r8a7745.dtsi | 34 ++++++++++++++++++++++
3 files changed, 58 insertions(+)

--
2.7.4

[PATCH 2/2] ARM: dts: r8a7745: Add TPU support

Fabrizio Castro <fabrizio.castro@...>
 

Add TPU support to SoC DT.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit b9db514555274eb325c9b13a0b0587c0e600d75a)
(moved node to a better location to allow for better sorting. modified
clocks and power-domains properties. removed resets property)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
arch/arm/boot/dts/r8a7745.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 4163ae4..6fdd3c2 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -173,6 +173,15 @@
reg = <0 0xe6060000 0 0x11c>;
};

+ tpu: pwm@e60f0000 {
+ compatible = "renesas,tpu-r8a7745", "renesas,tpu";
+ reg = <0 0xe60f0000 0 0x148>;
+ clocks = <&mstp3_clks R8A7745_CLK_TPU0>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
2.7.4

[PATCH 1/2] ARM: dts: r8a7745: Add PWM SoC support

Fabrizio Castro <fabrizio.castro@...>
 

Add the definitions for pwm[0123456] to the SoC .dtsi.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
Reviewed-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 3711d0ede24d2e3c90ae10e1a79746ac87169609)
(modified clocks and power-domains properties. removed resets
property)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
Reviewed-by: Biju Das <biju.das@...>
---
arch/arm/boot/dts/r8a7745.dtsi | 63 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 68ef545..4163ae4 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -772,6 +772,69 @@
status = "disabled";
};

+ pwm0: pwm@e6e30000 {
+ compatible = "renesas,pwm-r8a7745", "renesas,pwm-rcar";
+ reg = <0 0xe6e30000 0 0x8>;
+ clocks = <&mstp5_clks R8A7745_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm1: pwm@e6e31000 {
+ compatible = "renesas,pwm-r8a7745", "renesas,pwm-rcar";
+ reg = <0 0xe6e31000 0 0x8>;
+ clocks = <&mstp5_clks R8A7745_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@e6e32000 {
+ compatible = "renesas,pwm-r8a7745", "renesas,pwm-rcar";
+ reg = <0 0xe6e32000 0 0x8>;
+ clocks = <&mstp5_clks R8A7745_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm3: pwm@e6e33000 {
+ compatible = "renesas,pwm-r8a7745", "renesas,pwm-rcar";
+ reg = <0 0xe6e33000 0 0x8>;
+ clocks = <&mstp5_clks R8A7745_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm4: pwm@e6e34000 {
+ compatible = "renesas,pwm-r8a7745", "renesas,pwm-rcar";
+ reg = <0 0xe6e34000 0 0x8>;
+ clocks = <&mstp5_clks R8A7745_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm5: pwm@e6e35000 {
+ compatible = "renesas,pwm-r8a7745", "renesas,pwm-rcar";
+ reg = <0 0xe6e35000 0 0x8>;
+ clocks = <&mstp5_clks R8A7745_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
+ pwm6: pwm@e6e36000 {
+ compatible = "renesas,pwm-r8a7745", "renesas,pwm-rcar";
+ reg = <0 0xe6e36000 0 0x8>;
+ clocks = <&mstp5_clks R8A7745_CLK_PWM>;
+ power-domains = <&cpg_clocks>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
pci0: pci@ee090000 {
compatible = "renesas,pci-r8a7745",
"renesas,pci-rcar-gen2";
--
2.7.4

[PATCH 0/2] Add PWM and TPU support

Fabrizio Castro <fabrizio.castro@...>
 

Hello Ben,

this series backports PWM and TPU support for the r8a7745 SoC,
and it applies on top of branch linux-4.4.y-cip, commit
4d769b2b8749e89dfc7ea179a44f652dcfbedb37 ("PM / OPP: Move error
message to debug level").

Thanks,
Fab

Fabrizio Castro (2):
ARM: dts: r8a7745: Add PWM SoC support
ARM: dts: r8a7745: Add TPU support

arch/arm/boot/dts/r8a7745.dtsi | 72 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)

--
2.7.4

DebConf 2018

Ben Hutchings <ben.hutchings@...>
 

For those of you attending DebConf or interested in watching the live
video streams, the schedule is now available.

The following sessions may be of particular interest to CIP members:

Arm ports BoF
https://debconf18.debconf.org/talks/93-arm-ports-bof/

Backporting hardware support in Debian (BoF)
https://debconf18.debconf.org/talks/92-backporting-hardware-support-in-debian/

Building Debian-based system images (BoF)
https://debconf18.debconf.org/talks/89-building-debian-based-system-images/

Civilization runs on Debian (talk)
https://debconf18.debconf.org/talks/112-civilization-runs-on-debian/
I would guess that the talk itself won't be news to us, but the
questions from attendees may still be interesting.

How to engage developers to contribute effectively to Debian and other
open source projects in Asia (talk)
https://debconf18.debconf.org/talks/36-how-to-engage-developers-to-contribute-effectively-to-debian-and-other-open-source-projects-in-asia/
This talk will *not* be video recorded or streamed.

Running tests and analysing results on an Embedded Debian system with
BMW/Genivi tooling (talk)
https://debconf18.debconf.org/talks/17-running-tests-and-analysing-results-on-an-embedded-debian-system-with-bmwgenivi-tooling/

Using FAI to build Live debian images for ARM developer boards (talk)
https://debconf18.debconf.org/talks/84-using-fai-to-build-live-debian-images-for-arm-developer-boards/

I was surprised to see that there is no LTS (long-term support) BoF
scheduled. It should be possible to add a BoF to the schedule, though
without video coverage.

Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

[CIP Core] Criteria for prioritizing security fixes in Debian LTS

Daniel Sangorrin <daniel.sangorrin@...>
 

Hello Ben,

As platinum-level sponsors of the Debian LTS, we (CIP members) can provide a list of packages that we rely on and that should be prioritized in terms of security support.
[Note] The list of packages from each member can be found here:
Ref: https://docs.google.com/spreadsheets/d/1hrhYnDYSxeA-ZXaHB329-CzgY8H4H5iHXP1AeFFdJDc/
[Note] The list can be updated at any time (by notifying deblts@...)
[Note] The votes will be weighted by the amount of money contributed.
[Note] The Customer recognizes that this contract is a best-effort contract

During the Open Source Summit in Japan, we discussed about how to prioritize those packages. I proposed to create a set of criteria and Agustin mentioned that it would be a good idea to have you (Ben) evaluate these criteria and its impact before attending to DebConf.
[Note] Based on your feedback, CIP will decide to contact the Freexian leads before the DebConf or not.

Without further delay, I would appreciate it if you reviewed the criteria below to prioritize security fixes:
1) Packages that are popular among members' package lists
[Rationale] popular packages are often the target of exploits
- Examples: bash, busybox[-static], zlib, sqlite3, iptables, net-tools, libcap2, util-linux, dropbear, libsqlite3, tzdata
2) CVEs with high "base score", high "impact score",
high "exploitability score", and low "attack complexity"
[Rationale] these CVEs usually refer to bugs that are easy to exploit
or have a high impact.
3) Network software (CVEs with "Access Vector (AV): Network")
[Rationale] bugs that can be exploited remotely are the most dangerous
- Network servers examples: apache2, nginx, openssh-server, openssh-sftp-server,
tftp-hpa, postgresql, nfs-kernel-server, strongswan, netcat,vsftpd
- Network libs examples: libssh, libssl, zeromq3, libsocketcan, net-snmp,
libnet, libnss, openldap, openvpn, libcurl..
- Network clients examples: openssh-client, sshpass, ntp, wireless-tools,
wget, obexftp, iproute2...
- Update software examples: apt, unattended-upgrades...
4) Security software
[Rationale] LSM modules, encryption, and authorization are the
foundation of a security-hardened system
- Examples: apparmor, libseccomp, libselinux, *crypt*, libnettle4, libkeyutils1, tpm2-tools, pam, login, passwd, pwauth, xauth, libsasl, php-auth, shadow, sudo...
5) Language runtimes/compilers
[Rationale] they are common to many applications.
- Examples: gcc, libc, libstdc++, lua, nodejs, openjdk, perl, python, tcl...

Best regards,
Daniel Sangorrin

[Git][cip-project/cip-testing/board-at-desk-single-dev][master] 2 commits: More helpful final output #178

Agustin Benito Bethencourt
 

Robert Marshall pushed to branch master at cip-project / cip-testing / board-at-desk-single-dev

Commits:

  • db10d21f
    by Robert Marshall at 2018-06-13T14:08:31Z 
    More helpful final output #178

Tailor the output depending whether there's an authentication token
for lavauser.
  • f6ac0420
    by Robert Marshall at 2018-07-18T09:40:21Z 
    Merge branch 'betterTest' into 'master'

More helpful final output #178

See merge request cip-project/cip-testing/board-at-desk-single-dev!61

1 changed file:

Changes:

  • scripts/create_test.sh
    ... ... @@ -29,4 +29,12 @@ sed -i $OUP -e 's/TAG/'"$TAG"'/'
    29 29 
     sed -i $OUP -e 's/BRANCH/'"$BRANCH"'/'
    30 30
    31 31
    32 
    -echo now run lava-tool submit-job http://lavauser@localhost:8080/RPC2 $OUP
    32 
    +# assumes that lavauser is being used (as specified in the wiki)
    33 
    +AUTH=$(lava-tool auth-list | grep -c lavauser)
    34 
    +if [ $AUTH -eq 1 ]
    35 
    +then
    36 
    +   echo now run lava-tool submit-job http://lavauser@localhost:8080/RPC2 $OUP
    37 
    +else
    38 
    +   echo move $OUP to /etc/lava-server/dispatcher-config/health-checks/ naming it device-type.yaml
    39 
    +   echo if you want to use lava-tool you need to add an authentication token
    40 
    +fi

    • —
    View it on GitLab.
    You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can adjust your notification settings.

    [Git][cip-project/cip-testing/board-at-desk-single-dev][master] 2 commits: Use 2018.4 version of LAVA #185

    Agustin Benito Bethencourt
     

    Robert Marshall pushed to branch master at cip-project / cip-testing / board-at-desk-single-dev

    Commits:

    • d7d61d0b
      by Robert Marshall at 2018-07-18T07:26:18Z 
      Use 2018.4 version of LAVA #185
    • ed0c61c4
      by Robert Marshall at 2018-07-18T07:26:18Z 
      Merge branch 'stableLAVA' into 'master'

Use 2018.4 version of LAVA #185

See merge request cip-project/cip-testing/board-at-desk-single-dev!60

    2 changed files:

    Changes:

  • integration-scripts/install_dependencies.sh
    ... ... @@ -22,8 +22,6 @@ if [ -f ~/git-repos/kernelci-backend/tmphosts ] ; then
    22 22 
         echo continuing kernelci-backend provisioning
    23 23 
         exit 0
    24 24 
     fi
    25 
    -# Add backports repository - main branch
    26 
    -echo "deb http://deb.debian.org/debian stretch-backports main" | sudo DEBIAN_FRONTEND=noninteractive tee -a /etc/apt/sources.list
    27 25
    28 26 
     # Add Architectures that you will be building
    29 27 
     sudo DEBIAN_FRONTEND=noninteractive dpkg --add-architecture armel

  • integration-scripts/install_lava.sh
    ... ... @@ -15,16 +15,18 @@ set -e
    15 15 
     # Stop nginx
    16 16 
     sudo DEBIAN_FRONTEND=noninteractive systemctl stop nginx.service
    17 17
    18 
    -# Update the system
    19 
    -sudo DEBIAN_FRONTEND=noninteractive apt-get -y update
    18 
    +# retrieve 2018.4 of LAVA from here
    19 
    +echo "deb     http://snapshot.debian.org/archive/debian/20180526T153644Z/ stretch-backports main " | sudo DEBIAN_FRONTEND=noninteractive tee -a /etc/apt/sources.list
    20 
    +sudo DEBIAN_FRONTEND=noninteractive apt-get -o Acquire::Check-Valid-Until=false -y update
    20 21 
     sudo DEBIAN_FRONTEND=noninteractive apt-get -y upgrade
    21 22
    22 23 
     # Install postgresql & tftp
    23 24 
     sudo DEBIAN_FRONTEND=noninteractive apt-get -y install postgresql tftp
    24 25
    26 
    +
    25 27 
     # Install qemu, KVM & LAVA
    26 28 
     sudo DEBIAN_FRONTEND=noninteractive apt-get -y install qemu-kvm libvirt-clients libvirt-daemon libvirt-daemon-system
    27 
    -sudo DEBIAN_FRONTEND=noninteractive apt-get -y install lava -t stretch-backports
    29 
    +sudo DEBIAN_FRONTEND=noninteractive apt-get -y install lava=2018.4-1~bpo9+1 -t stretch-backports
    28 30
    29 31 
     # Add the vagrant user to the libvirtd and kvm groups
    30 32 
     sudo DEBIAN_FRONTEND=noninteractive usermod -a -G libvirt,kvm vagrant

    • —
    View it on GitLab.
    You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can adjust your notification settings.

    [Git][cip-project/cip-testing/board-at-desk-single-dev][master] 2 commits: Use a local test for the BBB health check

    Agustin Benito Bethencourt
     

    Robert Marshall pushed to branch master at cip-project / cip-testing / board-at-desk-single-dev

    Commits:

    • f9d2bb54
      by Robert Marshall at 2018-07-18T07:25:45Z 
      Use a local test for the BBB health check
    • 01551476
      by Robert Marshall at 2018-07-18T07:25:45Z 
      Merge branch 'localTest' into 'master'

Use a local test for the BBB health check

See merge request cip-project/cip-testing/board-at-desk-single-dev!62

    1 changed file:

    Changes:

  • tests/bbb_debian_local.yaml
    1 
    -# Copyright (C) 2017, Codethink, Ltd., Robert Marshall <robert.marshall@...>
    1 
    +# Copyright (C) 2018, Codethink, Ltd., Robert Marshall <robert.marshall@...>
    2 2 
     # SPDX-License-Identifier:	AGPL-3.0
    3 3 
     # This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, version 3.
    4 4
    ... ... @@ -10,7 +10,7 @@ device_type: beaglebone-black
    10 10
    11 11 
     # NFS fails on panda and arndale.
    12 12
    13 
    -job_name: local test of ramdisk test on bbb using /TREE/BRANCH/TAG/arm/omap2plus_defconfig/zImage
    13 
    +job_name: test of bbb using /TREE/BRANCH/TAG/arm/omap2plus_defconfig/zImage
    14 14 
     timeouts:
    15 15 
       job:
    16 16 
         minutes: 10
    ... ... @@ -62,11 +62,22 @@ actions:
    62 62
    63 63 
     # TEST_BLOCK
    64 64 
     - test:
    65 
    -    # defines the tests to be run once the health check passes
    66 65 
         timeout:
    67 
    -      minutes: 5
    66 
    +      minutes: 2
    68 67 
         definitions:
    69 
    -    - repository: git://git.linaro.org/qa/test-definitions.git
    70 
    -      from: git
    71 
    -      path: common/dt-selftests.yaml
    72 
    -      name: smoke-tests
    68 
    +    - repository:
    69 
    +        metadata:
    70 
    +          format: Lava-Test Test Definition 1.0
    71 
    +          name: kernel-version-basic
    72 
    +          version: "1.0"
    73 
    +          description: "check kernel version"
    74 
    +          os:
    75 
    +            - oe
    76 
    +          scope:
    77 
    +            - functional
    78 
    +        run:
    79 
    +          steps:
    80 
    +            - lava-test-case uname --shell uname -a
    81 
    +      from: inline
    82 
    +      name: kernel-version-inline
    83 
    +      path: inline/kernel-version-basic.yaml

    • —
    View it on GitLab.
    You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can adjust your notification settings.

    Re: [CIP testing strategy] Vagrant disksize plugin introduced, and some other (Vagrant-less) ideas

    Zoran
     

    Hello Robert,

    Please, also check the VBox and Vagrant versions:
    VBox version & VBox extension 5.2.14 do not work with Vagrant 2.1.2 (rather with Vagrant 2.1.1).
    VBox version & VBox extension 5.2.12 do work with Vagrant 2.1.2.

    At least, this is what I experienced.

    (I am working to completely get rid of Vagrant, but I have another emergency projects, now)
    _______

    For the CIP testing issue 190 (which is originated by me):
    https://gitlab.com/cip-project/cip-testing/testing/issues/190

    Here is the workaround/solution:

    And, the last desperate attempt was to swap 2018.5-3 base-uboot.jinja2 with 2017.7 base-uboot.jinja2.

    Fortunately, I saved this one (The ONLY one complex one before destroying last Lava 2017.7 machine)),
    for NO apparent reason, which (somehow) shows that I have very good psychic abilities!? ;-)

    And, for the reference, here is the 2017.7 base-uboot.jinja2, presented as original:

    Lava 2017.7 generic device-type base-uboot.jinja2 file
    https://pastebin.com/rhs8wt4H

    This did the trick! Everything works like a charm.

    Thank you,
    Zoran

    On Fri, Jul 13, 2018 at 12:23 PM, Robert Marshall <robert.marshall@...> wrote:
    Zoran

    Thanks for alerting me to this I'll take a look!

    Robert

    Zoran S <zoran.stojsavljevic.de@gmail.com> writes:

    > Hello CIP members,
    >
    > Recently, I have learned that vagrant disksize plugin was introduced.
    > https://github.com/sprotheroe/vagrant-disksize
    >
    > This, actually, replaces two native VBox commands (example given below):
    >
    >   VBoxManage clonehd stretch.vmdk stretch.vdi --format VDI --variant Standard
    >   VBoxManage modifyhd stretch.vdi --resize 81920
    >
    > The disksize plugin creates .VDI type of virtual HDD with the
    > stretched virtual size of 80GB (default .VMDK has limited 10GB size).
    >
    > Please, do note that third party tool is required to extend the actual
    > virtual disk limit (as tool example: gparted).
    >
    > In Vagrant file, you could create/add some code like this:
    >
    > if !Vagrant.has_plugin?("vagrant-disksize")
    >    system('vagrant plugin install vagrant-disksize');
    > end
    >
    > Vagrant.configure(2) do |config|
    >   config.vm.provider :virtualbox do |vbox, override|
    >     config.vm.box = "debian/stretch64"
    >     config.disksize.size = '80GB'
    >
    >     vbox.customize ["modifyvm", :id, "--vram", "32"]
    >     vbox.customize ["modifyvm", :id, "--memory", "4096"]
    >     vbox.customize ["modifyvm", :id, "--cpus", "4"]
    >     vbox.customize ["modifyvm", :id, "--firmware", "bios"]
    >     vbox.customize ["modifyvm", :id, "--acpi", "on"]
    >     vbox.customize ["modifyvm", :id, "--ioapic", "on"]
    >     vbox.customize ["modifyvm", :id, "--cpuexecutioncap", "75"]
    >     vbox.customize ["modifyvm", :id, "--rtcuseutc", "on"]
    >     vbox.customize ["modifyvm", :id, "--cpuhotplug", "on"]
    >     vbox.customize ["modifyvm", :id, "--pae", "on"]
    >     vbox.customize ["modifyvm", :id, "--hwvirtex", "on"]
    >     vbox.customize ["modifyvm", :id, "--accelerate3d", "on"]
    >     vbox.customize ["modifyvm", :id, "--clipboard", "bidirectional"]
    >     vbox.customize ["modifyvm", :id, "--draganddrop", "bidirectional"]
    >     vbox.customize ["modifyvm", :id, "--usb", "on"]
    >     vbox.customize ["modifyvm", :id, "--usbehci", "on"]
    >     ...
    > _______
    >
    > I also created [1] VBox VMM configuration and [2] Debian Stretch VM
    > configuration stages with pre-seed script (both stages execute with
    > one single command respectively), but [3] Lava VM test machine
    > creation without Vagrant assistance failed!
    >
    > In other words I was not able to create [3] Lava VM provisioning stage
    > (in my first Vagrant-less attempt), using blindly unchanged CIP test
    > integration scripts.
    >
    > I need to revisit integration scripts, my best guess. But I'll
    > continue to work on Vagrant-less test strategy, as my time allows
    > (engaged in several other projects).
    >
    > Thank you,
    > Zoran
    > _______________________________________________
    > cip-dev mailing list
    > cip-dev@...
    > https://lists.cip-project.org/mailman/listinfo/cip-dev
    >
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev
    Re: [CIP testing strategy] Vagrant disksize plugin introduced, and some other (Vagrant-less) ideas

    Robert Marshall <robert.marshall@...>
     

    Zoran

    Thanks for alerting me to this I'll take a look!

    Robert

    Zoran S <zoran.stojsavljevic.de@...> writes:

    Hello CIP members,

    Recently, I have learned that vagrant disksize plugin was introduced.
    https://github.com/sprotheroe/vagrant-disksize

    This, actually, replaces two native VBox commands (example given below):

    VBoxManage clonehd stretch.vmdk stretch.vdi --format VDI --variant Standard
    VBoxManage modifyhd stretch.vdi --resize 81920

    The disksize plugin creates .VDI type of virtual HDD with the
    stretched virtual size of 80GB (default .VMDK has limited 10GB size).

    Please, do note that third party tool is required to extend the actual
    virtual disk limit (as tool example: gparted).

    In Vagrant file, you could create/add some code like this:

    if !Vagrant.has_plugin?("vagrant-disksize")
    system('vagrant plugin install vagrant-disksize');
    end

    Vagrant.configure(2) do |config|
    config.vm.provider :virtualbox do |vbox, override|
    config.vm.box = "debian/stretch64"
    config.disksize.size = '80GB'

    vbox.customize ["modifyvm", :id, "--vram", "32"]
    vbox.customize ["modifyvm", :id, "--memory", "4096"]
    vbox.customize ["modifyvm", :id, "--cpus", "4"]
    vbox.customize ["modifyvm", :id, "--firmware", "bios"]
    vbox.customize ["modifyvm", :id, "--acpi", "on"]
    vbox.customize ["modifyvm", :id, "--ioapic", "on"]
    vbox.customize ["modifyvm", :id, "--cpuexecutioncap", "75"]
    vbox.customize ["modifyvm", :id, "--rtcuseutc", "on"]
    vbox.customize ["modifyvm", :id, "--cpuhotplug", "on"]
    vbox.customize ["modifyvm", :id, "--pae", "on"]
    vbox.customize ["modifyvm", :id, "--hwvirtex", "on"]
    vbox.customize ["modifyvm", :id, "--accelerate3d", "on"]
    vbox.customize ["modifyvm", :id, "--clipboard", "bidirectional"]
    vbox.customize ["modifyvm", :id, "--draganddrop", "bidirectional"]
    vbox.customize ["modifyvm", :id, "--usb", "on"]
    vbox.customize ["modifyvm", :id, "--usbehci", "on"]
    ...
    _______

    I also created [1] VBox VMM configuration and [2] Debian Stretch VM
    configuration stages with pre-seed script (both stages execute with
    one single command respectively), but [3] Lava VM test machine
    creation without Vagrant assistance failed!

    In other words I was not able to create [3] Lava VM provisioning stage
    (in my first Vagrant-less attempt), using blindly unchanged CIP test
    integration scripts.

    I need to revisit integration scripts, my best guess. But I'll
    continue to work on Vagrant-less test strategy, as my time allows
    (engaged in several other projects).

    Thank you,
    Zoran
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev
    Beaglebone Black sumo kas-bbb-sumo.yml script

    Zoran
     

    Hello,

    I needed sumo script to do some dirty and quick bbb YOCTO rootfs and kernel production.

    For this purpose I have enhanced the initial Beaglebone Black rocko kas script to sumo, to serve to the purpose.

    If anybody needs it, please, find it attached (with some addendums).

    Please, also do note that the script takes default variables, if they are not explicitly specified.

    Thank you,
    Zoran
    _______

    ?
    kas-bbb-sumo.yml

    Re: Altera CIP branch vs. Denali NAND driver

    Takuo Koguchi
     

    Jan,

    Yeah, I wouldn't be surprised if I missed some patch that makes a
    difference on your board. But upstream 4.14+ works fine for you, right?
    Oops, I should have done it before hand!
    I tried 4.17.0-rc2 on my cyclone5 board just now.
    It was better than denali-cip-backport but it did not work either. It found Bad block table but
    timeout while waiting for irq 0x4
    nand_bbt: error reading BBT
    and cannot mount the file system on it.

    I will have to investigating this shortly...

    Takuo


    -----Original Message-----
    From: Jan Kiszka <jan.kiszka@...>
    Sent: Thursday, July 12, 2018 2:36 PM
    To: 小口琢夫 / KOGUCHI，TAKUO <takuo.koguchi.sw@...>; Marek Vasut <marex@...>
    Cc: Henning Schild <henning.schild@...>; cip-dev <cip-dev@...>
    Subject: [!]Re: Altera CIP branch vs. Denali NAND driver

    On 2018-07-12 03:47, 小口琢夫 / KOGUCHI，TAKUO wrote:
    Jan,
    I have tried to build denali-cip-backport and spent some time. It does not work yet on
    my boards.
    I saw "nand: timed out while waiting for chip to become ready" several times and the probe
    function failed.
    Sorry to say, I will not able to continue this effort for now.
    When I would make a progress, I will let you know.
    Yeah, I wouldn't be surprised if I missed some patch that makes a
    difference on your board. But upstream 4.14+ works fine for you, right?

    Thanks for trying out nevertheless!

    Jan

    Best Regards,

    Takuo

    -----Original Message-----
    From: Jan Kiszka <jan.kiszka@...>
    Sent: Friday, July 06, 2018 8:21 PM
    To: 小口琢夫 / KOGUCHI，TAKUO <takuo.koguchi.sw@...>; Marek Vasut
    <marex@...>
    Cc: Henning Schild <henning.schild@...>; cip-dev
    <cip-dev@...>
    Subject: [!]Re: Altera CIP branch vs. Denali NAND driver

    On 2018-07-06 10:53, 小口琢夫 / KOGUCHI，TAKUO wrote:
    Hi Jan,

    -----Original Message-----
    From: Jan Kiszka <jan.kiszka@...>
    Sent: Friday, July 06, 2018 5:06 PM
    (2) Bootloader needs to set SPARE_AREA_SKIP_BYTES properly, which is used by
    denali_hw_init.
    (I do not remember the actual value off the top of my head). Without this, it resulted
    in
    ECC errors as far as I remember.

    We are using upstream U-boot (Marek sorted out the BSP U-boot
    differences for us). I suppose you were using the Altera's version,
    right? Marek, any comment on this tuning?
    Yes. I am using u-boot which came with Altera SoCSDK for the custom boards.



    Regarding to Denali Driver backport, "ignores other NAND drivers" is not a good idea
    even
    for the playground, though I am not quite sure.

    I know, but this is related to the fact that the backport started as
    proof-of-concept and targets that single device only so far. This would
    have to be resolved when we wanted broader use, but it only makes sense
    if there is interest.
    At lease I am interested.
    That's a good start! To help the discussion, I just pushed our
    work-in-progress branch here:

    https://clicktime.symantec.com/a/1/F8dAar5oXXL8ThwUCaqkcZWZ4mzqV2UK6LFuZQ8TuME=?d=EXT8h
    pgpr56TSRvXnP65tXaLN2CmPa-z5_-z-jES6Avk7IHyojYPdGlFS55ZRmMK3wgYGo6wDmN5xCrI8DyPN0X5kLeM
    irO_Aq3Yk6V0A5dp7VJNu2I0P-6Fv0f0VQ8cgamsxMALkTpiaihP39xTkygbp0CEvtis80ATkWGXpYLqsbPZ92t
    jlqKb8zYq28fZzg5m2JU5EEFU7uyN5GISKV03Msk8EBE883MXcBV5HS3sQZ87_-uBu0lRIvjdjai5s1UWLxlgb9
    kjj51qXxSOGkoRuYsPHD_aaP-FSs5yOj1DCMS8moiRA2M8JWJYjL9mTCv9ebr3wau_UEtuMoXGGIVqQVoEwOWFL
    qUf-wX9qa2ad1QUhQ0JLBk86NNP8a4rPNMTZRkYUw%3D%3D&u=http%3A%2F%2Fgit.kiszka.org%2F%3Fp%3D
    linux.git%3Ba%3Dshortlog%3Bh%3Drefs%2Fheads%2Fdenali-cip-backport

    Jan

    --
    Siemens AG, Corporate Technology, CT RDA IOT SES-DE
    Corporate Competence Center Embedded Linux

    --
    Siemens AG, Corporate Technology, CT RDA IOT SES-DE
    Corporate Competence Center Embedded Linux
    Re: Altera CIP branch vs. Denali NAND driver

    Jan Kiszka
     

    On 2018-07-12 03:47, 小口琢夫 / KOGUCHI，TAKUO wrote:
    Jan,
    I have tried to build denali-cip-backport and spent some time. It does not work yet on my boards.
    I saw "nand: timed out while waiting for chip to become ready" several times and the probe function failed.
    Sorry to say, I will not able to continue this effort for now.
    When I would make a progress, I will let you know.
    Yeah, I wouldn't be surprised if I missed some patch that makes a
    difference on your board. But upstream 4.14+ works fine for you, right?

    Thanks for trying out nevertheless!

    Jan

    Best Regards,

    Takuo

    -----Original Message-----
    From: Jan Kiszka <jan.kiszka@...>
    Sent: Friday, July 06, 2018 8:21 PM
    To: 小口琢夫 / KOGUCHI，TAKUO <takuo.koguchi.sw@...>; Marek Vasut <marex@...>
    Cc: Henning Schild <henning.schild@...>; cip-dev <cip-dev@...>
    Subject: [!]Re: Altera CIP branch vs. Denali NAND driver

    On 2018-07-06 10:53, 小口琢夫 / KOGUCHI，TAKUO wrote:
    Hi Jan,

    -----Original Message-----
    From: Jan Kiszka <jan.kiszka@...>
    Sent: Friday, July 06, 2018 5:06 PM
    (2) Bootloader needs to set SPARE_AREA_SKIP_BYTES properly, which is used by
    denali_hw_init.
    (I do not remember the actual value off the top of my head). Without this, it resulted
    in
    ECC errors as far as I remember.

    We are using upstream U-boot (Marek sorted out the BSP U-boot
    differences for us). I suppose you were using the Altera's version,
    right? Marek, any comment on this tuning?
    Yes. I am using u-boot which came with Altera SoCSDK for the custom boards.



    Regarding to Denali Driver backport, "ignores other NAND drivers" is not a good idea
    even
    for the playground, though I am not quite sure.

    I know, but this is related to the fact that the backport started as
    proof-of-concept and targets that single device only so far. This would
    have to be resolved when we wanted broader use, but it only makes sense
    if there is interest.
    At lease I am interested.
    That's a good start! To help the discussion, I just pushed our
    work-in-progress branch here:

    https://clicktime.symantec.com/a/1/F8dAar5oXXL8ThwUCaqkcZWZ4mzqV2UK6LFuZQ8TuME=?d=EXT8h
    pgpr56TSRvXnP65tXaLN2CmPa-z5_-z-jES6Avk7IHyojYPdGlFS55ZRmMK3wgYGo6wDmN5xCrI8DyPN0X5kLeM
    irO_Aq3Yk6V0A5dp7VJNu2I0P-6Fv0f0VQ8cgamsxMALkTpiaihP39xTkygbp0CEvtis80ATkWGXpYLqsbPZ92t
    jlqKb8zYq28fZzg5m2JU5EEFU7uyN5GISKV03Msk8EBE883MXcBV5HS3sQZ87_-uBu0lRIvjdjai5s1UWLxlgb9
    kjj51qXxSOGkoRuYsPHD_aaP-FSs5yOj1DCMS8moiRA2M8JWJYjL9mTCv9ebr3wau_UEtuMoXGGIVqQVoEwOWFL
    qUf-wX9qa2ad1QUhQ0JLBk86NNP8a4rPNMTZRkYUw%3D%3D&u=http%3A%2F%2Fgit.kiszka.org%2F%3Fp%3D
    linux.git%3Ba%3Dshortlog%3Bh%3Drefs%2Fheads%2Fdenali-cip-backport

    Jan

    --
    Siemens AG, Corporate Technology, CT RDA IOT SES-DE
    Corporate Competence Center Embedded Linux

    --
    Siemens AG, Corporate Technology, CT RDA IOT SES-DE
    Corporate Competence Center Embedded Linux

    Re: Altera CIP branch vs. Denali NAND driver

    Takuo Koguchi
     

    Jan,
    I have tried to build denali-cip-backport and spent some time. It does not work yet on my boards.
    I saw "nand: timed out while waiting for chip to become ready" several times and the probe function failed.
    Sorry to say, I will not able to continue this effort for now.
    When I would make a progress, I will let you know.

    Best Regards,

    Takuo

    -----Original Message-----
    From: Jan Kiszka <jan.kiszka@...>
    Sent: Friday, July 06, 2018 8:21 PM
    To: 小口琢夫 / KOGUCHI，TAKUO <takuo.koguchi.sw@...>; Marek Vasut <marex@...>
    Cc: Henning Schild <henning.schild@...>; cip-dev <cip-dev@...>
    Subject: [!]Re: Altera CIP branch vs. Denali NAND driver

    On 2018-07-06 10:53, 小口琢夫 / KOGUCHI，TAKUO wrote:
    Hi Jan,

    -----Original Message-----
    From: Jan Kiszka <jan.kiszka@...>
    Sent: Friday, July 06, 2018 5:06 PM
    (2) Bootloader needs to set SPARE_AREA_SKIP_BYTES properly, which is used by
    denali_hw_init.
    (I do not remember the actual value off the top of my head). Without this, it resulted
    in
    ECC errors as far as I remember.

    We are using upstream U-boot (Marek sorted out the BSP U-boot
    differences for us). I suppose you were using the Altera's version,
    right? Marek, any comment on this tuning?
    Yes. I am using u-boot which came with Altera SoCSDK for the custom boards.



    Regarding to Denali Driver backport, "ignores other NAND drivers" is not a good idea
    even
    for the playground, though I am not quite sure.

    I know, but this is related to the fact that the backport started as
    proof-of-concept and targets that single device only so far. This would
    have to be resolved when we wanted broader use, but it only makes sense
    if there is interest.
    At lease I am interested.
    That's a good start! To help the discussion, I just pushed our
    work-in-progress branch here:

    https://clicktime.symantec.com/a/1/F8dAar5oXXL8ThwUCaqkcZWZ4mzqV2UK6LFuZQ8TuME=?d=EXT8h
    pgpr56TSRvXnP65tXaLN2CmPa-z5_-z-jES6Avk7IHyojYPdGlFS55ZRmMK3wgYGo6wDmN5xCrI8DyPN0X5kLeM
    irO_Aq3Yk6V0A5dp7VJNu2I0P-6Fv0f0VQ8cgamsxMALkTpiaihP39xTkygbp0CEvtis80ATkWGXpYLqsbPZ92t
    jlqKb8zYq28fZzg5m2JU5EEFU7uyN5GISKV03Msk8EBE883MXcBV5HS3sQZ87_-uBu0lRIvjdjai5s1UWLxlgb9
    kjj51qXxSOGkoRuYsPHD_aaP-FSs5yOj1DCMS8moiRA2M8JWJYjL9mTCv9ebr3wau_UEtuMoXGGIVqQVoEwOWFL
    qUf-wX9qa2ad1QUhQ0JLBk86NNP8a4rPNMTZRkYUw%3D%3D&u=http%3A%2F%2Fgit.kiszka.org%2F%3Fp%3D
    linux.git%3Ba%3Dshortlog%3Bh%3Drefs%2Fheads%2Fdenali-cip-backport

    Jan

    --
    Siemens AG, Corporate Technology, CT RDA IOT SES-DE
    Corporate Competence Center Embedded Linux
    Re: [PATCH 62/86] ARM: dts: r8a7745: Add operating-points to cpu0

    Fabrizio Castro <fabrizio.castro@...>
     

    [...]

    Then I will cherry-pick that commit instead.
    Could you please cherry-pick this commit too then:
    035ed07208dc501d023873447113f3f178592156 ("PM / OPP: Move error
    message to debug level")
    OK, done.

    Ben.
    Thank you Ben.



    Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

    Re: [PATCH 62/86] ARM: dts: r8a7745: Add operating-points to cpu0

    Ben Hutchings <ben.hutchings@...>
     

    On Mon, 2018-07-09 at 10:29 +0000, Fabrizio Castro wrote:
    Hello Ben,

    Thank you for your feedback!

    -----Original Message-----
    From: Ben Hutchings [mailto:ben.hutchings@...]
    Sent: 08 July 2018 20:02
    To: Fabrizio Castro <fabrizio.castro@...>
    Cc: cip-dev@...; Chris Paterson <Chris.Paterson2@...>; Biju Das <biju.das@...>
    Subject: Re: [cip-dev][PATCH 62/86] ARM: dts: r8a7745: Add
    operating-points to cpu0

    On Fri, 2018-07-06 at 10:00 +0000, Fabrizio Castro wrote:
    Hello Ben,

    Thank you for your feedback.

    Subject: Re: [cip-dev][PATCH 62/86] ARM: dts: r8a7745: Add
    operating-points to cpu0

    On Fri, 2018-06-29 at 15:39 +0100, Fabrizio Castro wrote:
    shmobile_defconfig builds cpu freq into the kernel by default,
    therefore we get error and warning messages at boot, when
    hotplugging cpus, and when waking up from suspend to RAM.

    Although the r8a7745 SoC does not support DVFS, defining one
    operating point makes cpu freq happy and therefore all of the
    nasty messages disappear.
    Why was this not needed upstream?
    Since there is a chance for the OPP to be registered dynamically the
    upstream kernel won't print error messages (only debug messages), as
    opposed to the CIP kernel which will print error messages. Have a
    look at 5b60697cd89cf5a438b2984e11859228e5ec1c6b.
    [...]

    Then I will cherry-pick that commit instead.
    Could you please cherry-pick this commit too then:
    035ed07208dc501d023873447113f3f178592156 ("PM / OPP: Move error
    message to debug level")
    OK, done.

    Ben.

    --
    Ben Hutchings, Software Developer   Codethink Ltd
    https://www.codethink.co.uk/ Dale House, 35 Dale Street
    Manchester, M1 2HF, United Kingdom

    9221 - 9240 of 10626