[judges]

I've just released NORway v0.5 (see first post for download links).

Changes:
+ Added block table for Samsung K8Q2815UQB. The programming modes "writeword" and "writewordubm" don't require manual chip/sector erase prior to writing anymore!
+ Bugfix: "NORway.py COMx release" didn't work. Now you can leave Teensy powered at all times and console will boot up correctly after issuing a "release" command
+ Bugfix: increased TRANSMIT_TIMEOUT for Teensy's serial device to 10000ms (required for OS X)
+ Bugfix: disabled DSR/DTR flow control (wasn't working reliably on OS X)
+ Bugfix: TRISTATE wasn't set correctly
+ Added additional verification when writing is done. Although each write command verifies each written sector/block, it happened that written bytes weren't persistent
+ Added "verify" command

-- judges

[judges]

New beta version available.. Now the "write" command only takes 4:30 minutes (instead of 6:45) to flash a completely empty NOR.

Changes:
+ Changed programming modes "write", "writeword" and "writewordubm" to
"vwrite", "vwriteword" and "vwritewordubm"
+ Added new programming modes that skip verification for single 4KB blocks:
"write", "writeword" and "writewordubm"
Since verification is done anyway at the end of programming, it's not
necessarily required anymore to verify each single block individually.

-- judges

[desperado]

Please check me dump.
http://dump.ru/file/5840035

Look like a brick.

[judges]

Originally Posted by desperado Please check me dump. http://dump.ru/file/5840035 Look like a brick.

Looks good to me at the first glance...

[CrackMyDay]

Thanks for the effort and new release judges. I'll try it soon. Specially if i get a Samsung's QB memory.

Cheers.

[judges]

Originally Posted by CrackMyDay Thanks for the effort and new release judges. I'll try it soon. Specially if i get a Samsung's QB memory. Cheers.

CrackMyDay's back! Hi!

Your mods for Samsung QB might/should be obsolete now. At least the latest beta did work for a few guys on Samsung without your mod. Just give it a shot (power teensy from console). Your feedback is always appreciated! Thanks..

[Bohemio]

Judges ... i have another issue , with a PS3 FAT with RSOD , and OFW 4.21

it have samsung QB, i solder 2 times the teensy...


i dumps 14 times the Nor ... and i have different MD5 nors , not all different but like that




The last dumps are ... NUEVO1 , NUEVO2 and NUEVO3 ...

il try with the latest beta ... with v5 , console OFF , console on ...

then i try downgrade a ps3 slim and all the process was Okei, conclusion the teensy is fine ..

What do you think ???



EDIT: I compare the 2 differents Dumps and the only difference is in one field

MD5:DC7759FAD7D0DE78174F1EB8BF98E820
00EE4940 00 00 00 00 04 00 04 12 00 00 00 00 00 00 04 12


MD5:B52CDFB60A16B4F9EFBE770E01782FA6
00EE4940 00 00 00 00 00 00 04 12 00 00 00 00 00 00 04 12


I compare with others dumps and all have "00" in thats field .....

What do you think , what is the reason ??

[baileyscream]

Originally Posted by Bohemio Judges ... i have another issue , with a PS3 FAT with RSOD , and OFW 4.21 it have samsung QB, i solder 2 times the teensy... i dumps 14 times the Nor ... and i have different MD5 nors , not all different but like that The last dumps are ... NUEVO1 , NUEVO2 and NUEVO3 ... il try with the latest beta ... with v5 , console OFF , console on ... then i try downgrade a ps3 slim and all the process was Okei, conclusion the teensy is fine .. What do you think ??? EDIT: I compare the 2 differents Dumps and the only difference is in one field MD5:DC7759FAD7D0DE78174F1EB8BF98E820 00EE4940 00 00 00 00 04 00 04 12 00 00 00 00 00 00 04 12 MD5:B52CDFB60A16B4F9EFBE770E01782FA6 00EE4940 00 00 00 00 00 00 04 12 00 00 00 00 00 00 04 12 I compare with others dumps and all have "00" in thats field ..... What do you think , what is the reason ??

i dont like coming into developers threads to answer a question aimed at said developer.

@judges the guy has p/m'd me asking to take a look. i'm not comming in to step on your toes.

.......................................................................................................
ok i have no idea about the creation of the md5 for all i know it could be a date/time stamp.

go to my thread and check the dump propperly. dont mess about with md5 check's any further.

http://www.ps3hax.net/showthread.php...466#post387466

[judges]

Originally Posted by baileyscream i dont like coming into developers threads to answer a question aimed at said developer. @judges the guy has p/m'd me asking to take a look. i'm not comming in to step on your toes.

That's certainly not a problem. I appreciate anyone's help. Also I'm not omniscient. Like in this case I wouldn't be able to relate this single byte difference to a flasher related issue.

Originally Posted by baileyscream ok i have no idea about the creation of the md5 for all i know it could be a date/time stamp. go to my thread and check the dump propperly. dont mess about with md5 check's any further.

Comparing multiple dumps from the same console is always a good idea. Using MD5 is a valid way of doing this. You just have to be aware that that's all you get. So it's just one of the steps in the validation process. Since you cannot validate the per console data, you'll never get a 100% validation. And in this case where just one single byte was different in all his dumps, you would never have noticed that without comparing the dumps.

Long story short, we discussed this yesterday on #ps3downgrade, and @euss had, as most of the times, the solution to this (thanks again!). To sum this up, the dumps were (probably) valid, the single byte difference was actually caused by the (RSOD) console itself. This makes the console change the cvtrm table in the flash.

-- judges

[judges]

Originally Posted by Tracy476 So.. this allows you to downgrade to 3.55? Sorry haven't been looking at the news recently.

Yes (depending on the model of your console). And you probably won't find it in the news, since this really isn't new anymore.. ;-)