Giter Club home page Giter Club logo

gmp-z003's Introduction

Synopsis

Set of information and tools whilst working with my M3i Zero (GMP-Z003) and it's firmware. Use this information however you want.

Hardware

Image of the carts PCB Image of the FPGA

Flash Memory

The GMP-Z003 uses a MX29LV160DBXEI-70G for flash memory, it is a 2MB chip. This device operates over a voltage range of 2.7V to 3.6V typically using a 3V power supply input. The flash memory is read directly to the NDS as a cartridge, the format of which can be found here. It is writeable through the flashing process.

Flashing

The device can be flashed by providing DC power to the J3 port. I just stripped a USB cable and put the positive and ground in. The FPGA searches the SD card for /F_CORE.DAT and copies 0x200000 -> 0x400000 to the flash memory chip. I believe the F_CORE.DAT needs to be signed in order for the FPGA to copy it first however.

The LED light D1 will change depending on the status of the flash:

  • Nothing: No power or completed
  • Static: Error reading F_CORE.DAT (SD card might not be inserted, etc..)
  • Flashing: Copying F_CORE.DAT to the flash memory.

Alternatively the device can be flashed whilst inserted via the DS itself using card commands.

Card Commands

The common DLDI interface for the flash cart can be found here: G003.dldi And the reconstructed C source of that DLDI interface can be found here: iointerface.c

  • B0 00 00 00 00 00 00 00 = Card Info (should be 0x5AA5)
  • C9 oo oo oo oo xx 00 00 = Read (FIFO read 0x200 words)
  • C5 oo oo oo oo xx 00 00 = Write (write 0x200 words)
  • C6 00 00 00 00 00 00 00 = get write status, read 1 word (= 0 when finished)
  • CA 00 00 00 00 00 00 00 = get read status, read 1 word (= 0 when finished)

Where oooooo is the offset in number of words(?), MSB first Where xx represents the type in the DLDI interface this is set to 0x00 for SD card access.

  • 0x00 : SD card access afaik.
  • 0xE0: "SW" header, used with offset = 0, after that offset += 0x10000 (in number of words)
  • 0xF0: "SW" regular sector (0x200 bytes)
  • 0xA0: "HW" sector. One sector (header ?) is at 0x80000000 then the others start at offset 0.

Credits

  • TuxSH for everything on card commands.

gmp-z003's People

Contributors

handsomematt avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar

Forkers

wlcd lifehackerhansol

gmp-z003's Issues

Other model(s)?

The PCB of my M3i Zero GMP-Z003 isn't exactly the same as yours.
It uses a W19B160BBT7H for flash memory.
It seems to be the same as a MX29LV160DBXEI-70G but i took some pictures anyway.

IMG_20190531_184813
IMG_20190531_184247
IMG_20190531_185659
IMG_20190531_185505

Can you compile the ntrboot_flasher tool?

Hi, I'm pretty noob with github and with hacking in general, so I was wondering if you could compile a z003_ntrboot_ds(i).nds file, since I have no idea where to start (sorry...). I tried to do it myself, but to no avail, I don't even know if this is the right section to post these kinds of requests (sorry again if I messed up).

The thing is that I have an gmp-z003 flashcard around and I'd like to use it to hack my 3ds with ntrboot, so if you could help me that would be really nice :) Thank you.

Figuring out the checks embedded in `ioM3LogicCardRead`

In the adventure of reconstructing the DLDI (I was working on it independent of this repository), I can't get reads to work in any reliable capacity.

The 0xCA command is doing something weird; it's checking the address of the destination and will either use an inlined cardPolledTransfer (or at least what seems like it) or the normal cardPolledTransfer. The check is definitely doing something; running the DLDI from VRAM causes it to go complete haywire and crash. But not even a direct copy-paste from a decompiler is fixing it.

The reconstructed DLDI found here also seems to lack the buffer address check. Would this be something you're willing to observe? I'm really lost on this weird quirk.

`ioM3LogicCardRead` and `ioM3LogicCardWrite` have incorrect CARD_COMMAND order

For SDIO (uncertain about flash IO), the MSByte of the sector address is actually CARD_COMMAND[7].
CARD_COMMAND[1-3] are the following bits.

So it should in fact be:

  command[7] = 0xC9; // GMP-Z003
  command[6] = (address >> 16) & 0xff;
  command[5] = (address >> 8)  & 0xff;
  command[4] =  address        & 0xff;
  command[3] = 0;
  command[2] = 0;
  command[1] = 0;
  command[0] = (address >> 24) & 0xff;

Alternatively:

u64 command = (0xC9ull << 56) | ((u64)(sector & 0xFFFFFF) << 32) | ((u64)sector >> 24 & 0xFF);

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.