Editing Talk:Boot modes

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