Thank You for your continued support and contributions!
You only need to svn username and password to commit. To check out source you don't need anything.http://www.rockbox.org/twiki/bin/view/Main/UsingSVN
Thanks for your reply. I've downloaded the sources: it was my mistake; to download no username or password is required. Now that I have all the right files, I would try to use cmake again then let you know. Excuse me for the dumb questions but I'm quite new to these things...
p.s. Is there a manual way alternative to using update extract to extract the firmware from the package executable?
Instead of directly downloading through SVN, you could've also downloaded the most recent source tarball..
For help compiling, don't forget to read utils/zenutils/notes.txt.
Quote from: GuybrushThreepwoodp.s. Is there a manual way alternative to using update extract to extract the firmware from the package executable?Yes there is. While upgrading your ZVM, copy C:\CtJbFW\cttemp\nk.bin to a safe place.
...I already know this trick: it's described on many forums and I've already used it to extract the 1.62.02 nk.bin. The problem is that I've a faulty Zen and on some forums I've read that flashing back to 1.30.02 could help. Though I don't believe this, I'd like to make a try but the 1.30.02 updater doesn't even recognize my player and because of this doesn't extract the firmware and I can't use that trick. fw 1.30.02 is among those firmwares that don't work with update_extract and I can't succeed in compiling the revised version. Here's what I did:- downloaded the sources from the SVN- set up the build environment for Watcom (I use open-watcom-c-win32-1.7a) by cmakebut, when I try to launch wmake, I get a lot of errors and can't go on any further...I certainly miss something (as said, I'm quite new to these things) though it seems to me that everything is fine (obviously the situation is different: my environment has certainly some kind of issue)...
I'm sorry, but this forum (and this thread) is dedicated to porting Rockbox to the Zen Vision (:M), not helping people fix their player.And I've never tested Watcom, but as I heard MingW on Windows requires some patches to the source I can imagine open-watcom won't compile zenutils magically without changes...
This is as far as I get now, but I'm stuck at the cluster chain's stuff.I can't figure out what the structure of the cluster chain is, where it's located and how I need to find the data that belongs to the file attached to the cluster..
...p.s. If the code has to be modified to be compiled under Windows, how was the version on pimpmyzen compiled? Was it cross-compiled?
p.p.s What I meant by "manual way to extract the firmware" was asking what's the updater file structure and how to manually extract the firmware from it.
...If there is something more I could do, I'm free to help!
p.s. As said in my last post, I hope that I haven't done anything wrong writing again here on this thread, instead I hope that sharing the results of my tests could be useful.
@mcuelenaereI've updated my copy of the SVN: tomorrow I would build again the sources and see what happens then let you know. Tomorrow I would try to set up a better Windows environment too...I've opened the updater executable with a PE Editor and the .rdata section is only 60Kb worth while the .data section is a lot bigger (a little less than the entire package dimension): isn't the firmware (scrambled and compressed as you've said and I've expected) supposed to be in the .data section? BTW I have to go deeper into this...
@mcuelenaereHi! I've built the revised version of zenutils: everything is fine now and it extracts the updater packages v1.62.02 and v1.30.02 too. Great work! Where was the problem?Unfortunately, I haven't still succeeded in setting up a working environment under Windows: I've tried with MinGW but, though the build process with cmake succeeds, when I try to make the executables I still get many errors... As soon as I would have some spare time, I would try with Microsoft Visual Studio 2008 Express... Have a good day! ---EDIT---I've tried to flash the v1.62.02 and v1.30.02 firmwares extracted by the newer update_extract version to my ZVM: both CreativeWizard and the hacked firmware updater succeed in flashing the 1.62.02 version but not the 1.30.02 (exactly the one I was interested in ). This means that update_extract correctly extracts the firmware file (otherwise the firmware v1.60.02 shouldn't be flashed too) but I don't understand what's wrong with the firmware v1.30.02. I've noticed that the file size is the greatest (21,4Mb) among all the firmwares I've seen: perhaps the problem is there and CW nor the hacked updater can handle such a big firmware file (maybe they truncate the firmware file...).I've tried also the older versions of CW but they don't even recognize my player (though CW v0.8.4.0, Windows and Creative Media Explorer do).
Try opening it with CreativeWizard and see if it can recognize the format...
Then try calculating the checksum and see if it's correct with the one in the NULL block
BTW why can't you just use the original fw updater which contains v1.30.02 ?
It recognizes and opens the firmware.
I don't know if I've calculated the checksum well (I've used CW with the default key 'CTL:N0MAD|PDE0.DPMP.') but the checksum doesn't correspond to that in the null block while it corresponds for the other firmwares I've tested. What's wrong??? I've thoroughly tested update_extract and I'm almost sure that now it works as expected so where is the problem?
Because, as said, my ZVM is faulty and, among the other issues I'm working on, it doesn't correctly reports the battery charge level and the v1.30.02 updater package hangs up on the low battery warning (it's impossible to ignore it like with the newer versions also when the player is connected to the AC adapter).
p.s. You haven't told me what was wrong with the older update_extract version. I'd like to know it if you want. Have a good day!
I also decrypted FRESC (v.1.30.02) and checked for the checksum key and it's exactly the same; so that can't be the problem either.
Try using other/older versions? I found this site.
The problem was the find_firmware_offset() routine, like I explained previously.
Page created in 0.1 seconds with 21 queries.