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



== 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?
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 ===
<pre>
 <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)