To make OpenQA work with real ARM devices, we need to control
- Reset
- HDMI
- USB keyboard / tablet
- SD card
Reset can be done using GPIO. HDMI can be done with a USB HDMI grabber. USB keyboard/tablet can be emulated via USB OTG.
That leaves only SD card simulation to be implemented to automatically verify whether our current openSUSE images still work on ARM development systems.
This project is part of:
Hack Week 14 Hack Week 16
Activity
Comments
Similar Projects
Create openSUSE images for Arm/RISC-V boards by avicenzi
Project Description
Create openSUSE images (or test generic EFI images) for Arm and/or RISC-V boards that are not yet supported.
Goal for this Hackweek
Create bootable images of Tumbleweed for SBCs that currently have no images available or are untested.
Consider generic EFI images where possible, as some boards can hold a bootloader.
Document in the openSUSE Wiki how to flash and use the image for a given board.
Boards that I have around and there are no images:
- Rock 3B
- Nano PC T3 Plus
- Lichee RV D1
- StartFive VisionFive (has some image needs testing)
Hack Week 22
Hack Week 21
Resources
Investigate non-booting Forlinx OKMX8MX-C board (aarch64) by a_faerber
Description
In the context of a SUSE customer inquiry last year, a Forlinx OKMX8MX-C arm64 board had been relayed to me from China that a customer was not successful booting SUSE Linux Micro on. Typically this happens when the vendor's bootloader (e.g., U-Boot) is not configured properly (e.g., U-Boot's distro boot) to be compliant with Arm SystemReady Devicetree (formerly IR) band. Unfortunately I could not immediately get it to emit any output, to even diagnose why it wasn't working. There was no public documentation on the vendor's website to even confirm I was checking the right UARTs.
Earlier this year (2024) I happened to meet the ODM/OEM, Forlinx, at Embedded World 2024 in Nuremberg and again the Monday before Hackweek 24 at Electronica 2024 in Munich. The big puzzle was that the PCB print "OKMX8MX-C" does not match any current Forlinx product, there being OKMX8MM-C and OKMX8MP-C products with the Mini and Plus variants of NXP i.MX 8M family instead. One suggestion from Forlinx staff was to double-check the DIP switches on the board for boot mode selection.
Goals
Double-check the board name and investigate further what may be wrong with this board.
Resources
none
Progress
- The board name is indeed as spelled above, not matching any product on forlinx.net.
- The DIP switches were set to boot from microSD.
- Changing the DIP switches to eMMC boot did result in UART1 RS-232 output! (although at times garbled with the cable supplied and USB adapter used)
- As feared, it did not automatically load our GRUB from USB.
- Booting our GRUB manually from USB (via eMMC U-Boot commands fatload+bootefi) was unsuccessful, with partially Chinese error messages.
- This confirmed the initial suspicion, already shared with Forlinx at Embedded World 2024, that the Forlinx System-on-Module's boot firmware was not Arm SystemReady Devicetree compliant and that a firmware update would be necessary to remedy that.
- The microSD card turned out not to contain a bootable image but to only include Chinese-language board documentation (dated 20220507) and BSP files. They used a diverging name of OKMX8MQ-C.
Improve various phones kernel mainline support (Qualcomm, Exynos, MediaTek) by pvorel
Similar to previous hackweeks ( https://hackweek.opensuse.org/projects/improve-qualcomm-soc-msm8994-slash-msm8992-kernel-mainline-support, https://hackweek.opensuse.org/projects/test-mainline-kernel-on-an-older-qualcomm-soc-msm89xx-explore-mainline-kernel-qualcomm-mainlining) try to improve kernel mainline support of various phones.
Investigate non-booting Forlinx OKMX8MX-C board (aarch64) by a_faerber
Description
In the context of a SUSE customer inquiry last year, a Forlinx OKMX8MX-C arm64 board had been relayed to me from China that a customer was not successful booting SUSE Linux Micro on. Typically this happens when the vendor's bootloader (e.g., U-Boot) is not configured properly (e.g., U-Boot's distro boot) to be compliant with Arm SystemReady Devicetree (formerly IR) band. Unfortunately I could not immediately get it to emit any output, to even diagnose why it wasn't working. There was no public documentation on the vendor's website to even confirm I was checking the right UARTs.
Earlier this year (2024) I happened to meet the ODM/OEM, Forlinx, at Embedded World 2024 in Nuremberg and again the Monday before Hackweek 24 at Electronica 2024 in Munich. The big puzzle was that the PCB print "OKMX8MX-C" does not match any current Forlinx product, there being OKMX8MM-C and OKMX8MP-C products with the Mini and Plus variants of NXP i.MX 8M family instead. One suggestion from Forlinx staff was to double-check the DIP switches on the board for boot mode selection.
Goals
Double-check the board name and investigate further what may be wrong with this board.
Resources
none
Progress
- The board name is indeed as spelled above, not matching any product on forlinx.net.
- The DIP switches were set to boot from microSD.
- Changing the DIP switches to eMMC boot did result in UART1 RS-232 output! (although at times garbled with the cable supplied and USB adapter used)
- As feared, it did not automatically load our GRUB from USB.
- Booting our GRUB manually from USB (via eMMC U-Boot commands fatload+bootefi) was unsuccessful, with partially Chinese error messages.
- This confirmed the initial suspicion, already shared with Forlinx at Embedded World 2024, that the Forlinx System-on-Module's boot firmware was not Arm SystemReady Devicetree compliant and that a firmware update would be necessary to remedy that.
- The microSD card turned out not to contain a bootable image but to only include Chinese-language board documentation (dated 20220507) and BSP files. They used a diverging name of OKMX8MQ-C.
Enhance UV openQA helper script by mdonis
Description
A couple months ago an UV openQA helper script was created to help/automate the searching phase inside openQA for a given MU to test. The script searches inside all our openQA job groups (qam-sle) related with a given MU and generates an output suitable to add (copy & paste) inside the update log.
This is still a WIP and could use some enhancements.
Goals
- Move script from bash to python: this would be useful in case we want to include this into MTUI in the future. The script will be separate from MTUI for now. The idea is to have this as a CLI tool using the click library or something similar.
- Add option to look for jobs in other sections inside aggregated updates: right now, when looking for regression tests under aggregated updates for a given MU, the script only looks inside the Core MU job group. This is where most of the regression tests we need are located, but some MUs have their regression tests under the YaST/Containers/Security MU job groups. We should keep the Core MU group as a default, but add an option to be able to look into other job groups under aggregated updates.
- Remove the
-a
option: this option is used to indicate the update ID and is mandatory right now. This is a bit weird and goes against posix stardards. It was developed this way in order to avoid using positional parameters. This problem should be fixed if we move the script to python.
Some other ideas to consider:
- Look into the QAM dashboard API. This has more info on each MU, could use this to link general openQA build results, whether the related RR is approved or not, etc
- Make it easier to see if there's regression tests for a package in an openQA test build. Check if there's a possibility to search for tests that have the package name in them inside each testsuite.
- Unit testing?
More ideas TBD
Resources
https://github.com/os-autoinst/scripts/blob/master/openqa-search-maintenance-core-jobs
https://confluence.suse.com/display/maintenanceqa/Guide+on+how+to+test+Updates
Post-Hackweek update
All major features were implemented. Unit tests are still in progress, and project will be moved to the SUSE github org once everything's done. https://github.com/mjdonis/oqa-search
Learn obs/ibs sync tool by xlai
Description
Once images/repo are built from IBS/OBS, there is a tool to sync the image from IBS/OBS to openqa asset directory and trigger openqa jobs accordingly.
Goals
Check how the tool is implemented, and be capable to add/modify our needed images/repo in future by ourselves.
Resources
- https://github.com/os-autoinst/openqa-trigger-from-obs
- https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin/-/tree/master?ref_type=heads
Setup a new openQA on more powerful server by JNa
Description
- currently local openQA storage is insufficient
Goals
-Migrate to more powerful machine
Resources
-Service Rainbow
OpenQA Golang api client by hilchev
Description
I would like to make a simple cli tool to communicate with the OpenQA API
Goals
- OpenQA has a ton of information that is hard to get via the UI. A tool like this would make my life easier :)
- Would potentially make it easier in the future to make UI changes without Perl.
- Improve my Golang skills
Resources
- https://go.dev/doc/
- https://openqa.opensuse.org/api
New features in openqa-trigger-from-obs for openQA by jlausuch
Description
Implement new features in openqa-trigger-from-obs to make xml more flexible.
Goals
One of the features to be implemented: - Possibility to define "VERSION" and "ARCH" variables per flavor instead of global.
Resources
https://github.com/os-autoinst/openqa-trigger-from-obs