PCM Hammer P12 development

[antus]

I truly do want to see asm kernels. If pcmhammer gains the ability to support a limited subset of kernel features I'll create an asm kernel for read for P01/P04/P59 and now maybe P12. Then once we see some results and can test it, build on it from there. At the moment a lot more code needs to be cut in asm for pcmhammer to work, or cut out of pcmhammer which is a bit too yuck for a stepping stone. I'd like to get some more simple working PCM read kernels out there to start with, and not worry about a compatible CRC implementation initially. And for the P04 there wouldn't be room to have it at all.

[Gampy]

Yea me too Tazzi ... Patience is not one of my strong points!

Actually the P04 can have all the same stuff, we just need a tiny mode3680 kernel to get a more capable one onboard.

Like I said earlier, It would be nice to add a Vehicle Factory, PCM Factory and Comms Protocol Factory to the PCM Hacks suite ... give it growing room!
The architecture is beyond my skills ...

[antus]

I dont think we need the boot loader which you have described to take another larger to support mode 36 00 and 36 80 to load a larger kernel in parts on the P12 because it looks like it has that natively. Its the P04 that lacks that, and it would need it. If we had one we could re-use it and it would be nice. Its just more development work.

[Gampy]

Didn't say the P12 needed it, just the P04 so far.

The P12 is handling multi packet handsomely.

[Gampy]

I guess we found some important toes ... It becomes unresponsive at about 73% upload.

I guess I should not have tried the full blown 7782 byte C write kernel ...
Go big or go home ...

Now I'll have to trim PCM Hammer's ancillary process features to use a less featured read kernel.

High Ho, High Ho it's off to work I go ...

[kur4o]

DOn`t go over ffff7fff, and try lowering at upto ffff0000, Might fit that way.

[Gampy]

Tried FF0000 as well ... same result.

[Gampy]

Hmmm, a deeper look at the log, it's getting to the 3680 packet every time, no matter the base address ... So, maybe, just maybe I messed up the sending of the ack from the kernel after the os jumps to it.
I am fallible after all, and it was 3am or so when I built that package, then went to sleep only to wake in horror about an hour later knowing something was wrong ...

Then I remembered ... I forgot to add the needed elements to PcmInfo.cs, it would never have worked!

ToothPickEyes-Tom.jpg

I edited, I rebuilt, edited the PM adding the new build.

[Gampy]

Yup, sure enough ...

So, PCMHammer's stock write-kernel.c has this as some of the first code to run after the Os jumps to it and before the main loop (what I call the entry point/area),

Code: Select all

	// The factory code jumps into the kernel before sending this message
	SendWriteSuccess(0);

Code: Select all

void SendWriteSuccess(unsigned char code)
{
	// Send response
	MessageBuffer[0] = 0x6D;
	MessageBuffer[1] = 0xF0;
	MessageBuffer[2] = 0x10;
	MessageBuffer[3] = 0x76;
	MessageBuffer[4] = code;

	WriteMessage(MessageBuffer, 5, Complete);
}

Now I know for a fact that at least on the P01 on my bench ATM that is not needed ... The Os sends the 3680 ack just before it jumps to the kernel.
write-kernel.c is the only one that has this, neither micro-kernel.c or read-kernel.c have it, and they both work for their purposes, including with PCM Hammer (with limits).

Now on the P12, it's Os does not ack the 3680 until it returns from the kernel, yup, the P01 before, the P12 after, so the kernel loader (PCM Hammer for example) chokes, as it is expecting the ack before it can continue, so in my test kernel I had,

Code: Select all

  MessageBuffer[0] = 0x6C;
  MessageBuffer[1] = 0xF0;
  MessageBuffer[2] = 0x10;
  MessageBuffer[3] = 0x76;
  MessageBuffer[4] = 0x00;
  MessageBuffer[5] = 0x73;

Note the subtle differences ...

It's a computer, it must be right!

That's my theory and I'm sticking to it ... (Until I don't )

So, now that I spoiled the surprise that I was trying a full blown write kernel (with write disabled), I have the next one out for testing ...

Edit;
I may test this with a P01, I'd like to see what happens if you do not reboot the P01.
Maybe I should try rebooting to end the kernels life with the P12 versus exit (rts) ... ie Don't pet the Dog!

[Gampy]

Kernel code is not ID'ing the Flash Chip.

I'm perusing the datasheet to verify the ID commands ... The problem, I can read about a paragraph of data sheets before I fall asleep, this might take all night!