There's no need to update anything if you're using XBR. You need the 7371 files from *your* console to use the build scripts and tools for Freeboot, though.

How you trigger the install ? Plug a IPOD in ?

Search for "config block" on this forum. Video region is defined there and isn't even protected with encryption or hashing. Have fun.

I know that I have a XBR-ed Falcon here and changing region doesn't work.



Because one might want to setup multiple XBR systems or make one system with multiple regions as
putting existing discs on them without having to extract is appealing to an certain extent. 
But yes I am aware that I can just undo the disc and lay the bare files either on the XBOX HDD or on mass storage.

Just setup all folders you want to copy on the PC and copy them in a single move with the XBOX tool.

delete or copy back then merge with what you're trying to add on Windows then copy *all stuff* back to the XBOX360 HDD. That way there will be no name collisions and no abortions. And yes it lags a lot, to the point the guide menu will take ages to open.

\Content\0000000000000000\FFFE07DF\00000002   <- Optional Media Update goes here.  Yaris-Swap it then dump it at that path. Should work from any storage device that works for game saves.

Funny ... I had a console with 0003 on my workbench today. It was a 2007 Zephyr.

The reason it was giving 0003 is because someone "cooked" it's GPU with a hot air rework station to the point it shorted out one of it's power rails.

There's a bunch of big ceramic capacitors close to the GPU. The ones at the right side are for the power rail which is shared with the CPU.
This one should measure around 2 ohm to the ground.

The two ones to the left and really close to the heatsink screw hole are for the DDR memory bus (GPU memory controller and memory chips) and it should
measure something around 68 ohms to the ground.

Either be shorted and you will have 0003.  And shorted RAM power rail is quite common.

You can as long you watch for name collision within folders or filenames.

You can, but the program will abort if there's name collision (It doesn't overwrite) even with folder names.

Can't region change yet if it's Zephyr or newer. But then you can just unpack the games and remove the restrictions with xextool. Play it from the USB, then. Won't even waste expensive DVD+R DL discs

Arakon, if you use XeXLoad you can copy things in and out of the harddisk to USB mass storage, which is not bad at all... For an temporary fix it works fine.

I'm using a 80GB Fujitsu drive that came from a PS3 which had been updated with a bigger drive. And it works fine besides the fact that neither Xplorer360 or XPort360 can access the partition 3.

If you're trying to put a big (3.5 inch) HDD, it will require both +5v and +12v (which the XBOX don't supply as it's supposed to have an laptop harddisk as drive. So no 12v the HDD will behave like if it were broken (which should make the XBOX show you E68)

In fact, the ultimate goal for analyzing this custom I2C bus would be understand the communication protocol for then add *that project* an "sync button"

If you press the guide button you don't even need to wait the 10 seconds.  It's some kind of bug and happens often at the first app or game you start.

So I found out only one of my original XBOX360 hard disks are giving me issues with the rebooter. It's a SAMSUNG HM020GI.
It's an original MS HDD which works fine on any consoles and with Xport/Explorer360 only when formatted with an non exploited console.

If I format it on the exploited console, it's usable for it but I can't access the contents in it through the mentioned PC apps. Also an original console will "report" it as empty.

If I take it back to a original console and format again the PC tools are able to access it perfectly. But then the hacked console will say it's empty (just as when it was on the retail after being formatted on hacked).

I believe this is a problem caused by the kernel patching. And considering that this HM020GI drive isn't very common Ikari360 (the said author of the kernel patches) would not have one to test. Maybe the same issue happens with non standard drives.

ST920217AS (SEAGATE) is more common and worked fine with both hacked and unhacked boxes at same time. I happen to own one spare loose of this drive (from an PS3) and after I pasted the HM020GI HDDSS.BIN in it (just to have Xport accept it as a valid 360 drive) it worked properly.  I know this model is common on official hard drives.

MHY2040BH (Fujitsu) also works correctly on both hacked/nonhacked consoles and with the PC tools.

Now completely non standard HDDs seem to aways cause problems with the PC apps.
MK8052GSX (Toshiba, 80GB) works properly with the hacked console but does not work with PC apps. Testing on a normal console is not possible (It has no matching/proper HDDSS.BIN)

In conclusion I believe this has something to do with the unusual size of these troublesome drives. I believe it would be easier to fix on the rebooter side of things than on the apps side as you can see the "bug" may causes issues with some legitimate/original drives.

Neither I was being mean or anything of the sort. I just wanted to emphasis what I said earlier as I am also thinking about the possibility of other people reading this thread. So don't think I'm angry or anything. I'm not... lol

Again, very understandable. To help you a little further I'll post this:

Xenon console, CB 1903
00: C0FFFFFFFFFFFFFF \  I believe these two are used to differ the system from DEV to RETAIL.
01: 0F0F0F0F0F0F0FF0 /
02: 0F00000000000000   <-   CB 1903
03: XXXXXXXXXXXXXX  \  These two are doubled...      1st half of CPU key
04: XXXXXXXXXXXXXX  /
05: XXXXXXXXXXXXXX  \  So are these.                     2nd half of CPU key
06: XXXXXXXXXXXXXX  /
07: FFFFFFFF00000000   <- Fusebits for updates. They blow 4 bits on each update so an extra F will show up here each time you update.
08: 0000000000000000
09: 0000000000000000
0a: 0000000000000000
0b: 0000000000000000

Jasper, CB 6723
C0FFFFFFFFFFFFFF
0F0F0F0F0F0F0FF0
0000F00000000000    <- CB6723
XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
FF00000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000

If you flash a hacked image onto an "fixed" (updated) board you will get 3RLOD with secondary error code 0022. So it's possible to test. It's just that there's a good chance you might be wasting time with it. With a XELL image, you don't even need to worry if the system is software-bricked, if the hardware is in perfect working order and the JTAG hack wired up properly it will boot onto XELL. That actually allowed me to unbrick two XBOX360 consoles that failed updating due to power outage.
 

Of course the person who had the idea to setup the write protect, test it and posted it on X-S never had bad intentions, but of course the person forgot to think of eventual collaterals/side effects such a mod could have.


Not at all but it won't work. Restoring the original image would then be necessary to make the system work again.
Like I mentioned on other thread, even a system that has E74 will boot the hack...
But once the revocation fuse is set, kiss JTAG goodbye on that CPU chip.

Dump a megabyte or two of the flash (use 0 50 on the end of the nandpro command line to dump about 1.5mb) and hexedit that to find out the CB version.

You can't create a keyvault with xell.
At this moment you can't run any keyvault besides the original one that came with the console. If you try it will "Christmas lights" (you will know what it is once you try). Current keyvaults contain the CPU key for the console and some nasty hashing so you can't swap them around neither you can edit them.

I'd say your best shot is try to extract whatever is on that mobo flash chip.
For the current rebooter (XBR) all you need is the keyvault and the config block. It got to a point you don't even need to know the console CPU key for booting XBR.

You fried the southbridge "tray status" pin. So it thinks the tray is in middle of either closing or opening then the power led will never stop blinking and it will keep sending the eject command for the DVD drive.