profiles: improve SUPPORTED_DEVICES handling and profile identification

[map-b]

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

---

V2:

• Extracted profile resolution into a standalone resolve_profile() function that handles DTS compatible → canonical profile name resolution with explicit ambiguity detection, replacing the inline valid_profile() helper.
• Fixed a cache consistency issue: the request hash was computed from the raw board_name before profile resolution. The comma-to-underscore sanitization in get_request_hash() handled the case where board_name equals profile_name after sanitization, but not aliases resolved via the supported_devices list or the x86/armsr/... generic fallback — those produced different cache keys than the canonical profile, defeating caching.

Resolution behavior comparison (profile → list format vs flat dict):

Profiles data (profile: SUPPORTED_DEVICES list):
  engenius_esr1200:         ["engenius,esr1200", "esr1200", "esr1750", "engenius,esr1750"]
  engenius_esr1750:         ["engenius,esr1750", "esr1750", "esr1200", "engenius,esr1200"]
  ubnt_unifi-ap:            ["ubnt,unifi-ap", "unifi", "ubnt,unifi"]
  ubnt_unifi-ap-lr:         ["ubnt,unifi-ap-lr", "unifi", "ubnt,unifi", "ubnt,unifi-ap"]

Input	Flat raw	Flat sanitized	List format
engenius_esr1200	engenius_esr1200 ✅	engenius_esr1750 ❌	engenius_esr1200 ✅
engenius,esr1200	engenius_esr1750 ❌	engenius_esr1750 ❌	engenius_esr1200 ✅
esr1200	engenius_esr1750 ❌	engenius_esr1750 ❌	error ✅
esr1750	engenius_esr1750 ❌	engenius_esr1750 ❌	error ✅
engenius,esr1750	engenius_esr1750 ✅	engenius_esr1750 ✅	engenius_esr1750 ✅
engenius_esr1750	engenius_esr1750 ✅	engenius_esr1750 ✅	engenius_esr1750 ✅

Input	Flat raw	Flat sanitized	List format
ubnt_unifi-ap	ubnt_unifi-ap ✅	ubnt_unifi-ap-lr ❌	ubnt_unifi-ap ✅
ubnt,unifi-ap	ubnt_unifi-ap-lr ❌	ubnt_unifi-ap-lr ❌	ubnt_unifi-ap ✅
unifi	ubnt_unifi-ap-lr ❌	ubnt_unifi-ap-lr ❌	error ✅
ubnt,unifi	ubnt_unifi-ap-lr ❌	ubnt_unifi-ap-lr ❌	error ✅
ubnt_unifi-ap-lr	ubnt_unifi-ap-lr ✅	ubnt_unifi-ap-lr ✅	ubnt_unifi-ap-lr ✅
ubnt,unifi-ap-lr	ubnt_unifi-ap-lr ✅	ubnt_unifi-ap-lr ✅	ubnt_unifi-ap-lr ✅

Footnotes

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

[efahl]

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]

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]

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

[map-b]

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]

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]

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]

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]

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]

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?

[map-b]

Do we have a clear view of the problem or not? IMO there are two cases:

1. ASU client sends the profile -> OK*. (firmware-selector and owut which needs to know the profile, to do its default_packages analysis, does the translation based on SUPPORTED_DEVICES which also has the same problem since it actually is mimicking ASU translation/mapping)
   *After "sanitization" commits asu: revert sanitize  #1554 even these "profile" cases started to fail too for the cases with shared entries in SUPPORTED_DEVICES.
2. ASU client sends the board_name -> Not OK for the shared entries cases. (Luci ASU app)

*In both cases, ASU server is doing (during "validation request" step) a subtle translation/mapping, based on SUPPORTED_DEVICES entries from profiles.json's data, to get a proper profile name.

Bugs (in ASU side, I think):

1. In case 1. there is not need to do the mapping/translation.
2. We are mixing things with a "direct" translation doing the ',' -> '_' replacements.
3. We are not accounting for the possible shared entries, not redundant since the ones which are the first in the list can be considered "special".

*The actual state, mixing profile and board_name plus replacing ',' by '_' is confusing.

---

If the concern is to keep ASU server simple, then simplify it and only accept profile names, not board_name.

Since the mapping/translation is only required for the on-device ASU clients, leave to them the responsibility:

• ASU server only accepts image profile names, not board_name names.
• ASU clients on-device (Luci ASU, owut) has to do the mapping/translation before sending the request to ASU server.
• *Offer an independant API call on ASU server to do the translation/mapping board_name -> image profile to avoid to replicate code in ASU clients.

Regards.

[mcprat]

I fully agree with you that the fix should take place in ASU, but I think its much more simple than it seems:

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

This is completely irrelevant, two separate images should NEVER share a DTS compatible for the device. We define SUPPORTED_DEVICES to simply say that 2 images can work on 1 device, NOT that 2 identical images can work on 1 device. We don't generate identical images with different names...

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

This is the key, the profile is already in SUPPORTED_DEVICES, so either we use the profile entry or we don't care which image is used... we don't need to apply both fixes at the same time, just choose a path.

However, there is no need to "allow" a compatible image that doesn't match the profile when in reality both images are available, in other words, ASU should not decide that it is ok to change profiles during sysupgrade, that should be only up to the user in a manual sysupgrade.

so the path should be to use the profile entry only...

my example:

the two engenius devices

define Device/engenius_esr1200
  SOC := qca9557
  DEVICE_VENDOR := EnGenius
  DEVICE_MODEL := ESR1200
.......
  SUPPORTED_DEVICES += esr1200 esr1750 engenius,esr1750
endef
TARGET_DEVICES += engenius_esr1200

define Device/engenius_esr1750
  SOC := qca9558
  DEVICE_VENDOR := EnGenius
  DEVICE_MODEL := ESR1750
.......
  SUPPORTED_DEVICES += esr1750 esr1200 engenius,esr1200
endef
TARGET_DEVICES += engenius_esr1750

After these definitions are called the SUPPORTED_DEVICES lines are

engenius,esr1200 esr1200 esr1750 engenius,esr1750
and
engenius,esr1750 esr1750 esr1200 engenius,esr1200
respectively

because in image.mk we have

define Device/Init
...
  SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
...
endef

like hauke said, just select the first one (I can't find the comment where he said that idea, just that you mentioned he did)

[map-b]

To keep the discussion simple, what this PR does is:
Given a device identifier, the board_name (usually the DTS compatible)

• if there is only one profile which has the board_name in SUPPORTED_DEVICES select the profile as before,
• when there are shared entries in SUPPORTED_DEVICES in several profiles, select the profile where the board_name is the first, if not throw an error.

*If the ASU client sends a true valid profile, select the profile, don't do any mapping/translation with SUPPORTED_DEVICES.

We have: Image profiles (vendor_device) and devices aka board_name aka DTS compatible (vendor,device), the way to map them, from ASU perspective, is the SUPPORTED_DEVICES entries.

The shortcuts replacing the '_' with ',' to do this mapping don't help to see the full picture. Not always the board_name is equal to the profile replacing the comma by an underscore.

Thanks @mcprat for dig in, I would make some corrections in your analysis explicitly but with this answer I hope you notice the oversights.

[mcprat]

my point is that it sounds like this change makes a 2 step process when really just 1 step is necessary.

We do not have to "map" profiles in order to treat groups of profiles one way and a single matching profile another way.
The reality is that there exists ONLY 1 profile where the board name is the FIRST element in supported_devices.

I have limited python experience and I don't want to figure out specifics right now
so I will write some garbage pseudocode for example:

foreach profile in profiles {
   if (profile.supported_devices[0] == board_name) {
      image = profile.image;
      break;
   }
}

//Keep existing logic for when the board name is legacy, and matches nothing above.
if (!image) {
  foreach profile in profiles {
      if (legacy_matching_method) {
        image = profile.image;
        break;
      }
   }
}

and thats all we need...

although, I understand in real life application it will take more lines to do the equivalent here.

[map-b]

But, we allow mappings where it is not the first in the list (Look at rpi cases).

And the idea is to only apply the stricter requirement (be the first in the list) when there are shared entries. So we allow shared entries (compatible images) but consciously implemented).
*Oh, wait your proposal could work... But to detect the wrong cases... Anyway I hope we can move this forward, thanks again.

[map-b]

Time pass and new tools are available, I was going to propose make the translation a proper function but ended doing the next steps like make an API endpoint for ASU clients which do the profile identification. I have the proposal for an API endpoint for serve the profile resolution for owut and the required owut little adaptation code, I also have a proposal for the complementary required change to this PR for owut, just mimicking the new profile resolution logic. But by now, I have only updated this PR with a simplified and cleaner code.

V2 changes: (two new commits to keep PR evolution clear)

• Reworded the reverts commits messages.
• Refactor the proposed profile identification changes: make the profile validation (and translation) a proper function and simplify the code.
• Add comment with examples of devices profiles affected and commented in this PR.
• Add a long-standing bug fix with the build_request jobs hash generation which takes the profile before its validation and translation is done.

The ASU job cache issue is there since the beginning, it mostly affects ASU LuCI app since it sends the raw board_name and it gets a different build request hash that owut and firmware-selector since these sends the profile name. (e.g. each x86 request made in ASU LuCI app gets a unique hash, not the shared "generic")

We could also attach a single profile into each firmware image, by making devices "self aware", we'd avoid this entire shenanigans... #1533 (comment)

@aparcar I have thought many times about other possibilities to "attach" the used profile in the running image to uniquely identify the running image but... I cannot get anything better that DTS compatible string and the SUPPORTED_DEVICES map.

It is not clear what are the concerns here, as you can see i am all for this (and fixing any other missing bits related to ASU) but please give some real feedback so i can work on it.

*Completing the ASU integration tests is pending.

Recap: What does this PR propose?

• Avoid a, too much, simple mapping between profile name and SUPPORTED_DEVICES entries and add logic to select the first in the list when required.
• Unify and harmonize the profile validation (and translation) process between all ASU clients and server, no more confusing "sanitization" is done.

@efahl please, have a fresh new view on this