Hacking EZ-FLASH Junior TestFlight

[paburo-san666]

Easy. Absolutely nothing. Radio silence.

At least explain

 

[Jayro]

CAN YOU ALL EXPLAIN TO ME WHAT THE HELL IS HAPPENING
DAMMIT

Basically EZ-Flash made promises to put out a fix in an update and never delivered. They've basically stopped supporting a product they still actively sell.

 

[paburo-san666]

Basically EZ-Flash made pro.ises to put out a fix in an update and never delivered. They've basically stopped supporting a product they still actively sell.

I mean, i got this EZFlash... And at the moment I don't have any problem with the experimental firmware I had. The worst thing I got is my PKMN Yellow got corrupted, but nothing worse like cart bricking as people claims.
Too bad anyway EZ-Flash team doesn't give enough support. Hope someone make reverse engineering and then develop a custom firmware.

 

[Reshiban]

I mean, i got this EZFlash... And at the moment I don't have any problem with the experimental firmware I had. The worst thing I got is my PKMN Yellow got corrupted, but nothing worse like cart bricking as people claims.
Too bad anyway EZ-Flash team doesn't give enough support. Hope someone make reverse engineering and then develop a custom firmware.

Or hope they finally release the EZ-Flash Junior source like they've made for EZ-Flash Omega

 

[Jayro]

I just switched to the EDGB from AliExpress and I'm much happier with it. No RTC, but I hardly care about that. I play my Pokemon games on dedicated flash carts for that reason.

 

[DrunkenMonk]

Or hope they finally release the EZ-Flash Junior source like they've made for EZ-Flash Omega

They probably don't actively own the source code and the programmer may have cut ties due to a relationship breakdown or underpayment or etc, wouldn't be the first time this kind of thing would happen, nor would it be the last.

Generally these kinds of guys will outsource the work since they don't have active connections with the ability to create the product in it's entirety, but they do have the initial capital. This then leads to whomever they decide to go with to also be protective of their work and only provide compiled products without any way for anybody outside to modify without essentially rebuilding, but the cost for work to be completed as well as getting the source code from the programmer would also likely be higher too, enough to that they'd rather not pay the extra up-front cost.

It's possible that this isn't the case and they were actively working on it internally, but the much more likely scenario is unfortunately one of the above, disgruntled programmer or disinterested investors who aren't likely to see a large enough return to continue funding work.

 

[Jayro]

They probably don't actively own the source code and the programmer may have cut ties due to a relationship breakdown or underpayment or etc, wouldn't be the first time this kind of thing would happen, nor would it be the last.

Yeah, just look at the MSI Afterburner fiasco. MSI pays a single russian programmer to keep the app going. But the relationship is crumbling, and so we might not have that app updated much longer.

 

[Reshiban]

They probably don't actively own the source code and the programmer may have cut ties due to a relationship breakdown or underpayment or etc, wouldn't be the first time this kind of thing would happen, nor would it be the last.

Generally these kinds of guys will outsource the work since they don't have active connections with the ability to create the product in it's entirety, but they do have the initial capital. This then leads to whomever they decide to go with to also be protective of their work and only provide compiled products without any way for anybody outside to modify without essentially rebuilding, but the cost for work to be completed as well as getting the source code from the programmer would also likely be higher too, enough to that they'd rather not pay the extra up-front cost.

It's possible that this isn't the case and they were actively working on it internally, but the much more likely scenario is unfortunately one of the above, disgruntled programmer or disinterested investors who aren't likely to see a large enough return to continue funding work.

I didn't known many company makes software through proxy work, but now that you says this it makes sense

 

[SirByte]

I just got the EZ-Flash Jr recently, and indeed it's concerning there has been no word from EZ-Flash2 who was "Last seen Dec 8, 2022" but at least there's a more recent firmware in this thread than at the websites (.cn, .com). For now I'm on the old FW4 but should I need it for RTC, I can at least install that.

If you go in the CityCom file storage on the Chinese website, you still see the old Firmware 4 but there's also the QQ chat, did anyone go in there and see if there was anything newer available?

Edit: can't reach QQ via PC anymore it seems only mobile as of September 26, 2022. Do we have any Chinese users that want to have a look?

 

[elijah067]

Looks like EZ-Flash2 is back.

 

[hippy dave]

Looks like EZ-Flash2 is back.

They'd better have a remarkably good excuse for abandoning all support for their products while continuing to sell them.

 

[SirByte]

They'd better have a remarkably good excuse for abandoning all support for their products while continuing to sell them.

User EZ-Flash2 is back, but I didn't see any new postings yet. Who knows what happened, but in case @EZ-Flash2 reads this: please consider open-sourcing at least part of the firmware so others can have a look at the remaining issues, add RTC support for "well-known" mods and make other improvements.
Not just for the Junior, also other products including legacy like EZ-Flash IV. Kind of odd to erase the flash first, and then check for a valid ezfla_up.bin file - if that's still true, not going to test stuff like that

 

[nitro2k01]

Hi. I've decided to dust off an old project. I made the SGB enabler which allows you to get SGB functionality working without upgrading beyond FW4. But behind that project there's also a lot of other reverse engineering. Because of that I'm able to replace the first stage boot ROM in the FPGA bitstream (what EZ Flash calls firmware). This can be useful for solving various issues, like potentially the slow SD card issue. I'll do a straw poll here, is anyone interested in beta testing a potential hacked version of the EZFJr firmware with improvements?

I'm also interested in the experience of anyone using FW5, either the (now deleted) 7-31 version or the 9-18 version that can be found in this thread. Has anyone actually experienced permanent bricking of their cartridge? Is that actually thing or is it just referring to the slow SD card problem? Are there any other problems in FW5 that you've experienced over earlier firmwares?

If you have an SD card that can't load because the card is too slow, I'd especially be interested in having you test something. Or better yet, if you'd be willing, send me the SD card so I can try to reproduce and troubleshoot the problem myself.

 

[Jayro]

Hi. I've decided to dust off an old project. I made the SGB enabler which allows you to get SGB functionality working without upgrading beyond FW4. But behind that project there's also a lot of other reverse engineering. Because of that I'm able to replace the first stage boot ROM in the FPGA bitstream (what EZ Flash calls firmware). This can be useful for solving various issues, like potentially the slow SD card issue. I'll do a straw poll here, is anyone interested in beta testing a potential hacked version of the EZFJr firmware with improvements?

I'm also interested in the experience of anyone using FW5, either the (now deleted) 7-31 version or the 9-18 version that can be found in this thread. Has anyone actually experienced permanent bricking of their cartridge? Is that actually thing or is it just referring to the slow SD card problem? Are there any other problems in FW5 that you've experienced over earlier firmwares?

If you have an SD card that can't load because the card is too slow, I'd especially be interested in having you test something. Or better yet, if you'd be willing, send me the SD card so I can try to reproduce and troubleshoot the problem myself.

You sir, are the goat. I'd send you my SD card if I still had my Jr, but I replaced it with an EDGB from AliExpress for 3/4ths the price, and it's actually better.

Besides the terrible SD card init issues and the ridiculous power consumption, the sluggish menu when navigating a page at a time also infuriated me. Would that be able to be optimized a bit by chance?

 

[moon_rabbit]

Hi. I've decided to dust off an old project. I made the SGB enabler which allows you to get SGB functionality working without upgrading beyond FW4. But behind that project there's also a lot of other reverse engineering. Because of that I'm able to replace the first stage boot ROM in the FPGA bitstream (what EZ Flash calls firmware). This can be useful for solving various issues, like potentially the slow SD card issue. I'll do a straw poll here, is anyone interested in beta testing a potential hacked version of the EZFJr firmware with improvements?

I'm also interested in the experience of anyone using FW5, either the (now deleted) 7-31 version or the 9-18 version that can be found in this thread. Has anyone actually experienced permanent bricking of their cartridge? Is that actually thing or is it just referring to the slow SD card problem? Are there any other problems in FW5 that you've experienced over earlier firmwares?

If you have an SD card that can't load because the card is too slow, I'd especially be interested in having you test something. Or better yet, if you'd be willing, send me the SD card so I can try to reproduce and troubleshoot the problem myself.

I have 4 ezFlash Jr and I also have a backup of SPI FLASH.
They are recoverable, so I should be fine.

My experience with updating FW0918 has never gone wrong.
As for SD cards, I've used class 10 from SanDisk or Samsung.

 

[moon_rabbit]

And Junior, produced after 2022, has 512KB of SPI FLASH. -> puya p25d40h
Considering that OMEGA DE's SPI FLASH is still 2MB -> zbit zb25vq16
The firmware for Junior's SPI FLASH does not seem to exceed 512KB.

 

[nitro2k01]

You sir, are the goat. I'd send you my SD card if I still had my Jr, but I replaced it with an EDGB from AliExpress for 3/4ths the price, and it's actually better.

Besides the terrible SD card init issues and the ridiculous power consumption, the sluggish menu when navigating a page at a time also infuriated me. Would that be able to be optimized a bit by chance?

To be clear, I would just need the SD card itself, or an SD card exhibiting this issue, not the cartridge. When you say you sent it back, do you mean that the cartridge even came with a SD card that was problematic? Or did you send back the SD card separately?

The menus could definitely be optimized. It's likely that that would have to involve a complete rewrite of the menu though. Someone (not me, but someone called Daid) has started reverse engineering the interface protocol for accessing the SD card and a proof of concept loader called OpenGBLoader which would be a good starting point. This is also something I might be looking into.

My experience with updating FW0918 has never gone wrong.
As for SD cards, I've used class 10 from SanDisk or Samsung.

And just to confirm, no issues with SD card errors I assume?

And Junior, produced after 2022, has 512KB of SPI FLASH. -> puya p25d40h
Considering that OMEGA DE's SPI FLASH is still 2MB -> zbit zb25vq16
The firmware for Junior's SPI FLASH does not seem to exceed 512KB.

The firmware size depends on the FPGA. The actual size is something like 200 kB. Then there are two copies for redundancy/recovery from failed upgrades. The rest if empty space. So indeed most of the 2 MB SPI flash was empty.

 

[Jayro]

To be clear, I would just need the SD card itself, or an SD card exhibiting this issue, not the cartridge. When you say you sent it back, do you mean that the cartridge even came with a SD card that was problematic? Or did you send back the SD card separately?

The menus could definitely be optimized. It's likely that that would have to involve a complete rewrite of the menu though. Someone (not me, but someone called Daid) has started reverse engineering the interface protocol for accessing the SD card and a proof of concept loader called OpenGBLoader which would be a good starting point. This is also something I might be looking into.

And just to confirm, no issues with SD card errors I assume?

The firmware size depends on the FPGA. The actual size is something like 200 kB. Then there are two copies for redundancy/recovery from failed upgrades. The rest if empty space. So indeed most of the 2 MB SPI flash was empty.

I don't think my SD card had any issues, I mostly just hated the sluggish menu.

 

[moon_rabbit]

To be clear, I would just need the SD card itself, or an SD card exhibiting this issue, not the cartridge. When you say you sent it back, do you mean that the cartridge even came with a SD card that was problematic? Or did you send back the SD card separately?

The menus could definitely be optimized. It's likely that that would have to involve a complete rewrite of the menu though. Someone (not me, but someone called Daid) has started reverse engineering the interface protocol for accessing the SD card and a proof of concept loader called OpenGBLoader which would be a good starting point. This is also something I might be looking into.

And just to confirm, no issues with SD card errors I assume?

The firmware size depends on the FPGA. The actual size is something like 200 kB. Then there are two copies for redundancy/recovery from failed upgrades. The rest if empty space. So indeed most of the 2 MB SPI flash was empty.

I've tried to update over 10 times, all of which have been successful.
I tried them all on the GBC and used IKEA LADDA battery with plenty of power.
I haven't tried it with a slow SD card, so I don't know what the failure situation is.


https://gbatemp.net/threads/ez-flash-junior-stucks-at-loading-osinit.581395/post-9383612

Based on this, it seems that the role of recovery kernel is to load the old firmware.
Recovery kernel is not publicly available, so it would be helpful if you get it from someone who has this file.

I don't know why there is such code, but FW5 seems to have the biggest problem with limiting the time to find or load ezgb.dat file.

 

[swutch]

Updated 3 ez-junior to FW5 without any problem. Micro SD was a Kingston Class 10.