Rebooter - Alternatives to Cygnos360 v2?

[Grim187]

im not ready to shell out $70 + ship for a Cygnos360 v2 without first exploring all my options.

how is the rebooter communicating with the Cygnos360 v2 and can this be duplicated without a microcontroller or ignored while the nand is switched? (to a 2ndary chip)

would it be possible to use a bigger tsop48 say 256mbit (32mb) for a multibank nand?

[iLLNESS]

i dont see why you couldnt use a larger tsop for dual nand.. but i dont know that there'd be any benefit for a rebooter.

i think cygnos is the only solution for rebooters as of now

[iLLNESS]

it might be worthwhile to take a glance at this thread:
http://www.xboxhacker.net/index.php?topic=8737.0

it seems theres some people already asking about the larger nand

[Grim187]

thanks, i gotta start reading.

[Shaun]

Im assuming they are using the smc code to talk to the cygnos to swap banks.
iirc, when the cygnos was released they had a patched smc so that the hack would work with it so its only an extension (plus others) of that

[cory1492]

Freeboot is not tinkering with SMC code at all as far as I can see, unless the cygnos flasher does something in between.

It looks to me like freeboot uses the SMC untouched from falcon/xenon_hacked file (meaning with the jtag exploit code embedded.) Because of that I don't see any real indication this was originally intended to be cygnos only, it's just simpler/better to not have to initialize (and thus find a way to reset) other hardware (like all the hardware required to compose and show a message to flip a switch on the screen - not to mention, just flicking a switch isn't going to wait for RB to go high before swapping CE which could easily corrupt a NAND and isn't necessarily going to put the second NAND in a ready state, as some folks with XD mods found out.)

I'd advise patience, there is no telling which direction this "unknown" coder is actually going in (though considering some of the mis-info out there, cygnos has to be enjoying this boost.)

Anyone with this working willing to catch a log of what happens on serial during successful "freeboot"?

[Shaun]

looking back

-We have added the possibility to communicate from "Xell" to Cygnos360 V2, for example to switch kernel via software command. (hotswap)
-We have added the functionality to enable switching between kernels having different SMC versions. It is not necessary to unplug the console for kernel switching, which is the case on current homebrew nand switchers and XD card solutions.
- Since our microcontroller cannot handle serial communication at 115200 baud, we had to make a minor modification to XeLL. The modification will set the baud rate register of the Xbox 360 to 38400 baud, 8 data bits, no parity and one stop bit.

They only changed xell to OP @ a slower baud - my apols. Must be some other way then

[l-tyrosin]

Anyone with this working willing to catch a log of what happens on serial during successful "freeboot"?

"SWITCH" is the key.

[Redline99]

I've only done a little peeking.



"!SWITCH" 

[l-tyrosin]

got me there mate suppose i shouldnt have assumed 32bit alginment guess who cant calculate LOL
nb: instead of a delay, u could add a response, more reliable, but w/e works

[cory1492]

I figured it was "!SWITCH" with a hex editor, though without a log is it safe to assume that 'putstring' is outputting to the serial port on J2? Can't tell for myself if that is actually doing the switching though as I know it could be simple as sending a unacceptable command to the NAND chip which cygnos interprets.

Only other thing that bothers me now that Shaun mentions it is the SMC reset. I'd presume this can be done by software?  Or is that what the cygnos connection to FT2N3 is for? (though by trying to trace it, it looks like it goes directly to HANA and I can't imagine why a chip like that needs a connection to HANA.)

Any rate, despite those doubts I do believe reboot could be reproduced without $70 hardware but would need to be much more complex to do so. Using a small/cheap micro to replicate at least some of the switching along with an external nand should be preferred over having to patch the code to use a single larger nand.

[Redline99]

it only uses the smc to query the dvd tray state, if fully open it runs xell, if not it does rebooter
(if someone with the setup wants to confirm for me, please)

hehe just read this in the readme... so uhmmmm yeah.

   16. Power on your Xbox 360. If everything went correctly, you should see the
       blue LED light up a few seconds later, followed by the usual boot
       animation. If you power on your Xbox 360 with the DVD tray eject button,
       XeLL will be loaded instead.

[MastaG]

I guess 50 euro's isnt that expensive.
You get the possibility to keep playing the latest games using the latest dash, and run XeLL for homebrew.

[Badger101]

So it should be quite easy to emulate the Cygnos360 v2 with a Pic?

The two CE lines from the Nands get controlled by the Pic.
The Pic also has the tray status line (FT2N3?), and the comms line (Via J2?), so it knows which Nand to enable and also when to switch.

Or am I missing something?

[damox]

So it should be quite easy to emulate the Cygnos360 v2 with a Pic?

The two CE lines from the Nands get controlled by the Pic.
The Pic also has the tray status line (FT2N3?), and the comms line (Via J2?), so it knows which Nand to enable and also when to switch.

Or am I missing something?

Where is your other nand.

[Badger101]

Where is your other nand.

This would be for people who have a dual Nand box already (like me), controlled by a switch and don't want to/shouldn't need to get a Cygnos.

[B1N4RY]

Except that you'll need to switch to the second NAND exactly when XeLL calls for SWITCH, or the kernel will not boot if you switched it late.

[cory1492]

I thought of that too B1N4RY but that is not the main problem, a delay with a RO-light change wouldn't be difficult to insert into present bin (even for me now that the relevant code has been pointed at.) The problem is the corrupt NAND that people with dual NAND setup encountered when live switching them, as well as what Shaun mentioned in quoting cygnos (SMC reset.)

Redline99: thank you for constantly sharing screenshots of what you are talking about, they've helped me related to the disassembly I've been looking at much better even on other platforms (I am a visual learner, if I can "see" it I understand it and IDA/assembly has always been tough for me to "see" so every example of reverse helps - one day soon I hope I will be proficient.)

Badger101:
See what Redline99 just posted there? Tray status is taken care of by SMC which is accessed to do the decision through cpu code in freeboot.bin - cygnos v2 still uses a physical switch rather than monitor tray status (so it is also conceivable you could reverse on it which nand is flashed with what provided the switch command isn't device specific and just switches.)

Controlling the CE lines with a small/cheap PIC or similar micro (preferably 3.3V compat.) should be easy, though 38400 uart (even if receive only) is pretty fast for most PIC on internal osc. to handle. Catching !SWITCH on serial to set up to do the deed (and monitor R/B for safety just before switching) seems to be about all that is needed (provided micro startup delay isn't an issue at plugin) - though the problem missed is the same one I mentioned, I hadn't considered cygnos is dealing with SMC reset and I've found nothing clear on how that is done.

What I do know now though, after some hours reading and searching in trying to do my due diligence to support my belief:
- first, that SMC code from NAND apparently has no soft reset vector to reload itself from NAND
- speedy documented FT2N3 as having something to do with southbridge ("ON/OFF  Power On" is all xbox360southbridge13.pdf says); what this means exactly I don't know and lack the tools that could tell me (speculation: perhaps it could be used to reset southbridge, which would make a chainload somewhat simpler in that it would in a way reset the devices attached to it, or even just the smc the same way as a 8051 could be reset by pulling high for a couple cycles; without a LA to know what it is doing in normal use I'm very hesitant to try anything with this southbridge point. For all I know at this point they could be using it to detect if the box is coming on to pull cygnos out of sleep.)
- possible jtag commands outside of the ones used in the exploit == ? (another way via cygnos' wiring to reset SMC which I have been trying to ignore as a possibility)

Regarding that last one, I'd find the possibility highly unlikely, but very little info seems to exist on the 360 JTAG ports. For example, try to find the CPU JTAG command to read out POST here.

[l-tyrosin]

in that case, wire up a pulse circuit to do it? like a resistor from a gpio to ft3n2 and modify smc but i doubt its this easy

[gupek]

maby it will be possible to have binary of nand on hdd and boot from there... ?