pcmhacking.net

No, we'll have to figure it out from other code, and/or older Motorola DLC datasheets. We figured out the P01/P59 DLC from the MC68HC58 datasheet, but I dont think that describes the fewer register version of the silicon. You could take a look though, maybe I missed it. There is a lot in there. http://www.datasheetcatalog.com/datashe ... HC58.shtml

I wouldnt even know where to begin looking for that kinda info in the data sheet

any one know where this data came from or if its just arbitrary numbers?
void ScratchWatchdog()
{
WATCHDOG1 = 0x55;
WATCHDOG1 = 0xAA;
WATCHDOG2 &= 0x7F;
WATCHDOG2 |= 0x80;
}

its from the hammer kernel

WATCHDOG1 and WATCHDOG2 are register addresses defined here https://github.com/LegacyNsfw/PcmHacks/ ... mmon.h#L20 found by disassembling factory code. 0x55 and 0xAA are from the code and the DLC data sheet, and are just picked by Motorola as the magic values the hardware checks for to know the code is alive. Probably because: ANDing with 7F where 7F is 0111 1111 clears the high bit and leaves other bits as they were, and ORing with 80 which is 1000 0000 sets the high bit. So were toggling the high bit. The factory code uses bit set and bit clear asm, but there isnt really a way to specify those opcodes from C, though we could have inlined some asm like:
But then we cant use the #define macro so you need to know to look at that code right there instead of the values in the H file should you want to port it to another system. Pros and cons...

Here is part of the documentation about it from the datasheet. The above is what they're on about and with enough sifting through the datasheet you can figure it out. The datasheet doesnt give you the addresses in this implementation though, so you need to put 2 and 2 together from the disassembly.

Antus beat me ... Darn I'm slow!

[edit]
Technically it's called Computer Operating Properly watchdog.
Or COP for short as many call it including me, COPA and COPB in this case.

got it some what, got all the way to read but couldnt find any data, im thinking I removed to much info from kernel to shrink it down.

anyway we could do away with the stuff to query flash and just add that data to pcminfo like the other stuff. the added amd and 1024 intel stuff in the kernel makes it way to big to load, maybe separate kernels for each or at least for seperate for read write?

Good work, but yes it looks like it crashed instantly, thus restarting the factory OS which responds responds that it there is an error (7F) with the non-standard kernel version command (3D 00). Not sure about the 11 on the end, but its still a 7F (Error) for 3D 00 (PCMHammer kernel version)

That's where I'm at, I would say it's a DLC issue, it's not talking back to us.

I can only do 2048 bytes in one packet due to my tool, so I have had to really hack hard, but it's enough to do research with.
It is tested on a P01/59 and works fine.

I'm suspecting the DLC command structure is different being there are only two (that I can find in disassembly) DLC register addresses.
At the moment I'm trying to understand the commands needed to achieve the goal.

If a data sheet could be found that covers a DLC chip with two registers that could possibly help.

But to be totally honest, I do not know for sure there is only two register addresses, that is all I have found, that doesn't mean that is all there is.
They could be using far different addresses and not all close to each other like on the P01/59.

For those that want to take a look without spending a lot of time ... In the 2005 Grand Am GT file uploaded by Vampyre, look at addresses starting around 0x00000C?? (Search for FFFFE8), At 0x00001702 is what I believe is the DLC Command table (just found this while writing this post).
I need to go find this table in my most annotated OS 12587603, if there is one.

And I just noticed something looking for info for this post, In my previous post,

Gampy wrote: I have tried,

Code: Select all

  char volatile * const DLC_Configuration          = (unsigned char*)0xFFE800;
  char volatile * const DLC_InterruptConfiguration = (unsigned char*)0xFFF800;
  char volatile * const DLC_Transmit_Command       = (unsigned char*)0xFFE800;
  char volatile * const DLC_Transmit_FIFO          = (unsigned char*)0xFFE801;
  char volatile * const DLC_Status                 = (unsigned char*)0xFFE800;
  char volatile * const DLC_Receive_FIFO           = (unsigned char*)0xFFE801;
  char volatile * const Watchdog1                  = (unsigned char*)0xFFFA27;
  char volatile * const Watchdog2                  = (unsigned char*)0xFFC006;

Note the ERROR!should be, I will correct and test.

Its not just not talking back, its crashing. If it was not crashing there would be nothing coming back from the pcm, because the kernel would be running and keeping the watchdog going, but unable to talk back. this is the hardest bit with kernel dev. sorting out crashes, blind. I think 2 registers is right, tx and rx are the same, and command and status are the same. But I havnt found a datasheet that describes this yet. Since the chip is initialised when the kernel handover happens, we should not have to init it, just talk to it.

I actually quit working on this for a couple of days to let things soak, did a couple other projects, am back at it with a new look on things ... That is one of the things I was going to try, removing the init stuff and just leave the talking stuff.

[12:29:32:183] RX: 83 00 20
[12:29:32:355] RX: 6C F0 10 7F 3D 00 11

And because there is a response, that tells you it's crashed or at least the kernel is not running, correct??

So, how do we know that the OS even attempted to run the kernel??
That it recognizes sub mode 80, Once it responds ...