Hacking [RCM Payload] Hekate - CTCaer mod

[CTCaer]

And when this 3.0.0 is planned ?
if it released it will be RCM-less ?

When I iron out some bugs. And also multitest the recovery options.

RCM-les? no.. It doesn't work like this

 

[Deleted_444986]

When I iron out some bugs. And also multitest the recovery options.

RCM-les? no.. It doesn't work like this

ok i understand autoboot is like sx os boot immediately if no button pressed .
what's the recovery option ?

 

[tecfreak]

what's the recovery option

Writing nand backups?

 

[Deleted User]

Deleted

 

[coned_miro]

When I iron out some bugs. And also multitest the recovery options.

RCM-les? no.. It doesn't work like this

Would it be advisable to use the hacky method of getting exFAT support on the lower firmwares [3.0.2 in my case] to do proper NAND / etc dumps to 32GB+ microSD cards in preparation for Atmosphere? I tried the 2-GB piece-meal method but for some reason am weary of the results...

Is there a way to verify I got proper dumps??

 

[BelmontSlayer]

Would it be advisable to use the hacky method of getting exFAT support on the lower firmwares [3.0.2 in my case] to do proper NAND / etc dumps to 32GB+ microSD cards in preparation for Atmosphere? I tried the 2-GB piece-meal method but for some reason am weary of the results...

Is there a way to verify I got proper dumps??

If you're using CTCaer's hekate it will verify the dumps with a green progress bar. You can also dump your bis keys and use HacDiskMount to verify your dump.

 

[CTCaer]

Would it be advisable to use the hacky method of getting exFAT support on the lower firmwares [3.0.2 in my case] to do proper NAND / etc dumps to 32GB+ microSD cards in preparation for Atmosphere? I tried the 2-GB piece-meal method but for some reason am weary of the results...

Is there a way to verify I got proper dumps??

Hekate has built-in exFAT support. You don't need the exFAT micro update for this. The micro update is needed only in Horizon.
So format your sd card to exfat, make the backup in hekate and reformat to fat32.

If you're using CTCaer's hekate it will verify the dumps with a green progress bar. You can also dump your bis keys and use HacDiskMount to verify your dump.

Unfortunately, yesterday when I was fixing some more bugs around, I found out that the verification is not working.
Not only that, but with working verification, the process of backing up rawnand.bin, takes 4.5hours more. And this is fixed time, so sd card speed does not matter.
(Check comment here)

I'm trying to find a way though.

 

[tecfreak]

@CTCaer
So the memcmp is the slowing down part.
Maybe using a hashing algorithm like xxhash would be faster?

 

[CTCaer]

@CTCaer
So the memcmp is the slowing down part.
Maybe using a hashing algorithm like xxhash would be faster?

It was broken though. But if you had mostly empty eMMC it would continue to check because of the 00s.

I don't think that any hashing algo is faster than an arch optimized memcmp without hardware acceleration support.
Don't forget that BPMP is ARM7 (armv4t instuction set) with no special acceleration.

But I'll try this hash algo and update my comment in the fix commit I linked.
(I've also made a sparse memcmp that checks 4bytes every 128Bytes blocks. But I'll probably change it to a 512byte blocks because if something goes wrong, it will probably happen at a diskio 512B block level.)

 

[tecfreak]

@CTCaer
So probably the fastest and most reliable way for vrification would be to utilize the CCPLEX for this task instead of the BPMP. But the CCPLEX is out of reach with the current state of hekate, right?

 

[CTCaer]

@CTCaer
So probably the fastest and most reliable way for vrification would be to utilize the CCPLEX for this task instead of the BPMP. But the CCPLEX is out of reach with the current state of hekate, right?

It's not out of reach. It's how you launch HOS actually. You enable CCPLEX and let it run secmon and then you give control to it with the FLOW register.

But this will imply a secondary payload that runs this code and then gives control to BPMP again and then you must trigger a CCPLEX power down also.

 

[arnoldcoolful/aKMTR]

Hey
So after a while of using hekate
I decided to launch another switch game and it instead crashed my entire switch.
Any reason why that happens?

 

[masamune19]

Could you make the payload to autoclean logs before start any firmware? (cfw, layered compatibily or ofw)

 

[riyyi]

@CTCaer Something to add to CTCaer mod v3.0?
https://github.com/crystalseedgba/BatteryFix/commit/5b1aa3bc39c70485687c8730b75640ec39964e07
The thread of this release:
https://gbatemp.net/threads/fix-for-linux-battery-issue.508715/

 

[tecfreak]

@CTCaer Something to add to CTCaer mod v3.0?
https://github.com/crystalseedgba/BatteryFix/commit/5b1aa3bc39c70485687c8730b75640ec39964e07
The thread of this release:
https://gbatemp.net/threads/fix-for-linux-battery-issue.508715/

He already has a solution for the battery desync problem:
https://github.com/CTCaer/hekate/commit/52506def30d2ea18ce4ccad3546567fa082cfc2f

 

[riyyi]

He already has a solution for the battery desync problem:
https://github.com/CTCaer/hekate/commit/52506def30d2ea18ce4ccad3546567fa082cfc2f

Ah, I thought he must have found it somewhere. An user with 1 post isn't gonna release something of that complexity.

 

[CTCaer]

Hey
So after a while of using hekate
I decided to launch another switch game and it instead crashed my entire switch.
Any reason why that happens?

Care to explain your configuration?
I never had any problems.

Could you make the payload to autoclean logs before start any firmware? (cfw, layered compatibily or ofw)

It does not work like this.
If you want this, just add the nx-dreport kip configuration key to your every boot entry.

Ah, I thought he must have found it somewhere. An user with 1 post isn't gonna release something of that complexity.

His work is independent. Because I only told to my test group, that this is a possible solution, but I never gave them the source code.
Also the datasheets are online for anyone that wants to research:
http://www.ti.com/lit/ds/symlink/bq24193.pdf

 

[tecfreak]

Ah, I thought he must have found it somewhere. An user with 1 post isn't gonna release something of that complexity.

Nope, it looks like his very own solution/workaround and has nothing to do with CTCaer's his code.

 

[CTCaer]

Nope, it looks like his very own solution/workaround and has nothing to do with CTCaer's his code.

This ^



Btw, @tecfreak I've added a memcmp sparse derivative.
This checks 4 bytes every 128 byte blocks.

It's a alternative, because normally problems happen at diskio and fatfs level. And the blocks are 512 bytes and clusters are 32KB+
So this can catch most corruption problems. The default will probably be this. With the added options to disable it completely or have a full check that can take 4.5 hours.

I also tried to "overclock" (not exactly overclock, bc it was inside nvidia's operation limits) the BPMP, but it did almost nothing to the performance..

 

[tecfreak]

a full check that can take 4.5 hours.

I'm not sure, but maybe xxhash would be faster in generating the two hash values needed for comparison than a memcmp on these two 4MiB buffers.

 

[CTCaer]

I'm not sure, but maybe xxhash would be faster in generating the two hash values needed for comparison than a memcmp on these two 4MiB buffers.

nwert told me that SE will probably be extremely fast because it seems to run on ram's clocks.
I'll try and implement it.

 

[tyler004]

so is there a download for the battery fix or not yet?