pcmhacking.net

here you gohttp://www.gearhead-efi.com/Fuel-Inject ... DII-Tuning has tons of bins

antus wrote:We might need to drop the crc code and maybe more still to get the file size down. Also if we cant do multi part uploads we may not be able to support a number of interfaces, or might need a small stub that can run then take further segments.

I had to remove all the crc checks and OS check since v6 file has them at different address

Vampyre wrote:here you gohttp://www.gearhead-efi.com/Fuel-Inject ... DII-Tuning has tons of bins

Thanks

Mike

First we need to validate the vpw tranciever addresses are the same or different. I think they might be different and thats why the kernel is running but we cant here from it or vica versa. Probably do need to use ida on a factory bin now and find / investigate vpw code.

Edit: I just took at quick look at that bin file above.

These are the register addresses for the P01 and P59:

.equ J1850_Config, 0xFFF600
.equ J1850_Command, 0xFFF60C
.equ J1850_TX_FIFO, 0xFFF60D
.equ J1850_Status, 0xFFF60E
.equ J1850_RX_FIFO, 0xFFF60F

I looked for FFF60D and came up empty. I think this confirms that the VPW transceiver is mapped differently, and thats our current hurdle.

Ive been looking at factory code - the second watchdog is 0xFFFFC006 (it was 0xFFFFD006 in the P01 / P59) so there is one change we'll need. The first watchdog is still 0xFFFFFA27. The VPW registers appear the same. If you update the second watchdog in the cut down kernel it'll probably run and might communicate.

What is watch dog, what are the hex bytes we need to look for

Its a safety thing. The factory code flips some bits every so often which resets a reboot timer. This means that if the code crashes in an infinite loop the watchdog wont get scratched and the pcm will reboot. The idea is this might make your engine misfire a few times but then it'll be running rather than stop dead and staying that way. Many embedded systems have this. I just edited my post above - the VPW registers (the DLC, data link controller) appear to be the same. So load address, kernel size, and second watchdog address might be the things we need to solve to get reading working.

https://github.com/LegacyNsfw/PcmHacks/ ... rnel.c#L21
to

Cool I'll try that tomorrow when I get back home.

What data in the bin do i need to look for is it readable only in hexcode or ida

sorry, my eyes must have been bleeding, now I look again its not FFC006, its actually FFD006 as it was in the P01/P59, so nothing to try
ida can show you the bytes and the instructions from the factory bin so you can identify how the hardware works. but to compile a new kernel you'd use the gnc 68k toolchain from here http://gnutoolchains.com/m68k-elf/ and run build.bat in the kernel source dir.

I read somewhere NSFW wasnt posting the kernel data with the rest of the program, is that why When I compile it or run debug with my changes in cant find the kernel and I have to copy paste it from distro version?

Since im loading the kernel to a different address than it was built for could that be causing issues?