massdrop alt/ctrl: support saving into nvm

[daltona]

Use SAMD51 virtual eeprom to store eeprom in nvm instead of ram buffer so it is persistent accross reboots.
In order to have this working it is required to set PSZ and SBLK values in the NVM user row, I believe that can be done with the mdloader, but not having the source code, I am not able to implement this, I would be happy to do so.
I've tested by manualy updating the NVM user row connecting a JLINK probe on my keyboard.

Signed-off-by: Alexandre d Alton [email protected]

[drashna]

@patrickmt you should absolutely see this.

[drashna]

Anyone want to test this out?

@XScorpion2 @reywood @abishalom @MatthewRobo @valen214

[reywood]

I wouldn’t be able to test the nvm part, but could test that it behaves normally without those bits set.

[XScorpion2]

I'll test this out later tonight I hope

[zvecr]

To fully understand the situation, does the proposed change require mdloader changes or external hardware to function? If this code was merged as-is, what would users who dont have access to the above see? If its runtime failures, I dont see how this can be merged yet.

[reywood]

@zvecr Looks like the code will work with or without changes to mdloader. Though you wouldn't see the benefits until mdloader is changed.

[zvecr]

@reywood that's good. Let's see what the testing brings.

[XScorpion2]

Well, so far my CTRL has yet to crap itself from these changes. Also types just fine, except my fingers are now too use to a grid layout...
Would really like to get an updated mdloader to try the whole saving portion of this pr.

[drashna]

@patrickmt

[daltona]

I can try to add the code that will automatically update the configuration area, but this is too dangerous in my opinion as it cannot be recovered without a change in mdloader or JTAG hardware.

having mdloader changed would allow to securely update the configuration area without risking to lose some important data that is stored in it.

[XScorpion2]

Please no, last thing that needs to be floating around is test code that could break a popular kb. We can wait for an official mdloader change.

[daltona]

fully agree.
Well I figured out that there is host part of mdloader in the form of source code, so I might be able to implement the NVM configuration change in here.
I'll implement this, try and report back.

[daltona]

This patch to mdloader allows to enable smarteeprom feature in order to test configuration persistence.
daltona/mdloader@0aaf775
tested on a mac.

[XScorpion2]

@daltona tried your modified mdloader on windows with no luck. It still does not save out rgb matrix state. Did I use the right option?
.\mdloader_windows.exe -f -D -r .\massdrop_ctrl_xulkal.bin --restart

Interestingly enough, when I swap the order of the params, it spits out that another command conflicts with download:
.\mdloader_windows.exe -f -r -D .\massdrop_ctrl_xulkal.bin --restart

And the command list does not mention the -r option at all. Tried -r option by itself:
.\mdloader_windows.exe -f -r --restart
This at least spit out that it was updating the user row, but still not saving any state.

Opening port 'COM12'... Success!
Found MCU: SAMD51J18A
Bootloader version: v2.18Jun 22 2018 17:28:08
user row: 0xfe9a9239 0xaeecff80 0xffffffff 0xffffffff
SmartEEPROM not configured, proceed
dsu statusb: 00000010
nvm config: 00000004

Running it again states it is already configured:

Opening port 'COM12'... Success!
Found MCU: SAMD51J18A
Bootloader version: v2.18Jun 22 2018 17:28:08
user row: 0xfe9a9239 0xaeecff92 0xffffffff 0xffffffff
SmartEEPROM already configured

Final edit:
I just realized I forgot to switch to this feature branch....

Switching to the correct branch makes it work! Nice! 👍

[ash0x0]

I can maintain an updated branch of MDLoader with the NVMe support enabled and windows support. Do you think that will be worth it?

It would be based off Massdrop/mdloader#49 and Massdrop/mdloader#50

Given there are "proprietary" blobs involved, I doubt it would be a good idea to maintain a "community official" branch or something similar. Massdrop also seem to have their own unpublished versions of the blob for new keyboards that they're using in their configurator, all of this is in violation of GPL btw. The assumption that you can plug the blobs in and it'd work is false because they change between the MD boards and their revisions so you can never actually maintain that.
Maintaining a branch under your username (I doubt qmk would want it under the org) would cause confusion too. Even if updated in the keyboard README it'd still be confusing.
It'd definitely be better than whatever the hell is going on at Massdrop/mdloader but it's not without issues.
Also, it wouldn't do anything for #11119 which would still hold up this PR.

[pfruh]

How feasible would it be to create our own open source bootloader to be able to ditch their proprietary applet-mdflash.bin blob and use the drop keyboards as a "clean slate" for QMK?

[fauxpark]

It's certainly possible to write your own bootloader for ATSAM devices, the problem is that you will need extra hardware to replace it, in this case a J-Link and a Tag-Connect cable: https://learn.adafruit.com/how-to-program-samd-bootloaders

Which for most users then becomes completely useless once you've done it.

[pfruh]

I see, thanks for explaining. I thought the applet-mdflash.bin was the bootloader, but that makes more sense :)

Apart from the bootloader (that's definitely different between boards, mine is v2.20 Mar 27 2019 10:04:47 [ctrl]), would it be of any use (or even possible) to replace the applet-mdflash.bin with our own, assuming their bootloader is based on the official SAM-BA Bootloader (https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/SAM-BA%20In-system%20Programmer)? Looking through the mdloader releases, the applet hasn't changed at all.

[fauxpark]

As far as I can tell, the applet simply contains routines for programming external memories; it is uploaded to the chip before flashing proper starts, so that the bootloader knows where to shove the data it's receiving. From the SAM-BA docs:

Applets are binary programs that can be loaded through the sam-ba connection into some RAM region of the target before being executed. Applets extend the SAM-BA monitor to provide more features. The main usage of applets is to program the bootstrap into some Non-Volatile Memory (NVM).

So it would make sense that the mdloader's applet file hasn't changed, as it is fairly specific to the hardware configuration. In any case, I don't think it would be useful.

[daltona]

@zvecr Thank you for completing this and allowing it to be merged !

[zvecr]

Thanks go to you for putting in the bulk of the work!

[vmalloc]

@zvecr @daltona Just to make sure I'm up to speed - what's the bottom line for mdloader? This PR being merged means the qmk side supports persistence, but this can't actually be used until Drop updates their mdloader binaries?

[nicoelayda]

@vmalloc mdloader officially supports persistence starting from v1.0.6 https://github.com/Massdrop/mdloader/releases/tag/1.0.6

[vmalloc]

@nicoelayda awesome! I missed that bit - updated mdloader and it works great. Thanks for all the hard work you guys put into this!