search

openinput-fw / openinput

Open source firmware for input devices
https://openinput.readthedocs.io
MIT License
70 stars 6 forks source link

Support for SteelSeries Sensei Ten #64

Open t-8ch opened 3 years ago

t-8ch commented 3 years ago

How hard would you estimate it to be adding support for SteelSeries Sensei Ten mouses?

MCU: STM32F103T6U6A ( https://www.techpowerup.com/review/steelseries-sensei-ten/4.html ) Sensor: TrueMove Pro (based off the PixArt PMW3389.)

Also: Is the assumption that the innards of the Sensei 310 are identical to the ones of the Rival 310 reasonable?

perigoso commented 3 years ago

support should be pretty straightfoward, just need to figure out what is connected to what, the pcbs are different, but it might be similar enough that no changes are required

t-8ch commented 3 years ago

Good to hear, then I'll probably try to do so.

FFY00 commented 3 years ago

Yeah, you just need to create a new config for the stm32f1-generic target (see https://github.com/openinput-fw/openinput/blob/main/src/targets/stm32f1-generic/config/rival310.h for an example), and add a symlink to stm32f103t6.ld for your config in https://github.com/openinput-fw/openinput/tree/main/config/linker/stm32f1-generic.

t-8ch commented 3 years ago

What about the SROM data? Can the generic one be used before a special one is extracted? How would it be extracted?

t-8ch commented 3 years ago

Also is the bootloader that is responsible for flashing a new firmware protected against overwrite? Or is there something to care about to prevent a hardbrick.

FFY00 commented 3 years ago

The firmware blob for the sensor should go to https://github.com/openinput-fw/sensor-blobs, and we'll generate a header that can be used in the code.

We don't have a bootloader yet, just the firmware. You can either flash it directly, or keep the stock bootloader. If you want to keep the stock bootloader, you will have to change linker script to put the ROM in 0x08002000 IIRC. We have reverse engineered the Steelseries update protocol used in the Rival 310 and friends, which I am pretty sure is the same use in the Sensei Ten. You should be able to use tools in https://github.com/openinput-fw/openinput/tree/main/tools to generate the CRC and flash the firmware. Though, we'd recommend to flash directly, if you have that option. But maybe it's better if you dump the original memory first so that you can go back. You can do this by flashing a custom firmware that just reads out the memory, that's what @perigoso did, I don't know if he still has the source around.

We want to write a custom bootloader and then a dummy firmware that can be flashed with the original bootloader and will replace it with ours, but that is still a TODO :stuck_out_tongue:.

t-8ch commented 3 years ago

How would I extract the firmware blob for the sensor?

How would "flashing directly" work?

Dumping the original memory would be great. Should it be possible to attach a debug probe and read the ROM via that?

Does the bootloader implement the update protocol? If so how would the firmware be updated after a firmware without a bootloder is flashed?

FFY00 commented 3 years ago

How would I extract the firmware blob for the sensor?

Your device as an external eeprom, right? It should be stored there.

How would "flashing directly" work?

Plugging a debug probe, like a st-link, and flash the firmware that way.

Dumping the original memory would be great. Should it be possible to attach a debug probe and read the ROM via that?

Possibly, though I think they probably enabled readout protection. If that is the case, you will have a to use the method I described -- flashing a custom firmware via the original bootloader to dump the contents.

Does the bootloader implement the update protocol? If so how would the firmware be updated after a firmware without a bootloder is flashed?

Yes, it does. If you flash it directly (remove the bootloader), you will only be able to update with the debug probe, and not USB. For now at least :wink:

t-8ch commented 3 years ago

Your device as an external eeprom, right? It should be stored there.

Will check as soon as I have it.

Possibly, though I think they probably enabled readout protection. If that is the case, you will have a to use the method I described -- flashing a custom firmware via the original bootloader to dump the contents.

Ok.

Yes, it does. If you flash it directly (remove the bootloader), you will only be able to update with the debug probe, and not USB. For now at least.

Then I'll keep the original bootloader for now probably.

perigoso commented 3 years ago

I dont recall what i did exactly to extract the original fw, i was just hacking around.

I had mixed results when keeping the original bootloader, i dont konw what they do there, but the firmware a lot of time just didnt work, while working fine when flashed directly.

I you do end up flashing with a debug probe you can restore the original state with the probe as well, provided you have the original fw

t-8ch commented 3 years ago

Is there a reason for baking the sensor firmware into the normal firmware instead of also taking it from the eeprom like the stock firmware?

FFY00 commented 3 years ago

I think we want to do that in the future, but for now it is simpler to do it this way.

t-8ch commented 3 years ago

@FFY00 Ok

@perigoso Do you still have the code the code to dump the flash? I used https://github.com/doegox/stm32f1-firmware-extractor but the result is not complete, so most probably not runnable.

perigoso commented 3 years ago

No, I dont.

If i recall, I flashed a custom firmware that was loaded with the stock bootloader, that then dumped the contents of the mcu and the external eeprom through swo

t-8ch commented 3 years ago

Okay. By any chance could you give me a dump of the stock bootloader?

perigoso commented 3 years ago

Here you can find most of what we figured fromt he 310, the bootloader dump is not there, i have to see if i find it and upload it too. https://github.com/perigoso/rival310-re

t-8ch commented 3 years ago

@perigoso Thanks. I flashed openinput which works mostly but the motion burst data received from the sensor is not parsed correctly. Then I tried to go back to the vanilla firmware which didn't work because the bootloader was also gone and I don't have an intact version of it. I managed to make it work by manually creating a stub bootloader consisting of 0028 0020 1970 0008 and a lot of zeros, setting the stack and PC to the firmware values. The mouse is fairly unhappy, both LEDs are blinking red, all hidraw devices are gone, but it's still capable of properly running the basic mouse functions. Now I just have to figure how the data is to be interpreted.

The attached file for example are motion burst reports (register 0x50) while the mouse is being moved at 4000DPI and then lifted. burst_reports.txt

perigoso commented 3 years ago

Sorry Im not following, you're saying the sensor is not being read properly?

t-8ch commented 3 years ago

Yes. The motion burst always reports 0 for the delta values. Looking at the "Motion" byte in the motion burst report shows that the sensor is in "Rest mode 1", although Rest mode should be disable via the Config2 (0x10) register.

t-8ch commented 3 years ago

If you want I can provide SPI traces for both cases.

Edit: Attached are sigrok SPI traces that can be viewed in PulseView. (Optionally with https://github.com/openinput-fw/sensor-blobs/pull/2 )

spi_traces.zip

perigoso commented 3 years ago

are you uploading the right fw blob? the truemove3 blob should not be compatible

perigoso commented 3 years ago

I have not yet tested with the pmw3389, so the driver might be doing something wrong, datasheets are obtainable

I'll look at the captures in a bit

t-8ch commented 3 years ago

Yes, it's the correct blob. I also added CRC checks (not in the trace) and it give the correct result.

t-8ch commented 3 years ago

Can you point me to the datasheet? The only one I found did only specify the numbers of the registers, not how they are to be used.

perigoso commented 3 years ago

ah, yeah pixart is terrible with info on their sensors, I dont think theres any more detailed DS around

perigoso commented 3 years ago

Well, from everything I'm looking at, this should just work, the behavior should be the same as in the 3360

Only just now looked at your captures, stock seems to be doing a couple different things, I'll be looking deeper.

t-8ch commented 3 years ago

I still could not get it to work. Except when not uploading the SROM; then it works nicely.

perigoso commented 3 years ago

what have you tried? we can try to modify the driver until the startup matches the stock exactly, from there we can figure out what we're missing

t-8ch commented 3 years ago

This is what I tried. I'll try to produce another SPI dump tomorrow and look again.

perigoso commented 3 years ago

right, sorry I'm not paying much attention to this

I'd like to try something myself but sadly I don't have anything with a pmw3389, or the sensor itself

FFY00 commented 3 years ago

Ugh, I must have that sensor somewhere, because I did order one, but I just can't find it.