Add a fwupd plugin for ASUS ROG ally and ROG ally X #7782

superm1 · 2024-09-24T16:34:09Z

This is only for querying the MCU firmware version for now. The sequence for writing the firmware update either needs some more RE or some help from ASUS.

@flukejones can I please ask you to test this branch on Ally and Ally X and show the versions it pulls up to see if everything looks sane?

plugins/asus-hid/asus-hid.quirk

plugins/asus-hid/fu-asus-hid-device.c

superm1 · 2024-09-24T19:28:09Z

I received an email confirming this is working. Here was the device ID that shows up:

├─N-KEY Device:
│ │ Device ID: b8a2645298053fb62ea03e27feea6c483d3fd27e
│ │ Current version: 0.2
│ │ Vendor: ASUSTek Computer, Inc. (USB:0x0B05)
│ │ GUID: a42577e5-92b2-53df-a7d1-513812a2ea4f ← USB\VID_0B05&PID_1B4C
│ │
│ └─Microcontroller 0:
│ Device ID: 669b88991d577a8d22a508e5dcbc798726edbf90
│ Current version: 312
│ Vendor: ASUSTek Computer, Inc. (USB:0x0B05)
│ GUID: 9a88fe8b-e444-595e-848e-c1937c54669e ← USB\VID_0B05&PID_1B4C&PART_RC72LA

flukejones · 2024-09-24T21:14:36Z

There is an issue where doing the probe now causes the Ally X MCU to start a vibration command and it won't stop until I remove/add my ally driver and then suspend/resume.

This vibration continues even in suspended state.

@superm1 I think the last version that worked fine was a8692e9 with the Ally X added to quirk

superm1 · 2024-09-24T21:17:08Z

There is an issue where doing the probe now causes the Ally X MCU to start a vibration command and it won't stop until I remove/add my ally driver and then suspend/resume.

This vibration continues even in suspended state.

@superm1 I think the last version that worked fine was a8692e9 with the Ally X added to quirk

Can you try taking out the command that is setting the manufacturer ID? I suspect that's what's doing it and that it happens to do more than we thought

flukejones · 2024-09-24T21:19:04Z

It seems I didn't notice this before as the vibration issue occurs on on AC plugged in. I'll try the suggestion now.

flukejones · 2024-09-24T21:22:16Z

@superm1 whcih command is this exactly? I'm not familiar with how fwupd works.

superm1 · 2024-09-24T21:29:26Z

plugins/asus-hid/fu-asus-hid-device.c

+		fu_device_set_proxy(dev_tmp, device);
+		if (!fu_asus_hid_device_ensure_version(dev_tmp, i, error))
+			return FALSE;
+		if (!fu_asus_hid_device_ensure_manufacturer(dev_tmp, error))


@flukejones comment this function call out and see if it helps.

flukejones · 2024-09-24T21:41:48Z

Output:

├─N-KEY Device:
│ │   Device ID:          b8a2645298053fb62ea03e27feea6c483d3fd27e
│ │   Current version:    0.2
│ │   Vendor:             ASUSTek Computer, Inc. (USB:0x0B05)
│ │   GUID:               a42577e5-92b2-53df-a7d1-513812a2ea4f ← USB\VID_0B05&PID_1B4C
│ │
│ └─Microcontroller 0:
│       Device ID:        669b88991d577a8d22a508e5dcbc798726edbf90
│       Current version:  312_T01
│       Vendor:           ASUSTek Computer, Inc. (USB:0x0B05)
│       GUID:             9a88fe8b-e444-595e-848e-c1937c54669e ← USB\VID_0B05&PID_1B4C&PART_RC72LA

Commenting the thing didn't help. But I've done now a full reset on the repo and rebuilt - it seems that another command is resetting the MCU as I'm seeing the LEDs reset to static-mode colour.

superm1 · 2024-09-24T22:40:47Z

Output:

├─N-KEY Device:
│ │   Device ID:          b8a2645298053fb62ea03e27feea6c483d3fd27e
│ │   Current version:    0.2
│ │   Vendor:             ASUSTek Computer, Inc. (USB:0x0B05)
│ │   GUID:               a42577e5-92b2-53df-a7d1-513812a2ea4f ← USB\VID_0B05&PID_1B4C
│ │
│ └─Microcontroller 0:
│       Device ID:        669b88991d577a8d22a508e5dcbc798726edbf90
│       Current version:  312_T01
│       Vendor:           ASUSTek Computer, Inc. (USB:0x0B05)
│       GUID:             9a88fe8b-e444-595e-848e-c1937c54669e ← USB\VID_0B05&PID_1B4C&PART_RC72LA

Commenting the thing didn't help. But I've done now a full reset on the repo and rebuilt - it seems that another command is resetting the MCU as I'm seeing the LEDs reset to static-mode colour.

I wonder if it's actually the opening and closing of the hid endpoint doing this.

flukejones · 2024-09-25T00:44:21Z

@superm1

I wonder if it's actually the opening and closing of the hid endpoint doing this.

The behaviour I see seems to be consistent for this. From memory it's when the HID endpoint is opened, I have to send a packet to the device to stop vibration when the hid-asus-ally driver first loads.

superm1 · 2024-09-25T00:45:34Z

@superm1

I wonder if it's actually the opening and closing of the hid endpoint doing this.

The behaviour I see seems to be consistent for this. From memory it's when the HID endpoint is opened, I have to send a packet to the device to stop vibration when the hid-asus-ally driver first loads.

Can you point me at the packet? I can try to send the same thing on fwupd open.

superm1 · 2024-09-25T01:14:10Z

@superm1

I wonder if it's actually the opening and closing of the hid endpoint doing this.

The behaviour I see seems to be consistent for this. From memory it's when the HID endpoint is opened, I have to send a packet to the device to stop vibration when the hid-asus-ally driver first loads.

Can you point me at the packet? I can try to send the same thing on fwupd open.

Is it this stuff?

static int ally_gamepad_init(struct hid_device *hdev, u8 report_id)
{
	const u8 buf[] = { report_id, 0x41, 0x53, 0x55, 0x53, 0x20, 0x54, 0x65,
			   0x63,      0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00 };
	int ret;

	ret = asus_dev_set_report(hdev, buf, sizeof(buf));
	if (ret < 0)
		hid_err(hdev, "Ally failed to send init command: %d\n", ret);

	return ret;
}

flukejones · 2024-09-25T01:15:49Z

	report->report_id = 0x0D;
	report->ff.enable = 0x0F; /* Enable all by default */
	report->ff.pulse_sustain_10ms = 0xFF; /* Duration */
	report->ff.pulse_release_10ms = 0x00; /* Start Delay */
	report->ff.loop_count = 0xEB; /* Loop Count */

I think a HID data packet of 0x0D, 0x0F, 0x00, 0x00, 0x00 should work.

flukejones · 2024-09-25T01:17:27Z

@superm1
Is it this stuff?

static int ally_gamepad_init(struct hid_device *hdev, u8 report_id)
{
	const u8 buf[] = { report_id, 0x41, 0x53, 0x55, 0x53, 0x20, 0x54, 0x65,
			   0x63,      0x68, 0x2e, 0x49, 0x6e, 0x63, 0x2e, 0x00 };
	int ret;

	ret = asus_dev_set_report(hdev, buf, sizeof(buf));
	if (ret < 0)
		hid_err(hdev, "Ally failed to send init command: %d\n", ret);

	return ret;
}

No that never stopped the vibration. Have to send the one above. It's possible I'm missing something else in the init but I've never got around to seeing what it is.

The ASUS app sends an absolute ton of stuff.

But for this issue I think we need to look at the MCU update capture to identify what might come after.

superm1 · 2024-09-25T05:06:04Z

I think a HID data packet of 0x0D, 0x0F, 0x00, 0x00, 0x00 should work.

Hmm, I don't see any write to report 13 in the dump you shared me. Perhaps this means more of the sequence of HID commands before getting the FW version may be needed?

flukejones · 2024-09-25T05:26:49Z

Most likely. I am fairly sure there is one that perhaps stops the dev from doing things? Really need an answer from asus about now

superm1 · 2024-09-25T06:09:48Z

I spent some time looking at the dll and pulled out some other commands. Will need to see if any of these show up before the get fw version from the dumps.

flukejones · 2024-09-25T07:27:15Z

I have a brief response from ASUS that they are studying update process and will get back to us soon, possibly in the email chain between us and Richard.

Below are some logs that will help match things up. I think the first one matches the pcap. And I'm willing to bet the bin file bytes would match the pcap data. I'll try to find those bin files again.

ROGKBFWUpdateTool_20231105122303.log
ROGKBFWUpdateTool_20231105160506.log

hughsie · 2024-09-25T09:07:28Z

Great work everybody!

superm1 · 2024-09-25T12:22:07Z

I have a brief response from ASUS that they are studying update process and will get back to us soon, possibly in the email chain between us and Richard.

Below are some logs that will help match things up. I think the first one matches the pcap. And I'm willing to bet the bin file bytes would match the pcap data. I'll try to find those bin files again.

ROGKBFWUpdateTool_20231105122303.log ROGKBFWUpdateTool_20231105160506.log

Can you add a log for Ally X? It seems for Ally that there is a set of flows that does second IC first, flash reset, then first IC and switch to main rom.

And if you can get a packet capture from Ally X (ideally through a VM if you can) it would be good to put it all together.

flukejones · 2024-09-26T04:46:18Z

ally-x-312_t01_update.log

Full capture data used. The log matches the pcap here, and the binary data also.

I did spot what looks like a "boot" command, lists the device in the string also as UUIT8297-BOOT-V1.1 in Packet 364 in response a 0xD1 packet. Oh yeah, this data looks like exactly what is in the bin file, so 0xD1 must be a "read me this block", and 0xC1 seems like a "write this block", and that data looks like a different format?

For that vibe issue: might be we need to send the ASUS Tech.Inc. data (initialise) after reading version. Or after the endpoint is opened before the version request.

NOTE: *the data read back in the pcap is the exact data in linked bin file since I forced an overwrite of same version. 0xD1 is hid page, second byte is the block address? I see FGA80100.RC72LA.312 is also in the bin file as data.

flukejones · 2024-09-26T05:00:44Z

I will get a capture of a downgrade to an earlier firmware so we can be double clear on what is what.

superm1 · 2024-09-26T05:03:24Z

Full capture data used. The log matches the pcap here, and the binary data also.

Man, unfortunately ./contrib/pcap2emulation.py doesn't want to convert the packet capture to fwupd format.
@fdanis-oss any ideas what is wrong with it?

Good news though, the new firmware parser I put in which pulls the string from the right offset in the binaries seems to be working both on Ally and Ally-X binaries!

❯ fwupdtool firmware-parse ~/Downloads/FGA80100.RC72LA.312.bin asus-hid
Loading…                 [************************************** ]
<firmware gtype="FuAsusHidFirmware">
  <data size="0x40000">[GInputStream]</data>
  <fga>FGA80100</fga>
  <product>RC72LA</product>
  <version>312</version>
</firmware>
❯ fwupdtool firmware-parse ~/src/asusmcu/ROGMCUFWUpdateTool/fw/FGA80100.RC71LS.318_T02.bin asus-hid
Loading…                 [************************************** ]
<firmware gtype="FuAsusHidFirmware">
  <data size="0x1e000">[GInputStream]</data>
  <fga>FGA80100</fga>
  <product>RC71LS</product>
  <version>318_T02</version>
</firmware>
❯ fwupdtool firmware-parse ~/src/asusmcu/ROGMCUFWUpdateTool/fw/FGA80100.RC71LM.318_T02.bin asus-hid 
Loading…                 [************************************** ]
<firmware gtype="FuAsusHidFirmware">
  <data size="0x1b000">[GInputStream]</data>
  <fga>FGA80100</fga>
  <product>RC71LM</product>
  <version>318_T02</version>
</firmware>

For that vibe issue: might be we need to send the ASUS Tech.Inc. data (initialise) after reading version. Or after the endpoint is opened before the version request.

I've been wondering about that, in the Ghidra stuff and packet capture it looked at first like random stale stack data, but it really does have a static string. If it's functional then yeah I should be able to force it in to see if it helps. I'll do that tomorrow.

NeroReflex · 2024-10-21T01:22:44Z

Capture shared. Cloud recovery did not work and I simply reinstall ed windiws the usual way.
Also yeah usbpcap refused to work in a win to go environment

superm1 · 2024-10-21T04:37:56Z

Thanks @NeroReflex! I've pulled it into my branch of emulation data and will continue to work with it.

superm1 · 2024-10-23T05:08:35Z

With my cleaned up emulation data at https://github.com/superm1/ally-emulation I've managed to do a full write sequence for the microcontroller RC71LS, but not for RC71LM.
I still need to dig into whether it's an emulation data capture problem or plugin problem with offsets for RC71LM.

@hughsie I was about to rebase, but with the changes in 88050ee I wanted to check how you think this should be handled. I need to send a few commands at the start of the page, write all the blocks, send a command at end of page. So walking a straightforward loop doesn't work unless I special case. Thoughts? Or maybe if you have an idea just (force) push to the branch.

hughsie · 2024-10-23T07:06:15Z

So walking a straightforward loop doesn't work unless I special case.

I think you're going to need a FuChunkArray of a FuChunkArray still - you need to do (failable) stuff at the start and end of the page. I've got a branch which adds the fu_chunk_get_stream() API you need, but it depends on the steelseries rustgen branch. If you want a sneak peak it's predictably hughsie/fu_chunk_stream_new

superm1 · 2024-10-23T15:27:27Z

So walking a straightforward loop doesn't work unless I special case.

I think you're going to need a FuChunkArray of a FuChunkArray still - you need to do (failable) stuff at the start and end of the page.

OK thanks, that clarifies my big confusion, I didn't see how this API could possibly work for that purpose without a FuChunkArray of a FuChunkArray.

I've got a branch which adds the fu_chunk_get_stream() API you need, but it depends on the steelseries rustgen branch. If you want a sneak peak it's predictably hughsie/fu_chunk_stream_new

Ack, as I still haven't verified RC71LM, I'll hold off on rebasing. Maybe by the time I'm ready that will have landed :)

hughsie · 2024-11-12T10:27:54Z

@superm1 I'd be fine if you wanted to merge this to avoid it bitrotting. We can always disable it by default in the build if you want.

superm1 · 2024-11-12T13:57:58Z

@superm1 I'd be fine if you wanted to merge this to avoid it bitrotting. We can always disable it by default in the build if you want.

That's not a bad idea to merge as is with some guard rail. I don't mind it being enabled by default, enumeration is definitely correct.

I am thinking to add a force check for the write routine though. Once I find the time to find the problem with the other microcontroller can drop that. I'll spin a change.

plugins/asus-hid/fu-asus-hid-device.c

hughsie · 2024-11-12T14:56:51Z

plugins/asus-hid/fu-asus-hid-device.c

+static void
+fu_asus_hid_device_init(FuAsusHidDevice *self)
+{
+	fu_device_add_private_flag(FU_DEVICE(self), FU_DEVICE_PRIVATE_FLAG_NO_AUTO_REMOVE_CHILDREN);


do you need the children to outlive the parent?

Yup! Specifically when doing the detach/attach dance the parent disappears. Without those children you won't have all the details of what payload goes to what child device.

plugins/asus-hid/fu-asus-hid-plugin.c

superm1 · 2024-11-12T16:47:57Z

Thx, let's hold off to merge 1-2 days more. I need to make sure I didn't break the installation emulation that was working so far with any of these changes for child vs parent ownership.

Until this has been validated end to end either on real hardware or on emulation the plugin should not be allowed to issue upgrades. Leave the flag in place however for testing with --force.

superm1 · 2024-11-13T06:35:06Z

Yup, found some regression. I've sorted it out and can get the secondary controller updating again.

│ ├─Microcontroller 0:
│ │     Device ID:        105a998eae01e451237dc37974beab9362f0066f
│ │     Current version:  319
│ │     Vendor:           ASUSTek Computer, Inc. (USB:0x0B05)
│ │     Update State:     Success
│ │     Last modified:    2024-11-13
│ │     GUIDs:            f7765461-3ff4-52a0-a4d8-d782b1f885ab ← USB\VID_0B05&PID_1ABE&PART_RC71LS
│ │                       5f0738ae-5e3a-5e94-99fb-62d1b0fefcb1
│ │                       571229d5-caed-5cbc-91c1-5c216601a194
│ │                       8eeac4f3-d98d-57aa-a1fc-b44e8d3d8ba3
│ │                       c33b161d-a538-57df-b1c8-90817ada2387
│ │     Device Flags:     • Updatable
│ │                       • Unsigned Payload
│ │                       • Emulated

The primary controller update flow is missing from the emulation data but I'm suspecting a conversion issue because it's quite obviously in the wireshark dump.

superm1 force-pushed the superm1/asus-hid branch from 3ae327a to c2c66bf Compare September 24, 2024 18:14

hughsie reviewed Sep 24, 2024

View reviewed changes

plugins/asus-hid/asus-hid.quirk Outdated Show resolved Hide resolved

hughsie reviewed Sep 24, 2024

View reviewed changes

plugins/asus-hid/fu-asus-hid-device.c Outdated Show resolved Hide resolved

hughsie reviewed Sep 24, 2024

View reviewed changes

plugins/asus-hid/fu-asus-hid-device.c Outdated Show resolved Hide resolved

hughsie reviewed Sep 24, 2024

View reviewed changes

plugins/asus-hid/fu-asus-hid-device.c Outdated Show resolved Hide resolved

hughsie reviewed Sep 24, 2024

View reviewed changes

plugins/asus-hid/fu-asus-hid-device.c Outdated Show resolved Hide resolved

superm1 force-pushed the superm1/asus-hid branch 2 times, most recently from b91b243 to eaca806 Compare September 24, 2024 19:27

superm1 commented Sep 24, 2024

View reviewed changes

superm1 force-pushed the superm1/asus-hid branch 4 times, most recently from d8ff5e7 to abc347a Compare November 9, 2024 20:54

superm1 force-pushed the superm1/asus-hid branch from abc347a to 6b2f356 Compare November 12, 2024 14:50

superm1 marked this pull request as ready for review November 12, 2024 14:50

superm1 requested a review from hughsie November 12, 2024 14:50

hughsie reviewed Nov 12, 2024

View reviewed changes

plugins/asus-hid/fu-asus-hid-device.c Outdated Show resolved Hide resolved

hughsie reviewed Nov 12, 2024

View reviewed changes

plugins/asus-hid/fu-asus-hid-device.c Outdated Show resolved Hide resolved

hughsie reviewed Nov 12, 2024

View reviewed changes

plugins/asus-hid/fu-asus-hid-device.c Outdated Show resolved Hide resolved

hughsie reviewed Nov 12, 2024

View reviewed changes

plugins/asus-hid/fu-asus-hid-device.c Outdated Show resolved Hide resolved

hughsie reviewed Nov 12, 2024

View reviewed changes

plugins/asus-hid/fu-asus-hid-plugin.c Show resolved Hide resolved

superm1 force-pushed the superm1/asus-hid branch from 6b2f356 to f6aaa6f Compare November 12, 2024 16:21

hughsie previously approved these changes Nov 12, 2024

View reviewed changes

superm1 added 2 commits November 13, 2024 00:29

Add a fwupd plugin for ASUS ROG ally and ROG ally X

200ec77

trivial: asus-hid: block upgrades for now

b6ca25b

Until this has been validated end to end either on real hardware or on emulation the plugin should not be allowed to issue upgrades. Leave the flag in place however for testing with --force.

superm1 dismissed hughsie’s stale review via b6ca25b November 13, 2024 06:29

superm1 force-pushed the superm1/asus-hid branch from f6aaa6f to b6ca25b Compare November 13, 2024 06:29

superm1 merged commit 6d77936 into main Nov 13, 2024
19 checks passed

superm1 deleted the superm1/asus-hid branch November 13, 2024 06:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add a fwupd plugin for ASUS ROG ally and ROG ally X #7782

Add a fwupd plugin for ASUS ROG ally and ROG ally X #7782

superm1 commented Sep 24, 2024

superm1 commented Sep 24, 2024

flukejones commented Sep 24, 2024

superm1 commented Sep 24, 2024

flukejones commented Sep 24, 2024

flukejones commented Sep 24, 2024

superm1 Sep 24, 2024

flukejones commented Sep 24, 2024

superm1 commented Sep 24, 2024

flukejones commented Sep 25, 2024

superm1 commented Sep 25, 2024

superm1 commented Sep 25, 2024

flukejones commented Sep 25, 2024

flukejones commented Sep 25, 2024 •

edited

Loading

superm1 commented Sep 25, 2024

flukejones commented Sep 25, 2024

superm1 commented Sep 25, 2024

flukejones commented Sep 25, 2024

hughsie commented Sep 25, 2024

superm1 commented Sep 25, 2024

flukejones commented Sep 26, 2024 •

edited

Loading

flukejones commented Sep 26, 2024

superm1 commented Sep 26, 2024

NeroReflex commented Oct 21, 2024

superm1 commented Oct 21, 2024

superm1 commented Oct 23, 2024

hughsie commented Oct 23, 2024

superm1 commented Oct 23, 2024

hughsie commented Nov 12, 2024

superm1 commented Nov 12, 2024

hughsie Nov 12, 2024

superm1 Nov 12, 2024

superm1 commented Nov 12, 2024

superm1 commented Nov 13, 2024

Add a fwupd plugin for ASUS ROG ally and ROG ally X #7782

Add a fwupd plugin for ASUS ROG ally and ROG ally X #7782

Conversation

superm1 commented Sep 24, 2024

superm1 commented Sep 24, 2024

flukejones commented Sep 24, 2024

superm1 commented Sep 24, 2024

flukejones commented Sep 24, 2024

flukejones commented Sep 24, 2024

superm1 Sep 24, 2024

Choose a reason for hiding this comment

flukejones commented Sep 24, 2024

superm1 commented Sep 24, 2024

flukejones commented Sep 25, 2024

superm1 commented Sep 25, 2024

superm1 commented Sep 25, 2024

flukejones commented Sep 25, 2024

flukejones commented Sep 25, 2024 • edited Loading

superm1 commented Sep 25, 2024

flukejones commented Sep 25, 2024

superm1 commented Sep 25, 2024

flukejones commented Sep 25, 2024

hughsie commented Sep 25, 2024

superm1 commented Sep 25, 2024

flukejones commented Sep 26, 2024 • edited Loading

flukejones commented Sep 26, 2024

superm1 commented Sep 26, 2024

NeroReflex commented Oct 21, 2024

superm1 commented Oct 21, 2024

superm1 commented Oct 23, 2024

hughsie commented Oct 23, 2024

superm1 commented Oct 23, 2024

hughsie commented Nov 12, 2024

superm1 commented Nov 12, 2024

hughsie Nov 12, 2024

Choose a reason for hiding this comment

superm1 Nov 12, 2024

Choose a reason for hiding this comment

superm1 commented Nov 12, 2024

superm1 commented Nov 13, 2024

flukejones commented Sep 25, 2024 •

edited

Loading

flukejones commented Sep 26, 2024 •

edited

Loading