http://en.techinfodepot.shoutwiki.com/wiki/Google_Stadia_(H2...
Broadcom are $#&@ for documentation and licensing, so I'm not super optimistic.
[1] https://www.nxp.com/products/processors-and-microcontrollers...
I'd imagine one would decompile the binaries, and modify the source code for redistribution as some portable library supporting whatever build target a user has. Of course, I assume (1) the decompiler can't detect compile-time macros detecting architecture and (2) you'd be screwed if you need shared libraries.
P.S. Interestingly, the first link when one googles "firmware decompiler" is to CIA code on Wikileaks lol
There's a few layers of firmware in a device like this, and none of them are interesting.
The device itself has firmware which reads button presses, talks to the wireless chipset, and drives the vibration motors.
The wireless chipset has firmware, too, but most of it is code provided by the chip manufacturer for free (this is actually the driver). There's a layer on top of the driver that acts to handle things like setting the device name, choosing wifi vs Bluetooth, managing connections.
The controller takes button presses and puts that data on a serial port over Bluetooth. Or in this case, feeds it to some web api over wifi.
As to the rest of your question, these images are not and really can't be very portable. Firmware is highly dependent on hardware. For example, a chip might have four SPI ports that can talk to the Bluetooth chipset. If this controller uses port 0, and another uses port 2, it will just fundamentally not work.
Firmware images just aren't really that useful outside of their target hardware. Decompiling won't tell you very much. If you're interested in the wireless chipset, the thing to do is get a device and open it up to see what chip is there. Then you can just download the SDK from the manufacturer.
On the developer side, you can build a firmware to target multiple devices. As you said, preprocessor directives can select code based on hardware at compile time. That's pretty much how you do it.
And yeah, the main tool for decompiling firmware is Ghidra, which was developed by the US government. IDA is another one to look at, but I'm not sure if it's relevant anymore
I'm not familiar with Stadia but when I saw 'Dump of controller BT firmware' I assumed that this is the code that runs on the actual bluetooth controller chip inside the controller. Presumably this handles at least the lower layers of comms between the controller and the host PC.
Maybe there's another application processor in the controller that handles higher-level communications or maybe the BT chip has a small general-purpose CPU core inside it, but regardless I don't see why this firmware would need to be modified to make the controller work on a windows PC.
Drivers, on the other hand, would run on the host PC side and would likely need to be rewritten for each platform that you want the controller to work with (although hopefully at least some of the lower-level bluetooth layers are already handled in windows/linux/etc. and the actual code required might not be too extensive)
Nearly every chip that supports Bluetooth has demo code available to make a Bluetooth HID device. All you'd need to do is run that and fix up the button mappings.
There’s also something awfully meta about Google discontinuing a support-page for their discontinued product…
For large tech companies, it's most likely due to organizational reasons. Someone (likely some team) has to own any component/subsystem and be responsible for its maintenance. This obviously comes at a cost of the teams' other projects (read bonus OKRs), a direct consequence is that it becomes hard to permanently rehome a dead-end project like the Stadia controller, best you can hope is a temporary reprieve from a sympathetic team.
https://support.google.com/stadia/answer/9565956?hl=en&ref_t...
I thought maybe it was the fault of my BT chip in my computer, so I turned it off and plugged it in instead, and the lag was most gone, but still worse than my Razer Wolverine.
I just threw mine in a box and gave up on it. I probably won't even bother flashing my other 2.
I have had the issue where the controller will connect but no button / axis events actually are produced. Disconnecting and reconnecting fixes it for me. This seems to be a common issue from other comments I've seen online.
And the Stadia controller was very slightly laggy even when just using the USB cable.
You’d need to read the iMX8 docs to know for sure, but it does support full secure boot IIRC.
Edit: Yup this appears to be true.
“The public key is included in the final binary and a hash of the public key is programmed in the SoC, in One-Time Programmable e-fuses, for establishing the root of trust.”
See https://www.variscite.com/blog/i-mx8-secure-boot-made-easy-c...
They may not be able to disable signature checking, but they can and should publish the private key.
(typing it from a i.MX8 phone right now - putting it into a gaming controller sounds hilariously ridiculous)
