pcmhacking.net

What do you mean "other than"? The list matches one of the hwid that matches my pcm originally, but I didnt include other p04 osids the first time around because it was just me testing at that point. I think we need the other osids to round it out. But yes.. does need a fresh look for sure. I wonder if a list of tasks that are outstanding for p04 would help with collaboration?

I do not believe they are all OsIDs, I think it has Hardware IDs, Calibration IDs, ETC..., ETC... in the list, ie unnecessary bloat!

TODO lists are most always helpful ...

Jakefunny wrote:The Watchdog patting in my read kernel is heavily based on WinFlash which worked for Antus.

Any ideas how I can tell what the issue can be? To bad not many people are interested in the P04 PCM, more data would be nice.

I've got a couple P04s and a bench harness, anything in particular I can do to help out? Only problem is I'm a little bit stuck on compiling the p04 branch as mentioned in the first post, and also haven't had any luck finding the 68k assembler that needs to be installed. Anyone able to give me a quick crash course on getting started?

The P04 branch is now merged into the base code ...

This might be helpful: How to Git with PcmHacks in Visual Studio

The m68k tool chain can be found here: GCC-m68k toolchain for Windows

Building the PCM Hammer Application is done within Visual Studio.
Building the PCM Hammer Kernel is done from the Command Prompt. (Or browse to and click, YUK)
1. Open a Command prompt. (NOT Powershell Prompt)
2. Change to the PcmHacks\Kernels directory.
3. Type BuildAll.cmd

FMI it would be best to start your own thread ...

-Enjoy

Hey all,

I'm ready to tackle P04 again.
I made a few variation of a read kernel and close to finishing a micro kernel that can read and write to RAM with a few other features.
All well under 2KB.

But... I am struggling to write to flash (intel). Any ideas? I am ready to try something different.

I tried to follows kur4o's code for writing to P04 from the 'V6 ability for pcm hammer.' thread.
Their code states to write:
0x0006 - 0xFFFA4C
0x6820 - 0xFFFA4A
0x7020 - 0xFFFA4E
0x0006 - 0xFFFA48
bitset #0 - 0xFFE2FA

I assume this is to unlock the flash and I do get an increase in current draw but it doesn't look like I can actually write to flash.

Reading out the values above after PCM boot up I get:
0x0006 - 0xFFFA4C
0x6820 - 0xFFFA4A
0x1020 - 0xFFFA4E
0x0006 - 0xFFFA48

Should I be changing 0xFFFA4C & 0xFFFA48 to 0x0007? Like its done on P01 & P59? So many questions...

Interesting timing ...

Not to slam the door on your face or anything like that, however the PCM Hammer suite already supports reading the P04, and has for awhile, code is in the Github repo.

As for writing to the P04, this is what I'll say to that, I'm close, real close ... Here is an example of how close. That's the new "Assembly Kernel" writing to the last target in PCM Hammers C Kernel 'Supported' write list (P01/P59, P10, P12, P12b).
The C Kernels are now superseded!

Next target ... Drum roll ... P04!

However right at this moment they are getting a rigorous beating wasting write cycles on the current PCMs ... Over and Over and Over and Over!

I should know within a few hours what it is going to take to write to the P04, I suspect I'll be trying shortly.

Post up your code, maybe we can help each other out?

-Enjoy

It been some time so that's awesome the code has been added to PCM Hammer.
I guess I should update my local repo from Github.
I've been writing all my kernels in ASM using program called Easy68K, I don't know if it will look the same...

I took a look at the new to me version. Way more developed then I remember. Good job everyone who contributing.
Would be interesting to see a way to write just the OS like its possible with Parameters and Calibration.

Certainly exiting times. Gampys work is looking really good. You may not have noticed the loader kernel that is working too. We are reading several more types of pcms than what is in the supported list, and gampy has hit this milestone, in theory it shouldn't be hard to keep extending it from here.

Why would you want to write just the OS? We have the CRC so that it only updates changed flash chip sectors, so if the calibration is the same (candidate for segment swap), or the boot block is the same it will not be erased and re-written. What is your concern? Generally speaking I think if people were to write OS without writing CAL inexperienced people would cause bricks where mismatched data crashes the OS, and the boot recovery code (where it exists) does not trigger because it sees a calibration sector signature present and thinks its healthy.

Very exciting. Disregard what I said, I see what you're saying. I just like the option to write to flash exactly what I want.
So for now with the current P04 kernel, erase and write don't work. Is there documentation how I can build on top of the existing kernels?
All of my changes to the bin were made in the OS sector. Antus, if you remember, I was working without the CRC, I didn't realize how CRC part worked.

Gampy has a private branch at the moment. I dont think there is much to add for now, it could be a too many cooks situation. There are no unknowns and it just needs some minor updates for more platforms and more testing. Common code is done. I have helped fix a bug in AMD erase, but now I am out also and just waiting. Erase and write is working for both intel and amd chip. Now its just a case of putting the configuration part in for the other platforms and testing. I expect he'll ask for beta testers soonish and we can jump back in then. The app does still need some more work on OSID databases, but I think P04 is good.