Getting a Second Kernel onboard, a repair kernel

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: Getting a Second Kernel onboard, a repair kernel

Post by Gampy »

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 130 times
Mini.map.txt
(732 Bytes) Downloaded 137 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!
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
antus
Site Admin
Posts: 8238
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Getting a Second Kernel onboard, a repair kernel

Post by antus »

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: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: Getting a Second Kernel onboard, a repair kernel

Post by Gampy »

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)
                {
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
antus
Site Admin
Posts: 8238
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Getting a Second Kernel onboard, a repair kernel

Post by antus »

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: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: Getting a Second Kernel onboard, a repair kernel

Post by Gampy »

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.
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
antus
Site Admin
Posts: 8238
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Getting a Second Kernel onboard, a repair kernel

Post by antus »

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: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: Getting a Second Kernel onboard, a repair kernel

Post by Gampy »

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 ??
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
antus
Site Admin
Posts: 8238
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Getting a Second Kernel onboard, a repair kernel

Post by antus »

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: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: Getting a Second Kernel onboard, a repair kernel

Post by Gampy »

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.
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Post Reply