The PTool Manual (WIP)

If you intend to test many different settings AND your current firmware is less than 1.32 then all you need to use is the "Compare Version Patch" switch - and you should use it everytime you write a custom firmware. You never need to use the "Version Change" under these circumstances.
Interesting, because when I tested two days ago (http://www.dvxuser.com/V6/showpost.php?p=2020219&postcount=3) and tried loading firmware with only "Compare Version Patch" checked off (and AVCHD patches that I wanted to test) with version-agnostic firrmware already running on the camera the version up process would fail after starting (message displayed "please turn off the camera") and corrupt the firmware file on the card. Couldn't delete the file either. After reformating the card I found that "Version Change" patch must always be checked in conjunction with "Compare Version Patch." It just didn't matter what increment number I put in.

EDIT: Could not repeat this in testing two days later http://www.dvxuser.com/V6/showpost.php?p=2022740&postcount=36, when patch worked the way descirbed in the manual.
 
Last edited:
My first guess would be a bad memory card. <shrug> I have no idea. All I know is what it did for me.

I do follow some simple basic rules whenever downloading any firmware images to any cameras tho:

1) Reset all user setting on a freshly powered up camera.
2) Turn the camera off and then on again.
3) Use only a freshly camera formatted card with ONLY the firmware image on it.
4) Always use the AC Adaptor.
5) Reset all User settings again after the image download.
6) Format the card immediately after
7) Power down and up the camera before using it and/or restoring my defaults.

Try it again to see if it wasn't just a fluke?
 
The card is Sandisk Extreme 30Mb/s Class 10. It is one of the better cards out there (as far as reviews are concerned) and it has never given me problems. I doubt it is the problem.

However, thanks for posting your upgrade procedures. Yours are definately more thorough, as for example, I normally don't do steps 1), 3), 5), 6). I'm starting to recall a recommendation (from Vitaliy IIRC) to reset user settings, so maybe that's the issue. I'll try again tonight.
 
My first guess would be a bad memory card. <shrug> I have no idea. All I know is what it did for me.

I do follow some simple basic rules whenever downloading any firmware images to any cameras tho:

1) Reset all user setting on a freshly powered up camera.
2) Turn the camera off and then on again.
3) Use only a freshly camera formatted card with ONLY the firmware image on it.
4) Always use the AC Adaptor.
5) Reset all User settings again after the image download.
6) Format the card immediately after
7) Power down and up the camera before using it and/or restoring my defaults.

Try it again to see if it wasn't just a fluke?


I've heard that it's dangerous to do firmware updates with AC adaptor and it should only be done with a fully charged battery.
 
Ok... Maybe I'm missing something.... I'm learning.... But I used this tutorial to do my first hack: http://wiki.eoshd.com/index.php/Beginners_GH1_Custom_Firmware_Guide

It worked... but after reading these boards I realized I wanted to do more. I went in, made more changes, and when saving the file added one number up, loaded the card, and then the cam wouldn't update. What did I do wrong? I also deleted the original hacked file... Was that a bad move? Someone help please. Thanks.
 
I've heard that it's dangerous to do firmware updates with AC adaptor and it should only be done with a fully charged battery.
Well, if you loose power during the upgrade there is a probability of firmware corruption in camera, with subsequent inability to operate it or finish the upgrade. If such an event is a concern, you can always plug into a UPS. I think most people will already protect their computer equipment if such concerns are not very minor.
It should be noted, that GH1 manual lists AC adapter as a valid option for upgrading, so if anything goes wrong it will be only fair to make that fact known when speaking to the warranty department. Perhaps then future products will be designed with DC in port. I'm not sure why this wasn't done in the first place and instead we got this fake-battery-thingy.
 
I've heard that it's dangerous to do firmware updates with AC adaptor and it should only be done with a fully charged battery.

Yeah, I followed that thread as well. I guess it's somewhat of a personal choice and knowing the stability factor of the AC at your location. In my case I'm completely off the public electrical grid and about the only way the AC could go out is if some stinker cut the wires or something. :)
 
The card is Sandisk Extreme 30Mb/s Class 10. It is one of the better cards out there (as far as reviews are concerned) and it has never given me problems. I doubt it is the problem.

However, thanks for posting your upgrade procedures. Yours are definately more thorough, as for example, I normally don't do steps 1), 3), 5), 6). I'm starting to recall a recommendation (from Vitaliy IIRC) to reset user settings, so maybe that's the issue. I'll try again tonight.

I think 1 and 3 are important - especially 3. 5 and 6 are probably just me being anal. :Drogar-BigGrin(DBG)

So, did you try it again? I'm dying to know how it went...

If you're right it means both Tester and I are wrong and I need to document it in the manual.

I tried mine 3 more times now and for me it works as I described. Are you on a GF1 or a GH1 btw?
 
Last edited:
So, did you try it again? I'm dying to know how it went...

I tried mine 3 more times now and for me it works as I described. Are you on a GF1 or a GH1 btw?
Neither, I have GH13 :2vrolijk_08:

No experiments while at work (for another 4 hrs or so).
 
Well, I couldn't stand waiting any longer and burnt me a GH13 custom firmware upgrade in order to find out how the reversioning (entry #1 and #2) actually work. It's actually completely logical and I have no idea what my problem was. :D I guess I had to see it to understand it.

Anyway basically it goes like this:

It your current firmware is anything less than 1.32 (like mine was 1.0 official!) then you do NOT need to use "Version Change" at all no matter what. Hacked, Official, it doesn't matter because you're writing a higher version when you write either the official or the hacked 1.32 for the first time. This was always the case I guess - peroid.

If you intend to test many different settings AND your current firmware is less than 1.32 then all you need to use is the "Compare Version Patch" switch - and you should use it everytime you write a custom firmware. You never need to use the "Version Change" under these circumstances.

Now, if you're trying to upgrade a camera that's already at 1.32 or higher then you need the Version Change iteration. But if the "Version Compare Patch" is set then after that image in burned you will never need to use the "Version Change" switch again. Assuming you always set the Version Compare ever after.

Once you have an image written with the Version Compare Patch installed you can also restore the camera to any of Panasonic's official patch releases. But of course you should only use 1.32 or later because of the different variables different firmware images store.

If you want to install or reinstall a GH13 custom image over the official 1.32 you then need to use the Version Change so that the camera recognizes the ROM image file as being an "upgrade" (new version). Although if you set the Version Compare Patch then you don't need the Version Change when you write it again after this.

The caveat? With the "Version Compare Patch" installed the GH1's "Version Display" screen reports a BODY FIRMWARE version of 0.0

No biggy, who cares about a version string?


Hehehe, what a fun manual entry! :Drogar-Kriz(DBG):

I would like to add that the version change feature allows testers the flexibility to test various options by carrying two SD cards - one with modified settings, the other with the original Panasonic version. Now it is easy to switch between versions to compare the before and after effects.

Thanks for your efforts in producing the manual.
 
Feature Patch Name: Audio Encoding BPS
  • Function: allows increasing bitrate for AC3 audio stream
  • Usage: from 192,000 (default) to 448,000 bps.
  • Dependencies: None
  • Tested:
  • Stable: Camera will record, but not playback footage. Files will playback on computer.
  • Notes: lpowell, who is an engineer at Dolby Labs recommends to leave audio bitrate at default http://www.dvxuser.com/V6/showpost.php?p=1999254&postcount=1652
  • Request For Information:
 
I just tested the "old" way (i.e. without formatting card etc.) in Release 3.37d and happy to report that "Version Check" works flawlessly. I blame "operator error".

OK, Awesome dooderz! Much appreciated! So I'll keep the current manual description. Also since there is currently such a large volume of conflicting info in these threads it might be a good idea to go back and click the edit button on old posts and add a quicky note - something to this affect.

Feature Patch Name: Audio Encoding BPS
  • Function: allows increasing bitrate for AC3 audio stream
  • Usage: from 192,000 (default) to 448,000 bps.
  • Dependencies: None
  • Tested:
  • Stable: Camera will record, but not playback footage. Files will playback on computer.
  • Notes: lpowell, who is an engineer at Dolby Labs recommends to leave audio bitrate at default http://www.dvxuser.com/V6/showpost.php?p=1999254&postcount=1652
  • Request For Information:

Awesome! Another entry too! You ROCK! man! Thanks!
 
OK, Awesome dooderz! Much appreciated! So I'll keep the current manual description. Also since there is currently such a large volume of conflicting info in these threads it might be a good idea to go back and click the edit button on old posts and add a quicky note - something to this affect.
Good idea, I added the note to my post in this thread.

I see that you are splitting patches up in between two posts. How about putting tested and "production-ready" patches in the first one and research and experimental ones (a majority of them, which also don't have descriptions ATM) in the second?
 
That would be a good idea but they change all the time. As it is they follow the order presented in PTool's GUI listview. This makes it easy for me to find and I'm hoping easy for others to locate the entry more easily.
 
How about color coding them?

RED = Not stable yet or can cause real problems.
YELLOW = Can be stable but use with caution.
GREEN = Good to go, no worries.

What do you think?
 
How about color coding them?

RED = Not stable yet or can cause real problems.
YELLOW = Can be stable but use with caution.
GREEN = Good to go, no worries.

What do you think?
Sounds good, I think this will quickly give an idea to those not familiar with latest developments a quick reference on what's safe to touch and what's not.
 
So... I guess go by Tester's own tagging?

WORKING = GREEN
TESTED / PARTIALLY TESTED = YELLOW
UNTESTED / EXPERIMENTAL = RED

Does that sound about right? Did I leave out anything?
 
Back
Top