Hekate breaks HDCP on all modes weather you boot stock or cfw. weather you use autorcm or a jig. This issue goes away when using the stock bootloader. I will quote this here as they have found the issue but it has yet to be fixed in atmo Hekate has the same issue
Did MC_SECURITY_CARVEOUT2_CLIENT_ACCESS2 = 0x3100000;
actually fixed it?
It did not.
Can you try and change this:
https://github.com/CTCaer/hekate/blob/master/bootloader/mem/mc.c#L97
And then stock (through hekate) or without exosphere?
(if you want to try without the mc carveouts you comment this https://github.com/CTCaer/hekate/blob/master/bootloader/main.c#L451 and this https://github.com/CTCaer/hekate/blob/master/bootloader/hos/hos.c#L742)
Also it's better to try with autorcm (and a single press to PWR) and with normal RCM.
EDIT:
Also what happens if you let it sleep for 1minute and then waking it up and try?
Tried the first one before to no success My jig is broken so no normal RCM. And ill try the other in about 10 hours when i wake.
OK. AutoRCM is better because these values are actually set.
A little explanation on commenting these 2 functions:
In 4.0.0+ Ninty started to use secmon to set these. So if commenting them works, it means I'll have to search there.
This ifixes it on stock. Im now going to try the updated exosphere
That works with the recent fix in atmo.
any news on this? i leave tomorrow and wont be able to test for a week
Not yet. I don't have time currently to make it proper.
Bringing the necessary changes for fixing the HDCP issue over here:
This issue has been fixed in Atmosph猫re by removing all carveout configuration from Fus茅e (which only works due to Exosph猫re doing it instead), but since Hekate is designed to be a general purpose bootloader, it should be necessary to configure the carveouts differently on each firmware version.
Ty. I saw your commit also.
That's the plan. For code to decide later if it should apply them.
I now wonder if the RAM will still be able to retain it's contents after a forced reboot to RCM.
CLK_RST_CONTROLLER_RST_DEV_H_CLR is basically a major bugfix and a big oversight from nintendo.
I normally use that a lot to dump the whole ram after a HOS session.
(I may add a CONFIG_EMC_MC_NO_RESET, depending on the results.)
What about configuring carveouts via a conf file so they can be updated without distributing a new hekate.
Because there's no need for that bloat. Reading dram after a reboot in rcm, already needs a custom hekate (that dumps it and access the upper ram) and it's only for development purposes.
Most helpful comment
Bringing the necessary changes for fixing the HDCP issue over here:
This issue has been fixed in Atmosph猫re by removing all carveout configuration from Fus茅e (which only works due to Exosph猫re doing it instead), but since Hekate is designed to be a general purpose bootloader, it should be necessary to configure the carveouts differently on each firmware version.