[NAND ROM] - Rom Dev only

[MassStash]

Originally Posted by Lmiller1708

Maybe I should have posted my test file here (I think I will for now on)...
but here is the Link to my post from this morning.
http://forum.ppcgeeks.com/2059067-post1306.html

still no dice brudda.... just flashed it. bout to reboot to try the mtty thang, but if we had "bad blacks" wouldn't winmo not flash correctly?

[MassStash]

Originally Posted by [ACL]

lets recruit more testers.

need people to volunteer testing the NHB from autobuild and see how it goes. There is no way lmiller and i are the only ones with super phones..lol

i'm watchin' now, will try one soon as it's there...

[arrrghhh]

Ran mtty task28... Here's the output:

Cmd>task 28
Format start
Fill RSVD information for block 351 to 384
Storage start sector=0x1A900, total sector=0x1F700
Storage start block=1733, total block=2012
Total Bad Block in CE: 1

Erase physical block from 2087 to 3944

formatstorage Bad block found: 2555
formatstorage Bad block found: 3022
si backup: Erase physical block from 4080 to 4096

Format end

I thought this was normal, to have bad blocks shipped with NAND devices...

Nate, actually found that thread on my own - thanks for the post tho. I didn't see any commands about searching for bad blocks, task28 is correct... no? Task29 I know is to wipe the device, which I certainly can do again, but have already tried... The thread didn't seem to address this.

Edit - did a task29 just for fun. Output is below, appears I do have a couple of bad blocks... but again, I thought this was expected:

Cmd>task 29
Format BINFS start
CE start start block=384, total block=3712
ERASE block 2204 FAIL !!!
ERASE block 2671 FAIL !!!
Write 0xFF start page=0x6000, total page=0x3A000
Format BINFS end

[[ACL]]

Originally Posted by arrrghhh

Ran mtty task28... Here's the output:

Cmd>task 28
Format start
Fill RSVD information for block 351 to 384
Storage start sector=0x1A900, total sector=0x1F700
Storage start block=1733, total block=2012
Total Bad Block in CE: 1

Erase physical block from 2087 to 3944

formatstorage Bad block found: 2555
formatstorage Bad block found: 3022
si backup: Erase physical block from 4080 to 4096

Format end

I thought this was normal, to have bad blocks shipped with NAND devices...

Nate, actually found that thread on my own - thanks for the post tho. I didn't see any commands about searching for bad blocks, task28 is correct... no? Task29 I know is to wipe the device, which I certainly can do again, but have already tried... The thread didn't seem to address this.

Edit - did a task29 just for fun. Output is below, appears I do have a couple of bad blocks... but again, I thought this was expected:

Cmd>task 29
Format BINFS start
CE start start block=384, total block=3712
ERASE block 2204 FAIL !!!
ERASE block 2671 FAIL !!!
Write 0xFF start page=0x6000, total page=0x3A000
Format BINFS end

hmm.. yes and no. I run thos bad boys too with no bad blocks. But we should be able to handle them since they can happen.

Now its hard for me to see where these blocks are in terms of tinboot. We may need to change your offset around to skip those parts.

Edit: may need to reach out to the godfather dzo and see how vogue handles bad blocks

[arrrghhh]

Originally Posted by [ACL]

hmm.. yes and no. I run thos bad boys too with no bad blocks. But we should be able to handle them since they can happen.

Now its hard for me to see where these blocks are in terms of tinboot. We may need to change your offset around to skip those parts.

Sounds tedious... isn't there a way we can identify bad blocks and intentionally avoid them? Because I would assume the bad blocks are going to be in different places for everyone.

Everything I've read says bad blocks aren't a big deal, even the Wikipedia article...

[[ACL]]

Originally Posted by arrrghhh

Sounds tedious... isn't there a way we can identify bad blocks and intentionally avoid them? Because I would assume the bad blocks are going to be in different places for everyone.

Everything I've read says bad blocks aren't a big deal, even the Wikipedia article...

ur absolutely right. we should be able to handle them with no issues.

from what i understand a format should mark the bad blocks so they can be skipped. So if you do a task 28/29 again, does it still say you have bad blocks? i guess it would be nice to know if these blocks can be avoided by the boot-loader since it has the ability to detect em.

[arrrghhh]

Originally Posted by [ACL]

ur absolutely right. we should be able to handle them with no issues.

from what i understand a format should mark the bad blocks so they can be skipped. So if you do a task 28/29 again, does it still say you have bad blocks? i guess it would be nice to know if these blocks can be avoided by the boot-loader since it has the ability to detect em.

I'll try it now...

Bleh, same output. task29 fails on the same two blocks, as does task28.

[[ACL]]

Originally Posted by arrrghhh

I'll try it now...

Bleh, same output. task29 fails on the same two blocks, as does task28.

ok so we will see how MassStash does to see if yall are on the same boat.

[natemcnutty]

Originally Posted by [ACL]

ur absolutely right. we should be able to handle them with no issues.

from what i understand a format should mark the bad blocks so they can be skipped. So if you do a task 28/29 again, does it still say you have bad blocks? i guess it would be nice to know if these blocks can be avoided by the boot-loader since it has the ability to detect em.

It will still say there are bad blocks, but you can ignore them. The reason is that Task 29 will still attempt to format every block, even if they have been marked as bad. Also, Task 28 performs the hard reset function, and Task 32 can be used to wipe the ROM area only.

NAND is almost always shipped with some bad blocks, and they are handled by the NAND controller. It is already doing the work of bypassing those blocks for you which is why everything says to not worry about them.

My thought would be more towards the SPL at this point. I'm wondering if some builds have validation that looks for the boot, RAWFS, IMGFS, and FAT partitions. I noticed that if I modify the NBH's that were working on my phone by removing the FAT partition, they fail to boot.

[santod]

First off, I just wanted to say, that I've been following along with most of the work from those involved here, on and off for a while now. You guys have done great work here. Thanks for it.
I've been real busy with classes myself, so I haven't really even began to get involved anywhere on this. Especially since my experience is stemmed in other programming languages to begin with.

However the degrees I'm working on currently, have me taking some Unix/Linux programming courses as I intended. Therefor I may be able to lend better help, when I have the time.
At the very least, I have a Rhod 500 and would be happy to help test whatever needs testing, even if just to get a feel for what is happening on one more device. If not, that's cool too, as I'm truly very busy lately.
Either way, I wish you guys the best of luck and appreciate your continued efforts. Keep it up!
Not trying to clog your thread here, just offering what little I can, in case it's needed or wanted and saying "Thanks" to all of you.