Homebrew The bootroms

[sirocyl]

MCU hax can and will brick if you fuck up.

From my understanding, the SoC (CPU, GSPGPU, etc) is still able to init with a busted MCU, and the MCU isn't in between the CPU, Bootrom, or NAND, so it will continue to load an a9lh payload from the SD card.

afaik, PMIC (The power management chip, which has no user-serviceable firmware) handles the power button before MCU does. This is likely due to a factory preinstall condition.
You can probably hotwire the PMIC or SoC to power-up the system, too.

What this means, is that using I2C commands from arm9loaderhax, you can reflash a clean MCU firmware, and then when you power-cycle the machine, it should be working.
The screen (at least, the backlight) will not be able to initialize until the MCU is fixed, however.

 

[ketal]

From my understanding, the SoC (CPU, GSPGPU, etc) is still able to init with a busted MCU, and the MCU isn't in between the CPU, Bootrom, or NAND, so it will continue to load an a9lh payload from the SD card.

afaik, PMIC (The power management chip, which has no user-serviceable firmware) handles the power button before MCU does. This is likely due to a factory preinstall condition.

What this means, is that using I2C commands from arm9loaderhax, you can reflash a clean MCU firmware, and then when you power-cycle the machine, it should be working.
The screen (at least, the backlight) will not be able to initialize, however.

If I'm not wrong, you could still have the LEDs as state indicator via I2C (assuming someone managed to mess with those registers without bricking)

 

[sirocyl]

If I'm not wrong, you could still have the LEDs as state indicator via I2C (assuming someone managed to mess with those registers without bricking)

I don't think LEDs can be used, considering that at least the notification, power and WiFi LED's seem to come off of the PWM pins of the MCU, and it's assumed that the charging and low battery light do too.
Ircomm using the SIR hardware module, as IrDA UART, might be a possible solution.

 

[yifan_lu]

If someone sends me a PARTNER-CTR device, I have some ideas of attacks there

 

[Deleted User]

If something happens to the bootroms, could we get stuff like the OTP on 11.0?

 

[Ev1l0rd]

If something happens to the bootroms, could we get stuff like the OTP on 11.0?

AFAIK, yes. It would mean the 3DS is fully hacked and Ninty would have to release a hardware revision to patch it.

 

[Reisyukaku]

If someone sends me a PARTNER-CTR device, I have some ideas of attacks there

PARTNER Debugger (and i assume the same for PARTNER-CTR) can only touch userland apps since it uses the dmnt and debugger modules to talk over HIO to the computer. But if you have ideas around that, im listening =)

 

[yifan_lu]

PARTNER Debugger (and i assume the same for PARTNER-CTR) can only touch userland apps since it uses the dmnt and debugger modules to talk over HIO to the computer. But if you have ideas around that, im listening =)

The FPGA is just an Altria Cyclone. The SDK references JTAG although the PARTNER Debugger does not use it. The existence of the files and symbols means that perhaps we can reconfigure the FPGA to enable JTAG access. With JTAG you can freeze the unit on boot and dump the boot rom.

 

[Psi-hate]

The FPGA is just an Altria Cyclone. The SDK references JTAG although the PARTNER Debugger does not use it. The existence of the files and symbols means that perhaps we can reconfigure the FPGA to enable JTAG access. With JTAG you can freeze the unit on boot and dump the boot rom.

Pretty sure Normmatt has a PARTNER CTR so you could ask him in case nobody else is willing to try it.

 

[yifan_lu]

Pretty sure Normmatt has a PARTNER CTR so you could ask him in case nobody else is willing to try it.

I doubt he wishes to brick his unit. I would take it apart and solder shit to it.

 

[sirocyl]

If the PARTNER unit has an identical bootrom to the retail unit, then shouldn't it be that the SoC is the same?
If the SoC has JTAG pins on it, which are just hidden/NC on the retail board, then it should be possible to do some hot rework to pop the chip into a BGA breakout socket, and meticulously wire it into the board where needed.
Though, I may be a little insane and/or masochistic, and I don't actually "know" the hardware of the dev/partner units, so yell at me if this is an unsound train of thought.

 

[dankzegriefer]

If the PARTNER unit has an identical bootrom to the retail unit, then shouldn't it be that the SoC is the same?
If the SoC has JTAG pins on it, which are just hidden/NC on the retail board, then it should be possible to do some hot rework to pop the chip into a BGA breakout socket, and meticulously wire it into the board where needed.
Though, I may be a little insane and/or masochistic, and I don't actually "know" the hardware of the dev/partner units, so yell at me if this is an unsound train of thought.

It doesn't.

 

[chaoskagami]

From my understanding, the SoC (CPU, GSPGPU, etc) is still able to init with a busted MCU, and the MCU isn't in between the CPU, Bootrom, or NAND, so it will continue to load an a9lh payload from the SD card.

afaik, PMIC (The power management chip, which has no user-serviceable firmware) handles the power button before MCU does. This is likely due to a factory preinstall condition.
You can probably hotwire the PMIC or SoC to power-up the system, too.

What this means, is that using I2C commands from arm9loaderhax, you can reflash a clean MCU firmware, and then when you power-cycle the machine, it should be working.
The screen (at least, the backlight) will not be able to initialize until the MCU is fixed, however.

From what you say, the MCU can only be softbricked and won't cause a bootrom error. That's interesting, because it means one can go nuts testing this stuff with zero fear if by flashing arbitrary MCU firmwares.

Three questions: Do O3DS MCU firmwares work on N3DS? If 3dbrew is correct, the firmwares are identical aside from the version. Two, are there any i2c commands to READ the MCU firmware? There's nothing documented on that. And three, if by some chance we get the timing correct to cause a hardware fault and load code, is the SoC going to be in an unstable state?

(Also: I think the PARTNER unit is a dead end. Not too many people have them, and I doubt anyone who does wants to destroy it. And I get why.)

 

[sirocyl]

I'll answer those in stack order.

If we punch the SoC with an NMI at the right moment, and the exception handlers are in our control, the SoC will not be in an unstable state, unless we fault in the code, triggering a double-fault - because then, it would jump back to our exception handler, possibly trigger a third exception and freeze up.
We can't return from the exception vector to clear a fault, because that would put the instruction pointer right back at bootrom.

I haven't heard of any commands to read-out MCU firmware from the chip - Nintendo handles it as a one-way, write-only memory. There are registers for retrieving data from the MCU binary, like firmware version - so there is a good chance a byte/block read command exists on the i2c interface for MCU.

The MCU firmwares should be identical - large differences were noted in the post-2DS and post-n3DS releases of MCU firmwares, though, so using an older MCU on a newer system will probably leave it in an unhandled state, disable some functions, or even cause damage to other functions (Display backlight PWM and voltage comes to mind - the 2DS screen is very different from the 3DS displays.)

 

[TuxSH]

NMI

Does the 3DS's ARM9 have a NMI though?

 

[ketal]

Does the 3DS's ARM9 have a NMI though?

afaik, no

 

[sirocyl]

From what I've read, the ARM9 processor serves two interrupt states, an IRQ and an FIQ. It does not have a generalized NMI, although FIQ is sometimes used as such.
Sorry if I confused anyone, I'm still learning as I go along with this.

 

[TheReturningVoid]

When this thread isn't just memes and shitposts, I feel like I'm learning stuff. I have little to no knowledge of low-level hardware/software, so this is all a really interesting read. If there's anything to test hardware-wise, I have a O3DS XL that I killed with a failed hardmod, so if that could be of use to anyone, just let me know.

 

[sirocyl]

When this thread isn't just memes and shitposts, I feel like I'm learning stuff. I have little to no knowledge of low-level hardware/software, so this is all a really interesting read.

I'm glad. Reverse engineering is a really interesting field.

I have a O3DS XL that I killed with a failed hardmod, so if that could be of use to anyone, just let me know.

How "killed" is it? Could the traces be repaired with a bit of work? Was there a successful a9lh install on it? Had you taken a NAND dump beforehand? xorpads?
I know I'm asking a ton of questions, but some things will make it easier to work with.
I won't be able to do anything for a long while, regardless. If the NAND really is unrepairable/the board is dead, then I'm not the right guy to send it to at the moment.
There may be others, who are interested in your SoC and MCU chips, and the raw board for tracing/delayering, however.

Has the CTR-CPU board (the motherboard, not the SoC) substrate, or any of its relatives in the 3DS Family, been delayered yet? Is there a schematic? I'd say that's an appropriate plan of action for this task.

 

[TheReturningVoid]

I'm glad. Reverse engineering is a really interesting field.


How "killed" is it? Could the traces be repaired with a bit of work? Was there a successful a9lh install on it? Had you taken a NAND dump beforehand? xorpads?
I know I'm asking a ton of questions, but some things will make it easier to work with.
I won't be able to do anything for a long while, regardless. If the NAND really is unrepairable/the board is dead, then I'm not the right guy to send it to at the moment.
There may be others, who are interested in your SoC and MCU chips, and the raw board for tracing/delayering, however.

Has the CTR-CPU board (the motherboard, not the SoC) substrate, or any of its relatives in the 3DS Family, been delayered yet? Is there a schematic? I'd say that's an appropriate plan of action for this task.

One of the contacts came out while soldering a hardmod to it after restoring a NAND backup that didn't copy over properly to the SD Card (I kept telling my dad to stop soldering on his lap. Clearly he didn't listen). I never got a9lh onto it, I bricked it going from 2.1 -> 9.2. I have the OTP is it helps at all, but I don't have any xorpads. I may have some of the nand dumps of it somewhere, I'll have to look.