Been working all day and need a little math assist. I found an old Jasper at a local store and grabbed it for an XBR box to complement my dev kit collection, but the flash has some bad blocks in the first 2MB. This means using Xellous to flash is out, which is fine, but I need a little assist to know where to start the bad block map so I can move them manually in order to get Xell on there and then boot a Debian CD and flash that way. These are the bad blocks that I've got: I figure these should be remapped to the end of the first 64MB block, but what does that equate to in hex? I should know this, but it's the middle of the night and exhaustion has set it. heh. Perhaps I should sleep, but the soldering iron is still hot! Thanks. -hl718
tiredness and soldering irons DO NOT mix dude! I once tried doing a spontanious ram upgrade on an old xbox back in the day after a hot date with Mary Jane. Took me forever to rectify the mess i made
Um that is a little odd to have that many in a row like that unless the soldering is bad, from my understanding bad block re mapper is only usable with a complete nand dump. You might what to invest into a USB nand reader and get the complete nand dump or at least double check your wires, the only time I've seen those errors in nand pro is when there was a wiring issue, not saying bad blocks aren't the cause but you will need a full dump to use the remapper from my understanding of how the remapper works anyway. Hawk
Perfectly normal on a BB NAND. They come in batches of 8. Soldering is rock solid and those are the only bad blocks in the entire 66MB range. Figures they'd be low, heh. Remapper app only works for small block NANDs, so this is a manual thing. By my count the bad block at 40 should be remapped to FF8 (FF8-FFF) and the second bad block at 48 should be remapped to FF0 (FF0-FF7). wan5 is correct. Too late to be worrying about soldering and testing. Did the math, will do the physical read/write and testing tomorrow when I'm more awake. -hl718
NandPro xbr.bin: -r512 badblock1.bin 40 8 Nandpro lpt: -w512 badblock1.bin ff8 8 NandPro xbr.bin: -r512 badblock2.bin 48 8 Nandpro lpt: -w512 badblock2.bin ff0 8 I find it odd that with nandpro reading at 16KB and not 132KB that it spits out 9 errors instead of 16 so block 40 (according to Nandpro) with error 250 being null data and the rest of the block being intact leads me to believe the block is fine and may just be a Null leadin. This block may not need to be remapped. https://docs.google.com/uc?export=download&id=0Bw8wDOXfh0b-ZTU4ZTdjMzAtOWM5My00ZDNjLWE1YTAtMTk1ZmJlMzgzMjY4 XeLL (Free60) + Debian + XBRFlash = Auto solution to bad big block's.
It's not odd, it's working exactly the way it is supposed to work if you read the error messages. The 250 failures are all you care about. You are also in error about the leadin guess. All of those blocks have no data by default, but they shouldn't be null. They should all be full of FF. That said, my original math was indeed correct. Your first stab at it was wrong, but your edit is correct. Those are the memory addresses that I used when I flashed Xell to the box two days ago. Though you are still wrong in saying: There is no "auto" solution to bad blocks in the first 2MB chunk of memory. Take my example for instance. If you tried to flash Xell to that system, it would have failed as two chunks of memory would have not been written right in the middle of the Xell block. Do that and Xell = no boot. Basically if you have any memory errors in the first chunk of memory where Xell lives, you need to remap maually. If you don't have any memory errors in that first big then you can use Xellous, xbrflash, etc. as soon as you flash the initial Xell image. All of those solutions take care of bad block remapping elsewhere in the NAND nicely. -hl718
Original xell should run if your errors begin at block 40. Xbrflash auto handels bad blocks and hybrid blocks
Xell has code at block 40 and at block 48. Simply dropping out those blocks of code from the image isn't good. If they were simply blank memory areas I wouldn't have worried about flashing the image without remapping. If you want to run xbrflash, you need to already have Xell installed on the system. In order to install Xell, you need to have a good NAND layout. Hence, it's a chicken/egg issue. To get Xell up when you have bad blocks in the lower area you need to do the remapping manually before flashing the Xell image. Once you do that you can go to town with xbrflash for every subsequent flash. -hl718
I installed 30 blocks of xell and booted debian worked fine when I used it. I did that on my last box. Fans just went ape shit because of no config.
