profiles: improve SUPPORTED_DEVICES handling and profile identification by map-b · Pull Request #1533 · openwrt/asu

map-b · 2025-12-04T18:50:45Z

The actual handling does not allow to several devices share a DTS compatible string to allow image compatibility between them.

Take the lists as lists and select the profile after checking all possible candidates.
Throw a new validation exception when it is not possible to identify a profile which will help to identify inconsistencies.

This also can help to make a little bit clearer the difference between "profile" and "DTS compatible string".

*There is not need to add [profile] to SUPPORTED_DEVICES list anymore.

asu/asu/util.py

Line 566 in 0328704

for name in data.get("supported_devices", []) + [profile]

Reasoning about the reverts: #1511 (comment) I would like to add that those commits would make harder to understand how we are handling the translation from Device Tree compatible strings to actual profiles names.

Before: ¹

'glinet,gl-mt2500': 'glinet_gl-mt2500-airoha',                    <-- Entries are overwritten translating, wrongly to airoha variant
'glinet,mt2500-emmc': 'glinet_gl-mt2500-airoha',
'glinet,gl-mt2500-airoha': 'glinet_gl-mt2500-airoha',
'glinet_gl-mt2500': 'glinet_gl-mt2500',
'glinet_gl-mt2500-airoha': 'glinet_gl-mt2500-airoha'

After:

'glinet_gl-mt2500': ['glinet,gl-mt2500', 'glinet,mt2500-emmc', 'glinet,gl-mt2500-airoha', 'glinet_gl-mt2500'],
'glinet_gl-mt2500-airoha': ['glinet,gl-mt2500-airoha', 'glinet,mt2500-emmc', 'glinet,gl-mt2500', 'glinet_gl-mt2500-airoha'],

With this structure, select the profile where the board_name appear first in the list if the entry is shared.

Fixes: #1525
Fixes: openwrt/openwrt#20566

https://github.com/openwrt/asu/issues/1525#issuecomment-3497242570 ↩

This reverts commit 1579236.

efahl · 2025-12-05T19:09:16Z

Hard NAK.

Is this AI slop code? You've broken event logging, broken a bug fix and removed an important test case.

As I've already explained to you several times, the root cause of this issue is incorrect metadata coming from upstream. Attempting to work around the upstream issue in the ASU server does not fix anything and leaves several other things broken (specifically both sysupgrade and the Firmware Selector).

map-b · 2025-12-05T19:40:58Z

In those two reverts, included in this PR, you were mixing totally the translation or the DT compatible strings into actually profiles, that is not sanitize that is lose track of what are the strings sended by ASU clients(if they do not try to translate before sending them) and the actual profiles which are used in ImageBuilders. It is not AI sope code, a bit unrespectfully comment was that.

If you do not want to reason, it is over, It is really sad.

map-b · 2025-12-05T19:48:52Z

-    # Sanitize the profile in case the client did not (bug in older LuCI app).
-    build_request.profile = build_request.profile.replace(",", "_")
-
-    add_build_event("requests")


This revert d7fd828 made this, I am not sure why. You are right on that.

You've broken event logging

This reverts commit 2e9edfd.

The actual handling does not allow to several devices share a DTS compatible string to allow image compatibility between them. Take the lists as lists and select the profile after checking all possible candidates. Throw a new validation exception when it is not possible to identify a profile which will help to identify inconsistencies. This also can help to make a little bit clearer the difference between "profile" and "DTS compatible string". * There is not need to add [profile] to SUPPORTED_DEVICES list anymore. Before: [1] 'glinet,gl-mt2500': 'glinet_gl-mt2500-airoha', 'glinet,mt2500-emmc': 'glinet_gl-mt2500-airoha', 'glinet,gl-mt2500-airoha': 'glinet_gl-mt2500-airoha', 'glinet_gl-mt2500': 'glinet_gl-mt2500', 'glinet_gl-mt2500-airoha': 'glinet_gl-mt2500-airoha' After: 'glinet_gl-mt2500': ['glinet,gl-mt2500', 'glinet,mt2500-emmc', 'glinet,gl-mt2500-airoha', 'glinet_gl-mt2500'], 'glinet_gl-mt2500-airoha': ['glinet,gl-mt2500-airoha', 'glinet,mt2500-emmc', 'glinet,gl-mt2500', 'glinet_gl-mt2500-airoha'], [1]: openwrt#1525 (comment) Fixes: openwrt#1525 Fixes: openwrt/openwrt#20566

They share the same "compatible" in device tree causing some incompatibilities (ASU profile identification), assign a unique "compatible" and "model" to each variant.[1][2] Commit [3] just avoided ASU profile identification limitation[4] but not fixed the root cause. [1]: openwrt#20632 (comment) [2]: openwrt#20632 (comment) [3]: openwrt@b71f466 [4]: openwrt/asu#1533 Fixes: b71f466 ("mediatek: filogic: fix supported_devices list for gl-mt2500") Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision") Fixes: openwrt#20566 Fixes(partially): openwrt/asu#1525 Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com>

These devices share the same "compatible" in device tree causing some incompatibilities (sysupgrades, ASU profile identification), assign a unique "compatible" and "model" to each variant. Context: Commit [1] added each variant's dts compatible to the SUPPORTED_DEVICES field of the other variant to make easy sysupgrades between these physically indistinguishable devices variants possible. But there were found three issues which does not allow this: - the sysupgrade's stricter check still used in some sysupgrade paths(this check is being replaced(and redundant) with the newer fwtool's SUPPORTED_DEVICES check using the info in images METADATA), this check will fail when sysupgrading from a different board_name(compatible dts) that the image was created for (image profile name).[2] - ASU needs unique "dts compatible" to identify the devices profile. - and an ASU's profile identification limitation when several devices from a common target share SUPPORTED_DEVICES entries.[3] There is a proposal for these issues but not yet implemented [4][3]. Until these issues are fixed we won't allow "easy" sysupgrades between these two device variants. Commit [5] avoided the ASU profile identification limitation but missed the required two unique dts compatibles in order to make the two variants fully work, although not allowing easy sysupgrade between them. [1]: openwrt@8d30e07 [2]: sysupgrade stricter check openwrt#20566 (comment) [3]: ASU proposal openwrt/asu#1533 [4]: allow easy sysupgrade proposal openwrt#20947 [5]: openwrt@b71f466 Fixes: b71f466 ("mediatek: filogic: fix supported_devices list for gl-mt2500") Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision") Fixes: openwrt#20566 Fixes: openwrt/asu#1525 Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com>

These devices share the same "compatible" in device tree causing some incompatibilities (sysupgrades, ASU profile identification), assign a unique "compatible" and "model" to each variant. Context: Commit [1] added each variant's dts compatible to the SUPPORTED_DEVICES field of the other variant to make easy sysupgrades between these physically indistinguishable devices variants possible. But there were found three issues which does not allow this: - the sysupgrade's stricter check still used in some sysupgrade paths(this check is being replaced(and redundant) with the newer fwtool's SUPPORTED_DEVICES check using the info in images METADATA), this check will fail when sysupgrading from a different board_name(compatible dts) that the image was created for (image profile name).[2] - ASU needs unique "dts compatible" to identify the devices profile. - and an ASU's profile identification limitation when several devices from a common target share SUPPORTED_DEVICES entries.[3] There is a proposal for these issues but not yet implemented [4][3]. Until these issues are fixed we won't allow "easy" sysupgrades between these two device variants. Commit [5] avoided the ASU profile identification limitation but missed the required two unique dts compatibles in order to make the two variants fully work, although not allowing easy sysupgrade between them. [1]: openwrt@8d30e07 [2]: sysupgrade stricter check openwrt#20566 (comment) [3]: ASU proposal openwrt/asu#1533 [4]: allow easy sysupgrade proposal openwrt#20947 [5]: openwrt@b71f466 Fixes: b71f466 ("mediatek: filogic: fix supported_devices list for gl-mt2500") Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision") Fixes: openwrt#20566 Fixes: openwrt/asu#1525 Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com> Link: openwrt#21842 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

These devices share the same "compatible" in device tree causing some incompatibilities (sysupgrades, ASU profile identification), assign a unique "compatible" and "model" to each variant. Context: Commit [1] added each variant's dts compatible to the SUPPORTED_DEVICES field of the other variant to make easy sysupgrades between these physically indistinguishable devices variants possible. But there were found three issues which does not allow this: - the sysupgrade's stricter check still used in some sysupgrade paths(this check is being replaced(and redundant) with the newer fwtool's SUPPORTED_DEVICES check using the info in images METADATA), this check will fail when sysupgrading from a different board_name(compatible dts) that the image was created for (image profile name).[2] - ASU needs unique "dts compatible" to identify the devices profile. - and an ASU's profile identification limitation when several devices from a common target share SUPPORTED_DEVICES entries.[3] There is a proposal for these issues but not yet implemented [4][3]. Until these issues are fixed we won't allow "easy" sysupgrades between these two device variants. Commit [5] avoided the ASU profile identification limitation but missed the required two unique dts compatibles in order to make the two variants fully work, although not allowing easy sysupgrade between them. [1]: 8d30e07 [2]: sysupgrade stricter check #20566 (comment) [3]: ASU proposal openwrt/asu#1533 [4]: allow easy sysupgrade proposal #20947 [5]: b71f466 Fixes: b71f466 ("mediatek: filogic: fix supported_devices list for gl-mt2500") Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision") Fixes: #20566 Fixes: openwrt/asu#1525 Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com> Link: #21842 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 7aa1f7e)

map-b · 2026-03-08T22:44:47Z

+                if profile in supported_devices:
+                    return True
+
        if len(profiles) == 1 and "generic" in profiles:


if (len(profiles) == 1 or "geos" in profiles) and "generic" in profiles:

To remark that "geos" case is an exception in the "generic" targets/platforms? Adding a comment too?

@efahl I can add a separate commit for that issue since this PR is "touching" this code

These devices share the same "compatible" in device tree causing some incompatibilities (sysupgrades, ASU profile identification), assign a unique "compatible" and "model" to each variant. Context: Commit [1] added each variant's dts compatible to the SUPPORTED_DEVICES field of the other variant to make easy sysupgrades between these physically indistinguishable devices variants possible. But there were found three issues which does not allow this: - the sysupgrade's stricter check still used in some sysupgrade paths(this check is being replaced(and redundant) with the newer fwtool's SUPPORTED_DEVICES check using the info in images METADATA), this check will fail when sysupgrading from a different board_name(compatible dts) that the image was created for (image profile name).[2] - ASU needs unique "dts compatible" to identify the devices profile. - and an ASU's profile identification limitation when several devices from a common target share SUPPORTED_DEVICES entries.[3] There is a proposal for these issues but not yet implemented [4][3]. Until these issues are fixed we won't allow "easy" sysupgrades between these two device variants. Commit [5] avoided the ASU profile identification limitation but missed the required two unique dts compatibles in order to make the two variants fully work, although not allowing easy sysupgrade between them. [1]: openwrt@8d30e07 [2]: sysupgrade stricter check openwrt#20566 (comment) [3]: ASU proposal openwrt/asu#1533 [4]: allow easy sysupgrade proposal openwrt#20947 [5]: openwrt@2c19228 Fixes: 2c19228 ("mediatek: filogic: fix supported_devices list for gl-mt2500") Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision") Fixes: openwrt#20566 Fixes: openwrt/asu#1525 Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com> Link: openwrt#21842 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

map-b · 2026-04-10T17:55:17Z

I have been checking for any possible side effect and I do not find any, it is the normal and well stablished use of SUPPORTED_DEVICES mechanism to allow "force-less" sysupgrades and everything works as intended except the ASU profile identification.

List of issues that are pending of this little fix, basically any "advanced" use of SUPPORTED_DEVICES:

NOR/NAND devices with images using either storage support.
Realtek target images with two RAM sizes configurations.
Qualcommbe device with two images for support two SFP combo modes (Eth or SFP)
ADSL Annex A or Annex B images
Mikrotic board with two images, with and without POE support.
Boards with different PHY but with the same hardware revision like, this PR's original example, gl-mt2500/airoha.
etc.

*"owut" which is the only ASU client doing a parallel translation in order to known the specific profile needed for its nice default packages analysis, for example. It must do the same translation as the ASU server. I am willing to propose the needed same little change there to mimic the ASU translation if efahl wish (TODO: this should be an api call to ASU server for doing the translation, centralizing and avoiding inconsistencies?)

@aparcar @Ansuel, I tried too much with efahl and that path only got worse and worse, sorry for appealling and pinging to you directly but this seems to be an important missing bit to fully integrate the fwtool's SUPPORTED_DEVICES with the ASU subsystem, and avoid the actual proposed workarounds(remove shared entries) which is limititing the SUPPORTED_DEVICES mechanism too much.

TLDR: The proposal is just: look at all the SUPPORTED_DEVICES lists in the target/platform (profiles.json) and select the profile which has the board_name(dts compatible) as first entry in the SUPPORTED_DEVICES list if the entry is shared by several profiles.

map-b · 2026-04-15T14:07:00Z

Hard NAK.

Is this AI slop code? You've broken event logging, broken a bug fix and removed an important test case.

As I've already explained to you several times, the root cause of this issue is incorrect metadata coming from upstream. Attempting to work around the upstream issue in the ASU server does not fix anything and leaves several other things broken (specifically both sysupgrade and the Firmware Selector).

So, what should I understand from the 5 months of completely silent, no single comment? That you completely agree with efahl's unrespectfully feedback without giving a truly reasonable reason? And you just wait hopefully for me disappearing or...idk. What would you think in my shoes?

Can you point me to my own errors so I can learn from them, at least? If you both do not beat me definitively and I try to contribute in the future? The best would be you help efahl and me to find a common page... All my comments are public on GitHub and a few in the forum if you want to check. @aparcar

aparcar · 2026-04-16T03:12:18Z

Hey @map-b thanks for your patience. There are so many things to take care of, sometimes it takes a while.

I used an AI to tackle this upstream, from my understanding this should improve the situation? I think the "supported devices" string is misleading when it secretly switches your underlying storage and thereby resets your device. This should generally be avoided... @dangowrt not sure how much time you have, but maybe you can also comment on this. We could also attach a single profile into each firmware image, by making devices "self aware", we'd avoid this entire shenanigans...

openwrt/openwrt#22952

map-b · 2026-04-16T09:54:25Z

This exactly what I am trying to avoid... 🙃.

Upstream handles this correctly (manual sysupgrading) and its one of the usefulness of the fwtool's supported_devices mechanism. It's ASU who is silently swapping the images.

Can't we generalize and consolidate the mapping/translation process in the ASU side?

There are profile and board_name which identify uniquely to images and devices respectively. The SUPPORTED_DEVICES entries represent these mappings. And the order in these lists allows identify the primary/default mapping (the first entry should have priority). *This would be the requirement in upstream side, keep the desired default as first entry in supported_devices which is the actual default behavior and it is correct in all the studied cases.

Limiting the ability to allow these cross-sysupgrades from "downstream"(ASU) does not seem correct to me. And we will be losing valuable information.

But I'm repeating myself now. *@hauke also thought in the "selecting the first entry" idea.

Ansuel · 2026-04-16T10:48:37Z

My 2 cent on the topic... but can't we fix this upstream? Upgrade tool shouldn't implement workaround if the project is active and things can be fixed upstream...

map-b · 2026-04-16T11:43:27Z

I'm not sure if It's a workaround, the actual profile selection in the upgrade tool is a bit, too much simple. The upstream fix is to remove the ability...?

Upstream provides enough (and coherent) information?
Based on that information, is the upgrade tool (ASU) doing well enough to select the profile, correctly?

Revert "build-request: sanitize incoming "supported devices" list"

423489e

This reverts commit 1579236.

This was referenced Dec 4, 2025

Attended Sysupgrade OpenWrt 24.10.3 to 24.10.4 on GL-MT2500 #1525

Closed

Attended Sysupgrade and owut upgrade broken: invalid sysupgrade file openwrt/openwrt#20566

Closed

mediatek: filogic: gl-mt2500 fix compatibles openwrt/openwrt#20947

Open

map-b commented Dec 5, 2025

View reviewed changes

map-b added 2 commits December 5, 2025 21:08

Revert "build-request: sanitize profile before use"

d7fd828

This reverts commit 2e9edfd.

map-b force-pushed the improve-supported-devices-handling branch from 96024c1 to e8bf73f Compare December 5, 2025 20:11

map-b mentioned this pull request Dec 26, 2025

asu: revert sanitize #1554

Closed

map-b mentioned this pull request Jan 19, 2026

realtek: add Zyxel GS1900-24 B1 openwrt/openwrt#21595

Merged

map-b mentioned this pull request Feb 2, 2026

mediatek: filogic: fix supported_devices list for gl-mt2500 openwrt/openwrt#20632

Merged

map-b commented Mar 8, 2026

View reviewed changes

map-b mentioned this pull request Mar 27, 2026

GL.iNet GL-AR750S (NOR): Upgrade from 25.12.1 to 25.12.2 doesn't work openwrt/openwrt#22638

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

profiles: improve SUPPORTED_DEVICES handling and profile identification#1533

profiles: improve SUPPORTED_DEVICES handling and profile identification#1533
map-b wants to merge 3 commits intoopenwrt:mainfrom
map-b:improve-supported-devices-handling

map-b commented Dec 4, 2025 •

edited

Loading

Uh oh!

efahl commented Dec 5, 2025

Uh oh!

map-b commented Dec 5, 2025

Uh oh!

map-b Dec 5, 2025 •

edited

Loading

Uh oh!

map-b Dec 5, 2025

Uh oh!

map-b Mar 8, 2026

Uh oh!

map-b commented Apr 10, 2026

Uh oh!

map-b commented Apr 15, 2026

Uh oh!

aparcar commented Apr 16, 2026

Uh oh!

map-b commented Apr 16, 2026

Uh oh!

Ansuel commented Apr 16, 2026

Uh oh!

map-b commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

map-b commented Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

efahl commented Dec 5, 2025

Uh oh!

map-b commented Dec 5, 2025

Uh oh!

map-b Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

map-b Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

map-b Mar 8, 2026

Choose a reason for hiding this comment

Uh oh!

map-b commented Apr 10, 2026

Uh oh!

map-b commented Apr 15, 2026

Uh oh!

aparcar commented Apr 16, 2026

Uh oh!

map-b commented Apr 16, 2026

Uh oh!

Ansuel commented Apr 16, 2026

Uh oh!

map-b commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

map-b commented Dec 4, 2025 •

edited

Loading

map-b Dec 5, 2025 •

edited

Loading