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

 <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

RSOD question from Rogero

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

Target area	Patchfile	NOR Offset	Paste length	Remarks
ROS0	patch1 (7 MB)	0x0C0010	0x6FFFE0	version string 3.55
ROS1	patch1 (7 MB)	0x7C0010	0x6FFFE0	SAME as ros0
trvk_prg0 (0x40000) trvk_prg1 (0x60000) trvk_pkg0 (0x80000) trvk_pkg1 (0xA0000)	rvk-040000 (512 KB)	0x40000	0x80000	one big patch overlapping several revoke area's
CVTRM	cvtrm-0xEC0000.bin (256 KB)	0xEC0000	0x40000	magic: SCEI Don't use this on another console, it is here listed only for documentation purposes. It will brick other consoles!

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)