P04 R&W Testing

[Gatecrasher]

You've got to be careful with those sticker numbers. If the part has been reflashed since it was manufactured, those won't match. They're a good starting point though.

[kur4o]

3c 08 is what gm uses for cal identification. I think the database may be a good source to extract all p.n since there is all superseded numbers in there available in plain text format.

[kur4o]

Some quick chart to decode year by 10th digit in vin

Code: Select all

1980	'A'	13
1981	'B'	17
1982	'C'	17
1983	'D'	17
1984	'E'	17
1985	'F'	17
1986	'G'	17
1987	'H'	17
1988	'J'	17
1989	'K'	17
1990	'L'	17
1991	'M'	17
1992	'N'	17
1993	'P'	17
1994	'R'	17
1995	'S'	17
1996	'T'	17
1997	'V'	17
1998	'W'	17
1999	'X'	17
2000	'Y'	17
2001	'1'	17
2002	'2'	17
2003	'3'	17
2004	'4'	17
2005	'5'	17
2006	'6'	17

[Gampy]

Hardware number is simple ... For every change of hardware, the hardware id changes, no matter how small the change.

Unfortunately like Gatecrasher states, it is only valid if it has never been written with 3rd party tools ... Obviously this goes for the rest of the numbers as well.
They are after all stored in the binary ...

I personally engrave the original numbers on the cover.

I know I'm wasting my breath ... However I will still speak my peace!

Antus,
I assure you, the following,

This Operating System ID:BlaBla is unknown to PCMHammer, Please report it and it's accompanying Service Number to any of the following,
. . The PcmHacking Forum: pcmhacking.net
. . The PCM Hammer Facebook page: facebook.com/PcmHammer
. . The PCM Hammer Facebook Group: facebook.com/groups/PcmHammerUsers/
. . Or raise an Issue at github.com/LegacyNsfw/PcmHacks/issues
And it will be added as soon as possible, you will be notified via the same channel.
Thank you!

Is far far better for PCMHammer's public image then this,

[10:43:53:926] WARNING: P04 Support is still in development.
[10:43:55:049] The PCM didn't accept the unlock key value
[10:44:00:103] Unlock response truncated, expected 6 bytes, got 4 bytes.
[10:44:03:235] Unable to process unlock response.
[10:44:03:238] Unlock was not successful.

Especially considering it's not even a P04!

kur4o,

Thank you for providing more proof they are different animals.

flash_routines_v6.7z

I'm done with it, I'll waste my breath no more, Y'all are going deal with it longer then I, for I am living on borrowed time, two years so far ...

I was just hoping to wash the shit out of PCMHammer and get as many VPW PCM's working as possible before I do go!

Have a nice day!

-Enjoy

[Gatecrasher]

3c 08 is what gm uses for cal identification. I think the database may be a good source to extract all p.n since there is all superseded numbers in there available in plain text format.

It's not. It's the end model (also called end item) part number. End model is a combination of hardware + software. That's why it's different from the calibration ID or OS ID.

[kur4o]

Gampy,

You are the main reason p04 support exist now. And did excellent job, It will be sad to abandon now. I really don`t care how this will be setup in pcmhammer as long it works prone free. I am trying my best to get as much info as possible, so no time is wasted on reinventing the wheel. The issue is really not that easy for any solution. And I still haven`t come up with a way to identify the pcm without reading bin first out of it, or get some bin identifiers.

A temporary solution can be a user selectable pcm type before reading, with some logic to check chipID and algo. That way a test read can be made without adding each unknown OS number.

I will call that 256kb p03, it sound plausible and follows the p03-256kb,p04-512kb,p05-1mb in size increase.

[antus]

I was just hoping to wash the shit out of PCMHammer and get as many VPW PCM's working as possible before I do go!

You have done that, and done it well. That is why we are having this conversation!

Regarding the messages, there is a human factor to that. I don't think facebook is any good, I dont think any of us monitor that page full time. NSFW created it, I have a read every now and then if I have the time, but I dont have the time to monitor for posts about OSIDs. Forums are good for me, personally, I don't mind directing people here. If others wanted to put in the time ongoing making test builds and merging changes it might be possible, but having enough skilled developers with enough patience ongoing would be a requirement. Github has been good, but I have found that many don't know how to use git, and it ends up being help someone get started with git, then if they succeed maybe you get a pull request. People could log issues there. But we are still talking hundreds maybe a thousand submissions, edits, test builds, conversations with people who may be submitting the wrong pcm or the wrong information or maybe their pcm is supported they just have a broken bench setup etc. Even if they have best intentions the time cost will be huge and ongoing. The middle ground might be to improve the error message so people know where to send corrections or new data, but I really don't want to re-create the wheel from scratch.

So I think that hardware id, isnt a good way forward. Traceability aka serial number isnt either. I don't think we can cross reference it against anything. Yes any internal identifier can be changed with a clone, including OSID but that's OK, because if the PCM is booted and talking, the kernel we have listed against that identifier will run. Vin is an interesting way to put a year on the PCM, once we know what type it is and again assuming it is correct. Thats only if a different year needs a different kernel though, and OSID lookup still allows us to record different things.

I would like to have page where you can choose some options and hit read on any pcm for testing. If anyone wants to have a go at implementing it, it would be awesome.

I (partially) decompiled one of the 256Kb bins last night, it looks like the existing P04 kernel might run on it. If anyone has hardware please test.

I can see references to both the P04 watchdogs we know about, and the DLC registers in the same place as the other P04s. So I think it really is an early P04. Just from a bit of ebay searching I found service number 16211539 and 16207326. I'm sure there are more, I noted them down but I didn't get serious.

There was some code in one of the watchdog functions that I havnt seen in the later ones. Im not sure what is at FF8FC0, perhaps the 256K will need that and will crash without it. Also perhaps it'll be safe to put it in the kernel and it will just do nothing on the other P04s, thus we still get a one size fits all P04 kernel.

I'd be somewhat surprised if something else was at FFE800 and FF801 other than a DLC, but we'll see when we get up to testing that variant.

@gampy I hope your not serious about being done. We certainly could still use more help if you are up for it. I don't think we are going to agree on the data side of things, but your work on the asm kernels, build system and UI has been great. I reckon I could finish of the flash part, but your code is nicer and tidier than mine. I've been leaving that for you.

Code: Select all

96 Bonneville L36 16257922.bin

ROM:00001698 ; =============== S U B R O U T I N E =======================================
ROM:00001698
ROM:00001698
ROM:00001698 watchdogs:                              ; CODE XREF: sub_72A:loc_7F8↑p
ROM:00001698                                         ; sub_72A:loc_83A↑p ...
ROM:00001698                 move.b  #$55,($FFFFFA27).w ; 'U'
ROM:0000169E                 move.b  #$AA,($FFFFFA27).w
ROM:000016A4                 bclr    #7,($FFFFC006).w
ROM:000016AA                 bset    #7,($FFFFC006).w
ROM:000016B0                 move.b  #1,($FFFF8FC0).w   <------- ?????
ROM:000016B6                 rts
ROM:000016B6 ; End of function watchdogs

ROM:000016B8 ; =============== S U B R O U T I N E =======================================
ROM:000016B8
ROM:000016B8
ROM:000016B8 watchdog1:                              ; CODE XREF: sub_DBD2↓p
ROM:000016B8                                         ; sub_DBD2+C↓p ...
ROM:000016B8                 move.b  #$55,($FFFFFA27).w ; 'U'
ROM:000016BE                 move.b  #$AA,($FFFFFA27).w
ROM:000016C4                 rts
ROM:000016C4 ; End of function watchdog1
ROM:000016C4
ROM:000016C6
ROM:000016C6 ; =============== S U B R O U T I N E =======================================
ROM:000016C6
ROM:000016C6
ROM:000016C6 watchdog2:                              ; DATA XREF: ROM:00000404↑o
ROM:000016C6                 bclr    #7,($FFFFC006).w
ROM:000016CC                 bset    #7,($FFFFC006).w
ROM:000016D2                 move.b  #1,($FFFF8FC0).w   <-------   ?????
ROM:000016D8                 rts
ROM:000016D8 ; End of function watchdog2

ROM:0000105E sub_105E:                               ; CODE XREF: sub_72A+128↑p
ROM:0000105E                                         ; sub_72A+160↑p ...
ROM:0000105E                 move    sr,-(sp)
ROM:00001060                 ori     #$700,sr
ROM:00001064                 jsr     (watchdogs_noFF8FC0).l
ROM:0000106A                 move.b  d0,($FFFFE801).w ; P04 DLC Register?
ROM:0000106E                 move    (sp)+,sr
ROM:00001070                 rts
ROM:00001070 ; End of function sub_105E

ROM:00001072 sub_1072:                               ; CODE XREF: sub_72A:loc_75C↑p
ROM:00001072                                         ; sub_72A+D4↑p ...
ROM:00001072                 move    sr,-(sp)
ROM:00001074                 ori     #$700,sr
ROM:00001078                 move.b  ($FFFFE800).w,d0 ; P04 DLC Register?
ROM:0000107C                 move    (sp)+,sr
ROM:0000107E                 rts
ROM:0000107E ; End of function sub_1072

[antus]

The only thing it doesn't have is service part numbers.

Thats probably the main field we would want. Does it have any fields we can use to identify hardware from OSID, Hardware ID, or Calibration ID?

[Gampy]

.
kur4o,
Antus,

Thank you for the kind words, however the facts are, I could not have done it without you.

There is however a miss understanding, one thing I am not, is a quitter, I don't quit ... I will continue to do as much as I possibly can to improve PCMHammer to my last dying breath! Literally!

But I refuse to continue debating whether what is currently in PCMHammer for P04 OsID's is other then a truck load of shit, it is.

If it is possible to get a list of OsID's from TIS2000, then that is what needs to happen, a fresh start with GM info, not 3rd party crap.

Obviously I'm happy to do the work ... Of course I must first figure out how, never used TIS2k ... No big deal, I'm up for it.
If it takes me purchasing some kind of TIS2k access, I will unless it's thousands of dollars, then I'd like the opportunity to rethink, I still may, but I'll want to think about it much harder.

Antus,

The message and facebook, is just something I threw together as an example, I don't waste my time on that cesspool either!
I wanted more then pcmhacking.net ... in a real message an email addy would be great.

I agree, we are not going to agree on some things, you're a truck load approach kind of person, I am a baby spoon approach kind of person.
Or as I always say, I like to eat my elephant one bite at a time!
But that doesn't mean we cannot agree to disagree and move on ... However, sooner or later we will still have to resolve the disagreement somehow or what it is over will suffer.
I don't want it to be PCMHammer that suffers.

I do also understand the constant (babysitting) verifying, adding and building by user submissions, and that I really am the only one ATM that has time to do so, and that you understand my time is running out.
Hopefully we/I can get others to take over as my abilities dwindle.

--------

Now on with it, what to call the 256k twin 80 pin connector PCM, I don't care as long as it's not gobbed together under the same exact name as another, if it's otherwise identical to the 512k P04, then IMO GM likely would have
called it P04, then when they came out with the 512k version that is otherwise identical, they would have called it P04b, if there is a 1m version it would be P04c.
But only if they only differ by size ...

I am just assuming by following suit with others, like the P01/P59, P12/P12b.

If there is a difference, it will have a different moniker.

-Enjoy

[Gatecrasher]

My first thought was to just go by utility file part number. The utility file should be unique to a given hardware type. You can also work backwards through the database to get VIN data from software part numbers. So you'd know this software goes to that make, model, engine and year.

I don't think it's possible to get 100% coverage, but it should be possible to close up a lot of the gaps.

The other problem is the data ends at Nov 2007. I've heard of a mid 2008 update, but that might be for Global TIS.

I only just got it converted the other day and I'm still working on pulling meaningful data. My SQL isn't much better than my Python. I did come up with a list of 71 P04 OSIDs based on a common utility number, so that was promising. My sincere wish is to contribute quality data instead of just exchanging one truckload of shit for another.

In other news, I finally wired up my P04 for bench use. Nearly all of the DIDs either return zeroes, or 7F 31. So that's annoying.