Difference between revisions of "eFuse"
(Fix grammar) |
(Removed table copied from Wiibrew, added new info with sources) |
||
| Line 1: | Line 1: | ||
{{DISPLAYTITLE:eFuse}} | {{DISPLAYTITLE:eFuse}} | ||
| + | {{Template:Wikipedia|https://en.wikipedia.org/wiki/eFuse}} | ||
| + | |||
| + | On Nintendo consoles, '''eFuse'''s are used as irreversible data storage for keeping values which are set while the chip is being manufactured and will never be updated again. They are mostly used to store information which is sensitive and cannot be changed for security purposes. | ||
| + | |||
| + | == Wii == | ||
<span style="background: #F1EBEB; border: 2px #CACACA solid; padding: 2px 1px 2px 4px;"> | <span style="background: #F1EBEB; border: 2px #CACACA solid; padding: 2px 1px 2px 4px;"> | ||
[[File:Wii.png |30px]] This topic has a Wiibrew article. For more information, check [https://wiibrew.org/wiki/Hardware/OTP here].</span> | [[File:Wii.png |30px]] This topic has a Wiibrew article. For more information, check [https://wiibrew.org/wiki/Hardware/OTP here].</span> | ||
| − | The | + | In the Wii homebrew community, the term "OTP" (one-time programmable) is usually used to refer to the console's eFuses. Official documentation & code uses the "eFuse" name. |
| + | |||
| + | The Wii has 128 bytes of eFuses within the [[Hollywood]] package, which all have a default value of 0. The final byte of the eFuses, which reverse engineering efforts were unable to document, has been revealed by leaked documentation to be used for toggling certain debugging features.<ref>[[emeralds.7z]]/doc/hw/chip/vegas_clocks_resets.doc - pg 44</ref> | ||
| + | |||
| + | Bits 4-7 of the final eFuse byte each have a function: | ||
| + | |||
| + | Bit 4 - when set, disables trace | ||
| + | |||
| + | Bit 5 - when set, disables debug boot (booting directly from [[EXI]] as done on the [[GameCube]], rather than through the [[IOP]]) | ||
| + | |||
| + | Bit 6 - when set, disables scan | ||
| + | |||
| + | Bit 7 - when set, disables JTAG | ||
| + | |||
| + | Retail consoles typically have everything disabled except for trace, resulting in a byte value of 0x7. | ||
| − | + | An [[NDEV]] 2.1 prototype was observed to have everything enabled except for debug boot, resulting in a byte value of 0x4. It is unknown if this value is used in other NDEV revisions or other development consoles. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | All NDEVs have a blank [[boot1]] hash in their eFuses. This makes boot1 updateable on NDEVs, and in theory it could be replaced with homebrew as there is no other verification. [[boot0]] checks the integrity of boot1 by ensuring that it matches the hash stored in eFuses, but it will skip verification if the hash is blank.<ref>[[unsorted.7z]]/d1/routefree/ng/depot/sw/rvl/boot/boot0/bootc.c - loop at line 458 enables verification only if the hash is not blank</ref> | |
| − | |||
| − | + | The Wii's eFuses are normally programmed (or "cut") during production of the Hollywood package. They cannot be programmed afterwards on most systems, as the only mechanism to do so is through the JTAG, which is locked out by the eFuses on retail consoles.<ref>[[emeralds.7z]]/052306/doc/hw/chip/vegas_datasheet.doc - pg 20</ref><ref>[[emeralds.7z]]/052306/hw/sys/jtag/jtag_bfm.v - has code to cut an eFuse at line 655</ref> | |
| − | + | {{Template:WiiNavbox}} | |
[[Category:Wii]] | [[Category:Wii]] | ||
[[Category:Hardware]] | [[Category:Hardware]] | ||
Revision as of 08:33, 16 September 2021
This topic has a Wikipedia article. For more information, check the article.
On Nintendo consoles, eFuses are used as irreversible data storage for keeping values which are set while the chip is being manufactured and will never be updated again. They are mostly used to store information which is sensitive and cannot be changed for security purposes.
Wii
This topic has a Wiibrew article. For more information, check here.
In the Wii homebrew community, the term "OTP" (one-time programmable) is usually used to refer to the console's eFuses. Official documentation & code uses the "eFuse" name.
The Wii has 128 bytes of eFuses within the Hollywood package, which all have a default value of 0. The final byte of the eFuses, which reverse engineering efforts were unable to document, has been revealed by leaked documentation to be used for toggling certain debugging features.[1]
Bits 4-7 of the final eFuse byte each have a function:
Bit 4 - when set, disables trace
Bit 5 - when set, disables debug boot (booting directly from EXI as done on the GameCube, rather than through the IOP)
Bit 6 - when set, disables scan
Bit 7 - when set, disables JTAG
Retail consoles typically have everything disabled except for trace, resulting in a byte value of 0x7.
An NDEV 2.1 prototype was observed to have everything enabled except for debug boot, resulting in a byte value of 0x4. It is unknown if this value is used in other NDEV revisions or other development consoles.
All NDEVs have a blank boot1 hash in their eFuses. This makes boot1 updateable on NDEVs, and in theory it could be replaced with homebrew as there is no other verification. boot0 checks the integrity of boot1 by ensuring that it matches the hash stored in eFuses, but it will skip verification if the hash is blank.[2]
The Wii's eFuses are normally programmed (or "cut") during production of the Hollywood package. They cannot be programmed afterwards on most systems, as the only mechanism to do so is through the JTAG, which is locked out by the eFuses on retail consoles.[3][4]
- ↑ emeralds.7z/doc/hw/chip/vegas_clocks_resets.doc - pg 44
- ↑ unsorted.7z/d1/routefree/ng/depot/sw/rvl/boot/boot0/bootc.c - loop at line 458 enables verification only if the hash is not blank
- ↑ emeralds.7z/052306/doc/hw/chip/vegas_datasheet.doc - pg 20
- ↑ emeralds.7z/052306/hw/sys/jtag/jtag_bfm.v - has code to cut an eFuse at line 655
