Interested in investing time and money into PSXHAX.COM? Read More and Contact Us for details!
Category PS4 Help       Thread starter Thread starter engineer       Replies 4      
Status
Not open for further replies.

engineer

Member
Verified
Hi,

I have a backup of the HDD, NOR (sflash) and syscon chip from a fat PS4 with FW 8.50/8.03 (Active/Inactive).

Case #1
Say I update to 10.0 (USB). So now I'm at 10.00/8.50 (Active/Inactive).

I am aware that I can revert (old or newer revert method) to FW 8.50. Then, I would have the option to update to any FW >= 8.50. Or, stay at 8.50.

What I'd like to know is, if I choose to not revert, but rather write back the 8.50/8.03 back-ups (HDD, NOR, and syscon chips). Would that essentially undo the 10.0 FW update, and restore everything to the initial state of FW 8.50/8.03?

Case #2
Say I update the now 10.00/8.50 (Active/Inactive) PS4 to 11.00 (online). So now the PS4 is 11.00/10.00 (Active/Inactive). Would writing back the 8.50/8.03 back-ups (HDD, NOR, and syscon chips) undo the 10.0 and 11.0 FW updates, and restore everything to the initial state of FW 8.50/8.03?

Simply put, with a matching trio of backups of HDD, NOR and syscon, would writing (back to the PS4) any of these trio of back-ups from past date x, restore the PS4 to this back-up FW state from past date x? Or, are there other locations/efuses that would limit us to only switch back to either of the two latest (on-console) active/inactive FW states?

CUH 1001A, SOP16 NOR (MX25L25635FMI-10G), and 100-pin (R5F100PLAFB) syscon IC. All original components.

Cheers
 
Solution
To answer my own question, yes you can.

I have a fat 8.50/8.03 (active/inactive) unit which I backed-up all three of syscon, sflash (NOR) and HDD (I'll refer to them as the trio). Then I updated (USB) this PS4 to FW 9.00/8.50. Power-cycled and all. Then I took a back-up of the 9.00/8.50 trio. Then I wrote back the 8.50/8.03 back-ups to the trio. PS4 booted fine and all. Did an online FW update to 11.02/8.50. Power-cycled, synced with PSN, etc... Then I took a back-up of the 11.02/8.50 trio. Then I wrote back the 9.00/8.50 trio. Again booted and everything is fine. Then I wrote back the 8.50/8.03 trio. Again everything is fine. Then I wrote back the 11.02/8.50 trio back, and again everything is fine.

In short, as long as you have...
If you haven't yet, try reaching out to @BwE on Twitter about these questions.. he hasn't been on the forum for a few years, but would likely know the answers as console repairs are part of his profession. 🏆

If anyone else can lend a hand feel free to jump in, and the psdev wiki also contains loads of information if you have the time to research it all of course. :geek:
 
To answer my own question, yes you can.

I have a fat 8.50/8.03 (active/inactive) unit which I backed-up all three of syscon, sflash (NOR) and HDD (I'll refer to them as the trio). Then I updated (USB) this PS4 to FW 9.00/8.50. Power-cycled and all. Then I took a back-up of the 9.00/8.50 trio. Then I wrote back the 8.50/8.03 back-ups to the trio. PS4 booted fine and all. Did an online FW update to 11.02/8.50. Power-cycled, synced with PSN, etc... Then I took a back-up of the 11.02/8.50 trio. Then I wrote back the 9.00/8.50 trio. Again booted and everything is fine. Then I wrote back the 8.50/8.03 trio. Again everything is fine. Then I wrote back the 11.02/8.50 trio back, and again everything is fine.

In short, as long as you have matching FW back-ups of all three of syscon, sflash (NOR) and HDD, you can switch back and forth to any FW you have a back-up of.

I didn't need to change/modify any addresses in any of the binary images.

Cheers.
 
Solution
Hi,

For those whom are not able to get consistent NOR dumps on-board, I have found a few alternative solutions. Three of the alternatives are to lower Vcc even further!

Powering-up (3.3V) the NOR/S-Flash while the chip is still soldered on-board the PS4 would also power-up other chips. Some of these chips may also be trying to communicate with the NOR/S-Flash chip. This leads to inconsistent reads/dumps from the NOR chip.

The most common recommendation is to remove the NOR chip off-board, then read it using a programmer (Teensy++ 2.0, CH341A, etc...). I have done this, and it works well.

Another common recommendation is to provide a lower Vcc. Something in the range of 2.7V – 2.8V. There are different ways to achieve this. The idea is to lower the voltage going to the NOR chip (Vcc soldered to the board) with the hope that the other chips won’t power-up at ~2.7V. Thus, allowing the NOR chip to be read/dumped consistently. This solution didn’t work for me. I was using a Teensy++ 2.0. I was not getting consistent reads.

After some tinkering...

PSA: PS4 - Alternative Solutions for Consistent On-Board NOR Read/Writes

Alternative solution #1:

Use an external variable power supply to provide power to the on-board NOR chip, instead of the Vcc from the Teensy++ 2.0. That is, all the IO signal pins from the on-board NOR chip would connect to the Teensy++ 2.0, while the power and ground pins from the on-board NOR chip would connect to the external power supply. In my case, Vcc of 2.55V worked for me. 2.50V and 2.40V also worked for me. I didn’t try lower than 2.4V. Vcc of 2.6V – 2.8V didn’t work for me.

While having this setup connected to the external variable power supply, I noticed that with Vcc 2.60V and higher, the idle current was ~24mA (from the external power supply). While with Vcc of 2.58V or lower the idle current was ~15mA. This meant that with Vcc of 2.58V or lower, other chips were not getting powered-up. Taking a few reads from the on-board NOR chip at 2.55V and 2.40 got me consistent reads, which matched off-board NOR dumps as well.

If you are using the Teensy++ 2.0 to also communicate with the syscon chip, make sure that no other VCC is going from the Teeny++ 2.0 (or any other programmer) to the board. The only source of power (Vcc) to the board should be coming from the external variable power supply, so you can lower the Vcc to a range that works for you.

The datasheet of the NOR chip states that Vcc min is 2.7V. While, the NOR chip powers-up and reads/writes fine with Vcc as low as 2.4V. Operating the chip outside the spec may lead to unpredictable behavior. It may have worked for me, but may not for others. It may work now, but not in the future, etc...

In addition, the NOR chip VIH IO signal voltage level gap is Vcc+0.4 max (from the NOR chip MX25L25635F datasheet). That is, if NOR Vcc is 3.0V, then the VIH IO levels (into NOR) should be 3.4V max. With the Teensy++ 2.0 3.3V voltage regulator mod, the IO signals going out into the NOR would be 3.3V. So (external) VCC into NOR should be min 2.9V. Again, anything outside of this would be violating the spec, which could work, but may lead to unpredictable behavior, etc...

In my case, I had my Teensy++2.0 voltage regulator mod using a 2.8V regulator (instead of 3.3V). The Atmel (AT90USB1286) on-board the Teensy++ 2.0 has a Vcc Range of 2.7V-5.5V.

Alternative solution #2:
Instead of using the 3.3V voltage regulator mod on the Teensy++ 2.0, use a 2.8V regulator instead. Then you can add some resistors at the output Vcc of the Teensy++ 2.0 (going to on-board NOR Vcc) to bring the voltage down further to a range that works for you (similar to resistors being used to bring the Teensy++ 2.0 from 3.3V to ~2.7V). I have not tested this method.

Alternative solution #3:
Use a programmer like CH341A (clone). I have purchased a green version which allows the control of Vcc (and IO signal) level: 1.8V, 2.5V, 3.3V, and 5V. For our needs we only need 2.5V or 3.3V. For off-board NOR read/writes, 3.3V worked for me. And for on-board NOR read/writes, 2.5V worked for me. For on-board NOR read/writes, obviously you would need to wire-up the on-board NOR to the CH341A programmer (Similar to what you would do with a Teensy++ 2.0).

Alternative solution #4:
This method is easier for on-board NOR chip in SOP packages. Basically, lift the Vcc pin of the on-board NOR chip, and connect only the lifted Vcc pin to Vcc on Teensy++ 2.0 (or an external power supply). All other on-board NOR pins should be left as-is, and have them connected to the matching pins on the Teensy++ 2.0. The Teensy++ 2.0 should have the regulator mod on it (either 3.3V or 2.8V).

While I have not tested this method, it should work. Since by lifting the on-board NOR VCC pin, and connecting an external Vcc to only this lifted NOR Vcc pin, you are giving power only to the on-board NOR chip. Nothing else on the PS4 board will power-up. Thus, nothing will communicate with the NOR chip, which is what causes inconsistent dumps (provided all the connections are correct and good).

If you are going to do the switch between regular and jailbroken method swapping drive/NOR/SYSCON images, it would be recommended to keep the NOR pin lifted permanently. Just solder a small wire to the lifted Vcc pin. And another small wire to the NOR Vcc pad, which you lifted the Vcc pin off of. This way, you can short the wires to have regular Vcc going into the NOR chip. Or, separate the wires, to connect the lifted Vcc pin to external power supply, or Teensy++ 2.0 for NOR read/writes.

For consoles with the WSON NOR package... Well... it’s doable... I guess. If you manage to remove the WSON NOR package, solder a small wire to the Vcc pad. Put a small piece of electrical tape on it. Then solder a small wire the Vcc pin on the WSON NOR package. This way, when you solder the WSON NOR chip back on the board, you would have isolated the Vcc pad from the Vcc pin of the NOR chip, while still having the small wires which you can short for normal use, etc... If you managed to de-solder the WSON NOR chip, use this opportunity to read it while it’s off-board. You may even want to consider buying an SOP version, and use that one instead. You’ll have to solder the WSON pads on the PS4 boards to some small wires, which would go to the new SOP NOR chip pins, then use some adhesive to secure everything.

And of course, the PS4 should be powered-off for al NOR/SYSCON read/writes.

I’ve tried to give enough (but not too much) details to give people an idea of these alternates. Hopefully this helps some.

Cheers
 
Status
Not open for further replies.
Back
Top