Editing Talk:Boot modes

== YLOD remark ==
  <jestero> what do you mean with ylod?
  <jestero> green, bip bip bip, yellow, red flashing ?
  <jestero> if it is, as i told you when i bricked my ps3
  <jestero> the problem was that the hash of the coreos files on syscon eeprom was wrong
  <jestero> and it's hv that make these checks
  <jestero> so i disagree if you say that ylod it's a hardware stage problem

  <mysis> i had ylod when booting into ps2 lpar, turned out to be dev_flash/file access error when replacing files there. pup reinstall solved it.

== Bluescreen without any information ==
example: http://www.youtube.com/watch?v=gv72yI8851s
===Problem description===
QA flagged 3.41 CECHC04 system (MinVerCheck says lowest applicable is 1.00), when downgrading to 1.02, 1.50, 1.51, 1.54, 1.60, 1.70   Retail/CEX in Recovery on 2.50 or higher, after installation the only output was a Blue filled screen (YPrPb/Component + Composite cable on multi-input TV).
Resetting videosettings by holding power until beep did not solve the issue.

'''Note:''' trying to use 2.43 Retail/CEX in Recovery on 2.50 or higher on the same downgrade QA flagged console results in abort of installation with reason: "The latest version of the system software is already installed. There is no need to update."

=== Solution ===
Used PSGrade JiG (PS3key) to trigger service mode (had noticed it still had USB activity) - after which system shutdown as expected, then lv2diag downgrader 3.50 and 2.50 PUP in root of USB for reinstall like a normal downgrade (expecting system would still be on 3.41 and failed the 1.02 before) and then the out of service mode lv2diag. Only after getting out of service mode the videooutput was restored and needed to do initial setup of userconfig again (also harddrive database needed to be restored and my old userdata was also reenabled).

== Redscreen without any information ==
===Problem description===
When experiencing above bluescreen, enabling factory service mode and trying to boot it normally to XMB will result in an empty full red screen.

=== Solution ===
See above reinstall of 2.50 (or higher) firmware in service mode.

== RSOD ==
=== kado ===
<pre>
 <kado> i want to confirm about RSOD
 <kado> my english is bad, but i want you can tell to evryone
 <kado> there is 2 types of RSOD
 <kado> 1.come from CFW 2.from OFW
 <kado> if coused by CFW we should patch the cVTRM
 <kado> and if coused by OFW we should patch the core_OS. and use the last official Core_OS
 <kado> btw, i have fix this 2pcs off RSOD today
    
 <kado> guys here i upload 3.55 board ver-001 (including here are OFW,CFW, service Mode dump)
 <kado> its all for studying RSOD
 <kado> http://www.sendspace.com/file/ywvmox
 <kado> you can compare with them, if you have RSOD come from ofw 3.55
</pre>

=== RSOD question from Rogero (based on Abkarino/kado marked files) ===
==== How is it addressed? ====
   http://www.mediafire.com/?na6vdx9fkiac0v5 <--- RSOD
   http://www.mediafire.com/?gmd6rml9q9hgsr6 <--- 'fixed'

*Basic downgrader (with exception of trvk_prg0 0x040000 not/already patched):
**0x060000   trvk_prg1  (370.000 > 355.000) 
**0x080000   trvk_pkg0  (370.000 > 355.000) 
**0x0A0000   trvk_pkg1  (370.000 > 355.000) 
**0x0C0000   ros0  (370.000 > 355.000) 
**0x7C0000   ros1  (370.000 > 355.000)

- This downgrade patch was used because the original dump 

*and 00'd entry in cvtrm:
::old  00EC4CCD  08 04 12
::new  00EC4CCD  00 04 12

=====Simplified table=====
{|class="wikitable sortable"
|-
! Target area !! Patchfile !! NOR Offset !! Paste length !! Remarks
|-
| ROS0 || [http://www.multiupload.com/RJVZP6CKZ5 patch1 (7 MB)] || 0x0C0010 || 0x6FFFE0 || version string 3.55
|-
| ROS1 || [http://www.multiupload.com/RJVZP6CKZ5 patch1 (7 MB)] || 0x7C0010 || 0x6FFFE0 || SAME as ros0
|-
| trvk_prg0 (0x40000) <br />trvk_prg1 (0x60000)<br />trvk_pkg0 (0x80000) <br />trvk_pkg1 (0xA0000) || [http://www.multiupload.com/MU7JRLE8R1 rvk-040000 (512 KB)] || 0x40000 || 0x80000 || one big patch<br />overlapping several revoke area's
|-
| CVTRM || [http://www.multiupload.com/Z1J1631VOR cvtrm-0xEC0000.bin (256 KB)] || 0xEC0000 || 0x40000 || magic: SCEI<br />Don't use this on another console,<br />it is here listed only for documentation purposes.<br />'''It will brick other consoles!'''
|-
|}
<!--//
==== What was the use of patch_rsod.tcl? ====
   http://www.pastie.org/private/cjkbenvexqjbyzlom7y4dw
   (documentation purpose only, DO NOT USE! BRICK/CORRUPTION RISK)
//-->
==== What's the strange patch? swindle explaination ====
It patches basic_plugins.sprx so that whenever corruption is detected, it will not show RSOD, never error out to alert the user of the problem and FIX the issue and thus only blindfolds the user while the system corrupt it further and further, until beyond repair (in short: '''they use it to swindle their customers''' by NOT fixing the issue and LIE to the customer that it is solved)


=== Abkarino ===
 <Abkarino> he had teached me a lot of things
 <Abkarino> like fixing RSOD consoles
 <Abkarino> i'm not using vsh.self patching eussNL
 <Abkarino> even if not touching any COREOS File
 <Abkarino> i didn't access a perconsole data
 <Abkarino> or patch vsh.self
 <Abkarino> give me a RSOD dump and i'll patch it and you can see your self
 <Abkarino> i had fixed RSOD consoles for 3 users in Progskeet channel
 <Abkarino> no eussNL not by rehashing
 <Abkarino> anyway i didn't fix it by patching vsh.self anyway
 <Abkarino> so give me more info about RSOD and why it appear?
 <eussNL> look in vsh
 <eussNL> RSOD = msg_error_fatal2
 <eussNL> called for via impose_plugin.rco
 <eussNL> resource is actualy inside basic_plugins.sprx
 <eussNL> but error is catched in lv2/vsh
 <eussNL> if you patch vsh.self you are only blinding it
 <Abkarino> so this way not working
 <eussNL> and not FIXING
 <Abkarino> yea but problem still exist
 <eussNL> exactly
 <Abkarino> so it is not a fix
 <Abkarino> i'm not using this method
 <domelec> how are u doing it then?
 <domelec> so how do u fix the rsod Abkarino?
 <eussNL> or other question : how do you diagnose which type of RSOD it is?
 <eussNL> so you would know WHICH data to rehash or change?
 [...] (long silence)
 <eussNL> I know 8 very different flash regions you can manipulate to generate RSOD, so how do YOU diagnose /which/ region is causing the RSOD in the first place Abkarino ?
 <eussNL> (not even talking about the region contents atm)
 <eussNL> I think I will never get a straight answer on above question, just like the past 2 months..
 [...] (long silence)
 <eussNL> retry....
 <eussNL> <eussNL> I know 8 very different flash regions you can manipulate to generate RSOD, so how do YOU diagnose /which/ region is causing the RSOD in the first place Abkarino ?
 <eussNL> <eussNL> (not even talking about the region contents atm)
 <eussNL> <eussNL> I think I will never get a straight answer on above question, just like the past 2 months..
 <domelec> id like an answer to that too just for referance on how its fixed
 [...] (long silence)
 <Abkarino> sorry eussNL i was out
 <Abkarino> just come back
 <Abkarino> i had fixed more than one console
 <Abkarino> cVRTM had undocumented structure
 <Abkarino> and if any of this value changed by anyway it give RSOD
 <Abkarino> look at cVRTM file from NOR dump
 <Abkarino> separet it to 2 files
 <Abkarino> every one is 0x20000 file
 <Abkarino> this patch must be doen for every console
 <Abkarino> that is why no generic patch to solve this kind of problems
 <Abkarino> you must do it for every console
 <Abkarino> compare this 2 files
 <Abkarino> there's a unique 20 byte value repeated at the end of every file
 <Abkarino> in squince
 <Abkarino> try to zeros one of themn and see what if you will get RSOD or not
 <Abkarino> sorry talk to u morning
 <Abkarino> have to go
 [...] (long silence)


 <n00b774> http://depositfiles.com/files/nti7olk5b
 <Abkarino> http://www.mediafire.com/?86v681x9wl5o3qn
 <eussNL> http://pastie.org/3149193 ^diff

NOTE: If you are crazy enough to want an RSOD, just 0x00 fill CVTRM. DO NOT DO THIS WITHOUT A FLASHER!!!

==Firmware Crashes==
This is a collection of crashes ordered from small to bigger (in order or importance), are separated by the behaviour the user see when the crash happens

All this "standard" crashes listed here are supposed to happen over a firmware that is running without problems, and the crash is not caused by a firmware modification

The firmware crashes when one of his threads/subprocess crashes, so when the firmware crash can be considerd a consequence of other crash (there is also the possibility of the thread to be "stuck" in a infinite bucle ... in this case the firmware doesnt crash, but is "stuck" in a black screen forever)

*The most common cause of a firmware crash is a problem in the thread that is running (app or game)
**Typicall in homebrew apps in beta stage, eboot game fixes, version spoofers, etc...
*The second common cause of a firmware crash is a "semi-corruption" of the [[XMB database]]
**Typicall when adding content manuallly in the hdd that needs to be managed by XMB (e.g: any content in XMB game category column)

Always try to avoid forcing one of this "turn-off" methods when the "HDD activity led" is blinking to avoid a problem with the filesystem. All this methods needs to be used in order, if the "eject crash" doesnt works try with the next one

===Eject===
Press the eject button 1 time. The "eject blue led" blinks, then the disc ejects, and you are "kicked out" to XMB

This only works when you have a real disc inserted in the BD drive

===PowerOFF #1===
Push 1 time "power off button". The red led of power button blinks for 1 or 2 minutes then the Ps3 turns off (can be long, wait calmly)

This can be considered a correct turn-off, in the next boot the firmware boots without problem

===PowerOFF #2===
Push "power off button" and keep it pressed. The red led doesnt blinks, after 1 or 2 minutes the PS3 turns-off suddenly (can be long, wait calmly)

This is not a correct turn-off, can generate corrupted files, and in the next boot the firmware can trigger one of the options in "recovery menu" automatically to repair the XMB database or the filesystem

===PowerOFF #3===
If nothing of the previous methods works... the last option is to disconnect the electricity power cord

This is the same case than the previous one, is not a correct turn-off

*Notes
Power-off button is connected to syscon. Is syscon who turns off the PS3, so this can be considered a "syscon crash" (in some way) because syscon is not responding correctly to the button

===Autocrash===
Nothing to do here, this happens automatically when booting a game or app, is the worst of all

===XMB database corruption===
This can be a consequence of some of the previous crashes, but also can be generated by adding manually content to the XMB (XMB database will try to make a copy of any file you make available to XMB, but this is not done in every boot to improve booting time... so there can be a mistmatch between what XMB database contains and what is displayed in XMB... also any corrupted or problematic files you use can be copyed to the database making the problem more annoying)

If the problematic file is not very important XMB can display a "corrupted icon" in his XMB position, but sometimes XMB doesnt know where is his position, this "corrupted icon" can be stuck forever, or the file is important enought to freeze XMB completly

To solve all the problems related with the "XMB database" or filesystem corruption, go to "recovery menu" and use the option "rebuild database"