To quote: New update has arrived to the popular Kmeaw LV2 patcher now with the support of Syscall 36 and Waninkoko V2 CFW. The version is still the same though as according to Kmeaw himself, no code has been changed.
kmeaw: i have added sc36 payload
kmeaw: it is still v8
kmeaw: no code has been changed
kmeaw: just new .txt and .bin files
lv2patcher : Dukio, sorry, I have updated the lv2patcher again icon smile Kmeaw LV2 Patcher V8 *Updated* Syscall 36 Payload, Waninkoko V2 CFW Support The difference is minor – I have added a delay into gamepad reading loop which fixes accidental skipping while the user is selecting the patchset.
In related PS3 homebrew news today rms has made available NOR UnPKG followed by PS3 eEID Splitter source code.
Finally, Mathieulh shared a theory on how to unlock the 8th PlayStation 3 SPU, as follows: I just figured how to unlock the extra spu which sony has disabled at factory. Upon startup, the syscon firmware will read the eeprom value located at 0x48C30 and will set the cell config ring accordingly. That value is set to 0x06 on all consumer consoles which means 7 SPEs are actually enabled. Incrementing it should unlock the extra SPE. btw by EEPROM I obviously mean Syscon's EEPROM. You can read/write to that offset through the Update Manager.
Mathieulh: http://twitter.com/#!/Mathieulh/status/33274848042033152 Mathieulh: http://twitter.com/#!/Mathieulh/status/33275753294462976 Mathieulh: http://twitter.com/#!/Mathieulh/status/33275984421593088 Mathieulh: http://twitter.com/#!/Mathieulh/status/33278019523055616 Luzifer42: *should* unlock the extra SPE. Did you test it? Mathieulh: no, I am not too keen on bricking Mathieulh: but that's the right offset CsakEn: why was that spu disabled anyway? Mathieulh: yield improvements Mathieulh: the problem is I dunno what will happen if I do enable it and that the spu is defective Mathieulh: or if there are extra checks to make sure that spu isn't enabled later on in the bootchain Luzifer42: i am surprised that the spu is not disabled with a fuse Mathieulh: Luzifer42 it's disabled using the config ring which syscon sends to the cell at startup Mathieulh: in fact you can enabled it another way Mathieulh: you have to highjack the spi bus Mathieulh: and change the config ring on the fly as it's sent to the cell processor Mathieulh: and then you can enable/disable any SPE you like Mathieulh: geohot actually did that Mathieulh: but it's messy and needs extra hardware and soldering Mathieulh: and it's not sony's way Pockets69: disabling just one meaning we will have 6 wouldn't it work just for testing? Mathieulh: Pockets69 not if you have a sanity check that ensures at least 7 spes are available Mathieulh: also I am quite sure that if you disable either SPE0 or SPE2, you brick Mathieulh: cause they are used for isolation by respectively the bl and metldr Pockets69: any idea where the check might be? Mathieulh: Pockets69 well in theory you can set any given value from 0x00 to 0x07 and the config ring will be changed and the cell will only start with the given number of SPEs but then you might mess up the bootchain Mathieulh: and if you can't boot again, you can't write to the eeprom anymore Mathieulh: (0x00 is actually an SPE as well) Mathieulh: I assume there is some internal config in the cell Mathieulh: which attributes a specific id Mathieulh: to a SPE Mathieulh: and which is set at factory Mathieulh: so the defective SPE Mathieulh: will always be given SPE7 Mathieulh: in fact it can't be "random" cause the bl always loads at SPE0 Mathieulh: so does the cell bootrom Mathieulh: and metldr always loads at SPE2 Mathieulh: the BL is actually supposed to load at some random SPE Mathieulh: but for some unknown reason Mathieulh: it doesn't Mathieulh: SPE0 isn't supposedly the first physical SPE to be used Mathieulh: and each SPE is attributed a certain id at factory Mathieulh: the defective one should always be 7