Custom P04 OS... going off the deep end

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
User avatar
antus
Site Admin
Posts: 8237
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: Custom OS... going off the deep end

Post by antus »

I just noticed the P04 question at the top of this page. We were able to get a kernel loaded and responding over obd2 with pcmhammer, but it was bare bones and very small and didnt do anything useful. So succefull proof of concept is a tick, We can get it loaded and the kernel talking on the OBD2. Just nobody is wanting to pick up that work and develop it further at this point in time.
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
DWS
Posts: 129
Joined: Tue Oct 12, 2021 10:04 am
cars: Tons of Toyotas, 2003 cavi derby car, ford trucks, etc.
Location: USA
Contact:

Re: Custom OS... going off the deep end

Post by DWS »

Nice, does the bare bones code work for intel and amd flash chips? Eventually being able to flash over OBD2 would be a nice feature. I don't know if I'll ever get to the point of having a full os custom coded, but if I do, being able to flash over obd2 would be a perk to add to the os too, just real low on my priority list currently. I should probably update the thread title to include P04.
Ford EEC-V Bin Converter (bank swapping and padding): viewtopic.php?f=41&t=8342
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: Custom OS... going off the deep end

Post by kur4o »

bdm for debugging code is awesome feat. It will really help you do what you need the proper way.

Now it stands the question how you will upload to ram. Over obd2 port or by some other means.

Some notes on the sensors and rpm.

The raw signal for rpm is not rpm. It is usually the time between 2 low resolution events. Than the pcm converts the time needed for a piston to travel x amount of time and some calculations based on cpu speed to get the current rpm target. than you will find dfferent rpm target for low rpm tables high rpm tables and so on. It is just scaled to whatever the ocm needs.

About the ect sensor. The sensor output is totally unlinear. Actually to get a higher Digital resolution, the pcm switches between 2 RC networks to read sensor voltage around 40*C and the table lookup is to convert the non linear analog signal to linear digital signal. Also it could be 2 of these table lookups based on the Rc network being used.
User avatar
antus
Site Admin
Posts: 8237
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: Custom OS... going off the deep end

Post by antus »

DWS wrote:Nice, does the bare bones code work for intel and amd flash chips? Eventually being able to flash over OBD2 would be a nice feature. I don't know if I'll ever get to the point of having a full os custom coded, but if I do, being able to flash over obd2 would be a perk to add to the os too, just real low on my priority list currently. I should probably update the thread title to include P04.
no, it doesnt work for anything other than proving we can unlock security and load our own code which can keep the watchdog happy and drive the DLC chip for inbound and outbound communication over the obd2 bus. Now the flash chips we have working on other pcms, so we need someone to write kernel code and .net code to solve the how does pcmhammer handle the packet size problem (getting enough code in to ram to do the rest) both pcmhammer side and kernel side. Then add some of the flash pieces we have together, and overcome any new problems found along the way. Im imagining a kernel that can load another payload to ram in parts, but a really small flash kernel that might only work on the bigger interfaces (max 4k kernel size) is another option.

viewtopic.php?f=42&t=6574&p=96406#p96406
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
DWS
Posts: 129
Joined: Tue Oct 12, 2021 10:04 am
cars: Tons of Toyotas, 2003 cavi derby car, ford trucks, etc.
Location: USA
Contact:

Re: Custom P04 OS... going off the deep end

Post by DWS »

Yea I noticed that with the RPM, in Ghidra I've been labeling the raw values before conversion rpm pulse time or similar since it's clearly a time based value and I figured cpu clock was part of the math. Not sure what it runs at but I think I read 16mhz and 20mhz were the main options.

I noticed in the IAC/ECT tables that the start/end jumped values faster than the mid range. Makes sense it converts a non-linear value to a linear one since it's easier to work with in that form (mimics actual temps I guess lol).

For loading the ram, just the BDM for now. Once I have a proof of concept built, I can push it into the actual flash memory. Ulink has a getram and setram command. Easily editing the actual program code that it loaded into the ram I'm not sure what the easiest way is. For now the plan is to clone the main part of the code that sets everything up located at $440 into ram, then plug away at stripping down what's not needed. I might also try setting the register values that's used in the code and make a loop to read the sensor values into D0 for example. Change the resistance and get the value to change that shows up in D0 and I'll have atleast one base line concept figured out. Timing, spark, crank, and map sensors seems to be the most complicated sensors to read/process so sticking with something pretty simple seems to make sense to learn what all is required and how this hardware works. Besides that, the crank/rpm data seems to come from one of the addresses that's not documented so pretty sure it's talking to another chip so I don't even know for sure what addresses are registers, could try to guess and check, but I'd need a way to generate a signal and such.

I've for sure learned a ton on this project so far. I've been having slow progress the whole time, so it's nice not being stuck on the same thing banging my head against the wall trying to figure something out lol. There's a hand full of sections of code that I don't grasp 100% yet, but in time I think they will click. Stepping through the code over BDM seems to be the best way for me to learn what's going on, and follow along in ghidra.


@antus

Are you able to read/write ram addresses over OBD2? Maybe you can load the full size of the flash kernal in unused ram space. Start the flash and have the first chunk just jump to the ram address and have that load the data to the flash chip? I've already done a small proof of concept over OBD that programs can run directly in ram instead of directly off the flash chip. What you're doing is a completely different route to what I'm trying to do, but if I find a large space of the ram that's not used, I can give you the address range.
Ford EEC-V Bin Converter (bank swapping and padding): viewtopic.php?f=41&t=8342
User avatar
antus
Site Admin
Posts: 8237
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: Custom P04 OS... going off the deep end

Post by antus »

yes we can and thats how its done. its your 'just' that isnt really just a just... see the thread with the link I just edited in to the post above.
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
DWS
Posts: 129
Joined: Tue Oct 12, 2021 10:04 am
cars: Tons of Toyotas, 2003 cavi derby car, ford trucks, etc.
Location: USA
Contact:

Re: Custom P04 OS... going off the deep end

Post by DWS »

The "just" reference means do nothing but jump to ram, nothing else so there's no size issue in the packets.
Ford EEC-V Bin Converter (bank swapping and padding): viewtopic.php?f=41&t=8342
User avatar
antus
Site Admin
Posts: 8237
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: Custom P04 OS... going off the deep end

Post by antus »

Jumping to RAM is implemented in the factory OS. The hard bit is getting your code in to RAM, and thats the size issue. Many interfaces wont do 4k, and the pcmhammer kernel is closer to 8k with the crc functionality in it and written in C, not asm. Flashing might fit in 4k if the kernel is written in asm. Then pcmhammer needs a way to know and a way to skip stages which are not available in the kernel (so block crc) and still needs to run smoothly for P01/P59 when those features are available. The ls1flassh-free kernel I wrote in asm would be a good contender, but it'd need flash write added, as well as the other functionality pcmhammer needs (they dont speak the same language at the moment)
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
DWS
Posts: 129
Joined: Tue Oct 12, 2021 10:04 am
cars: Tons of Toyotas, 2003 cavi derby car, ford trucks, etc.
Location: USA
Contact:

Re: Custom P04 OS... going off the deep end

Post by DWS »

I see, I figured the kernel was a bit smaller and would fit in ram alone. My thought would be you'd do all the pre-processing on the laptop/flashing device and the stub script just reads what's incoming and dump it into the right addresses. I see where memory limits are a problem though. Clearly I don't know how things work on that side of the coin. Once I get more experience under my belt, maybe I can help, but I think I'd be pretty worthless at this stage lol.

I probably should poke around to see if there's any good books on working with CPU32 or the MC683xx chips. The reference guides help a lot, but some things I think I need to see an example of and explained how it works exactly for me to grasp it. I did finding myself looking at the assembly code more and more when scanning over the bin's for things and grasping the code logic and flow a bit better. The decompiled code is still my overall reference for anything more than a hand full of lines though.

I'm not sure how pcmhammer is structured, but a super optimized (and open source) program to reference would be hashcat. Each hash algro has it's own dll if I recall correctly so each hash type doesn't slow the program down overall. Clearly not the same program design, but maybe a similar style could be used for p01/59 vs p04 and others.
Ford EEC-V Bin Converter (bank swapping and padding): viewtopic.php?f=41&t=8342
User avatar
antus
Site Admin
Posts: 8237
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: Custom P04 OS... going off the deep end

Post by antus »

the pcmhammer flash kernel is open source on github here https://github.com/LegacyNsfw/PcmHacks/ ... op/Kernels
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
Post Reply