The Disk Utility should be able to do that. If Mac OS can't create a NTFS partition, you can also create an exFAT one, it should have the same ID as NTFS
If we had the keys form the otp, we could recrypt another SLC for this console. But everything on the SLC and MLC would be lost. So we would need the correct files for the devkit or whatever this is.
No uncorrectable ECC errors... that is untypical for SLC corruption... Maybe it ha a messed up system.xml but this doesn't look like the typical a SLC page became bad and corrupted the fw.img problem.
If you sent me the SLC and a list of the the ECC errors during the dump I can see which files are affected, so we could narrow down if it is SLC corruption or bad DRAM.
We could also run the memtest to see if the DRAM is good.
1715807735
Don't restore the SLC yet, because with that we would...
hm yeah the versions look wrong, so the decryption probably failed. On the other hand the versions look close together, so maybe not? Very strange.
That is a standard retail console? What board revision does it have?
you should not write the backup back. Just flash the boot1.raw backed up from another console and then it should prompt you to update the bboot1 version in the seeprom. If it fais at that I have to see if I can decrypt the seeprom and looks at how minute veriefies the seeprom. Do you have the...
Yes some 4GB sdcard that was even 10 years ago old and it looked like it just was the cheapest at the time.... Everything has a limited life span, I also have a stack of dead HDDs. I had a higher class 32GB Samsung card in my phone for years and ran Android from that, which is much heavier than...
There are two copies of the the boot1 on the SD. Did it reject to write the seeprom? Then you should be good.
What is the attached seeprom? A freshly dumped one?
Was it a refurbished console or something like that or really brand new? If it was new, then it is likely the firmware is to old for UDPIH and you would need to defuse, which also requires the pico but also some soldering