iPatched compatibility

[yoboto]

Either the fw files produced by EmmcHaccGen are not compatible with ipatched boards or the systemRestore.te script isn't or there is possibly some form of modchip interference?

attempted to downgrade an ipatched switch to FW version 6.1 with valid keys from lockpick (confirmed valid by decrypting PRODINFO, USER partition etc in NXNandmanager)

after running systemrestore script and after boot Tegraexplorer throws an error about mounting EMMC...presumably because it doesn't have the keys.

then when going into Hekate and dumping CAL0 it complains it is not valid and does not produce SBK whereas before systemrestore they were valid,

feels like a write at incorrect offset issue..... but then i am clueless on this subject.

If i can be of help in any way for testing purpopes then would be happy to.

Btw thanks for all the effort you put into your tools :)

[suchmememanyskill]

Ipatched boards are indentical to non-ipatched boards, just with the bootrom code being different, so that likely is not an issue.

Sounds like something odd is happening with boot0, as that's all that is used to derive the biskeys. I'm assuming you're getting a failed to derive biskeys error after using systemrestore.te and re-booting tegraexplorer. I haven't done anything to support ipatched/mariko switches on TE's side, so i wouldn't trust it to "just work" with an entirely different entrypoint.

Might be worth to try flashing back the files the old way, what i mean by that is to mount boot0 via usb inside hekate (turn read only off first), and flash back boot0.bin using etcher (i'm not sure if you're using caffine or a modchip here, i'm assuming the modchip, as you want to downgrade to 6.1, while caffine only works on 4.1. And afaik, that modchip uses boot1 to store some stuff so it probably isn't smart to overwrite that, unless you're using an emu. If you are using an emu, you can flash boot1.bin back the same way as boot0, just with selecting boot1 in hekate first). Then, mount the gpt section, and open it in hacdiskmount, and flash back all bcpkg2's that emmchaccgen generates. Then mount system (insert the biskeys, verify biskeys, install driver, mount), and copy everything inside the generated system folder into there. If i didn't forget anything, this is the exact same procedure as systemrestore.te, just not automated.

[yoboto]

Thanks for your detailed reply,

Yeah I'm using a modchip, reason for the 6.1 FW restore is i suspect bad boot0/1 partition data, for whatever reason i can boot Stock and CFW no problem via SX/Hekate with original FW 9.0.0 nand backup or the attempted FW 11.0.0 daybreak install i tried, but it will not "genuine boot" as the SX boot menu calls it, or boot with the EMMC module back in original connector just a black screen no nintendo logo. Symptoms are similar to FW/Fuse mismatch

I figured if there was an issue with the boot files/partitions and that downgrading back to 6.1 with EmmcHaccGen generated files and re-upgrading to FW 11 after to match my 14 burnt fuses might resolve the issue, no interest in keeping the modchip installed here, just using it to try and resolve these issues.

Pressumably downgrading to 4.1 and using caffine would still require the modchip to be present afterwards?

Thanks for the info, i will give mounting within hekate a try and follow those steps.
I have done them a few times before on an unpatched board successfully so fingers crossed :)

Thanks again.

I'll just add, with the original FW9.0.0 or FW11.0.0 valid nand (or semi valid in this case) installed, in order for Hekate to display the correct SBK after dumping CAL0 it is neccessary to first launch either the tegraexplorer payload or the lockpickRCM payload from the SX boot menu and then afterwards exit back to Hekate, it seems only then does hekate display the correct SBK following the CAL0 dump

If this step isn't done and hekate is launched directly from the SX boot menu then after a CAL0 dump the SBK remains emty (all FFFF) don't know if that means anything to you?

[suchmememanyskill]

Unsure about the sbk, honestly. I don't know much about the sx core

Also, why exactly are you downgrading then upgrading anyway? Emmchaccgen supports 11.0.1 (at least i think. Last time i tested it with was 10.2.0).

Also, might be worth adding me on discord (Such Meme, Many Skill#2921 would be my tag)

[yoboto]

Oh it's just force of habit from back when using ChoiDujour to generate the files, never had any luck with FW files lower than FW ver 6 and > than FW ver 9+ using ChoiDujour . Most of the systems at that time were on FW/burnt fuse ver 9+ and required the downgrade and then upgrade on the system itself.

Emmchaccgen supports 11.0.1 (at least i think. Last time i tested it

Ah didn't realise, good to know, will generate the files like this from the off then, thanks

Also, might be worth adding me on discord (Such Meme, Many Skill#2921 would be my tag)

Not currently a member but will sign up, thanks again

[yoboto]

I did try the manual method and mounting the partitions from within Hekate.

First tried with the FW 11.0 generated files by EmmcHaccGen, first without altering/writing boot0/1 to the EMMC which didn't work, then trying again and using the EmmcHaccgen generated boot0/1 (with the auto RCM flag disabled using NXNandManagaer) and didn't seem to work either, just shows the first Nintendo logo then black screen.

Tried the usual stuff, clearing the system partition before putting the EmmcHaccGen system files on, did the same with the user files, no change, then tried to format the user partition and leave it empty and no change unfortunately.

Repeated the manual process but with FW ver 9.0.0 generated files and tried both with the emmchaccgen boot0/1 and with my original boot0/1 from my original FW 9.0 nand backup and in both cases it had the same symtoms, nintendo logo then black screen.

Restored my FW 9.0.0 Nand backup and i am able to boot stock/CFW again from hekate or SX boot menu.

Don't know if these means much but HacDiskMount gave the following warning when opening the main partition, Primary and secondary GPT are both valid but are different, which would you like to use. In both cases i selected primary. I don't recall seeing this message before when doing this process on other consoles.

Maybe the partition structure is bad, but to my untrained eye they all appear to be of the correct size,.

Maybe the modchip is causing an issue here and i should put the EMMC module on an unpatched board and repeat the process, Though as far as I'm aware, the modchip only modifies boot 0, peforming a "cleanup" in the SX boot menu restores boot 0 data back to it's original state until next boot where it will then re-modify it.

[suchmememanyskill]

if it shows the nintendo logo it at least is getting past boot0/1 and bcpkg2, but something seems amiss then with SYSTEM. are you using this console's prod.keys? (you need to in order to generate a valid 120 system save to at least see the nintendo logo)

Also, it's probably worth messing me directly via discord. talking via issues is a little annoying imo