Hardware page refactor

[minash-ti]

Background

KernelCI dashboard has two main listing pages:

• /tree -- kernel trees/branches being tested
• /hardware -- hardware boards being tested

This document covers the redesign of the /hardware listing page only. The detail page (/hardware/$hardwareId) is out of scope and will be a separate effort.

---

Current State

Listing Page (/hardware)

• Paginated table with columns: Platform, Compatibles, Build status, Boot status, Test status
• Origin dropdown in TopBar filters all data to a single lab/data-source
• Time range = rolling window relative to now (?intervalInDays=N)
• Sorted alphabetically by platform ID
• Platform IDs are raw identifiers (e.g. am62-sk, arm-juno-r2)

Key files in the dashboard repo

• dashboard/src/pages/Hardware/HardwareListingPage.tsx -- main listing component
• dashboard/src/pages/Hardware/HardwareTable.tsx -- table with columns and pagination
• dashboard/src/components/TopBar/TopBar.tsx -- contains OriginSelect component
• dashboard/src/api/origin.ts -- fetches available origins
• dashboard/src/pages/hardwareDetails/HardwareDetails.tsx -- detail page (out of scope)

---

Problems to Solve

1. Cross-origin view

Current behavior: The Origin dropdown scopes ALL data to a single lab. If you select "maestro", you only see hardware tested by maestro.

Problem: Hardware coverage should be reported across all labs. A board is either tested in KernelCI or it isn't -- the lab that tests it is secondary.

Proposal:

• Default view shows hardware aggregated across all origins
• Origin is demoted from a global TopBar control to an optional filter (alongside vendor, architecture, board type, etc.)
• Lab owners can filter to their own origin when needed, but it is not the top-level scope for the page

---

2. Historical navigation

Current behaviour: Time range is always relative to now (last N days). No way to pin to a past kernel release.

Important clarification: The intervalInDays filter only widens/narrows the collection window for test results submitted against the latest commits - it does NOT navigate to older commits. Since test results are submitted shortly after a kernel build, this filter adds no meaningful value. (extending number of days may find more builds in other trees that have not been tested recently)

Proposal:

• Remove the intervalInDays / calendar days filter entirely
• Add tree/kernel version tag selector (e.g. v6.12, v6.13-rc1) as the navigation control for the listing page
• Commit-level navigation stays on the detail page only
• No calendar date navigation

---

3. Hardware registry integration

Registry location: https://github.com/kernelci/kernelci-pipeline/tree/main/config/hardware_registry

Schema summary (schema.yaml):

silicon_vendors:  chip manufacturers (id, url, details)
platform_vendors: board manufacturers (id, url, details)
processors:       SoCs (vendor_id, architecture, cores, max_clock_speed_mhz, url, details)
system_modules:   optional SoM/SiP layer (vendor_id, processor_id, form_factor)
platforms:        boards (type, vendor_id, processor_id, system_module_id, url, details)

Platform types: evaluation_board, single_board_computer, development_board, reference_board, product_board, industrial_gateway, laptop, desktop

Key insight: Platform IDs in the registry (e.g. am62-sk) match the platform field in KernelCI API data -- the join is direct.

Currently covered: TI boards only (ti.yaml). More vendors expected over time.

Proposal: Boards with registry entries get enriched display. Boards without entries still appear with raw platform ID and test data. This creates an incentive for vendors to contribute registry entries.

Fields to surface on the listing page:

Registry field	Display purpose
platform_vendors[vendor_id].id / details	Vendor name, grouping
processors[processor_id].architecture	Architecture badge (arm64, arm, x86...)
processors[processor_id].id + url	SoC name with link to datasheet
platforms[id].type	Board type badge (eval board, SBC...)
platforms[id].details	Human-readable description
platforms[id].url	Link to vendor product page

---

Audience

Mixed -- the page must serve all of these:

1. Kernel developers -- checking if patches broke something on specific hardware
2. Hardware vendors (e.g. TI) -- monitoring their boards' test health over time
3. Lab operators -- checking coverage and test infrastructure
4. External companies -- evaluating hardware for Linux-based product designs; they need a catalog-like experience with human-readable info, not just test counts

---