проблема такова, принесли бокс trinity на даше 14719. Вычитал 3 раза, сохранил ... Потом пришла бредовая идея повысить даш до 15574 (DVD привод не читал диски).... В итоге решил поставить фрибут, собрал ecc на базе 14719 (16202). Один раз дождался xell - забэкапил ключик. Запуска больше не добился, решил вернуть всё назад, залил изначальный образ нанда (14719). В итоге: приставка секунд 15 пытается запуститься и рисует красный огонь.
Ошибка Nand'a образ 14719, а когда повысили даш до 15574 поменялся LDV. На 15574 тоже dump надо было снять, попробуйте в J-Runner поменять LDV(хотя врятли поможет).
так и есть... думал, что поможет сборка просто Retail, как говорил Ленин - учиться дальше. Код: 13th December 11, 19:10 After countless posts of repeating myself, I've decided that it's best to write this guide instead. First off, let's understand the main difference between the old SMC exploit (JTAG) and the new Reset Glitch. JTAG consoles emulate the e-fuses, therefore data stored within (with the exception of the lines 3,4,5,6 - the CPU key) are not addressed. This is why JTAGs are a lot easier to manage in terms of updating. It doesn't matter what state the remainder of fuse lines are in as it doesn't care. So, back to RGH (as this is an RGH tutorial). Every time you run an OFFICIAL MS update on your console, the Lock Down Value (LDV) will increment by one. This value is written to the base address of the NAND as well as into secdata.bin as well as a couple of others. I think the console can go up to an LDV of 80 and after that, it doesn't increment any more. It's worth noting at this state that the bootloader (CB) and LDV are the FIRST thing the console checks when it boots. If the LDV doesn't match what the CPU e-fuses say (or more importantly, is LOWER than the CPU e-fuse LDV), you'll get 3 red lights and 0022 Secondary Error Code. This isn't your average run-of-the-mill RRoD, so don't assume it is. Whatever you see in XeLL is LAW. The value for CPU key for instance is a permanent string and CANNOT be changed (and won't ever change, unless you replace the CPU). The e-fuse lines are a different matter, and this is where you will trip up if you don't understand the basics. Example - you've just finished with an RGH console (or indeed rebuilding a retail NAND for unflagging) and after flashing, the console sits and looks at you for about 20 secs and FINALLY gives you 3 red lights 0022. Crap. Don't panic. The chances are you've done something out of sequence or the NAND dump you used for the source image is older than what was previously on the console. Solution: 1. Boot XeLL. If it's an RGH console doing this, then XeLL should still work as it doesn't need to know about any details from your console (with exception of the smc and CB values, but that's by-the-by). 2. Count the number of ffff's you see on lines 7 and 8 (directly below the CPU key). This is the current LDV number for the console. As long as you don't run any more official MS updates, this number won't change. Alternatively on phat consoles, remove R6T3 and this number will NEVER change, regardless of what you try to apply. 3. Download Multi_Builder (latest version). You'll see me harp on about this tool just about everywhere. I do because it's probably the most functional image build tool out there. 4. Go into Data/my360 and put your cpukey.txt (a txt file with your CPU key) and nanddump.bin into this folder . ANY previously valid dump for this console will do. LDV and dashboard level are irrelevent. You can even use a previous RGH image should you want to. 5. Open options.ini. Find "cfldv =" and add your number from XeLL after this, so if you counted 8 fff's, then "cfldv = 8". Save and close the ini file. 6. Run Multi_builder. Choose your board type, then choose whether you're building a retail or RGH NAND. Note at the very end you should see something like this: --------------------------------------------------------------- nandflash.bin glitch image built, info: --------------------------------------------------------------- console : falcon NAND size: 16MiB CPU Key : 71929DA455E71BD95654E071D1018C33 1BL Key : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx CF LDV : 8 --------------------------------------------------------------- ggBuild Finished. Have a nice day. --------------------------------------------------------------- The CF LDV should match what you entered into options.ini. Flash this new nandflash.bin to your console and it should now be ok. NOTES: 1. It's possible to sort this out without being able to boot XeLL. If you only have the CPU key for example and no longer have the ability to run XeLL, take the LAST KNOWN DUMP for the console and open in 360 Flash Dump Tool. Note the highest LDV number. Now follow the steps above and increment the LDV number by one each time, so build and flash to the console - rinse and repeat until it boots. 2. It's also possible to do the increment in 360 Flash Dump Tool, however this is not advisable since other files like secdata.bin etc have the LDV in there too. Whilst this won't affect an RGH console, those booting a retail dash will have issues the next time they update (E81 more than likely). Therefore, simplicity rules and using the same method for both RGH and Retail NANDs wins. Hope this helps some of you scratching your heads over this. PS I've done this entirely from memory and it's 1am here, so please excuse any errors! PPS timing your 0022 error is quite important. Approx timings for 0022 on stock NAND: 5s- issue with CPU_RST/CPU_PLL_BYPASS 15s - LDV 30s - GPU issue. Therefore don't always assume that a 0022 after x seconds is LDV.
в J-runner выбираю дамп 14719 (окно выше), CPU ключ .... жмакаю птичку retail, даш 15574 и Create Image - никаких окошек не вылазит...
