Editing Dual Firmware
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 1: | Line 1: | ||
[[Category:Hardware]] | |||
These methods are currently theoretical and have not been tested as of yet. | |||
= Hardware Based = | = Hardware Based = | ||
== NOR/Nand Piggybacking == | == NOR/Nand Piggybacking == | ||
This method involves physically soldering another flash chip ontop of the existing flash packages, soldering the legs pin for pin ( | This method involves physically soldering another flash chip ontop of the existing flash packages, soldering the legs pin for pin (piggybacking). You will lift both #CE pins and provide a switch between them to select the appropriate flash chip, of which each will have a different firmware. | ||
E.g.: http://www.elotrolado.net/hilo_la-dual-nand-fat40g-ya-es-una-realidad_1650176 | E.g.: http://www.elotrolado.net/hilo_la-dual-nand-fat40g-ya-es-una-realidad_1650176 | ||
=== Reset pin for NOR === | === Reset pin for NOR === | ||
| Line 13: | Line 14: | ||
After looking into this some more, Simply switching the #CE pin may not be sufficient as the chip is still operating and can interfere with the bus. | After looking into this some more, Simply switching the #CE pin may not be sufficient as the chip is still operating and can interfere with the bus. | ||
However, it appears that whilst the #reset pin is tied low, all input/output pins on the flash are in a state of high-impedance. We should be able to simply ground this pin to disable that chip, rather than lifting the #CE pin. | However, it appears that whilst the #reset pin is tied low, all input/output pins on the flash are in a state of high-impedance. We should be able to simply ground this pin to disable that chip, rather than lifting the #CE pin. | ||
== Dual-Banking == | == Dual-Banking == | ||
This method relies on the fact that SYSCON has 2 EEPROM banks, and a "recovery mode" flag that can be set to load a recovery firmware located in the | This method relies on the fact that SYSCON has 2 EEPROM banks, and a "recovery mode" flag that can be set to load a recovery firmware located in the ros1 region of the flash. | ||
By pulling the backup_mode pin low or high, you can aparently switch eeprom banks in the SYSCON EEPROM. In the second bank, you would have the recovery mode flag set, thus loading firmware from the | By pulling the backup_mode pin low or high, you can aparently switch eeprom banks in the SYSCON EEPROM. In the second bank, you would have the recovery mode flag set, thus loading firmware from the ros1 region on flash. | ||
== Increased size NOR Flash == | == Increased size NOR Flash == | ||
This method relies on entirely lifting the existing NOR flash chip and planting a 256mbit chip, you could lift Address pin 23 and have a switch to tie this low or high to switch banks. A compatable samsung | This method relies on entirely lifting the existing NOR flash chip and planting a 256mbit chip, you could lift Address pin 23 and have a switch to tie this low or high to switch banks. A compatable samsung chip can be found below: | ||
http://www.samsung.com/global/system/business/semiconductor/product/2007/8/7/620430ds_k8p5615uqa_rev11.pdf | |||
This looks like it could work, as per the spansion and samsung charts, when using autoselect commands etc, it does not care about the state of pin 23. So there should not be any interference. | This looks like it could work, as per the spansion and samsung charts, when using autoselect commands etc, it does not care about the state of pin 23. So there should not be any interference. | ||
== Limitations == | == Limitations == | ||
=== Firmware hash checks === | === Firmware hash checks === | ||
Firmware hash checks are located on SYSCON EEPROM, aparently these checks are run within Indi info manager on LV1. These compare the hashes stored in syscon with the files stored on flash. If the checks fail, the console does not boot | Firmware hash checks are located on SYSCON EEPROM, aparently these checks are run within Indi info manager on LV1. These compare the hashes stored in syscon with the files stored on flash. If the checks fail, the console does not boot. We could get around this by using dual-banking on SYSCON or by patching the checks out. | ||
=== VFlash === | === VFlash === | ||
Only a single version of VFlash is stored on flash in NAND consoles, and a single copy is stored at the beginning of the PS3 hard drive on NOR consoles. Because the firmware stored here doesn't match that stored on flash, you would have to reinstall the rest of firmware everytime you switch. We could possibly overcome this limitation by patching the storage manager to redirect vflash to another region of the hard disk. | Only a single version of VFlash is stored on flash in NAND consoles, and a single copy is stored at the beginning of the PS3 hard drive on NOR consoles. Because the firmware stored here doesn't match that stored on flash, you would have to reinstall the rest of firmware everytime you switch. We could possibly overcome this limitation by patching the storage manager to redirect vflash to another region of the hard disk. | ||
[[Category:Software]] | |||
= Software based = | = Software based = | ||
== Using graf_chokolo's payload == | == Using graf_chokolo's payload == | ||
In graf_chokolo payloads, there is a payload that can be used to load an alternative | In graf_chokolo payloads, there is a payload that can be used to load an alternative lv2_kenel.self | ||
You have to save the alternative lv2_kernel.self on flash and use the payload to make lv1 load it. | You have to save the alternative lv2_kernel.self on flash and use the payload to make lv1 load it. | ||
| Line 72: | Line 54: | ||
With both of those payloads i’m able to boot a patched lv2_kernel.self from FLASH without flashing PUP, i just store a second lv2_lernel.self | With both of those payloads i’m able to boot a patched lv2_kernel.self from FLASH without flashing PUP, i just store a second lv2_lernel.self | ||
on FLASH, then patch System Manager in HV which is reponsible for booting GameOS and boot custom LV2 kernel from 3.41. | on FLASH, then patch System Manager in HV which is reponsible for booting GameOS and boot custom LV2 kernel from 3.41. | ||
You don’t need NOR flasher if something goes wrong | You don’t need NOR flasher if something goes wrong, just reboot HV and your original lv2_kernel.self will be booted again | ||
just reboot HV and your original lv2_kernel.self will be booted again | |||
The same way you could boot lv2_kernel.self from dev_flash. | The same way you could boot lv2_kernel.self from dev_flash. Just patch path to lv2_kernel.self in System Manager and point it to lv2_kernel.self stored on dev_flash | ||
Just patch path to lv2_kernel.self in System Manager and point it to lv2_kernel.self stored on dev_flash | |||
</pre> | </pre> | ||
| Line 82: | Line 62: | ||
*Same as above and this could ONLY be used with a lv2_kernel.self compatible with you actual lv1.self | *Same as above and this could ONLY be used with a lv2_kernel.self compatible with you actual lv1.self | ||
*You can only customize lv2_kernel.self and below | *You can only customize lv2_kernel.self and below | ||
= Bootloader = | = Bootloader = | ||
| Line 89: | Line 69: | ||
This would be the best solution, having a bootmii like bootloader with recovery options, but it is also the most farfetched. | This would be the best solution, having a bootmii like bootloader with recovery options, but it is also the most farfetched. | ||