Brick

From PSP Developer wiki
Revision as of 01:43, 24 November 2023 by Alexvlad3118 (talk | contribs) (→‎Inproper IDStorage Keys)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

A brick refers to a status of an electronic device that is inoperable due to corruption of one or more of its vital components needed for operation. In most cases, bricks are usually results of an incomplete firmware. In the case of the PSP, bricks can occur within the nand, usually in either firmware, or IDStorage Keys.

Causes/Types of Bricks

Bricks can caused by many user errors mainly in the firmware.

Firmware (flash0) bricks

A firmware brick can occur as a result of a flash0 error. This can occur in the following:

  • Loss of power during flashing operations.
  • Loss of power during updating.
  • CRC error during flashing via computer.
  • No free space in flash0 during operations.
  • Flashing operation failing.
  • Corruption within flash0.


The pre-Pandora period made recovery from a firmware brick near to impossible. If the user was on official firmware, the only other method was to service the PSP and replaced the current motherboard with a completely new one. However, this method voided all warranties. On custom firmwares, if the firmware brick was a semi-brick, a user can use the recovery menu to flash 1.50 to their firmwares, and then re-install the custom firmware. However, if the firmware brick resulted in a full brick, the only two options available was to replace the motherboard or send it in to Sony and hope that they would service it.

However, any Pandora install can successfully reflash the firmware, therefore restoring the PSP to normal usage.


Inproper IDStorage Keys

Bricks as a result of IDStorage Keys are more uncommon. However, with the rise of downgraders, and homebrew such as KeyCleaner, bricks of this type has came up. These types of bricks are caused by:

  • Improper IDStorage degeneration (In which can the values of the IDStorage keys are incorrect)
  • Incorrect or Empty IDStorage (In which the IDStorage keys were flashed from another PSP, or was deleted)
  • Unnecessary corruption of IDStorage Keys (Corruption of keys that aren't necessary for operation)

Corruption within IDStorage didn't necessary cause bricks, but it lead to certain features of the PSP acting up or just failing to operate. However, if the damage was severe enough, the PSP can be rendered unbootable. If a user was lucky enough to have a backup of their nand or IDStorage Keys, this can be simply fixed by running an application on the PSP that can restore the keys to their correct and/or default values. However, if the PSP was to the point of a brick, the only way possible was to replace the motherboard or restore via Pandora Battery. However, if no backup was present, the last-resort effort would require a user to flash IDStorage keys that did not originate from that user's PSP. This method worked in most cases. However, the user will suffer a loss of Adhoc and UMD compatibilities. (Which in turn was not cureable even if the WiFi card/UMD Drive was replaced)

Missing or Incorrect IPL

Resulting in a full brick, if the ipl was missing or incorrect in the nand, the PSP will fail to boot. Usually, the ipl cannot be restored without the use of a Pandora Battery or replacement of the motherboard. With a Pandora Battery, and with Cory's nand tool, a user can take a backed up nand, and write the ipl to the nand so that the PSP may boot again. However, if the ipl was not compatible with the firmware, the PSP will still remain bricked. An alternative method to this was to full restore a backed up nand to the nand chip.


Symptoms of Bricks

With all types of bricks, signs can reveal what type of brick exists after flashing operation. Bricks can be diagnosed further depending on the reaction from the internal GPIO/Watchdog system.

Semi-Brick

Semi-bricks occur from one of the three types of bricks depending on where the fault lays. A semi-brick is differentiated from a full brick when a user is able to boot into the recovery menu. All semi-bricks are recoverable since a user has access to flash0 (over USB), and they can launch a recovery EBOOT which reflashes the 1.50 firmware. (Phats Only)

Full Brick

Full bricks can occur from all three types of bricks but it specifically lies within the ipl in the nand, or the firmware. (More specifically with 'opening_plugin.rco' or other files that controlled how the PSP booted). A full brick can be verified if the PSP cannot boot into recovery, and when it fails to boot when left alone.


GPIO/Watchdog System

The GPIO/Watchdog System exists on all motherboards and PSPs to date. The GPIO/Watchdog system controls on how the PSP boots when it is bricked. Two outcomes may occur:

  • The Watchdog system can shutdown the PSP after 20 seconds after boot.
  • The system makes an infinite loop trying to boot. This will occur until the battery dies out or it is taken out of the system. This only occurs when there are the conditions for a boot are not met.

Depending on what the Watchdog system does determines what the severity and possible cause of the brick. If the system shutdowns after 20 seconds, there is an incomplete firmware that is in flash0. The only ways to fix this are via Pandora Battery, or the Recovery Menu. (Semi-brick)

If the system continues the 20 second loop, one or more conditions are missing that are necessary for the PSP to boot. This can range anywhere from the corruption of the IDStorage keys (Key 5 on TA-082/086 motherboards only) or the ipl. Usually, the loop indicates a full brick in which is only recoverable with Pandora or a motherboard replacement.

See Also

Motherboards - Motherboards of the PSP
Recovery Methods - Methods of recovering from a brick

Retrieved from "http://www.psdevwiki.com/psp/index.php?title=Brick&oldid=12205"