From bf12e6e827e4e55df48704a486779e4af17504d2 Mon Sep 17 00:00:00 2001 From: Peter Chubb Date: Wed, 19 Mar 2025 12:04:06 +1100 Subject: [PATCH 1/4] Add RFC for depcrecating and removing old boards Signed-off-by: Peter Chubb --- src/proposed/0190-deprecation | 134 ++++++++++++++++++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 src/proposed/0190-deprecation diff --git a/src/proposed/0190-deprecation b/src/proposed/0190-deprecation new file mode 100644 index 0000000..c97a8c1 --- /dev/null +++ b/src/proposed/0190-deprecation @@ -0,0 +1,134 @@ + + +# seL4 RFC Template + + + +- Author: Peter Chubb +- Proposed: [2025-03-18] + +## Summary + +Deprecate boards using old no-longer-available-for-purchase system-on-chips + +## Motivation + +A number of the boards that are currently supported are no longer +available for purchase, and the System-On-Chip they use has been +marked 'End-Of-Life' by the manufacturer. These are not going to be +used for new designs. + +Our continuous integration process takes a long time to run; the more +systems that are supported and tested, the longer it takes. It is +better to test only the systems that are actually likely to be used, +rather than obsolete systems that noone uses. + +In addition, some of the boards we have for the continuous integration +testing have died, and cannot be replaced. Some have not been tested +for several years now. + +By removing some old boards from the list of supported boards: + - the time to perform CI will reduce + - we can over time remove board-specific code from the kernel + - we can create room in the CI system for newer boards. + + +## Guide-level explanation + +I propose removing the following boards from the list of fully +supported boards, and marking them as 'deprecated' on the docs website: +| Board | SoC | Notes | +|----------------|-------------|-------| +| Arndale | Exynos 5250 | Introduced 2012, last available in 2018 | +| Odroid X | Exynos 4412 | introduced 2012, last available 2018| +| Beagleboard Xm | DM3730 | introduced 2014, still available as new-old-stock, but no longer manufactured.| +| Hikey960 | Kirin 620 | Introduced 2017, last available 2020| +| Inforce IFC6410| Snapdragon | Introduced 2013; no userspace support at present| + +This would mean in the short term, changing their status to +'unsupported' on the docs wenbsite, and removing them from the CI +system. For some of them they haven't been tested in quite a while +_anyway_, because of the lack of available working hardware. + +In longer term, another RFC in six month's time can propose removing +the code that supports them from the seL4 kernel source. + +In addition I propose a regular trigger for considering board +deprecation. I suggest that once a year, all boards using SoCs no +longer available for purchase be considered for deprecation. Polling +via the `devel` mailing list, followed by a public RFC, will ensure +that anyone continuing to support and provide seL4-based firmware +updates for such a SoC can object and keep the SoC supported until +they too have marked their product end-of-life. + +Any board marked 'deprecated' should have added a time for the +deprecation period to end, and the code that supports it removed from +the kernel. + + +## Drawbacks + +If anyone is still using any of these boards, or supporting a product +that uses the SoC with firmware updates based on seL4, then removing +the board is obviously a bad idea. However the RFC process should +ensure that such uses can be identified and the board's life extended +if necessary. + +Removing code from the kernel (even though board-support code is +generally unverified) is work that would not need to be done without +this proposal. + +## Rationale and alternatives + +Sooner or later, all things come to an end. Maintaining systems that +noone wants to use is wasted effort. + +## Prior art + +RedHAT divides hardware into 'Enabled and fully maintained', +'Deprecated', 'Unmaintained', 'Disabled', and 'Removed' (see +https://access.redhat.com/solutions/6663421 ) + +Using a deprecated driver results in a message on the console; +'disabled' drivers don't work; 'removed' are not compiled into the +kernel. +Typically a driver remains in 'Deprecated' state for one release +before becoming 'unmaintained' and then 'Disabled' or 'Removed' + + +## Unresolved questions + +Is anyone maintaining seL4-based firmware in a production environment +that uses any of these SoCs? From b18423dac9a7cb2aa17304d51075da838740500f Mon Sep 17 00:00:00 2001 From: Gerwin Klein Date: Fri, 25 Jul 2025 17:10:05 +1000 Subject: [PATCH 2/4] 0190-deprecation: rename to .md Rename to .md so GitHub renders the text. Signed-off-by: Gerwin Klein --- src/proposed/{0190-deprecation => 0190-deprecation.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/proposed/{0190-deprecation => 0190-deprecation.md} (100%) diff --git a/src/proposed/0190-deprecation b/src/proposed/0190-deprecation.md similarity index 100% rename from src/proposed/0190-deprecation rename to src/proposed/0190-deprecation.md From c4e141a95173a221ece65344bddad5f788b68352 Mon Sep 17 00:00:00 2001 From: Gerwin Klein Date: Mon, 15 Dec 2025 15:21:01 +1100 Subject: [PATCH 3/4] 0190: move RFC to active Signed-off-by: Gerwin Klein --- src/{proposed => active}/0190-deprecation.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/{proposed => active}/0190-deprecation.md (100%) diff --git a/src/proposed/0190-deprecation.md b/src/active/0190-deprecation.md similarity index 100% rename from src/proposed/0190-deprecation.md rename to src/active/0190-deprecation.md From dd18bb929a943432517e6f83d147adbc76f0b842 Mon Sep 17 00:00:00 2001 From: Gerwin Klein Date: Mon, 15 Dec 2025 15:30:32 +1100 Subject: [PATCH 4/4] RFC-19: add disposition, update text Signed-off-by: Gerwin Klein --- src/active/0190-deprecation.md | 57 ++++++++++++---------------------- 1 file changed, 20 insertions(+), 37 deletions(-) diff --git a/src/active/0190-deprecation.md b/src/active/0190-deprecation.md index c97a8c1..7c53c03 100644 --- a/src/active/0190-deprecation.md +++ b/src/active/0190-deprecation.md @@ -1,41 +1,10 @@ # seL4 RFC Template - - - Author: Peter Chubb - Proposed: [2025-03-18] @@ -60,20 +29,21 @@ testing have died, and cannot be replaced. Some have not been tested for several years now. By removing some old boards from the list of supported boards: - - the time to perform CI will reduce - - we can over time remove board-specific code from the kernel - - we can create room in the CI system for newer boards. + +- the time to perform CI will reduce +- we can over time remove board-specific code from the kernel +- we can create room in the CI system for newer boards. ## Guide-level explanation I propose removing the following boards from the list of fully supported boards, and marking them as 'deprecated' on the docs website: + | Board | SoC | Notes | |----------------|-------------|-------| | Arndale | Exynos 5250 | Introduced 2012, last available in 2018 | | Odroid X | Exynos 4412 | introduced 2012, last available 2018| -| Beagleboard Xm | DM3730 | introduced 2014, still available as new-old-stock, but no longer manufactured.| | Hikey960 | Kirin 620 | Introduced 2017, last available 2020| | Inforce IFC6410| Snapdragon | Introduced 2013; no userspace support at present| @@ -130,5 +100,18 @@ before becoming 'unmaintained' and then 'Disabled' or 'Removed' ## Unresolved questions -Is anyone maintaining seL4-based firmware in a production environment -that uses any of these SoCs? +- Is anyone maintaining seL4-based firmware in a production environment + that uses any of these SoCs? + + - No reply has been received during the comment period and after posting to + the developer mailing list, so the assumption is that they are not in active + use. + +## Disposition + +The TSC has voted to approve this RFC, keeping support for the BeagleBoard which +was originally mentioned in the table. Since no concerns have been raised during +the comment period, support for the boards will be removed. + +As proposed, we are aiming to check annually for boards that should be dropped, +and are keeping the RFC process and comment period in place as before.