Your right on the code as well as some other things... except the seperate thing. I put a stop to that in a sense... EDIT: Just went through and checked my nand.bin it was clean of bad blocks. Then I went through and checked XBR.bin it was also clean but did a little "fix" on it, not sure what it really did. Then I erased my NAND to make sure it wasn't a overwrite issue, then I wrote to it with the patched XBR.bin. Afterwords I disconnected the power cable to hard reset the Xbox 360. After that I reconnected the power cable and booted the Xbox360. Same unstable operation. Sigh. Looks like I'm sticking to my little method as annoying as it may be >_> atleast till a fix is released.
You are oh so wrong here. This isn't exactly true, Yes it is a generic FULL image, but there is a lot more in that image than just kv and config. It has for example the rebuilt bootloaders, patched smc, jtag bootstrap, xell, xbr core, xbr patches and a remapped flash file system... Patches are applied on-the-fly during bootup. The physical nand could have bad blocks anywhere, but the "generic" xbr image is not taking that into consideration. Any bad blocks MUST be remapped in the xbr image or else it could have "random" errors anywhere with anything related to nand access, not necessarily just at bootup. This isn't to say that xbr doesn't have stability issues (I dont know since I haven't ran it much myself) But don't underestimate the complexity of the image and the role of bad blocks.
Please explain that to me since all your patching is a config file and a KV :shrug: I think yet again you are misunderstanding I'm not saying XBR.bin is a KV and a config file I am saying thats all it needs from the original NAND to boot. In other words as long as the KV and the Config are not corrupted then XBR should take care of any bad blocks from user error read because your not reflashing your original nand you are flashing XBR with only 2 tiny files from your nand. Simplified NAND -> KV CONFIG -> XBR.BIN Bad blocks could just cover the entire nand as long as its not in the offset located where your kv and config are because, that is all you need from your nand so checking your original nand is pointless, you should be checking XBR because nothing of your nand except kv and config file is required. To clarify this look up how to install XBR. I know what the image consists of. I think everyone here is having a gross misunderstanding of what I am saying. I know some things about XBR such as icekiller has mentioned and I know how it functions and why its freezing. This doesn't mean that I could fix it myself because I understand that of which is causing it but I do have an understanding. Like I said misunderstanding. At no point did I ever say XBR consists of a KV and a Config file. I said that is what is required from your original NAND dump to be patched to XBR.
You are not understanding how flash memory works. Hence the confusion. You say "checking your original nand is pointless" which doesn't make sense. You do realize that you are flashing your XBR image back to the NAND, right? The bad blocks we are talking about are physical locations on the NAND itself. The XBR image you are flashing is generic and has no concept of where those bad blocks are located on the physical chip. If you have a chip with no bad blocks, you're fine. If you do the raw NAND dump you make will have a record of those locations but the generic XBR image you are flashing will not (unless you account for it). If you do a raw flash of the generic image to a NAND with bad blocks, sections of the file you are flashing will be "written" to those bad blocks. The flash will appear ot be successful, but you will have no idea if every sector was properly written or is being properly read. The reason this is an issue is specifically because XBR is a generic image. I hope that clarifies things a bit. -hl718
Maybe I am misunderstanding but you are not patching your NAND to XBR.BIN XBR.BIN IS a NAND and your just patching your keyvault and config so that the Xbox360 recognises it. Here look at this. Step 1 extract 2 files from your NAND Step 2 patch those 2 files to XBR.bin Step 3 write XBR Only thing that is required is your keyvault and your config. Nothing else is being patched to XBR and nothing of your NAND survives. Furthermore i deleted my NAND and wrote XBR with just the 2 files patched. Nothing of the original NAND survives but those 2 files. You are not writing your original NAND at all. XBR comes with all the system files required to boot only without those two files that you must extract yourself.
What? you are making no sense. How is XBR taking care of bad blocks? Im not flashing my nand? How so, the file I flash is little more than 16MB (which happens to be the full size of the nand.) Look, I know what you are trying to say, but you are doing a terrible job at it. You are saying that XBR is prebuilt and fully functional but you only need to transfer the KV and Configs blocks from your old nand to the new XBR image and flash that to make it compatible with your console. In a perfect world that is great, in the real world there are physical issues with the nands. If you try to write a block to the physical nand and it fails without remapping it, you just lost that data. That bad block could be anywhere on the nand you might not notice it until later. Yes if it is a bad block of anything important or used during bootup, it would probably fail at bootup. Anyways, the bad block mapping needs to be transferred to the XBR image if you want to avoid bad block issues. The kernel is smart enough to handle/add any new bad blocks that arise. I'm sure what ever stability issues with XBR will be addressed as more releases come out. heh We cross posted.. Exactly!, thus you are losing the bad block maps!
You're still confusing terms. The NAND is the physical chip inside the Xbox 360. The NAND may have bad blocks. If it does, these are noted internally. The XBR image is what you flash to the NAND. The XBR image does not account for any bad blocks on the NAND. If you have zero bad blocks, then you have no worries. If you do have bad blocks on the NAND, then flashing the generic image will not account for those bad blocks and you will be writing parts of the XBR image to bad blocks. They may appear to write properly but still fail on a later read. By accounting for the bad blocks in your NAND you then reorder your XBR image to account for those bad blocks. This also prevents future filesystem writes from hitting those bad blocks as they are once again noted internally. Now does it make sense? -hl718
By take care of I mean that XBR during an extraction an extract if your nand dump has bad blocks it shoudln't matter because if XBR was extracted 100% propperly then it won't have bad blocks, Writing is another issue but its not like you can fix the blocks that are bad due to a bad write because its already on the physical NAND. Right but mapping bad blocks won't help if your doing it from your PC just to write bad blocks again. Right, so what I am saying is that there shouldn't really be need to map out XBR unless bad blocks are required lol. And if you create bad blocks during a write kind of pointless. Do you get what I am saying? Or am I just clueless and have a misunderstanding of all this? Wait I think I get what your saying, your saying by mapping them it can prevent bad blocks created during a write, if this is what you are trying to get across how does it do this?
I'm going to be blunt (so please don't take this as an insult), but the answer is yes. Let me try another example. It's not perfect, but it should illustrate the point. Think of the NAND flash chip as a physical book. Every "page" in your book is a block. Now, page 5 is water damanged. You can't read a thing on it. But your book has a second copy of page 5 in the appendix. And in the TOC at the beginning there's a note that says when you finish page 4, flip to the end to read page 5, then flip back to page 6. Your generic XBR image doesn't know about the damaged page 5. So when you do a raw flash of that image, it writes page 5 of the XBR image to the water damaged page 5 of your book. The TOC doesn't make any note of the damage, so when you go to read it later you finish page 4 and then there is a page of garabage data. By accounting for the bad blocks before flashing XBR you are inserting a note into the XBR image's TOC that says "page 5 is bad, so look for the page 5 data at the end." The data is also remapped to that appendix page. Now, when someone goes to read it later, they never see the damaged page 5. Everything is there. Does that clarify what Redline and I are trying to explain? -hl718
Yes I understand now, I figured we were talking about the software image. NAND chip actually can be the cause of bad blocks? I thought it was due to an impropper dump and because of which parts of the image are corrupt. So what your doing is relocating the data from "page 5" to another page? At anyrate my nand appears to be fine because I get no bad blocks.
Yes, NAND flash memory (and pretty much all current flash memory) is expected to have some bad blocks. This is why the chips are always slightly larger than their stated size and the size they show to the file system. By doing the "page relocation" internally the file system sees no difference even if the physical location on the chip is different than what you'd expect. Incidentally this is also how hard drives work. If a sector goes bad on your hard drive, the drive controller will flag it and remap it behind the scenes. This is invisible to you as a general user. The only time you have to worry about stuff like this is when you're doing a low level wipe/write as you are obliterating the known "bad block/sector" list. It's not quite the same as wear leveling (since there none of the blocks are marked as bad, individual blocks just aren't overwritten until all other blocks have already been written to an equal number of times) but the concept is in the same ballpark. -hl718
Yes perfectly. If you remap the data inside the XBR image you are doing two things... You are MOVING data to different locations AND you are telling the kernel (and nand) about the current known bad blocks. The nand might have more hardware tricks but at any rate, this is the basic idea.
long time lurker here but had a quick question - how come when you write XBR it cannot recognise bad blocks? I say this because when you do a bootmii nand recovery on the wii the program recognises bad blocks and skips them when writing back to the nand. hope my question makes sense
That would depend on the tool being used to write the image to the nand. Since there are multiple ways of achiving that task, that cannot be answered fully. The application gets back a "status" from the sfcx status register, the bits of the status tells the app how the request went. Sure an application could do additional logic and build a "bad block map" as it went. But I think it would be best to not rely on all tools doing that correctly and the bad block could have been marked at manufacturing time and placed into the bad block map even if it returns a good status on a write. My opinion is that the bad block map is there for a reason, it would be wise to keep it.
