Getting a Second Kernel onboard, a repair kernel

They go by many names, P01, P59, VPW, '0411 etc . Circa 1999 to 2006. All VPW OBD2 PCMs.
User avatar
Posts: 844
Joined: Sat Dec 15, 2018 7:38 am

Re: Getting a Second Kernel onboard, a repair kernel

Postby Gampy » Thu Jan 07, 2021 7:30 am

Because I am such a numbers dummy, I have not calculated out the exact memory foot print of the kernel.
Pretty sure I'm above it though.

NSFW wrote:If you can get the factory OS code to load both kernels into their address space and run (respond to a message, or maybe just send a heartbeat message periodically) then it should also be possible to get either kernel to load the other.
Gampy wrote:Both kernels work stand alone at the addresses used to load them both.
And those addresses are: Kernel at FF8000 and Mini at FFB800.

NSFW wrote:If you haven't already, you'd probably have to remove a bunch of code to make one small enough to fit two copies.
Gampy wrote:I've tried, loading mini above and below kernel.
Kernel binary is 7,894 bytes in size.
Mini binary is 529 bytes.

Map files for those interested.
kernel.map.txt
(5.97 KiB) Downloaded 4 times
Mini.map.txt
(732 Bytes) Downloaded 4 times

NSFW wrote:If not I'd look for bugs in the code that loads the 2nd kernel.

In the following log, note the value in red, that says, 'SendWriteSuccess(command);' in 'HandleWriteMode36()' responded.
That is display only, it's not breaking it, it is only to prove the code runs at least to that point ...
[01:59:20:548] Loaded T:\Automotive\PcmHacks\PcmInterrogator\PcmInterrogator\PcmInterrogator\bin\Debug\MKernel-FFB800.bin
[01:59:20:548] Sending upload request for kernel size 529, loadaddress FFB800
[01:59:20:548] Requesting permission to upload kernel.
[01:59:20:563] Setting timeout for ReadProperty, 25 ms.
[01:59:20:563] TX: AT ST 06
[01:59:20:579] OK
[01:59:20:579] TX: STPX H:6C10F0, R:1, D:34000211FFB800
[01:59:20:610] RX: 6C F0 10 74 00
[01:59:20:610] Found response, Success
[01:59:20:610] Upload permission granted.
[01:59:20:626] Going to load a 529 byte kernel to 0xFFB800
[01:59:20:626] Setting timeout for SendKernel, 50 ms.
[01:59:20:626] TX: AT ST 0C
[01:59:20:626] OK
[01:59:20:626] Sending end block payload with offset 0x0, start address 0xFFB800, length 0x211.
[01:59:20:626] Sending 'test device present' notification.
[01:59:20:626] Setting timeout for Minimum, 0 ms.
[01:59:20:626] TX: AT ST 01
[01:59:20:642] OK
[01:59:20:642] TX: STPX H:8CFEF0, R:0, D:3F
[01:59:20:657] Setting timeout for SendKernel, 50 ms.
[01:59:20:657] TX: AT ST 0C
[01:59:20:673] OK
[01:59:20:735] TX: STPX H:6D10F0, R:1, L:538
[01:59:20:751] TX: 36800211FFB800 ... wacked for brevity ... ACB1
[01:59:21:298] RX: 6D F0 10 76 82
[01:59:21:298] Found response, Success
[01:59:21:298] Kernel upload 100% complete.
[01:59:21:298] Kernel uploaded to PCM succesfully...
[01:59:21:313] Setting timeout for ReadMemoryBlock, 250 ms.
[01:59:21:313] TX: AT ST 3E
[01:59:21:313] OK
[01:59:21:313] Sending 'test device present' notification.
[01:59:21:313] Setting timeout for Minimum, 0 ms.
[01:59:21:313] TX: AT ST 01
[01:59:21:329] OK
[01:59:21:329] TX: STPX H:8CFEF0, R:0, D:3F
[01:59:21:345] Setting timeout for ReadMemoryBlock, 250 ms.
[01:59:21:345] TX: AT ST 3E
[01:59:21:360] OK

All that is left at that point is,
Code: Select all
      LongSleepWithWatchdog();

      // Execute if requested to do so.
      if (command == 0x80)
      {
         EntryPoint entryPoint = (EntryPoint)start;
         entryPoint();
      }
Time to move the 'SendWriteSuccess(command);' after the 'LongSleepWithWatchdog();' and see what goes!
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

Site Admin
User avatar
Posts: 6456
Joined: Sat Feb 28, 2009 8:34 pm

Re: Getting a Second Kernel onboard, a repair kernel

Postby antus » Thu Jan 07, 2021 9:19 am

And those addresses are: Kernel at FF8000 and Mini at FFB800.

Kernel binary is 7,894 bytes in size.
Mini binary is 529 bytes.


FF8000(hex) + 7894(decimal) = FF9ED6 (hex) and your loading to FFB800 so the uploaded kernel is clobbering the running one.

Try not calling the watchdog, not sending a response and just executing the uploaded payload straight away so no clobbered functions in the original kernel get called.
And make sure the mode 36 function ends below FFB800 in RAM.
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

User avatar
Posts: 844
Joined: Sat Dec 15, 2018 7:38 am

Re: Getting a Second Kernel onboard, a repair kernel

Postby Gampy » Thu Jan 07, 2021 10:25 am

antus wrote:FF8000(hex) + 7894(decimal) = FF9ED6 (hex) and your loading to FFB800 so the uploaded kernel is clobbering the running one.
Ain't that something like $FFB800 - $FF9ED6 = $192A (6,442) bytes between them ??

Gampy wrote:Time to move the 'SendWriteSuccess(command);' after the 'LongSleepWithWatchdog();' and see what goes!
After doing that it no longer responded with Success.

Thus, the LongSleepWithWatchDog() is killing it ...
[04:45:31:825] PCM Interrogator (12/27/2020, 5:35 PM)
[04:45:32:513] Voltage: 13.3V
[04:45:32:560] Elm ID: ELM327 v1.3a
[04:45:32:592] ScanTool device ID: STN1110 v4.2.1
[04:57:41:123] Querying operating system of current PCM.
[04:57:41:310] OSID: 12208322
[04:57:41:560] Unlock succeeded.
[04:57:41:623] This interface does not support VPW 4x
[04:57:41:732] Requesting permission to upload kernel.
[04:57:41:779] Upload permission granted.
[04:57:42:638] Kernel upload 9% complete.
[04:57:43:748] Kernel upload 22% complete.
[04:57:44:826] Kernel upload 35% complete.
[04:57:45:951] Kernel upload 48% complete.
[04:57:47:060] Kernel upload 61% complete.
[04:57:48:216] Kernel upload 74% complete.
[04:57:49:310] Kernel upload 87% complete.
[04:57:50:482] Kernel upload 100% complete.
[04:57:50:498] Kernel uploaded to PCM succesfully...
[04:57:54:060] Kernel Version: 010301BB
[04:58:11:544] This interface does not support VPW 4x
[04:58:11:607] Requesting permission to upload kernel.
[04:58:11:669] Upload permission granted.
[04:58:12:372] Kernel upload 100% complete.
[04:58:12:388] Kernel uploaded to PCM succesfully...
[04:58:14:951] Kernel Version: 82408241

The kernel code diff ...
Code: Select all
diff --git a/Kernels/common-readwrite.c b/Kernels/common-readwrite.c
index 6a2d8f0..a9cee25 100644
--- a/Kernels/common-readwrite.c
+++ b/Kernels/common-readwrite.c
@@ -37,7 +37,7 @@ void HandleWriteRequestMode34()
        unsigned length = (MessageBuffer[5] << 8) + MessageBuffer[6];
        unsigned start = (MessageBuffer[7] << 16) + (MessageBuffer[8] << 8) + MessageBuffer[9];

-       if ((length > 4096) || (start != 0xFFA000))
+       if (length > 4096)
        {
                MessageBuffer[0] = 0x6C;
                MessageBuffer[1] = 0xF0;
@@ -149,9 +149,6 @@ void HandleWriteMode36()
                // Notify the tool that the write succeeded.
                SendWriteSuccess(command);

-               // Let the success message flush.
-               LongSleepWithWatchdog();
-
                // Execute if requested to do so.
                if (command == 0x80)
                {
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

Site Admin
User avatar
Posts: 6456
Joined: Sat Feb 28, 2009 8:34 pm

Re: Getting a Second Kernel onboard, a repair kernel

Postby antus » Fri Jan 08, 2021 10:36 am

Uugh brainfart. I read that B as an 8 for some reason. Sorry.
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

User avatar
Posts: 844
Joined: Sat Dec 15, 2018 7:38 am

Re: Getting a Second Kernel onboard, a repair kernel

Postby Gampy » Fri Jan 08, 2021 8:04 pm

No biggie, we all have them ...

In order to clobber kernel code it would have to be loaded very low, within kernel size above base, the data follows the code and is what would be clobbered.
Thus lower then $FF9ED6. ($FF8000 + $1ED6)

Because we are not using everything in the compiled binary, using m68k-elf-size.exe reports incorrect stats ...
However it should be giving the correct data size, so if we use the data size from m68k-elf-size.exe and the actual kernel binary size we should get the actual memory footprint size.
$ m68k-elf-size.exe kernel.elf
text data bss dec hex filename
7903 5264 0 13167 336f kernel.elf

Thus the actual memory footprint size should be: 7,894 + 5,264 = 13,158 bytes.

Thus, technically the second kernel should be loaded at $FF8000 + $3366 + 1 = $FFB367
With things as they currently are, obviously it changes with change.
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

Site Admin
User avatar
Posts: 6456
Joined: Sat Feb 28, 2009 8:34 pm

Re: Getting a Second Kernel onboard, a repair kernel

Postby antus » Fri Jan 08, 2021 11:57 pm

I normally sus out the size by looking at the size of the bin (as its that undoes the relocations and makes it a flat image of the size it needs, but it doesnt include the buffer as its location is hard coded. But you can see that from the kernel.map file and see where MessageBuffer ended up, and how big it is. I dont think we typically use bread crumbs (that was only in dev) so I just build a kernel from the last checked out copy and I get kernel.bin is 7908 bytes (1EE4) so if we load it to FF8000 then the code is FF8000-FF9EE4, and kernel.map has:

Code: Select all
 common.o(.kerneldata)
 .kerneldata    0x00ff9ee8     0x107c common.o
                0x00ff9ee8                MessageBuffer
                0x00ffaefc                BreadcrumbBuffer
                0x00ffaf60                breadcrumbs


So we can see the comms buffer is using FF9EE8 - FFAEFC, so you need to watch out for that area too. The other way to see the end is to look in common.h and see:

Code: Select all
#define MessageBufferSize (4096+20)
EXTERN unsigned char __attribute((section(".kerneldata"))) MessageBuffer[MessageBufferSize];
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

User avatar
Posts: 844
Joined: Sat Dec 15, 2018 7:38 am

Re: Getting a Second Kernel onboard, a repair kernel

Postby Gampy » Sat Jan 09, 2021 1:19 am

Interesting that we get a different kernel size ... I get 7,894 bytes.
My repo is at ed3810b, one commit behind, it is just the Build.cmd change and that is not going to affect the binary size.

The hole between your end of kernel $FF9EE4 and the comms buffer (MessageBuffer) $FF9EE8 is flashIdentifier.
antus wrote:then the code is FF8000-FF9EE4, and kernel.map has:

Code: Select all
 common.o(.kerneldata)
 .kerneldata    0x00ff9ee8     0x107c common.o
                0x00ff9ee8                MessageBuffer
                0x00ffaefc                BreadcrumbBuffer
                0x00ffaf60                breadcrumbs

We can tromp on everything at and above $FFAEFC (breadcrumb buffer and above) if we choose to do so, thus technically a second kernel could be loaded at that address using your build.
$FFAEEE using my build, a whole 14 bytes lower ... :roll:

Antus, you use Build or Build.cmd to build the kernel ??
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

Site Admin
User avatar
Posts: 6456
Joined: Sat Feb 28, 2009 8:34 pm

Re: Getting a Second Kernel onboard, a repair kernel

Postby antus » Sat Jan 09, 2021 12:30 pm

I used build.bat, its easy just to click from the file explorer. I wasnt comparing the actual kernels, I just wanted to talk about how I calc sizes, because often having 2 ways to achieve the same thing is good for trouble shooting when they dont agree. I just checked and my current dev copy is develop from December 8. I can test a latest build if you need.
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

User avatar
Posts: 844
Joined: Sat Dec 15, 2018 7:38 am

Re: Getting a Second Kernel onboard, a repair kernel

Postby Gampy » Sat Jan 09, 2021 1:38 pm

Naw, I don't believe there are any kernel changes after that.

Just something I think is odd ... I would think we should get the same kernel size, our tool chain should be the same.
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

Previous

Return to GM LS1 512Kbyte and 1Mbyte

Who is online

Users browsing this forum: No registered users and 2 guests