summaryrefslogtreecommitdiffstats
path: root/meta-egvirt/recipes-kernel
AgeCommit message (Collapse)AuthorFilesLines
2022-11-10virtualization: Add virtio-can driver as external module.Vasyl Vavrychuk4-0/+1235
This driver should conform RFC spec draft v2 [1]. This driver is based on RFC version [2]. Imported from internal OpenSynergy's revision: 3918336a7caab95a72442c33945a193ca893d5e8 Supply build file `Kbuild` and do not supply makefile [3] since external kernel module could be built without it. On the other hand, module BitBake class relies on wrapper makefile presence, therefore `MAKE_TARGETS` and `MODULES_INSTALL_TARGET` had to be set to specify arguments per [3]. Add driver as an external module to avoid unnecessary kernel rebuild and simplify future updates. [1]: https://lists.oasis-open.org/archives/virtio-dev/202208/msg00159.html [2]: https://lists.oasis-open.org/archives/virtio-dev/202208/msg00160.html [3]: https://www.kernel.org/doc/html/v6.0/kbuild/modules.html Change-Id: I9b654f58cc0c34983cd4103a5f7836263db79ec7 Bug-AGL: SPEC-4597 Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
2022-09-22egvirt: linux-yocto: Support linux-yocto-dev for VIRTIO.Vasyl Vavrychuk4-3/+128
Bug-AGL: SPEC-4453 Change-Id: Ib3641884bac404c7281df37e5ed4f4939e2830b4 Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
2022-06-08egvirt: linux-yocto: Add virtio_bt driver.Vasyl Vavrychuk3-0/+91
virtio-bt is not part of OASIS standard yet (v1.2) but Linux kernel has driver for virtio transport for BT HCI. Submit driver to meta-agl-devel since patch [1] is WIP and has a known issue. [1]: 0002-Bluetooth-virtio_bt-fix-device-removal.patch Bug-AGL: SPEC-4363 Change-Id: Ib6851df24d430e991a4e9078345bef7e440fb6de Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
2022-06-08egvirt: linux-yocto: Remove virtio-scmi patches.Vasyl Vavrychuk5-184/+0
Those patches are now in mainline kernel, so they are moved to meta-agl. Bug-AGL: SPEC-3865, SPEC-4365 Change-Id: I08a184c6db63afef67a2e0906bc6a9a61ec4286f Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
2022-06-08egvirt: linux-yocto: Adapt for kernel v5.15.Vasyl Vavrychuk22-3791/+70
* Remove changes already present in v5.15. * Refresh other patches. * Document how to recreate kernel configs for future reference. Bug-AGL: SPEC-4365 Change-Id: If8f900c9de7d8536364d71288902fd842d3ddc5f Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
2022-03-24Update to SPDX license namesScott Murray1-1/+1
Apply updates from running the new convert-spdx-licenses script from upstream. This is not currently a hard requirement from upstream, but futureproofs for when the license name mapping is finally removed. Bug-AGL: SPEC-3819 Signed-off-by: Scott Murray <scott.murray@konsulko.com> Change-Id: Iad7f9d353d3111287e2b39ee98cd872e2b7fec32
2021-12-07virtualization: Add virtio-video driver as external module.Vasyl Vavrychuk16-0/+5847
This driver should conform WIP spec v3 [1] with some updates for spec v4 [2], and, some unspecified features such as VIRTIO_VIDEO_DEVICE_CAMERA. Imported from internal OpenSynergy's revision: bcc33b6b9e0156b381a70c54d2df02c57b63d270 Kernel was configured with necessary features for this driver: enable MEDIA_SUPPORT disable MEDIA_SUBDRV_AUTOSELECT enable MEDIA_PLATFORM_SUPPORT enable VIDEO_VIRTIO Keep driver as an external module to simplify future updates. [1]: https://lists.oasis-open.org/archives/virtio-dev/202002/msg00002.html [2]: https://lists.oasis-open.org/archives/virtio-dev/202006/msg00072.html Bug-AGL: SPEC-4148 Change-Id: Iea339194b22443f67b3e2ffddca84118357a2f15 Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
2021-11-23virtualization: linux-yocto build fail due to missing FILESEXTRAPATHS:prepend.Vasyl Vavrychuk1-0/+2
Apparently linux-yocto with meta-egvirt enabled was not built. Bug-AGL: SPEC-3865 Change-Id: I4e70ea0ec9e57b3c12e67fe2f9e533f2b78e1518 Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
2021-11-01virtualization/linux-yocto: iio/scmi: Add reading "raw" attribute support.Andriy Tryshnivskyy3-0/+143
agl-service-iiodevices reads IIO device "raw" attribute. Patches were adapted for current kernel version. Bug-AGL: SPEC-3865 Upstream-Status: Submitted [https://lore.kernel.org/all/20211024091627.28031-1-andriy.tryshnivskyy@opensynergy.com/] Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com> Change-Id: I4f3e14e9d557a13ff955de43035e564d80873038
2021-10-14virtualization/linux-yocto: Add SCMIv3.0 Sensor Extensions patches.Andriy Tryshnivskyy7-0/+1484
IIO SCMI driver assumes that those changes are present. It fails to compile without them. Bug-AGL: SPEC-3865 Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com> Change-Id: Ia0011b5b621fc08321a1d74f3ae00e2780f3188a
2021-10-14virtualization/linux-yocto: Enable IIO SCMI.Andriy Tryshnivskyy2-0/+2
Snippet has been updated using menuconfig/diffconfig tasks. Bug-AGL: SPEC-3865 Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com> Change-Id: I7c885d818f6ae80804f5ae9446072af05332bdf2
2021-10-14virtualization/linux-yocto: Backport IIO SCMI based sensors driver.Andriy Tryshnivskyy2-0/+802
This patch series is the latest implementation of ARM SCMI Protocol based IIO Device. Patch was cherry-picked from branch [1] created by IIO maintainer. [1]: https://lore.kernel.org/lkml/20210311210844.34371d8d@archlinux/ Bug-AGL: SPEC-3865 Upstream-Status: Submitted [https://lore.kernel.org/lkml/20210309231259.78050-1-jbhayana@google.com/] Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com> Change-Id: Idef6f0630887c49c1d8e651a5ac753ad74b20dc0
2021-10-14virtualization/linux-yocto: Enable virtio SCMI driver.Andriy Tryshnivskyy2-0/+6
Snippet has been generated using menuconfig/diffconfig tasks. Enabled VIRTIO_SCMI and ARM_SCMI_PROTOCOL. Switch off enabled by default ARM_SCMI_POWER_DOMAIN since it is not planned to be used at the moment. Bug-AGL: SPEC-3865 Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com> Change-Id: Ic4d3623c0fe330513a04b503c2037f0769d6ce69
2021-10-14virtualization/linux-yocto: Backport virtio SCMI driver.Andriy Tryshnivskyy11-0/+1489
This patch series is a "RFC v2" implementation of a driver for virtio SCMI device [1]. [1]: https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-scmi.tex Bug-AGL: SPEC-3865 Upstream-Status: Submitted [https://lore.kernel.org/linux-arm-kernel/20201105212116.411422-1-peter.hilber@opensynergy.com/] Signed-off-by: Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com> Change-Id: I653cb44769232ae5434bd54169910fd0518f1db8
2021-01-15meta-egvirt, templates: Remove virtio-aarch64 machine.koi_10.92.0koi/10.92.010.92.0Vasyl Vavrychuk6-69/+0
It is moved to meta-agl repository. Bug-AGL: SPEC-3668 Change-Id: I7f02d5afe42f96a955ebd1ea7735a9b84fee9cc8 Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
2020-11-17meta-egvirt, templates: Add virtio-aarch64 machineVasyl Vavrychuk6-0/+69
This machine is intended to run in ARMv8 virtualized environment that provides VirtIO devices. AGL machine configuration files are based on qemuarm64 machine from meta-agl branch master commit e1da0efcd2eece82b0326798cfeaeb8dd48797fc. Yocto machine configuration files are based on qemuarm64 machine from Poky branch dunfell commit 4e931b1d05018923dc145cd97f6f965f5cb6e1a5. Yocto Linux Kernel is used as recommended in [1]. Its metadata for the created machine are based on qemuarm64-standard.scc from yocto-kernel-cache branch yocto-5.4 commit 4aeda12f7f7eb84613ae1fe6e22cd9cd9790c20b. The rationale behind creating new machine is a wish to have a machine that could run on other hypervisor/virtual machine monitor that implements VirtIO, not necessary QEMU. For now, virtio-aarch64 machine runs under QEMU and OpenSynergy COQOS Hypervisor. virtio-aarch64 machine includes following changes comparing to qemuarm64: * use virtio-gpu instead of VGA display (to be upstreamed to work in conjunction with runqemu gl, sdl, etc. options) * use virtio-bus instead of PCI bus QEMU devices * remove unneeded configurations [1]: https://www.yoctoproject.org/docs/3.1.2/bsp-guide/bsp-guide.html#released-bsp-recommendations Bug-AGL: SPEC-3668 Change-Id: Iccfee8613de63770d371a57f0caab1c1eba8d912 Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
type (or for old FTDI without serial number) you need to get the devpath attribute via: ``` udevadm info -a -n /dev/ttyUSBx |grep ATTR|grep devpath | head -n1 ``` Example with a FTDI UART: ``` [ 6.616707] usb 4-1.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 6.704305] usb 4-1.4.2: SerialNumber: AK04TU1X The serial is AK04TU1X ``` So you have now: ``` - name: beagleboneblack-01 type: beaglebone-black uart: idvendor: 0x0403 idproduct: 0x6001 serial: AK04TU1X ``` Example with a FTDI without serial: ``` [2428401.256860] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected [2428401.256916] usb 1-1.4: Detected FT232BM [2428401.257752] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB1 udevadm info -a -n /dev/ttyUSB1 |grep devpath | head -n1 ATTRS{devpath}=="1.5" ``` So you have now: ``` - name: beagleboneblack-01 type: beaglebone-black uart: idvendor: 0x0403 idproduct: 0x6001 devpath: "1.5" ``` #### PDU (Power Distribution Unit) Final step is to manage the powering of the board.<br> Many PDU switchs could be handled by a command line tool which control the PDU.<br> You need to fill boards.yaml with the command line to be ran.<br> Example with an ACME board: If the beagleboneblack is wired to port 3 and the ACME board have IP 192.168.66.2: ``` pdu_generic: hard_reset_command: /usr/local/bin/acme-cli -s 192.168.66.2 reset 3 power_off_command: /usr/local/bin/acme-cli -s 192.168.66.2 power_off 3 power_on_command: /usr/local/bin/acme-cli -s 192.168.66.2 power_on 3 ``` #### Example: beagleboneblack, with FTDI (serial 1234567), connected to port 5 of an ACME ``` - name: beagleboneblack-01 type: beaglebone-black pdu_generic: hard_reset_command: /usr/local/bin/acme-cli -s 192.168.66.2 reset 5 power_off_command: /usr/local/bin/acme-cli -s 192.168.66.2 power_off 5 power_on_command: /usr/local/bin/acme-cli -s 192.168.66.2 power_on 5 uart: idvendor: 0x0403 idproduct: 0x6001 serial: 1234567 ``` ## Architecture The basic setup is composed of a host which runs the following docker images and DUT to be tested.<br/> * lava-master: run lava-server along with the web interface * lava-slave: run lava-dispatcher, the compoment which sends jobs to DUTs The host and DUTs must share a common LAN.<br/> The host IP on this LAN must be set as dispatcher_ip in boards.yaml.<br/> Since most DUTs are booted using TFTP, they need DHCP for gaining network connectivity.<br/> So, on the LAN shared with DUTs, a running DHCPD is necessary. (See DHCPD below)<br/> ![lava-docker diagram](doc/lava-docker.png) ## Multi-host architectures Lava-docker support multi-host architecture, Master and slaves could be on different host. Lava-docker support multiples slaves, but with a maximum of one slave per host. This is due to that slave need TFTP port accessible from outside. ### Power supply You need to have a PDU for powering your DUT. Managing PDUs is done via pdu_generic ### Network ports The following ports are used by lava-docker and are proxyfied on the host: - 69/UDP proxyfied to the slave for TFTP - 80 proxyfied to the slave for TODO (transfer overlay) - 5500 proxyfied to the slave for Notification - 5555 proxyfied to the master (LAVA logger) - 5556 proxyfied to the master (LAVA master) - 10080 proxyfied to the master (Web interface) - 55950-56000 proxyfied to the slave for NBD ### DHCPD A DHCPD service is necessary for giving network access to DUT. The DHCPD server could be anywhere with the condition that it is accessible of DUTs. (Could be on host, in a docker in the host, or is the ISP box on the same LAN.<br/> ### Examples #### Example 1: Basic LAB with home router Router: 192.168.1.1 which handle DHCP for 192.168.1.10-192.168.1.254<br> Lab: 192.168.1.2<br> So the dispatcher_ip is set to 192.168.1.2 #### Example 2: Basic LAB without home router Lab: 192.168.1.2 which handle DHCP for 192.168.1.10-192.168.1.254<br> So the dispatcher_ip is set to 192.168.1.2 #### Example 3: LAB with dedicated LAN for DUTs A dedicated LAN is used for DUTs. (192.168.66.0/24) The host have two NIC: - eth0: (192.168.1.0/24) on home LAN. (The address could be static or via DHCP) - eth1: (192.168.66.0/24) with address set to 192.168.66.1 On the host, a DHCPD give address in range of 192.168.66.3-192.168.66.200 So the dispatcher_ip is set to 192.168.66.1 #### DHCPD examples: ##### isc-dhcpd-server A sample isc-dhcpd-server DHCPD config file is available in the dhcpd directory.<br/> ##### dnsmasq Simply set interface=interfacename where interfacename is your shared LAN interface ## Generating files ### Helper script You can use the lavalab-gen.sh helper script which will do all the above actions for you. ### boards.yaml This file describe how the DUTs are connected and powered. ``` masters: - name: lava-master name of the master host: name name of the host running lava-master (default to "local") webadmin_https: Does the LAVA webadmin is accessed via https zmq_auth: True/False Does the master requires ZMQ authentication. zmq_auth_key: optional path to a public ZMQ key zmq_auth_key_secret: optional path to a private ZMQ key slave_keys: optional path to a directory with slaves public key. Usefull when you want to create a master without slaves nodes in boards.yaml. persistent_db: True/False (default False) Is the postgres DB is persistent over reboot http_fqdn: The FQDN used to access the LAVA web interface. This is necessary if you use https otherwise you will issue CSRF errors. users: - name: LAVA username token: The token of this user (optional) password: Password the this user (generated if not provided) email: email of the user (optional) superuser: yes/no (default no) staff: yes/no (default no) groups: - name: Name of the group this user should join groups: - name: LAVA group name submitter: True/False Can this group can submit jobs tokens: - username: The LAVA user owning the token below. (This user should be created via users:) token: The token for this callback description: The description of this token. This string could be used with LAVA-CI. slaveenv: A list of environment to pass to slave - name: slavename The name of slave (mandatory) env: - line1 A list of line to set as environment - line2 slaves: - name: lab-slave-XX The name of the slave (where XX is a number) host: name name of the host running lava-slave-XX (default to "local") zmq_auth_key: optional path to a public ZMQ key zmq_auth_key_secret: optional path to a private ZMQ key zmq_auth_master_key: optional path to the public master ZMQ key. This option is necessary only if no master node exists in boards.yaml. dispatcher_ip: the IP where the slave could be contacted. In lava-docker it is the host IP since docker proxify TFTP from host to the slave. remote_master: the name of the master to connect to remote_address: the FQDN or IP address of the master (if different from remote_master) remote_rpc_port: the port used by the LAVA RPC2 (default 80) remote_user: the user used for connecting to the master remote_user_token: The remote_user's token. This option is necessary only if no master node exists in boards.yaml. Otherwise lavalab-gen.py will get from it. remote_proto: http(default) or https default_slave: Does this slave is the default slave where to add boards (default: lab-slave-0) bind_dev: Bind /dev from host to slave. This is needed when using some HID PDU expose_ser2net: Do ser2net ports need to be available on host expose_ports: Expose port p1 on the host to p2 on the worker slave. - p1:p2 extra_actions: An optional list of action to do at end of the docker build - "apt-get install package" env: - line1 A list of line to set as environment (See /etc/lava-server/env.yaml for examples) - line2 boards: - name: devicename Each board must be named by their device-type as "device-type-XX" (where XX is a number) type: the LAVA device-type of this device slave: (optional) Name of the slave managing this device. Default to first slave found or default_slave if set. kvm: (For qemu only) Does the qemu could use KVM (default: no) uboot_ipaddr: (optional) a static IP to set in uboot uboot_macaddr: (Optional) the MAC address to set in uboot custom_option: (optional) All following strings will be directly append to devicefile - "set x=1" tags: (optional) List of tag to set on this device - tag1 - tag2 user: (optional) Name of user owning the board (LAVA default is admin) user is exclusive with group group: (optional) Name of group owning the board (no LAVA default) group is exclusive with user # One of uart or connection_command must be choosen uart: idvendor: The VID of the UART (Formated as 0xXXXX) idproduct: the PID of the UART (Formated as 0xXXXX) serial: The serial number in case of FTDI uart devpath: the UDEV devpath to this uart for UART without serial number interfacenum: (optional) The interfacenumber of the serial. (Used with two serial in one device) use_conmux: True/False (Use conmux-console instead of ser2net) use_ser2net: True/False (Deprecated, ser2net is the default uart handler) ser2net_options (optional) A list of ser2net options to add - option1 - option2 use_screen: True/False (Use screen via ssh instead of ser2net) connection_command: A command to be ran for getting a serial console pdu_generic: hard_reset_command: commandline to reset the board power_off_command: commandline to power off the board power_on_command: commandline to power on the board ``` Notes on UART: * Only one of devpath/serial is necessary. * screen usage is discouraged and should not be used, it was added as a workaround for some boards, but ser2net now can handle them. * For finding the right devpath, you could use ``` udevadm info -a -n /dev/ttyUSBx |grep devpath | head -n1 ``` * VID and PID could be found in lsusb. If a leading zero is present, the value must be given between double-quotes (and leading zero must be kept) Example: ``` Bus 001 Device 054: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC ``` This device must use "0403" for idvendor and 6001 for idproduct. Note on connection_command: connection_command is for people which want to use other custom way than ser2net to handle the console. Examples: see [boards.yaml.example](boards.yaml.example) ### Generate ``` lavalab-gen.py ``` this script will generate all necessary files in the following locations: ``` output/host/lava-master/tokens/ This is where the callback tokens will be generated output/host/lava-master/users/ This is where the users will be generated output/host/lab-slave-XX/conmux/ All files needed by conmux output/host/lab-slave-XX/devices/ All LAVA devices files output/host/udev/99-lavaworker-udev.rules udev rules for host output/host/docker-compose.yml Generated from docker-compose.template ``` All thoses file (except for udev-rules) will be handled by docker. You can still hack after all generated files. #### udev rules Note that the udev-rules are generated for the host, they must be placed in /etc/udev/rules.d/ They are used for giving a proper /dev/xxx name to tty devices. (where xxx is the board name) (lavalab-gen.sh will do it for you) ### Building To build all docker images, execute the following from the directory you cloned the repo: ``` docker-compose build ``` ### Running For running all images, simply run: ``` docker-compose up -d ``` ## Proxy cache (Work in progress) A squid docker is provided for caching all LAVA downloads (image, dtb, rootfs, etc...)<br/> You have to uncomment a line in lava-master/Dockerfile to enable it.<br/> For the moment, it is unsupported and unbuilded. ## Backporting LAVA patches All upstream LAVA patches could be backported by placing them in lava-master/lava-patch/ ## Backups / restore For backupping a running docker, the "backup.sh" script could be used. It will store boards.yaml + postgresql database backup + joboutputs. For restoring a backup, postgresql database backup + joboutputs must be copied in master backup directory before build. Example: ./backup.sh This produce a backup-20180704_1206 directory For restoring this backup, simply cp backup-20180704_1206/* output/local/master/backup/ ## Upgrading from a previous lava-docker For upgrading between two LAVA version, the only method is: - backup data by running ./backup.sh on the host running the master (See Backups / restore) - checkout the new lava-docker and your boards.yaml - run lavalab-gen.sh - copy your backup data in output/yourhost/master/backup directory - build and run docker-compose ## Security Note that this container provides defaults which are unsecure. If you plan on deploying this in a production enviroment please consider the following items: * Changing the default admin password (in tokens.taml) * Using HTTPS * Re-enable CSRF cookie (disabled in lava-master/Dockerfile) ## Non amd64 build Since LAVA upstream provides only amd64 and arm64 debian packages, lava-docker support only thoses architectures. For building an arm64 lava-docker, some little trick are necesssary: - replace "baylibre/lava-xxxx-base" by "baylibre/lava-xxxx-base-arm64" for lava-master and lava-slave dockerfiles For building lava-xxx-base images - replace "bitnami/minideb" by "arm64v8/debian" on lava-master-base/lava-slave-base dockerfiles. ## How to add custom LAVA patchs You can add custom or backported LAVA patchs in lava-master/lava-patch Doing the same for lava-slave will be done later. ## How to add/modify custom devices type There are two way to add custom devices types. * Copy a device type file directly in lava-master/device-types/ If you have a brand new device-type, it is the simpliest way. * Copy a patch addding/modifying a device-type in lava-master/device-types-patch/ If you are modifying an already present (upstream) device-type, it is the best way. ## How to made LAVA slave use a proxy ? Add env to a slave like: slave: env: - "http_proxy: http://dns:port" ## Bugs, Contact The prefered way to submit bugs are via the github issue tracker You can also contact us on #lava-docker on the freenode IRC network