Can't format JFFS partition =(

[RMerlin]

The more I look at it, the less comfortable I feel with that code, including my original code. The bad block check is done on a single address block at the start of the erase area, but the unlock + erase is done on the whole area.

 

[RMerlin]

I pushed the patch to a separate badblocks branch on Github, but I doubt I'll be merging it to master at this point unless I can get more info confirming the logic there is actually correct.

 

[john9527]

The more I look at it, the less comfortable I feel with that code, including my original code. The bad block check is done on a single address block at the start of the erase area, but the unlock + erase is done on the whole area.

I think the bad block flag is set for the entire erase block, so we should be OK here. On my 68R when the kernel does it's bad block scan during boot, the reported addresses are all based on addresses that are multiples of the erase size.

 

[RMerlin]

I think the bad block flag is set for the entire erase block, so we should be OK here. On my 68R when the kernel does it's bad block scan during boot, the reported addresses are all based on addresses that are multiples of the erase size.

Are you sure it's actually "scanning"? I suspect it's only reporting what blocks are currently mapped in the badblocks table.

Otherwise, that would leave the question as to how the kernel driver handles skipped blocks when reading the mtd device - does it automatically skip bad blocks (which were skipped at write time)?

The only way to test this would be to be able to write a file accross a partition having a known bad block, skipped at erase/write time, and then reading back to see if there's any error or "gap" in the file.

Otherwise, we'd have to study the nand/mtd driver code to see how read requests deal with mapped blocks.

 

[john9527]

Are you sure it's actually "scanning"? I suspect it's only reporting what blocks are currently mapped in the badblocks table.

Either way.....unless the router really beat the odds such that the bad blocks always occurred at the start of an erase block.

Also found this little blurb....

How does JFFS2 handle a block going bad in NAND flash ?
If an error occurs when writing to a page, JFFS2 will attempt recovery of the data. If the block contains nodes that have already been written to flash, the block is refiled onto the list of blocks that are bad but still in use (the bad_used_list). Then the write buffer itself is recovered. This takes into account any data that has been partially written to flash. Once the write buffer has been recovered, normal operation continues. Garbage collection is responsible for moving the valid nodes from the block that was refiled.

Once garbage collection has written all of the valid nodes to a different eraseblock, the block is moved to the erase pending list. From there JFFS2 will erase the eraseblock. If the erase failed, it is put on the erase pending list again for a retry. If the erase fails at the device level a total of three times, it is marked as bad in the OOB area and filed onto the bad_block_list. If the erase succeeds, a clean marker is written to the OOB area and the block is filed onto the free list. This is done because NAND flash can have non-permanent failures due to over-programing or write-disturb errors. A block erase clears these conditions.

 

[sfx2000]

@john9527 and @RMerlin - more I think about this - doing the NAND check and trying to map badblocks out - I agree, this is rather unsafe if a filesystem is already present - and that is not just userland, but also across the entire NAND address space...

As pointed out - we might have a block, but that might span several, or be a subset of blocks within a node in the filesystem, and to clean things up, as Eric points out, it's not just a single address range - we have to do a block erase and then write back...

One possible avenue is to do the scan, if one sees a problem, warn the user to back up and reflash... as the data inside that address range is likely already corrupted...

On the reflash - and here is gets tricky, is to do the scan, and remap all bad blocks, and note that in a table somewhere - nudge, nudge, but this table would have to be written back to somewhere in persistent space.

With a clean NAND, putting in a JFFS filesystem upfront, even if it's just there, but not mounted - John's comment suggests this could be an option.

It's ok for Devs, as we have JTAG units and what not, but for end users, even advanced users, this is not a good place to be...

(loading the bootloader and a sparse image into ram, and then nuke/build the embedded filesystem from there to land the image... my old code did just that with backup user settings/data, then run progflash.hex and then we dropped a fresh image and restored the nvitems and efsobjects... but that was back in the day...)

The other option would be to not touch the NAND at all for any user apps, as that would be safe - and then look at hotplug events for candidates there - but even then...

Gah - I should have left this alone...

 

[sfx2000]

The other option would be to not touch the NAND at all for any user apps, as that would be safe - and then look at hotplug events for candidates there - but even then...

Which is probably for the best - but this is backing out an option that many users have come to expect - which is not good...

Anyways, I've got some other work that I need to attend to - need to get some proto boards into a bootable way...

 

[Jozek]

So... Any solution for noob people like me?


Enviado desde mi iPhone utilizando Tapatalk

 

[john9527]

So... Any solution for noob people like me?


Enviado desde mi iPhone utilizando Tapatalk

If your AC68U isn't a C1/E1 rev, I included a test/potential fix in my latest fork beta (V22B4 near the top of the thread list). If you want to try it, you'll need to load it with the ASUS Firmware Recovery tool and factory reset after.

 

[sfx2000]

If your AC68U isn't a C1/E1 rev, I included a test/potential fix in my latest fork beta (V22B4 near the top of the thread list). If you want to try it, you'll need to load it with the ASUS Firmware Recovery tool and factory reset after.

@Jozek - Read thru the thread - it might work... no warranty based on some general concerns...

 

[john9527]

no warranty based on some general concerns...

Definitely....how's the saying go.....no warranty implied or expressed. But it's all we've got. But since I think ASUS now depends on jffs for the stock fw, you should be able to RMA it if in warranty.

 

[sfx2000]

Definitely....how's the saying go.....no warranty implied or expressed.

Kind of like used cars - 30 feet or 30 seconds, whichever comes first

 

[Jozek]

Definitely....how's the saying go.....no warranty implied or expressed. But it's all we've got. But since I think ASUS now depends on jffs for the stock fw, you should be able to RMA it if in warranty.

If i use your forks, partition is mounted. If go back to Merlín is unmounted


Enviado desde mi iPhone utilizando Tapatalk