pcmhacking.net

NSFW wrote:I've done an OS change on a P01, but haven't tried it yet on a P59. However it's probably just a matter of enabling the feature in the app and in the kernel. We disabled OS replacement on P59s temporarily so we could test P59 calibration changes first, since a bad calibration flash is easier to recover from than a bad OS flash.

At this point I want to fix a kernel bug that just came up, and then do another release, but I think we're ready to try OS flashing after that.

Awesome. I can probably guinea pig that if you'd like. Though my truck is not my daily, I do tend to prefer to drive it over my Vette.

Last post from me for the night. Anyone familiar with why my decompiler keeps saying invalid instructions? Every time it's with a 0xf8 byte. Every time my decompiler fails to decode, it's ALWAYS because of this 0xf8 byte. I cannot find the table look up instruction format in the pdf I have, but I would suspect it's that... Anyone know for sure? Wonder if this is one of the CPU32-specific instructions. Weird thing is if I put it into the online disassembler, it also gives me garbage..

NSFW wrote:I've done an OS change on a P01, but haven't tried it yet on a P59. However it's probably just a matter of enabling the feature in the app and in the kernel. We disabled OS replacement on P59s temporarily so we could test P59 calibration changes first, since a bad calibration flash is easier to recover from than a bad OS flash.

At this point I want to fix a kernel bug that just came up, and then do another release, but I think we're ready to try OS flashing after that.

I have, just now for the second time (and third time) (just to create a new log), that is try converting OS's on a P59 ... on an AMD unit, with fixes to HandleEraseBlock(), it still fails to Erase ... See log

jlvaldez wrote:Last post from me for the night. Anyone familiar with why my decompiler keeps saying invalid instructions? Every time it's with a 0xf8 byte. Every time my decompiler fails to decode, it's ALWAYS because of this 0xf8 byte. I cannot find the table look up instruction format in the pdf I have, but I would suspect it's that... Anyone know for sure? Wonder if this is one of the CPU32-specific instructions.

Yep, F8 is the table-lookup opcode, new for CPU32.

NSFW wrote:

jlvaldez wrote:Last post from me for the night. Anyone familiar with why my decompiler keeps saying invalid instructions? Every time it's with a 0xf8 byte. Every time my decompiler fails to decode, it's ALWAYS because of this 0xf8 byte. I cannot find the table look up instruction format in the pdf I have, but I would suspect it's that... Anyone know for sure? Wonder if this is one of the CPU32-specific instructions.

Yep, F8 is the table-lookup opcode, new for CPU32.

Thanks for the confirmation. Let me try to get in contact with the guy of that fork of ghidra and see if I can help him along. Would really like to get full cpu32 support.

Also I'm back at home and ready to attempt a full write of the NOP modification once I can figure out how to generate checksum inbtunerpro. Christmas day so I was traveling the last 2 weeks. Only had my laptop to work from.

There are data tables between the code and the dissassemblers cant always follow code which loads a saved address to a register then jumps to the register address. So they miss valid code, and not all unassembled data is code. Whats showing above looks like data, not code. The instructions before which did decompile dont look like sain code.

Gampy wrote:

NSFW wrote:I've done an OS change on a P01, but haven't tried it yet on a P59. However it's probably just a matter of enabling the feature in the app and in the kernel. We disabled OS replacement on P59s temporarily so we could test P59 calibration changes first, since a bad calibration flash is easier to recover from than a bad OS flash.

At this point I want to fix a kernel bug that just came up, and then do another release, but I think we're ready to try OS flashing after that.

I have, just now for the second time (and third time) (just to create a new log), that is try converting OS's on a P59 ... on an AMD unit, with fixes to HandleEraseBlock(), it still fails to Erase ... See log

SparkFun-Write-Debug-AMD-002.txt

Looks like it never got out of the loop in Amd_EraseBlock. If you have a way to monitor the bus it would be interesting to see if it ever sends a message with an error code. If not I'll give it a try in the next few days.

Might need to look deeper into the datasheet and see if there is something different that we need to do in order to erase blocks other than calibration.

Yeah the amd chips are hard to work with. If you are not, i'd suggest modifying the kernel to send more debug information as it goes monitor for that debug info on the pc side.

I know exactly where it's failing, It (Amd_EraseBlock) doesn't like the Address 0x80000 ... or any of the addresses above that. (9,a,b,c,d,e,f)

Is it possible it's in WordMode not ByteMode??
According to the datasheet, If the BYTE# pin is set at logic ‘1’, the device is in word configuration.

That is what I was testing when I forgot to comment out some previous test code that wound up hard bricking my AMD unit. Pissed me off!

Before that I soft bricked it doing a simple hard coded address test, it worked as expected, then with a carefully crafty kernel and the 'short' trick I was able to recover and rewrite the erased sector, wasn't so lucky the second time.
So, I need to either get another Pcm, a BDM or programmer as it appears to be hard done. Short trick doesn't get it done this time.

It's winter, I can't go outside, so I can't get another, I am not going to set here twiddling my thumbs until summer, I shake to much to get the chip off, so BDM will be ordered ASAP!

Yes im just on my phone but im pretty sure its in word mode. Everything is in 16 bit words.

Usbbdmnt can recover it or its time to desolder the chip and use an adapter. Bdm is a lot safer and wont result in bent pins.

If it's in WordMode, then doesn't that make the table in FlashChips.cs wrong ...
The way I read it, the table in FlashChips.cs is for ByteMode.

According to the datasheet, Table 3. Am29F800BB Bottom Boot Block Sector Address Table

Or am I showing how completely stupid I am and missing something obvious to most (most likely)??
I do know a rock has the one up on me when it comes to math, this I do not question.

It obviously erased, it's became inaccessible.
I looked at my kernel code ... I forgot to comment out an if() statement I had for testing in Amd_WriteToFlash(), thus nothing was being written.
Now that, is what I call STUPIDITY!

Now I don't have a Pcm to test further with and I am dying to know, curiosity is killing me!

[edit]
USB BDM NT ordered ...