Excuse me.  Xenon DOES NOT NEED aud_clamp because there's plenty of unused IO pins on the XSB chip for us to "borrow" for sending the JTAG commands.

Even, the Xenon SMC even have an separated IO pin being used to toggle the JTAG PORT RESET pin, which on HDMI consoles is simply connected to the +v for the GPU.

On HDMI consoles the pins are used to control the extra functions of the "new" analogic outputs chip (hence the name "ANA/HANA" and HANA stands as "High definition ANA")

So it's fine if your Xenon JTAG has no aud_clamp fix as it's useless on a Xenon.  Just chill ...  

Wait, WHAT ?  MS returned an console to a customer WITHOUT blowing the old CB revocation fuse ?

And creates a WHOLE lot of new problems.  Stay away from the pigsty

I believe that the real maximum is 8 devices (transmitter + 4 controllers + 3 wireless headsets) .

Standard BT limits the number of devices as eight and the initiator (BT antenna) takes one of the eight slots.

http://www.bluetooth.com/btmicro/faqs.html


XBOX360 wireless is no Bluetooth system, but it seems to be based on it and because of that it's possible that it relies on similar hardware implementation, but still using different software protocols. 

So I'm tossing an educated guess that no more than seven wireless devices can be connected to a XBOX360 console and be active at a given time.

Also, the number of controllers seems to be *soft capped* at four in kernel level.

Nope, that's not right, because the instructions I gave are for small block consoles.

If I had an large block console I could try something.

I believe that the smc_config file for a JASPER_BB console is 64KB, not 16KB....

Also, straight from nandpro help:

Meaning that it's +W, not -W for the command.  (But -W works and I don't know why lol)

With nandpro and files on your HDD:

You can either move the config block from a image file to another or you can simply flash it straight to the console if it's hooked to the PC through SPI.


To dump the smc_config from a flash image:

nandpro file.bin: -R16 smc_config.bin 3DF 1

To write smc_configbin into a flash image:

nandpro file.bin: -W16 smc_config.bin 3DF 1

(Please OBSERVE that R and W commands are in uppercase.)

To dump the smc_config from a console through SPI:

nandpro LPT: -R16 smc_config.bin 3DF 1
nandpro USB: -R16 smc_config.bin 3DF 1

To write smc_configbin into a console through SPI:

nandpro LPT: -W16 smc_config.bin 3DF 1
nandpro USB: -W16 smc_config.bin 3DF 1

External things like the controllers (wired and wireless), the wireless headset, wifi add-on, camera, kinect do have the security chip I mentioned.

Obviously the 4GB memory board does not as it's just a generic pendrive with a different format on the board. Also the wifi module have the security in it's firmware so the XBOX security is chip not needed.

It's possible, yes. But keep in mind that only XENON has independent speed control for each fan.
On all HDMI consoles only one PWM (speed control) exists for both fans.

How silly of you edit your own message ... 
It was a good question...

The MU slots on a older console are "special" as in the kernel expects the authentication data from the 8 pin "XBOX" chip that exists into the original MU.

That kind of experience you're proposing is not very useful ... lol

But I suppose that if it keeps you entertained then it's a good thing

The problem is that up to a certain version of the flashtool if you opened a image and then saved it would modify some stuff that would break the rebooter.

I don't know if that got changed. You know the wording "better safe then sorry".

And it's a pain in the b*tt open a console to flash through SPI if you can flash it in simpler ways.

You will brick the console if you do that.  That's why I said to rebuild the image with the new config block on the rebooter.

when editing the config, do not use the saved dump. Extract it's smc_config file using flashtool and put on the rebooter build files. Build the rebooter again with the new edited smc_config.

It's possible to flash only the edited config block if you have the 360 rigged to the PC instead of flashing the whole rebooter again:

nandpro lpt: -W16 smc_config.bin 3DF 1

With an normal flash (pre CD8453) if you try to update, the updater will first try to blow the CPU fuse, then it will try to install the updated CB (be it 1923, 1940, 5771 or 6750).

If blowing the efuse fails(hardware mod), it will quit trying and will show an error message.

Now, while you're using the rebooter, the flasher will read the CPU fuses and will see the new CB fuse blown (the new CB won't boot with the fuse not blown) so it goes straight to the patch slots (CF and CG 1 and 2). 

I believe the current updaters are deliberately programmed to erase 4532 or 4548 from the patch slot if it finds such update patches there.

So if you try to update while running a rebooter there's a chance that the update happens.

During the reboot after the update when the new kernel starts the fuse could be blown, bricking the console (which will be still with the old CB but likely will have the new CD 8453 installed) 

I know that with the efuse blowing mechanism blocked it will surely brick as both path slots will be deleted. But CB and CD were not overwritten.

That does NOT work that way.

An OFFICIAL/ORIGINAL image will never boot on a console which isn't it's original console.

Replacing a KV only works with rebooter images because they exploit something called "zeropaired image" which exists to allow MS to initialize and un-brick consoles (at factory and service centers).


Zero Pair images will boot on *ANY* console but normal ones need LDV and pairing data match to boot. If that's wrong you will get a nice 0022 RLOD.

If the efuse blowing block is in place during the update the console *will* brick but you can simply flash it again with SPI.

If it has a JTAG but is updated with an normal update there's a good chance it will fail during the update resulting on a blown fuse and a brick (SPI flashing will not allow you to boot games in it) or it can just finish updating fine.

I believe the example you mentioned was first without protection and got updated to 8955 then the person tried to block the fuses and update to 9199, which got it stuck at E80.

I suppose they changed the behavior of the update mechanism to make sure the unit borks if you keep fuses from blowing.

They're returning units which were denied service on "factory mode" now (blinking 2 red/2green). Even if they were working but had a DVD drive problem, for example.

I think it was updated while being a JTAG and instead of bricking it just finished updating. It did E80 while trying to update from 8955 to 9199. AFAIK, if you remove the EFUSES jumper it will finish updating then will boot into the dash.

Yeah ... then a few months in the future your kid goes to your neighbor borrow a game disk and shove it on your JTAG. He then presses yes on the update prompt.

You will have:

An XBOX360 console with both update slots zeroed out, CB updated to non JTAG version and CPU fuse blown (no return to the original condition).

Believe me it happens. I already "unbricked" two which were like that. (CPU fuses are blocked on all I do)

Good point. I didn't think of that.

Yes, because the nature of the damage caused by the heat is pretty random.

Only real repair is GPU replacement. Even MS learned that at some point, when they stopped to re-manufacture Xenon boards and started to replace with Opus(HDMI-less Falcon boards) boards.