Re: Back up of the Factory Bad Block Table BBT, needed or a waste of time?
On Sun, 29 Jul 2007 14:41:41 +0800 Harald Welte [EMAIL PROTECTED] wrote: On Sat, Jul 28, 2007 at 02:46:24PM +0200, Visti Andresen wrote: I'm probably going to receive my Neo next Monday (the joy). good luck. The gpsd should be backed up by the procedure in: http://wiki.openmoko.org/wiki/Getting_Started_with_your_Neo1973#Initial_backup this is not present on phase-1 handsets and only accidentially ended up on the GTA01Bv4 that were sent to phase-0 developers before. I've updated the wiki accordingly. Ahh yes the GLLIN driver will be available at some point in time: http://lists.openmoko.org/pipermail/community/2007-July/008466.html So there is no need to back up anything as I have the source :) I wish Nokia was this open about there hardware/software for the N770 and N800, oh well and inside the bad block table (BBT), I guess that the BBT isn't located inside the 4. partition and therefor not backed up? http://wiki.openmoko.org/wiki/NAND_bad_blocks#Bad_Block_Table_.28BBT.29 well, technically it is in the rootfs partition... but in blocks that are marked as bad blocks ;) so depending on the method of your backup, you will either have it or not. I suppose it is marked as a bad block inside JFS2? Should I go look for the OOB special markers (BBT0/BBT1)? or can I simply look for the last two good blocks at the end of NAND as suggested by: http://wiki.openmoko.org/wiki/NAND_bad_blocks#Bad_Block_Table_.28BBT.29 QUESTIONS: == Is it necessary to back up the BBT alt all? Depends on what you want to do. It makes sense. In fact, I have asked our production software team multiple times to store the bad-block information at the factory for each device, so we can theoretically restore that information for any given device. I don't know the status of it, though. I'm currently experimenting with creating a program that reads the Bad Block Table. It also seams I can get a list of bad nand blocks using the nand bad u-boot command Can the factory BBT be recreated using JTAG? not if you erase all inline and OOB data by something like 'nand scrub' of u-boot. This will erase everything! or has the factory used a special kind of magic when establishing the BBT? I was thinking more along the lines of, if they were writing it with bit patterns like memtest86 to detect the bad blocks. (which we might also do in an attempt to find bad blocks) or If they were probing the values of the ones and zeros to determine a statistical probability that the cell is faulty. Consulted the Oracle of Delphi, or used other means unavailable to us. The data sheet don't tell how they do it, so I'm assuming you don't know either... Anyway thank you for your time and answer, I think I will try to backup the bad block info using u-boot nand bad and my C program (given that I get to work) no. it just scans the nand flash for factory bad block markers (see nand data sheet) and creates its own table (for faster access and as a backup copy). Ah yes nothing like sitting with a cup of coffee reading a good data sheet a Sunday afternoon. It seems that the factory bad block info is located in the sixth OOB byte in the first or second page of a nand block. Any non 0xff values marks the block as bad. I'm updating the bad block wiki to include this info... Please correct me if I'm wrong. -- - Harald Welte [EMAIL PROTECTED]http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back up of the Factory Bad Block Table BBT, needed or a waste of time?
On Sun, Jul 29, 2007 at 05:26:06PM +0200, Visti Andresen wrote: and inside the bad block table (BBT), I guess that the BBT isn't located inside the 4. partition and therefor not backed up? http://wiki.openmoko.org/wiki/NAND_bad_blocks#Bad_Block_Table_.28BBT.29 well, technically it is in the rootfs partition... but in blocks that are marked as bad blocks ;) so depending on the method of your backup, you will either have it or not. I suppose it is marked as a bad block inside JFS2? jffs2 uses mtd, which in turn uses the bbt Should I go look for the OOB special markers (BBT0/BBT1)? or can I simply look for the last two good blocks at the end of NAND as suggested by: http://wiki.openmoko.org/wiki/NAND_bad_blocks#Bad_Block_Table_.28BBT.29 the OOB special markers are definitely the way more reliable method. the last two blocks of NAND is misleading, since those last two could be _real_ bad blocks, and the BBT thus in the previous blocks. using the same algorithm like the mtd code makes sense: Start from the end of the device backwards and look for the OOB special markers. I'm currently experimenting with creating a program that reads the Bad Block Table. It also seams I can get a list of bad nand blocks using the nand bad u-boot command yes, you can get the list from 'nand bad'. However, that list will only provide 1 bit information (bad/non-bad) whereas the actual BBT uses 2 bit per block (good/factory bad/wear-out bad). I was thinking more along the lines of, if they were writing it with bit patterns like memtest86 to detect the bad blocks. unfortunately this is not a reliable method to detect factory-marked bad blocks. Those blocks might work just fine, but e.g. lose their information later on. Or only work for way less erase cycles than other blocks. I'd recommend googling for some general information on NAND before implementing such algorithms (based on wrong assumptions). If they were probing the values of the ones and zeros to determine a statistical probability that the cell is faulty. there really is no method, sorry. The data sheet don't tell how they do it, so I'm assuming you don't know either... you cannot do it by software. you have to do actualy (I guess even analogue) measurements on the cells. It seems that the factory bad block info is located in the sixth OOB byte in the first or second page of a nand block. Any non 0xff values marks the block as bad. I'm updating the bad block wiki to include this info... Please correct me if I'm wrong. that's correct. however, you can easily erase the OOB area of a bad block, resulting with that byte becoming 0xff ;) -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Back up of the Factory Bad Block Table BBT, needed or a waste of time?
I'm probably going to receive my Neo next Monday (the joy). Therefor I'm curious about backing up important data from the device before I start to playing around with it. As far as I can tell there are to bits of important data? The gpsd and The Factory-programmed NAND bad block information The gpsd should be backed up by the procedure in: http://wiki.openmoko.org/wiki/Getting_Started_with_your_Neo1973#Initial_backup However badblock information is stored in out-of-band (OOB) data http://wiki.openmoko.org/wiki/NAND_bad_blocks#NAND_basics and inside the bad block table (BBT), I guess that the BBT isn't located inside the 4. partition and therefor not backed up? http://wiki.openmoko.org/wiki/NAND_bad_blocks#Bad_Block_Table_.28BBT.29 QUESTIONS: == Is it necessary to back up the BBT alt all? Can the factory BBT be recreated using JTAG? (http://wiki.openmoko.org/wiki/NAND_bad_blocks#BBT_creation) or has the factory used a special kind of magic when establishing the BBT? The recreation may of course not be an exact copy of the original as some FLASH pages may have gone bad since then. But that shouldn't be a problem If the JTAG recreation of the BBT is actually a working Factory BBT I suppose it isn't necessary to back it up, as any error sever enough to cause the need for a restore of the BBT probably will require a JTAG reprogramming anyway. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
