Homebrew Homebrew app sys-patch - sysmod that patches on boot

[Blythe93]

Nope, in fact, rayman worked a long time ago don't know the firmware version (i delete the savegame cause i know it can work), and i just install the other games, first on firmware 17.0.0 then i update the firmware to 20.3.0 because i thought it was the reason they doesn't wan't to work. (all game's are in 1.2v)

Now that you have the latest sys-patch (it was silently updated a few times, v5 is the latest one) and you can confirm that it appears to be working (via Ultrahand), if you reinstall the affected games, do they work afterwards?

any ideas whats causing this?

Option to skip firmware version is turned on?

 

[Veda95]

Nope, in fact, rayman worked a long time ago don't know the firmware version (i delete the savegame cause i know it can work), and i just install the other games, first on firmware 17.0.0 then i update the firmware to 20.3.0 because i thought it was the reason they doesn't wan't to work. (all game's are in 1.2v)

Ok, everythings 's working now !!! I just have to use tinfoil to install games, dbi, awoo and goldleaf make some games to crash for me... Thank you !!!

 

[bombayjack]

@impeeza

Recommend update to Sys-patch, add function to check the current firmware version:
Example working (tested) function:

int getFirmwareVersionInt() {
    SetSysFirmwareVersion firmware;
    Result rc = setsysGetFirmwareVersion(&firmware);
   
    if (R_FAILED(rc)) {
        return -1;
    }
   
    // Convert to integer format: major * 1000 + minor * 100 + micro
    // Example: 12.0.1 -> 12001, 16.1.0 -> 16100, 17.0.0 -> 17000
    return (firmware.major * 1000) + (firmware.minor * 100) + firmware.micro;
}

Example Use like this:

int fwVersion = getFirmwareVersionInt();
if (fwVersion == 21000){
---add code here to set patches
}

Next add menu item to set recommended patches based on detected firmware running. This should be very easy to implement and would help some newer users select the correct patches to use.

 

[josete2k]

@impeeza

Recommend update to Sys-patch, add function to check the current firmware version:
Example working (tested) function:

int getFirmwareVersionInt() {
    SetSysFirmwareVersion firmware;
    Result rc = setsysGetFirmwareVersion(&firmware);
   
    if (R_FAILED(rc)) {
        return -1;
    }
   
    // Convert to integer format: major * 1000 + minor * 100 + micro
    // Example: 12.0.1 -> 12001, 16.1.0 -> 16100, 17.0.0 -> 17000
    return (firmware.major * 1000) + (firmware.minor * 100) + firmware.micro;
}

Example Use like this:

int fwVersion = getFirmwareVersionInt();
if (fwVersion == 21000){
---add code here to set patches
}

Next add menu item to set recommended patches based on detected firmware running. This should be very easy to implement and would help some newer users select the correct patches to use.

Good idea.

But recommended patches are all set by default. You can install sys-patch without overlay, only sysmodule, and it works as expected.

 

[bombayjack]

Good idea.

But recommended patches are all set by default. You can install sys-patch without overlay, only sysmodule, and it works as expected.

Yes, sorry I mean add an option to the overlay list to set recommended patches based on FW version. I already know the main code detects firmware/ams version etc.

As far as I know the overlay just writes the config file depending on options chosen but doesn't have code to detect FW version, adding a section to enable recommended patches could set the ini file the correct selection of patches depending on FW detected. That way when the user reboots they should be using the correct patches if they messed about with the overlay.

 

[bth]

Yes, sorry I mean add an option to the overlay list to set recommended patches based on FW version. I already know the main code detects firmware/ams version etc.

As far as I know the overlay just writes the config file depending on options chosen but doesn't have code to detect FW version, adding a section to enable recommended patches could set the ini file the correct selection of patches depending on FW detected. That way when the user reboots they should be using the correct patches if they messed about with the overlay.

if an user disables patches, it should not be hardcoded to override their decision.

All the patches are enabled by default, and already know when to load which, depending on which firmware version is booted.


feel free to add bloat to the overlay ui telling which patches are loaded from, and to which firmwares, but it's not much value for the end user to know that, they at best need to know that i.e. ES1/ES2/ES3, and so on is loaded or not.

more value as feedback to troubleshooting and/or correcting something not working, which doesn't need functionality in an optional part of the sysmodule, as the overlay UI requires sys-ovloader

 

[bombayjack]

if an user disables patches, it should not be hardcoded to override their decision.

All the patches are enabled by default, and already know when to load which, depending on which firmware version is booted.

That's not what I am saying, I don't want a hard coded override which always overrides the user choice, I want a list item added when selected it can reset the correct selected patches based on FW version if the user messed around and enabled/disabled the wrong patches. (sort of a reset option if you want to call it that).

 

[bth]

That's not what I am saying, I don't want a hard coded override which always overrides the user choice, I want a list item added when selected it can reset the correct selected patches based on FW version if the user messed around and enabled/disabled the wrong patches. (sort of a reset option if you want to call it that).

cosmetic alteration to the overlay which is conditionally only loaded if user has sys-ovlloader present, is fine, but behaviour change should not be done in the overlay. Making the overlay only show patches that are actually loaded on X or Y firmware, is fine.

Overriding user decision is not fine.

the same reason why sys-patch defaults to disabling patches on sysnand, as the predicted guess is most users use one SD card, and if they boot into sysmmc via. hekate with atmosphere fully loaded, they won't have the patches present (assuming the end user isn't using some bundle, in which case they probably have exefs .ips patches) and end up getting their ticketbin contaminated.

If they boot into sysnand with atmosphere loaded, it requires the end user to override the normal behaviour and forcibly enable patches, as a safeguard for unaware end users to not have patches loaded (unfortunately atmosphers loader cannot conditionally not load exefs .ips patches)

at least the hekate "stock" (not real stock anyway) makes the atmosphere custom loader module not be executed, and that means no loading of exefs .ips patches, or sysmodules

 

[bombayjack]

Overriding user decision is not fine.

A simple line in the overlay to Reset - could just remove the ini file and reboot the switch, then when it reboots the default ini would be recreated and the correct patches applied, I think you are overthinking this or what is required/requested.

 

[bth]

A simple line in the overlay to Reset - could just remove the ini file and reboot the switch, then when it reboots the default ini would be recreated and the correct patches applied, I think you are overthinking this or what is required/requested.

and that is bad behaviour for the minority of users who forcibly enable patches on sysnand, now you are corrupting all their installed tickets.

wipe clean = no



adjust the sysmodule part of code instead, make cosmetic alterations to overlay only.

sysmodule part already permits rewriting keys and persisting key values end user has made changes to.

 

[bombayjack]

and that is bad behaviour for the minority of users who forcibly enable patches on sysnand, now you are corrupting all their installed tickets.

wipe clean = no



adjust the sysmodule part of code instead, make cosmetic alterations to overlay only.

WTF are you talking about? I am not wanting to touch their tickets at all or even suggesting this. Forget it, I'll fork the code and make my own changes.

 

[bth]

WTF are you talking about? I am not wanting to touch their tickets at all or even suggesting this. Forget it, I'll fork the code and make my own changes.

ok mrdude, you clearly don't understand what you're trying to change on a base level.

we've already come to terms in that one github issue you don't understand UX, stop trying to malware-ify sys-patch. Make Ui changes in overlay only, adjust sysmodule code instead.

 

[bombayjack]

ok mrdude, you clearly don't understand what you're trying to change on a base level.

we've already come to terms in that one github issue you don't understand UX, stop trying to malware-ify sys-patch. Make Ui changes in overlay only, adjust sysmodule code instead.

??? WTF are you on about now? I told you to forget it, I'll do it myself.

 

[josete2k]

Well, the skip firmware option do that... Only applies the recommended patches in every firmware.

 

[AllOver]

I don't understand the fw version thing. syspatch already checks the min/max fw for all patches. Is there a case where a patch should be enabled only a certain fw but not others?

If a patch is not required then it's usually due to being on a older fw. In the case where a new patch is needed, it's due them moving checks from fs to ldr and nim crashing etc. Another case for different patch is the pattern being invalid due to compiler changes, refactoring or logic changes. The min/max fw check covers all of the above.

 

[bombayjack]

I don't understand the fw version thing. syspatch already checks the min/max fw for all patches. Is there a case where a patch should be enabled only a certain fw but not others?

If a patch is not required then it's usually due to being on a older fw. In the case where a new patch is needed, it's due them moving checks from fs to ldr and nim crashing etc. Another case for different patch is the pattern being invalid due to compiler changes, refactoring or logic changes. The min/max fw check covers all of the above.

If you disable some patches on the overlay it writes a new ini file to /config/sys-patch/config.ini. If you forget what patches are set by default you can just remove /config/sys-patch/config.ini and then open the overlay again and they will be back to the default settings.

 

[josete2k]

I'd just add (optional) to the erpt and (expert) to the disablecaverification in the overlay...

 

[AllOver]

I'd just add (optional) to the erpt and (expert) to the disablecaverification in the overlay...

Or if Tesla supports text info to explain each patch. Maybe have a tab with the "advanced" patches underneath. Could even add a qr code which links to a GitHub wiki. I think the advanced tab works best as 99% of users do not need those patches. Just depends if any of this is worth doing.

 

[josete2k]

Redundant.

Sys patch was designed to be invisible for the regular user...

 

[AllOver]

Redundant.

Sys patch was designed to be invisible for the regular user...

If that were true, there wouldn't be an overlay.