Re: C development and patching for P01/P59
Posted: Fri Mar 18, 2022 1:29 am
If what fails?
What defines an OS sector error?
What defines an OS sector error?
Electronic Fuel Injection - Developement & Tuning
https://pcmhacking.net/forums/
Yea I've heard that ... Have you tested that assumption.bubba2533 wrote:I'm not modifying the boot sector. I was under the assumption that if that was in tact a PCM would still be able to be recovered.
You have twisted my words ... I said,bubba2533 wrote:If you don't know the checks are done
I do know there are checks performed!Gampy wrote:I do not know the exact validation checks performed, suffice it to say if a flash write fails in one of the sectors marked for the OS.
I just did, just that ... And the Assumption is correct!
For the sectors you are using!
PCM Hammer will recover them, my apologizes!
[03:18:49:909] PCM Hammer 020
[03:18:50:955] Voltage: 13.0V
[03:18:50:971] Elm ID: ELM327 v1.3a
[03:18:51:002] ScanTool device ID: STN1110 v5.0.0
[03:19:01:174] T:\Automotive\GM_ECU\Testbins\P59\Deleteme.bin
[03:19:01:221] Validating 1024k file.
[03:19:01:224] Start End Stored Needed Verdict Segment Name
[03:19:01:245] 00000 FFFFD D2E8 D2E8 Good Operating system
[03:19:01:249] 08002 162CF F304 F304 Good Engine calibration
[03:19:01:255] 162D2 195FF 27D5 27D5 Good Engine diagnostics.
[03:19:01:260] 19602 1D8AF 1F69 1F69 Good Transmission calibration
[03:19:01:266] 1D8B2 1E1AF E4E7 E4E7 Good Transmission diagnostics
[03:19:01:274] 1E1B2 1F6BF 34AA 34AA Good Fuel system
[03:19:01:282] 1F6C2 1FEAF E783 E783 Good System
[03:19:01:291] 1FEB2 1FFDF 11A9 11A9 Good Speedometer
[03:19:01:300] Requesting operating system ID...
[03:19:12:139] Operating system request failed, checking for a live kernel...
[03:19:18:020] Checking for recovery mode...
[03:19:28:743] PCM is not responding to OSID, kernel version, or recovery mode checks.
[03:19:28:752] Unlock may not work, but we'll try...
[03:19:31:080] Unlock was not successful.
Not sure I understand what you were testing. That is a currently used code section in the PCM so who knows what you erased. There is always a possibility of having a write failure when changing the OS. But with this patch you would only be writing to the factory OS section once. And from then on it would consist of only writes to the empty sections of the OS so while you may loose the calibration parameters that were added I would think that a flash would still work.Gampy wrote:I just may have to retract my last statement, I may of accidentally left a kernel in RAM ...
However, I have just erased sector 0x40000 (on an AMD P59), powered down the PCM and now PCM Hammer is unable to recover it!
Now that is a good point, the OS checksum would need to be updated. I planning on looking into something like that, but I wasn't sure if I would be able to define an additional segment. I figured I might have to just steal one segment. I've been busy figuring out the code and patching portion that I haven't looked into any of this yet.kur4o wrote:The biggest issue I see is the OS checksum is at $500 and you have to write boot block every time. A real hard brick disaster situation.
It will be best to change OS end range up to 90000 or a0000 depending how much code you have and include code patch there so it is one time flash, and create new cal segment, that lays within a flash chip erase segment so it can only that segment be updated.
You'll figure it out ...bubba2533 wrote:Not sure I understand what you were testing. That is a currently used code section in the PCM so who knows what you erased. There is always a possibility of having a write failure when changing the OS. But with this patch you would only be writing to the factory OS section once. And from then on it would consist of only writes to the empty sections of the OS so while you may loose the calibration parameters that were added I would think that a flash would still work.
Good call. If the new data can't be fit in the cal segment (possibly by removing something un-needed and recovering some cal and potentially code space), doing it kur4o's way way to avoid the need to erase the boot block and so is a winner. If the boot block is ok a recovery boot and flash should be possible.kur4o wrote:The biggest issue I see is the OS checksum is at $500 and you have to write boot block every time.A real hard brick disaster situation.
It will be best to change OS end range upto 90000 or a0000 depending how much code you have and include code patch there so it is one time flash, and create new cal segment, that lays within a flash chip erase segment so it can only that segment be updated.