Hacking Unbricking EZ4 (poorly written and long-winded but successful for me))

[computarman]

Disclaimer; whatever you do to your cart is at your own risk. I bricked my Ez4 original cart by using GBA Exploader where the cart was not seen by NDS or GBA. Well if the system cannot see the cart you cannot update the firmware by holding right shoulder button. Well GBA Exploader can always see EZ IV and you can switch between writing modes by pushing the left shoulder button between psram and NOR. I would say the best thing to do would be to just not use GBA Exploader with EZ4 and I think this should have been made more clear. However I had fun playing with recovering my cart from a bricked state. So in order to restore the EZ4 you will have to have the USB EZ-Writer device designed to write to the old EZII and EZIII GBA carts that did not have the mini SD slot like the EZ4.So essentially the ez4 is just an ez3 cart with a mini SD slot added. So you can write to the cart memory regardless of the state of the firmware and loader. So you might have to play with some ezmanager software versions, but I believe 2.22b (last version I believe) works. Anyway after you get all your USB drivers going for the writer and the drivers are contained in the usb folder of the software and I only tried this on XP so I don't know how newer versions of windows would work. Anyway replace GBA loader with a full dump of the firmware (not the update). The full firmware dump is around 4 MB, so if the size is around 2MB then you probably just have the update and not the full firmware. I think the ez4 kernel collection is available on GBA temp downloads. So with the ez-manager software started and the light on the programmer on showing the drivers are seeing the device, replace GBA loader file with the full firmware dump and rename it to whatever the name of the GBA loader is called inside the SYSBIN folder. With the software started if you unplug the usb cable to the ez-writer the software should see the writer and cart and ask you if you want to update and if you say yes and it will try to update. Sometimes the update will get stuck and you can unplg the cable from the writer to get it to progress to teh end. If you have to unplug then you will not successfully update the firmware and will have to try again until you get the update to complete. It takes patience and I also wrote the 4mb firmware dump with GBA exploader to the psram and the nor of the cart before getting the firmware to complete. It seems to be a bit of voodoo to get the ez-manager to complete the update. Sorry for this poorly written guide, but I wanted to share how I successfully unbricked my ez4 and your mileage might vary and again whatever you do, you do it at your own risk. Contact me if you want me to give your cart a shot at revival and I would do it for a few bucks if you ship in continental US.

 

[FAST6191]

Interesting. I should note that there are basically three models of EZ linker though (more technically but as far as this is concerned call it three)
1) The original EZ1 and EZ2 one, probably will not work for this without extra hacking of EZClient or EZManager.
2) The original EZ3 one, probably will work for this.
3) The later combined EZ2 and EZ3 one. Here is where you would have had to use EZMode to select what you wanted to use.

If this is the case though I might have to look closer at some of cory1492's dump/restore tools and see if I can sharpen them up.

 

[how_do_i_do_that]

Somebody did use a EZ-Flash III writer before, they never said back if it worked or not. So I guess computarman's post confirms that it does work.

 

[computarman]

It surprised me that my experimentation worked since I'm an amateur and I found little info on all the boards from all the super geniuses. Even the main ezflash site does not have much help on unbricking the ez4 (sosuke). I tried Cory's tools and I tried running the different ones from slot 1and I usually got a fat 32 error or the program seems to just get stuck. Perhaps I was not doing something correctly. I also tried the boot strap restore program. I am trying to figure why I had so much trouble getting the update to finish, but my guess is that writing to nor with the full firmware dump with GBA Explodes must have been the reason. I'm not sure if the firmware for the cart resides in the NOR or a special chip for this purpose.

 

[how_do_i_do_that]

Mine wasn't broken back then. I just never bothered to dig it up since that thread disappeared with the forum upgrades back then.

 

[kuwanger]

I used my F2A linker to rip a copy of the EZ4 firmware--apparently back in 2009 according to the file date. I didn't really do much with the information (or try unbricking my working EZ4 and risk bricking it). But a quick search though my dump indicates that the common ROM NOR space starts at 0x1400000 (or 20MiB). So, while that doesn't indicate per se that its all big NOR block, it does at least indicate that even a simple F2A linker will see it all mapped together something like that. Really, if my EZ4 was bricked and I managed to successfully unbrick it once, I'd play around with seeing if much of that seeming empty space could be written and read back successfully. It might tell you nothing about the internal layout of the system, but it might give you a couple megabytes to secretly store stuff--which is more amusing than at all useful.

By, yea, congratulations on your curiosity. It's always good to be able to unbrick something.

 

[computarman]

I tried pulling a dump from F2A linker and I got a complete dump of a file named ezpda that is 32mb. I don't know how this file could be written to the card, unless ezmanager software would do it since f2advance seems to only be able to read from the ez4. I tried once again to use cory1492's dump/restore tools with no luck. This time I tried running the programs with another slot 2 card. Maybe cory's tools are for the lite or compact version of the ez4 rather than my ez4 which is the original I believe which is the normal GBA cart size. Now that my card is working properly I'm just playing around seeing what could be done knowing I think I can restore anytime if needed.

 

[Coto]

a guy once managed to install moonshell in the EZ4's NOR.

It was bricked, no joke. Because from GBA mode was just idle, but as soon you loaded NDS mode it booted moonshell 1 (i'm not sure how he did it..).

-

This is not EZ related, but careful with moonshell2-ysmenu modded (rom loader) binaries, upon booting them on both r4igold.cc (2) and an old Ninjapass X9, it rewrote spi flash area with zeroes, then, bricking those cards..

This is the loader that kills flashcarts:

http://www.mediafire.com/?vimwrm4dnr03dd4

Don't try it unless you can dump and reprogram your SPI chip..

 

[FAST6191]

a guy once managed to install moonshell in the EZ4's NOR.

To be fair there was also a beta loader based on moonshell for the EZ4 at one point. http://www.4shared.com/file/8898252/ac0df8b4/ezfla_up_1168842886.html should be it, the forums are crashed right now (I will speak to sosuke at some point and get them sorted again) but

Likewise with something like ezf3me on the loader section and moonshell on the NOR you could probably have something interesting.

 

[Coto]

To be fair there was also a beta loader based on moonshell for the EZ4 at one point. http://www.4shared.com/file/8898252/ac0df8b4/ezfla_up_1168842886.html should be it, the forums are crashed right now (I will speak to sosuke at some point and get them sorted again) but

Likewise with something like ezf3me on the loader section and moonshell on the NOR you could probably have something interesting.

exactly, the most interesting part was, the moonshell 1 loader was turned into DS.GBA (modified header) so it could run from the EZIV NDS mode.

This guy rewrote that binary on the NOR somehow (like large 32 MB roms are written), but he messed up EZ4's bootloader so moonshell 1 was loaded directly. EZ wasn't detected by anything.. tough he fixed it later, it was interesting.

 

[kuwanger]

Yea, I contemplated trying to do something like that at one point to effective turn the EZ4 in something similar to a 32MB NOR cart (as people have asked in the past for the feature). It should be as trivial as (1) running the NOR game on the EZ4 to load the proper SRAM file into memory and (2) creating and "updating" a short stub "kernel" bank switch to the NOR space (and possibly bank switch the SRAM) and jump to 0x8000000. The EZ4 team even went through the bother of creating a test kit/sdk (AFAICT it's actually for the EZ3--but the EZ4 seems to be internally an EZ3 glued to an SD card, so all the NOR parts still apply) and providing the source for it, so it probably wouldn't be that hard to actually create said stub kernel. Further, I did a bit of mucking around with the EZ4 kernel (for theming purposes) so I know it'd be possible to verify it there to. But then, I tried to implement LZ7 compression and had to write an SRAM blanking kernel stub to unbrick my EZ4 and that sort of put me out of any real interest in trying that again.

tl;dr - The EZ4 "kernel" is readily replaceable with your choice of any ~2MB program. But "direct" NOR booting is a bit harder.

 

[Coto]

Yea, I contemplated trying to do something like that at one point to effective turn the EZ4 in something similar to a 32MB NOR cart (as people have asked in the past for the feature). It should be as trivial as (1) running the NOR game on the EZ4 to load the proper SRAM file into memory and (2) creating and "updating" a short stub "kernel" bank switch to the NOR space (and possibly bank switch the SRAM) and jump to 0x8000000. The EZ4 team even went through the bother of creating a test kit/sdk (AFAICT it's actually for the EZ3--but the EZ4 seems to be internally an EZ3 glued to an SD card, so all the NOR parts still apply) and providing the source for it, so it probably wouldn't be that hard to actually create said stub kernel. Further, I did a bit of mucking around with the EZ4 kernel (for theming purposes) so I know it'd be possible to verify it there to. But then, I tried to implement LZ7 compression and had to write an SRAM blanking kernel stub to unbrick my EZ4 and that sort of put me out of any real interest in trying that again.

tl;dr - The EZ4 "kernel" is readily replaceable with your choice of any ~2MB program. But "direct" NOR booting is a bit harder.

i'm interested in this as well.. by "bank switch" you mean a hack to redirect actual rom image offsets so they're replicated as pointers, starting from 0x8000000? (gba memory address)

This, would be to keep a real cart structure, "mounted"?

 

[kuwanger]

Not exactly. GBA roms start at 0x8000000. All static offsets in a ROM are based upon that presumption. Flash carts remap, with varying degrees of granularity, their (various) available internal storage so that the start of that storage begins at 0x8000000.

For the EZ-Flash 3-in-1, from triplecard_sample src, dsCard.cpp:

void SetRompage(u16 page)
{
        *(vuint16 *)0x9fe0000 = 0xd200;
        *(vuint16 *)0x8000000 = 0x1500;
        *(vuint16 *)0x8020000 = 0xd200;
        *(vuint16 *)0x8040000 = 0x1500;
        *(vuint16 *)0x9880000 = page;
        *(vuint16 *)0x9fc0000 = 0x1500;
}

And from main.cpp:

...
consolePrintf("--3--start PSRAM check.\n");
...
SetRompage(384);
...

The relevant part is "384" is passed as "page" to "SetRompage". PSRAM, btw, is the RAM part of the EZ3-in-1. So, internally PSRAM would appear to start on page 0x180 and I think full offset 0x9000000--I base this on libfc_ez3 from the defunct Pogoshell support of the EZ3 that a page is 32768KiB big, while I get the impression the EZ4 uses 4096KiB pages.

For the EZ4, the NOR where the kernel (and kernel flasher before it) are stored at page 0x8000 or full offset 0x8000000--the latter of which I'm pretty certain about because it's a core part of the reset code for the EZ4 and makes perfect sense (whether on start or reset, the GBA jumps to the default location of 0x8000000 to begin ROM execution).

From what I said earlier, though, it would appear the 32MiB NOR space for a game is at offset 0x1400000 in the EZ4, or 0x94000000 internally (ie, add 0x8000000). That doesn't really line up with the EZ3-in-1 from earlier, so perhaps the PSRAM in the EZ4 occurs earllier--something like 0x8000000 for the kernel, 0x8400000 for the PSRAM, and 0x9400000 for the NOR? But, then, I don't know if the EZ4 deluxe uses a different kernel. If they all use the same kernel, then the above doesn't add up either. Anyways...

So, if I presume the page for the 32MiB NOR is 0x9400, then it'd seem to be as simply as copying SetRompage(), a "SetRompage(0x9400);", and an execute 0x8000000 ("((void(*)(void))0x08000000)();") to RAM (so the code doesn't get bank switched out half-way through executing) to execute the 32MiB NOR. But, like I said, that's a presumption. And I don't want to risk bricking my EZ4, even if it's a really small probability.

Edit - I noticed the ">> 15"/">> 12" discrepancy between the EZ3/EZ4, but I'm not entirely sure if that's real either--dslinux seems to use a slightly different SetRompage() for the EZ4 which comments about PSRAM mode implying that NOR and PSRAM (and maybe the kernel) have different magic knocks. So, I tried to correct the above to make it clear that I'm even further speculating than my already speculating. :/ Regardless, I don't think I'd brick my EZ4. I just don't think it'd work and I wouldn't know how to debug it/fix it if it didn't, so I haven't bothered trying. And that sounds like a really bad excuse.

 

[Coto]

Not exactly. GBA roms start at 0x8000000. All static offsets in a ROM are based upon that presumption. Flash carts remap, with varying degrees of granularity, their (various) available internal storage so that the start of that storage begins at 0x8000000.

For the EZ-Flash 3-in-1, from triplecard_sample src, dsCard.cpp:

void SetRompage(u16 page)
{
        *(vuint16 *)0x9fe0000 = 0xd200;
        *(vuint16 *)0x8000000 = 0x1500;
        *(vuint16 *)0x8020000 = 0xd200;
        *(vuint16 *)0x8040000 = 0x1500;
        *(vuint16 *)0x9880000 = page;
        *(vuint16 *)0x9fc0000 = 0x1500;
}

And from main.cpp:

...
consolePrintf("--3--start PSRAM check.\n");
...
SetRompage(384);
...

The relevant part is "384" is passed as "page" to "SetRompage". PSRAM, btw, is the RAM part of the EZ3-in-1. So, internally PSRAM would appear to start on page 0x180 and I think full offset 0x9000000--I base this on libfc_ez3 from the defunct Pogoshell support of the EZ3 that a page is 32768KiB big, while I get the impression the EZ4 uses 4096KiB pages.

For the EZ4, the NOR where the kernel (and kernel flasher before it) are stored at page 0x8000 or full offset 0x8000000--the latter of which I'm pretty certain about because it's a core part of the reset code for the EZ4 and makes perfect sense (whether on start or reset, the GBA jumps to the default location of 0x8000000 to begin ROM execution).

From what I said earlier, though, it would appear the 32MiB NOR space for a game is at offset 0x1400000 in the EZ4, or 0x94000000 internally (ie, add 0x8000000). That doesn't really line up with the EZ3-in-1 from earlier, so perhaps the PSRAM in the EZ4 occurs earllier--something like 0x8000000 for the kernel, 0x8400000 for the PSRAM, and 0x9400000 for the NOR? But, then, I don't know if the EZ4 deluxe uses a different kernel. If they all use the same kernel, then the above doesn't add up either. Anyways...

So, if I presume the page for the 32MiB NOR is 0x9400, then it'd seem to be as simply as copying SetRompage(), a "SetRompage(0x9400);", and an execute 0x8000000 ("((void(*)(void))0x08000000)();") to RAM (so the code doesn't get bank switched out half-way through executing) to execute the 32MiB NOR. But, like I said, that's a presumption. And I don't want to risk bricking my EZ4, even if it's a really small probability.

//for specific ez-3-in-1 hardware
0x9f30000 -< d2 00 (53760 bytes long) //more embedded arm code? 1101b 0010b 0000b 0000b
0x8000000 -< 15 00 (5376 bytes long) //gba rom entry point expected 32bit arm mode branch value, possibly main branch 0001b 0101b 0000b 0000b
0x8020000 -< d2 00 (53760 bytes long) // (128kb + 0x8000000) same opcode as 0x9f30000
0x8040000 -< 15 00 (5376 bytes) //redirect to main branch
0x9880000 -< current page (1 page <-> n blocks)
0x9fc0000 -< 15 00 //redirect to main branch

by taking a look, again at gbatek site, real gba "gamepak" addresses begin at 0x8000000 and end at 0x9FFFFFF.

leaving us with a 32MB window for each state (state 0, in this case), state 1 from 0xa000000 to 0xbffffff and state
2 from 0xc000000 to 0x2ffffff.

by seeing that setrompage code, EZ3, and EZIV relies on state 0 to "recreate" the rompage settings which will be used
by the GBA hardware.


given 191 bytes starting from 0x8000000 are expected cart header values (by gba bios?).


I see you're talking about internal kernel handling (ez side), again, I know very little about EZ cards, and GBA/NDS hardware

here's my idea:

ez kernel thread generates a physical location, were the main branch is created

gba real 0x8000000 ARM 32 bit mode is fed with the where main branch is located, so even gamecode will reach it every time it
is required

ez kernel set rom page directly to where real gba game SRAM is located (on EZ3/4 sram location), through global GBA SRAM access offset,
an ARM opcode could do it (branch?)

same for current game libs (by disassembly of REAL OBJ palettes, sound banks, and tilemaps the main game code has for old offsets),

1.those will be patched by actual offsets the ez kernel can access to (NOR) on realtime

2.or simply redirect common GBA GAMEPAK data places (0x1FFFFFF in total) with arm jump opcodes so it matches the physical NOR GBA ROM offsets

Edit - I noticed the ">> 15"/">> 12" discrepancy between the EZ3/EZ4, but I'm not entirely sure if that's real either--dslinux seems to use a slightly different SetRompage() for the EZ4 which comments about PSRAM mode implying that NOR and PSRAM (and maybe the kernel) have different magic knocks. So, I tried to correct the above to make it clear that I'm even further speculating than my already speculating. :/ Regardless, I don't think I'd brick my EZ4. I just don't think it'd work and I wouldn't know how to debug it/fix it if it didn't, so I haven't bothered trying. And that sounds like a really bad excuse.

Where did you find such difference? EZ sdk? C alone takes numbers without "0x" as plain integers, bitwise, so value >> F and value >> C, could denote anything..

 

[kuwanger]

Your (2) is basically it. Bank switch describes the idea that there's a chunk of memory (say, 256KiB) but the memory address range to access it is smaller than that (say, 64KiB) so you can select which bank to use. Now, the basis design of such is rather inflexible (four banks of 64KiB for 256KiB) but GBA Flash carts are often much more flexible (map 32MiB of a total of 256MiB at 32KiB increments), all with the goal of mapping some segment of the GBA Flash cart's ROM/NOR/PSRAM/whatever in the the 0x8000000-0x9ffffff (and it's mirrors) spaces. So, strictly speaking there's no need to do any patching of gamepaks per se. However, patching is often done to (1) compensate for slower NOR than a genuine cart would have (basically, a non-existent problem of any remotely modern flash cart), (2) to change FLASH/EEPROM saves to use SRAM, (3) to include extra features like RAM cheats or save states (which can only work if a game is effectively 32MiB minus <extra features size> big), and (4) to include some simple reset code to go back to whatever launcher is used. The above code I mentioned is the core part of the "reset code to go back to whatever launcher is used". The "EZ-Flash kernel" is really just a code launcher. All the bank switching happens at a hardware level, AFAIK.

As for the differences, I found them in comparing the EZ3-in-1 SDK and Pogoshell EZ3 and the reset code disassembled from a patched game for the EZ4. The niggling point is that it could well be that the code was optimized by hand and the "0x8000" page may well be a special value and not indicative of a simple mathematical formula to calculate the offset/page relationship. It's also one of the reason I'm given pause because no matter how I look at, it's unclear to me if there is a simple mathematical formula to internally relate the address of the various NOR/ROM/PSRAM/whatever spaces for mapping into the GAMEPAK space(s). In any case, here's an example of the EZ4 disassemble reset code in question:

8effc68:4b52 ldrr3, [pc, #328]; (0x8effdb4)
8effc6a:4c53 ldrr4, [pc, #332]; (0x8effdb8)
8effc6c:4d53 ldrr5, [pc, #332]; (0x8effdbc)
8effc6e:8018 strhr0, [r3, #0]
8effc70:8021 strhr1, [r4, #0]
8effc72:8028 strhr0, [r5, #0]
8effc74:4b52 ldrr3, [pc, #328]; (0x8effdc0)
8effc76:4d53 ldrr5, [pc, #332]; (0x8effdc4)
8effc78:4e53 ldrr6, [pc, #332]; (0x8effdc8)
8effc7a:8019 strhr1, [r3, #0]
8effc7c:0b20 lsrsr0, r4, #12
8effc7e:8028 strhr0, [r5, #0]
8effc80:8031 strhr1, [r6, #0]
8effc82:4952 ldrr1, [pc, #328]; (0x8effdcc)
8effc84:20fc movsr0, #252; 0xfc
8effc86:6008 strr0, [r1, #0]
8effc88:df01 svc1
8effc8a:df00 svc0
...
8effdb4:0000 movsr0, r0
8effdb6:09fe lsrsr6, r7, #7
8effdb8:0000 movsr0, r0
8effdba:0800 lsrsr0, r0, #32
8effdbc:0000 movsr0, r0
8effdbe:0802 lsrsr2, r0, #32
8effdc0:0000 movsr0, r0
8effdc2:0804 lsrsr4, r0, #32
8effdc4:0000 movsr0, r0
8effdc6:0988 lsrsr0, r1, #6
8effdc8:0000 movsr0, r0
8effdca:09fc lsrsr4, r7, #7
8effdcc:7ffa ldrbr2, [r7, #31]
8effdce:0300 lslsr0, r0, #12

And, as you can see, it loads 0x08000000 into r4 at 0x8effc6a, it right shifts r4 12 (as 0x8000) into r0 at 0x8effc7c, and it stores r0 (0x8000) at r5 (0x09880000 from 0x8effc76). Further, we have a "A new try to enable EZ4/EZ5 support" commit for dslinux which seems to follow the same format (changing a static 0x8000 to a page variable). So, same exact format as the EZ3 but seemingly a different page value for the boot launcher. Of course, none of that answers where the PSRAM or 32MiB NOR is for the EZ4. In fact, since I wrote a simple hexviewer for the gba, maybe I should make one to look through the EZ4's page space?

Edit: And this is what I've discovered... Page= 0x8000-0xffff == ez kernel (more precisely, the ez-kernel flasher + ez kernel), page = 0x0000,0x0200,0x0400,... == 32MiB NOR, page = 0x0100,0x0300,... == PSRAM (and it actually gets written to). So, somewhat interesting stuff.

Edit2: And some further playing around, and I've managed to brick my EZ4. I foolishly was trying to recreate the EZ3's support for .lz7 files by writing a small stub program that could be prepended to .lz7 files and have the decompressor run from the last block to the first block to avoid overwriting the compressed data (as every block is smaller...but just now thinking, I'm not sure even that idea would actually work). In any case, the main core of the code was:

        ez_OpenNorWrite();
 
        for (i = blockcount - 1; i > -1; i--)
        {
                strcpy(str, "Decompressing ");
                strcat(str, dec(i));
                strcat(str, " of ");
                strcat(str, dec(blockcount));
                drawtext(5, str, 1);
                LZ77UnCompWram(blocks[i], (char *) (0x8000000 + i * BLOCKSIZE));
        }
 
        ez_CloseNorWrite();
        ((void(*)(void))0x08000000)();

At first I thought I had overwritten the boot NOR, but a dump using my F2A link cable seems to show it intact. Further, the Nintendo logo displays properly but it then goes to a blank black screen. I tried reflashing a new kernel, but holding down R does nothing. So, currently I'm at a loss to what's wrong. :/