#36201 - pipomolo42 - Wed Feb 16, 2005 1:20 am
Hello,
AFAIK, there is no linux driver for this cart, and no one seems working on one...
So, what about trying to write one ? I planned to do so, but unfortunately, I don't have a windows licence here (i'm from europe but currently living in africa for 6 months) nor the ability (or will) to install it on my computer.
Plugging the EFA gives me this :
- vendor id = 0547 (Anchor Chips, Inc.)
- product id = 2137
So, there is a good and a bad news here :
- the vendor is well known for its EZ-USB family of microcontrollers, which makes support from community very likely
- the product id is not the EZ-USB (or EZ-USB FX) product id. And google didn't answer me anything usefull about this one...
From what i've read on http://www.linux-usb.org/ezusb/ the driver can be done in three steps :
1/ use http://benoit.papillault.free.fr/usbsnoop/ to collect data
2/ extract firmware and commands from the dump (and maybe r-e the firmware to see exactly what can be done with it, but there are chances that it is useless)
3/ code a little app (using libusb ?) that will merely replay the commands we captured
But for this to work, we would need to capture many scenarii :
- plug the EFA, unplug the EFA
- plug the EFA, launch app, exit app, unplug the EFA
- plug the EFA, launch app, read memory, exit app, unplug the EFA
- plug the EFA, launch app, read rom, exit app, unplug the EFA
- plug the EFA, launch app, read savegame (every kind), exit app, unplug the EFA
- plug the EFA, launch app, write rom, exit app, unplug the EFA
- plug the EFA, launch app, write savegame (every kind), exit app, unplug the EFA
- etc...
As I said previously, my windows-able computer is now 4000km away from me... So, is anyone willing to try dumping at least the first one for me ?
Thanks,
Alex
#36236 - Vince - Wed Feb 16, 2005 10:33 am
Hello,
Most of what you describe/investigated upon has already been done when Spooo and I wrote if2a, the free software flashing utility for F2A/F2AUltra. Please have a look at http://if2a.free.fr and look at the source. I also wrote scripts to pretty-print the logs of usbsnoop, they are in the Sniffs and Hexdumps package.
As for the firmware, I doubt you can do anything useful with it (it consists of 80C521 code, as AN2131 are based upon). Much better to disasm the multiboot image that is sent to the GBA to flash the cart. It would give you much more HW info (cart registers, etc).
I'll gladly welcome other cart support as most of them are based on the same chip : yours is 0x2137, F2A one is 0x2131 for the AN2135SC (AN2131-compatible). I also have an XGFLash2Lite whose SRAM chip is dead and wanted to add support for it as well.
It would also be good for you to precise what HW/linker you are talking about. Under the EFA, I know of two linkers : the EZ Flash Advance and the Extreme Flash Advance, one of these being a ripoff of the other ...
HTH,
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#36241 - pipomolo42 - Wed Feb 16, 2005 12:18 pm
| Vince wrote: |
As for the firmware, I doubt you can do anything useful with it (it consists of 80C521 code, as AN2131 are based upon). Much better to disasm the multiboot image that is sent to the GBA to flash the cart. It would give you much more HW info (cart registers, etc).
|
Actually, I'm talking about the EFA from http://www.efa.cc/ (is it the good one, or the ripoff ?).
And it does not use multiboot : there's a miniUSB plug directly in the cart, and it has to be unplugged from the GBA to be flashed correctly.
I guess it does the following :
- firmware is sent to the microcontroler through usb
- microcontroller executes the firmware, which acts as a glue between the rom chips and the usb interface
- PC side software sends simple usb commands asking to read/write some data at some address
#36247 - Vince - Wed Feb 16, 2005 2:01 pm
Hello back,
Thanks for the info. It is indeed an Extreme Flash Advance. I made a wrong statement about it being a ripoff, sorry about that. The ripoff is in fact the EZ Flash Advance 2 which was never released by the EZFA guys but by a lame Chinese copier (AFAIK)...
The info you sent is very interesting, given that the design is relatively different from multiboot linkers. It's more close to the first EZ-USB (with a separate linker) except that now, they integrated the linker in the cartridge.
I think your guess about the operation mode is right. You may find more information by disassembling the firmware (as I said, probably 80C51 code). It surely contains more information than the F2A one. You first step would probaly to clearly identify the chip inside the cart (how about opening it and taking pictures?)
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#36257 - pipomolo42 - Wed Feb 16, 2005 5:21 pm
| Vince wrote: |
| You first step would probaly to clearly identify the chip inside the cart (how about opening it and taking pictures?) |
As the case is made of translucent purple plastic, I didn't even have to open it to notice that the references on the microcontroler have been sanded out :-(
If I manage to find a screwdriver, I'll nevertheless try to take a very close look at it...
#36266 - Vince - Wed Feb 16, 2005 6:36 pm
| Quote: |
| As the case is made of translucent purple plastic, I didn't even have to open it to notice that the references on the microcontroler have been sanded out :-( |
Oh my god! They went that far, just to protect their design ... and to make free software drivers even more difficult to write...
You'll have to rely on the usbsnoop traces and on the USB ID to know what chip it is ... I'm pretty sure they are not going that far from an EZ_USB/AN2131 one.
Hope you can get some pictures of the inside :)
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#36348 - pipomolo42 - Thu Feb 17, 2005 10:14 pm
| Vince wrote: |
| Hope you can get some pictures of the inside :) |
done : http://bigbugsite.free.fr/efa/
as you can see on http://bigbugsite.free.fr/efa/IMG_0016.JPG and http://bigbugsite.free.fr/efa/IMG_0013.JPG, the references are no more readable on the main chips. only the flash infos is still available...
So, we'll have to have a look at the firmware to guess what microcontroller is used in this one (and i'll only have access to a windows pc in two months).
Regards,
Alex
#36379 - Vince - Fri Feb 18, 2005 11:52 am
Hello back,
Thanks for the pics (as I see, you are also from France, given that you have a free/proxad account). I indeed see they sanded off the chip info. However, I think it's more to show that they ripped off a nother design that they improved than to protect their IP.
The design is very close to the one of F2A Ultras (see pics on http://if2a.free.fr/Pics/). I can say that because :
+ the chip under the battery is a CPLD/FPGA used to route saves read/writes to the SRAM chip (small one in the middle).
+ The right one is the EZ-USB variant (it's a variant because it's almost the same as the F2AUltra one 0x547/0x2131).
Keep us informed on your progress (PM me if you need AIM/more design info).
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
Last edited by Vince on Wed Feb 23, 2005 10:36 am; edited 1 time in total
#36507 - Dullin - Wed Feb 23, 2005 3:19 am
It's nice to see people working on this.
I don't think I have the technical knowledge to help you guys code the thing but I study in electronics and I'll surely poke around to see what I can do.
#36648 - Dullin - Sat Feb 26, 2005 11:01 pm
I have an update on my side of things.
I was checking out the pictures provided by pipomolo and saw that the configuration was different from the pictures from his so I dismantled my card to check it out (I will only have a digital camera on monday so no pictures yet). The 2 main chips have still been sanded off though so I don't know how important what I found his.
#36666 - wintermute - Sun Feb 27, 2005 11:43 am
#36700 - Vince - Mon Feb 28, 2005 10:16 am
Interesting. Thanks for the link.
Unfortunately, 2 things are problemtaic :
1. AFAIK, this is not the source of the driver itself, onyl the graphical client (did not look at the archive though but this source was released some time ago).
2. Much more important : the license. It is not possible to use that code/information in a free software program as the license is not free software. I, on my side, won't look at that to work on if2a as it would endanger the freedom of the software.
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#41048 - pipomolo42 - Sun Apr 24, 2005 4:54 pm
Hello again,
I finally put my hand on my copy of Win98 SE and used usbsnoop to get some data.
They're available from http://bigbugsite.free.fr/efa/ in tar.bz2 and zip format.
The EFA Linker uses two drivers : the first one (efaw) loads the firmware into the ?C and resets it. The second one reads and writes the rom through the ?C once it has been initialized with the firmware.
When you plug the EFA device, it is claimed by the first driver, which produces the usbsnoop_init.log file you can find in the archive.
When the EFA ?C boots the firmware, it is disconnected and reconnected with a different vendor and product ID, and is then claimed by the second driver. For this one, I recorded different scenarii for the second driver :
usbsnoop_plug_unplug.log : I did nothing else than wait for the driver to finish its stuff, then unplug the card.
usbsnoop_search.log : I waited for the driver, then launched the EFA Client, clicked the "search for cards" button, then unplugged the card
usbsnoop_search_format.log : I waited for the driver, then launched the EFA Client, clicked the "search for cards" button, clicked the "format card" button, then unplugged the card
usbsnoop_search_write.log : I waited for the driver, then launched the EFA Client, clicked the "search for cards" button, and wrote a rom to the card (without the EFA menu), then unplugged the card
The rom I wrote is the getID.ds.gba available at http://ds.gcdev.com/dsfirmware/ or from my directory.
#41668 - pipomolo42 - Sun May 01, 2005 12:09 am
Hello,
I managed to extract the firmware from the usbsnoop initialization log, and successfully uploaded it to the EFA linker again.
the python script I wrote to extract it is here : http://bigbugsite.free.fr/efa/extract_firmware.py
and the firmware is here : http://bigbugsite.free.fr/efa/firmware.hex
To upload the firmware, just plug your EFA linker and run : | Code: |
| fxload -D `lsusb|grep -i anchor|awk '{print "/proc/bus/usb/" $2 "/" $4;}'|cut -d: -f1` -t an21 -Ifirmware.hex |
Next, there are two (or maybe three) options to guess how to actually write to the linker :
- disassemble the firmware (but I'll have to learn 8051 and ez-usb architecture and asm)
- analyse the other usbsnoop logs (but there are many more usb packet types involved)
- ask the efa people for the sources or specs (but some people asked them previously, and they do not seem to cooperate with the community very much)
Regards,
Alex
Edit :
- All endpoints use Bulk transfer type.
- endpoints 04(out) and 84(in) are used to read and write the flash.
- endpoints 02(out) and 82(in) are also used (but there are only 3 ou 4 packets on these endpoints by session)
- I just noticed that my log don't include SRAM read/write... I'll have to check which endpoints it uses.
Edit 2 :
- when reading or writing on ep 2, length of data is always 32k. And it's only written when i write to the card, not when i format the card or just read it.
- when writing to the flash, each packet contains 6 data bytes (and sometimes 4) ... I don't know if there is a particular reason, but it doesn't sound very efficient.
- when reading from the flash, each packet contains 64 data bytes.
Edit 3 :
- Okay, I was wrong : ep2 is used to read and write to the flash. but if you take a look at my dumps, you'll see that the packet length is 32k, and between every 2 octets, there are 6 unused octets... so the 32k that are sent actually contain only 8k of useful data ! how clever :)
- Then I guess ep4 is used to send commands, addresses, and such. but I still wonder why it is read 73 times and written 798 times just to fetch the content of the card...
#41691 - tepples - Sun May 01, 2005 5:52 am
If there are three or four packets per session, then one of them might have something to do with the card's clock. Have you tried pressing "Sync Clock" or whatever it's called (the EFA I've used is at my cousin's house)?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#41707 - pipomolo42 - Sun May 01, 2005 11:49 am
| tepples wrote: |
| If there are three or four packets per session, then one of them might have something to do with the card's clock. Have you tried pressing "Sync Clock" or whatever it's called (the EFA I've used is at my cousin's house)? |
That's what I thought in the first place, but it's not correct, I'm affraid :
ep2 is written to only in the case I add a rom to the card. when I format the card, only ep4 is written to. That's why I guess ep4 is used to pass commands to the Linker (to tell it to erase some blocks, or where to write the data sent on ep2, or to sync the clock (but I'll have to check this one))
But now, as there are hundreds of commands on ep4 even when I just check the card's content, I fear I'll have to try to disasm it to understand what these comands do... (and maybe it'll be completely useless, if these commands are simply passed to the - completely unknown - CPLD also present on the card.)
Edit :
- there was a mistake in the hex file checksum calculation, fixed.
#41919 - pipomolo42 - Tue May 03, 2005 2:51 am
Hello, today I uploaded some files :
http://bigbugsite.free.fr/efa/analyse_bulkpackets.py : this script extracts the useful informations from a usbsnoop log.
http://bigbugsite.free.fr/efa/search.trace : this file was generated with the previous script (it represents the usb packet flow generated by the user clicking the 'search' button on the interface)
http://bigbugsite.free.fr/efa/find_next_urb.py : this scripts takes a list of offsets and a usbsnoop log and gives the sequence number of the packets immediately following each offset (usefull when logging a sequence of multiple user actions with usbsnoop : after each action, you write down the size of the logfile, which you'll then add to the offset list)
http://bigbugsite.free.fr/efa/firmware.a51.orig : the disassembled firmware, with addresses
http://bigbugsite.free.fr/efa/firmware.a51 : the disassembled firmware, commented. For now, I only clearly separated the different functions, and renamed some obvious ones. There are 25 functions and 14 "data sections" (which might in fact happen to be some IRQ handlers). the biggest function is 500 instructions long, and of course, it is the first function called in the main program loop :-( .
Next step will be to find or write a script that generates a graph from the branch instructions, which will help me getting the 'big picture' (and in fact, it will really be a big picture ;) )
Regards,
Alex
Edit :
- Modified the extract script so that it displays the first 8 bytes of each packet longer that 8 bytes. also updated the extraction result example.
#42050 - pipomolo42 - Thu May 05, 2005 2:45 am
Hello again,
Here is the script that converts ugly binary firmwares to nice and easily readable graph ;) :
http://bigbugsite.free.fr/efa/graphviz_generator.py
- Red circles are functions (branches that update the stack pointer)
- Grey circles are RET statements (end of functions, also modify the SP)
- Squares are normal branch instruction
- plain line means the branch is always taken
- dashed line means the branch is taken is some condition is true (like JZ, JNZ ...)
- red dashed line means a function call
And you use it like this, with dis51, python and the graphviz dot tool :
| Code: |
dis51 -l < firmware.hex > firmware.a51
python graphviz_generator.py firmware.a51 > graph.gv
dot -Tgif graph.gv > firmware_graph.gif |
You can see some examples on my site :
http://bigbugsite.free.fr/efa/firmware_graph.gif : generated from the EFA firmware (Just look at how fun it will be to understand the 500 lines L0021 function ;) )
http://bigbugsite.free.fr/efa/f2a_graph.gif : F2A firmware. Look how easier it looks ! I wish I have bought one of these instead, and forthermore, there is already an open source driver ...
http://bigbugsite.free.fr/efa/intel_graph.gif : There were two hex files in the 2.3 release of the EFA client. The product/vendor string in the firmware is 'Cypress EZ-USB-FX2' so maybe it's some kind of cypress development board firmware. Or just a beta version os the EFA firmware, because their structure look very close.
#42111 - pipomolo42 - Fri May 06, 2005 3:11 am
Hello again,
I updated my script to support multiple entry points. Multiple entrypoints are used for instance to tell the disassembler where to find IRQ handlers.
Now, blue circles in the graph are independant entrypoints.
http://bigbugsite.free.fr/efa/graphviz_generator.py is the updated script
http://bigbugsite.free.fr/efa/ep_list is the list of entrypoints addresses I extracted from the firmware
to use it :
| Code: |
dis51 -l `cat ep_list` < firmware.hex > firmware.a51
./graphviz_generator.py firmware.a51 `cat ep_list` > graph.gv
dot -Tgif graph.gv > firmware_graph.gif |
http://bigbugsite.free.fr/efa/firmware_graph.gif is the EFA firmware graph, generated once all entrypoints were spotted.
#42112 - pipomolo42 - Fri May 06, 2005 3:20 am
By the way : I happened to talk with someone who did the complete reverse engineering of the XG firmware, and he let me have a look at his notes and commented code ... And the more I read both codes, the more I found similarities between them, as if one of them is just a modified version of the other one, thus the commented version I got will greatly help me.