Talented members of XBH contributed in many ways. You know who they are. TeamXBR assembled the parts, coded the utilities, and glued it all together to make it work.
* How does it work?
Both XBR and Freeboot use a "patch engine" to apply patches to the bootloaders as the console reboots. For Freeboot, this is "freeboot.bin" or "freeboot-manual.bin"; For XBR, its "xbrfw.bin" Both of these binaries are based on xell type start up code, and are launched by the exploit. The code then applies patches contained at block 0x65+, and restarts the system.
* What went wrong?
Earlier versions of XBR used the same CB/CD pair to start the 8955 kernel as the exploit. Freeboot, using a dual nand setup, used the older bootloaders to start the exploit, than used the newer bootloaders on the alternate flash to start the kernel.
The problems were not related to the patches used by XBR, but rather the use of the older bootloaders. Please try to control yourselves if problems arise, they can always be fixed. Dont do anything crazy like start conspiracy theories, buy a cygnos, wire up a dual nand or xd card, rip out a big nand to swap in a smaller one etc, etc. Have a little patience, have a little faith
* So whats the fix?
1) Add a copy of the new bootloaders to flash.
2) Create patches to use the newer relocated bootloaders on reboot.
It was easier to re-use the freeboot.bin patch engine to accomplish this task.
The freeboot patches themselves are not used. XBR continues to use its own patches, however, the freeboot.bin patch engine will be used to apply them.
This also allows custom patches to be applied, in the format used by freeboot.
XENON_8955_3:
- Uses 6750 as the alternate CB to allow easy support for all hardware versions.
- No changes made to patches, exact same functionality as 8955_2.
XENON_8955_2:
- Add a copy of the new bootloaders to flash.
- Create patches to use the new relocated bootloaders on reboot.
- Translated existing XBR patches to use the freeboot.bin patch engine.
- Fixed build file to use CB/CD 1921 for all xenon.
- Eliminate media binding path checks, run xex from all media without patching.
* XBReboot Block Layout:
Ox00 - 0x2F Xell Boot firmware
0x30 - 0x3F Backup Xell
0x40 - 0x4F freeboot.bin or freeboot-manual.bin (patch engine core)
0x50 - 0x61 Alternate CG
0x62 - 0x64 Spare blocks
0x65 - 0x65 Patch.bin, patches for bootloaders and kernel
0x66 - 0x8F Alternate CB/CD/CE
0x90 - 0x?? Flash file system
* HowTo:
1) Extract KV and Config blocks from orig.bin
nandpro orig.bin: -r16 rawkv.bin 1 1
nandpro orig.bin: -r16 rawconfig.bin 3de 2
2) Inject those blocks into XBR.bin
nandpro XBR.bin: -w16 rawkv.bin 1 1
nandpro XBR.bin: -w16 rawconfig.bin 3de 2
3) Flash result
nandpro lpt: -w16 XBR.bin
* Notes:
There is no need to unpack and repack pirs files!
This is a limitation of freeboot. Not XBR.
Aside from that major difference, all functionality is the same.
Individual sections can be updated or extracted seperately using nandpro.
links are being added.
Xenon Download
Falcon _3a Fixed Image Download
Jasper16 Download
For those who used the previous releases for falcon/zephyr. BAD FLASH FIX
6 comments:
Definitely just bricked my Zeyphr. No longer can I flash via USB SPI, doesn't detect flash controller anymore. Will not power on either.
I posted the link to the fix for that.
the problem had been that an incompatible SMC was used to build the falcon and zephyr images.
versions _3a will be posted soon
I'm having a blank screen, solid green light with no error code problem with my Zephyr doing etiher a lpt/lflash update to 3a, but xell works fine.
I think something wrong with the 3a flash file (if I flash back to my first XBR it works fine). I already double checked kv and config
Anyone get their 3a Zephyr working?
Howdy Abdou.Retro. I was able to recover and flash using your 3a for my Zeyphr but now I just get a black screen upon power up, as many if not all Zeyphr users are getting as well.
I really do appreciate all the work and I am looking forward to fix :)
excellent writing .
Post a Comment