White and bottled.
Top JTAG:Programs flash memories connected to any JTAG-compliant device by manipulating the device's pins using boundary-scan technology. TopJTAG Flash Programmer can work with any parallel NOR flash memory compatible with AMD or Intel standard or extended command sets.
Both CFI (Common Flash Interface) and non-CFI memories are supported.
S29GL128P90 Datasheet:Support for CFI (Common Flash Interface).
http://www.mouser.com/ds/2/380/S29GL-P_00-220237.pdf
Sparky, maybe this will be useful:
http://www.topjtag.com/flash-programmer/
Well, it's good to know more tools I can use with the Amontec JTAG, but for now I'm following our local expert cybernet's advice --- it's my first experience with JTAG so I'm kinda tip-toeing around!
Continuing on with the matter...before I've hooked the JTAG up, I've done a little reading of the usual ADI JTAG interface, and also cybernet's earlier info about it (posted
here).
I attached a snippet of schematic from ADSP-BF526 ezboard manual, which shows JTAG with similar pinout as cybernet's schematic (in post 1 of this thread). Also see the Analog EE Note-68 which includes a bunch of example JTAG configurations, and from which it can be seen the conflicting pin 1 = GND for the usual ADI JTAG which cybernet cautions about in his post linked above.
My next task should be to hook things up
I realize this is not a DS4000 BW tread but I hope it can be viewed as close enough to investigating the DG4000 that I can ask some DS4000 things too.
The various serial decode option settings of the DS4000 can all be set by entering a code, but the BW hack is still not clear as far as I know.
So far I think there are two ways forward that looks promising.
1. HW straps (two resistors, where one is not populated) on the board for "HD Modify version" (not the "HD PCB version" bits)
2. option keys similar to the DS2000, except at least one user has reported unsuccessfully trying many of the bits apart from the ones we know activate the serial decode options.
1.
I have the 011 pattern on my DS4014 and the resistors are 10k to GND or a supply.
0 side is grounded both to metal frame and to pin 2 on the closest programming connector and to pin 13 on the one closer to the BF.
1 side is connected to pin 7 on the closest programming connector but not to any pins on the BF connector.
Very tempting to use micro clips and wire in a 1k here.
...
Well it was so tempting that I had to try it.
I did these patterns without getting any change to the major scope version in utility-system-system info: 010, 001, 111 and the original 011 of course.
I also did not see any changes in rise time but that is not conclusive due to uncertainty with the source I used.
Looking (afterwards) at the extended HW version (edge trigger mode F7 + F6 + F7 + Utility. then utility-system-system info ) it says 0.1.2.3.
This matches nicely with the straps for "HD PCB version" being 01 and 10, and the "HD Modify version" being 011.
I can verify this at a later time, did not think about the extended version screen until after put it partly together again.
This means that point 2 gets more interesting.
2. This is the part that sounds similar to the DG4000 work done in this tread ... what would be a good thing to investigate?
Sniffing the I2C for BW setting commands? (assuming for now that it is the same variable BW buffer as in DS2000)
possibly verifying by sending a higher BW setting on I2C?
extracting the BF image and search for hints of keys for BW upgrades?
search BF image for the I2C code setting the BW and back trace variables used?
I newer used the BF so I am on thin ice here when it comes to interfacing it.
Do we have a DS4000 image to look at already or do we need to get one?
I know someone that has recently worked on BF designs so I can borrow a programming pod from him if needed.
I realize this is not a DS4000 BW tread but I hope it can be viewed as close enough to investigating the DG4000 that I can ask some DS4000 things too.
I'm thinking of getting a DS4024, so I got interested in that to.
From what I read on the Rigol i2c thread (yes, I read the whole thing...) you need to get a JTAG adapter, or a BF programing pod (which is JTAG) and dump the memories. The dump then needs to be de-compiled using a tool like 'IDA pro' to try and find how the BW state is determined.
I'm reading some of the BF data sheets (ADSP-BF526) to find more information on the chip.
Well, it's good to know more tools I can use with the Amontec JTAG, but for now I'm following our local expert cybernet's advice --- it's my first experience with JTAG so I'm kinda tip-toeing around!
Continuing on with the matter...before I've hooked the JTAG up, I've done a little reading of the usual ADI JTAG interface, and also cybernet's earlier info about it (posted here).
I attached a snippet of schematic from ADSP-BF526 ezboard manual, which shows JTAG with similar pinout as cybernet's schematic (in post 1 of this thread). Also see the Analog EE Note-68 which includes a bunch of example JTAG configurations, and from which it can be seen the conflicting pin 1 = GND for the usual ADI JTAG which cybernet cautions about in his post linked above.
My next task should be to hook things up
Any progress on this?
Time limited on my part --- will hopefully get to it soon...
if some one wants to tinker with it too - thats the main routine of the license file verification.
atm i would believe they use some kind of HMAC with "YZDHZSGCX" being the secret key - i just tried a few common ones, but no luck so far.
it will be down to analyzing this bit of code and the 2 "randomly named crypt" functions which i will post later in time when i have some clue what they are doing.
the input arguments are somewhat speculative as i have only roughly done the top level file handling function. if anyone has a serious idea let me know.
i would be suprised if they rolled their own HMAC algo
Free DG4062, DG4102, DG4162, DG4202 and a serial# of your choice ...
http://pastebin.com/ipkJCxPM** ____ ______________ ___ __
** / __ \/_ __/ ____/ |/ / / /
** / /_/ / / / / /_ / /|_/ / / /
** / _, _/ / / / __/ / / / / /_/
** /_/ |_| /_/ /_/ /_/ /_/ (_)
**
** this tool generates a new model type (DG4XXX) & serial (DG4D1XXXXXXXX) string,
** calculates a MAC and creates a .CEN file.
**
** what to do with the file ?
**
** put it on an USB stick, plug stick into DG4000, goto "Store", browse USB Stick,
** change "File Type" to "All File", navigate to your .CEN file, press "Read".
**
** You should get a Popup telling you that you successfully changed your model type and serial
**
** if *not* you:
** used a wrong current model type
** used a wrong current serial
** used an invalid new model type
** used an invalid new serial
**
**
** firmware tested:
** 00.01.06
** 00.01.03
**
**
** no warranties, if it explodes, your problem ;-)
**
Damn ... another great job cybernet !
So, once you install this, how does it compare to the native DG4164? Calibration? (I've been one of those holding out until this hack appears... Thanks Cybernet!)
So, once you install this, how does it compare to the native DG4164? Calibration? (I've been one of those holding out until this hack appears... Thanks Cybernet!)
i doubt there is a native 4162 unless u mean the sticker on the front. thats whats rigol uses to determine the model & serial.
calibration can be done if needed with the cal menu. i dont have the knowledge and need to do that, i just needed the square wave limit raised, and that looks good on my scope when i make it a DS2202
Amazing work cybernet!
I was able to compile and read in the .CEN file no hassles whatsoever. I did the upgrade to DG4202 on firmware 00.01.06
This came around faster than I could get my JTAGKeyTiny hooked in the back of the arb. At least I have it ready for the next one!
Mega thanks!!
>> Edit: I updated to firmware 00.01.07 after applying the patch and it works fine.
Hello Cybernet,
as result of your phantastic work (many, many thanks) I now have a DSA815-TG with all options, a DS2072 (DS2202) with all options and now the chance to pimp up my DG4062 also.
I'm not a programmer and I'm to stupid to compile the file 'cengen.txt'. I renamed it to 'cengen.c' and tried to compile it with 'MinGW' in Win XP, but no chance for me. :-((
So I need help. Please can anybody compile it for me? Thank you for help.
Greetings
Rigol-Friend
Excuse my terrible english.
Cengen.c compiles with GCC under Linux (I use Wheezy running in a Virtualbox VM under Windows 7) and creates the .cen file with no problem. Cybernet's instructions in the source are clear and it was easy to do.
I have no Linux :-(
Not a valid excuse, if you have an internet connection...
You could download the cygwin installer and install cygwin under Windows, add the gcc, gdb and make packages under 'devel' in the cygwin installer. Then run the cygwin terminal and follow the instructions in cybernet's c file. I just did it, took only a few minutes to install. Compiled and ran exactly as it does in Wheezy.
BTW, I am not a Linux maven, I just did a couple of searches ... cygwin ... gcc under cygwin... and it didn't take a lot of time to find the downloads. You could save yourself some problems by installing a virtual machine like virtualbox and set a VM up as a linux box under Debian, Ubuntu or one of the turnkey linux distributions then running it when cybernet does his magic. He makes it easy, I think the guy's a genius.
Amazing job Cybernet...
Anywho, I've compiled it fine on Ubuntu 13.10 under Vbox, but when run I always get an error "Invalid <CURRENT_MODEL> len"
I thought this was a bit odd, as there's only so many ways you can get DG4062 wrong. So I copied and pasted the example command, and I get the same error. So obviously there's something wrong with the setup.
My guess is it's going to be something to do with local terminal options or the like? Can any linux guru's shed light on that one for me?
you are running it like:
./cengen DG4062 DG4162 DG4D123456789
correct?
Worked fine first time for me. Ubuntu 11.1 live CD on virtualbox.
Yep I need to do some more digging.
I changed the printf statement to print the strlen, for some reason it things its 5
Fan-Frickin-tastic , again CyberNet , I think that is a bottle of Champagne in your picture.
We owe you a Case.
I'm not quite sure why it's doing it, yet for me it was dropping the D off the front of each of the args. I just added an extra D i.e.
./cengen DDG4062 DDG4202 DD....
And it worked. I now have a DG4202
Thanks again Cybernet!!!