pcmhacking.net

Freescale MPC5674

So I have tested a couple more times and it seems like my NOP infinite loop (Test 7) does in fact stay alive. The only confirmation I have is that the ECU doesn't respond to commands until a key cycle, which I think is sufficient for now.

With my test 9 I wanted to send a message back out on the bus, so I used a function in the boot block. So perhaps because I jumped out of the code in RAM that caused the watchdog to timeout. That's quite interesting, and I will have to replicate those functions to be able to send and receive messages on the bus if I'm unable to jump outside of the kernel.

Entering mode 34 can disable watchdog and interrupts, otherwise the infinite loop will expire pretty soon and reset the cpu. It may enter some suspend state too, I don`t think it is hard to figure the cop registers and sequence and start tests with them.

bubba2533 wrote: Yeah, reading messages into the kernel would be a pretty big milestone, but it would be very time consuming to do with the manual assembly instructions that I’m using now. I would at least like to find a better method for that. If anyone has notes or suggestions on a compiler let me know.

When writing complex code for PPC, I would write the function in C and compile to PPC using something like codewarrior.
The compiler obviously puts all variables into a RAM location it chooses. I pushed the ram addresses into an empty RAM space for the specific CPU I was working with where the kernels do not run, and then appended the custom function to my kernels.
Also needed to make sure all jumps where dynamic and not fixed otherwise jumps needed to be updated to reflect correct locations. I believe I did have to actually change that to dynamic from memory.

I'm surprised you didn't write the entire kernel in C and compile it all at once. Was there any specific reason for that?

Another issue I'm seeing is that in the Ghidra disassembly a handful of times b (unconditional branch) instructions are viewed as the end of a function. This causes the decompiled view of the function to break the function decompiled view into multiple functions even though it should be one function. I'm going to download the latest version to see if that fixes anything.

bubba2533 wrote:I'm surprised you didn't write the entire kernel in C and compile it all at once. Was there any specific reason for that?

Another issue I'm seeing is that in the Ghidra disassembly a handful of times b (unconditional branch) instructions are viewed as the end of a function. This causes the decompiled view of the function to break the function decompiled view into multiple functions even though it should be one function. I'm going to download the latest version to see if that fixes anything.

Simple because I was unable to get it to understand that I was trying to run the entire code in RAM. I did ask questions on forums about it, but it doesnt appear it was designed to be like that, or at least I couldn't get it to be setup like that.
I ended up finding I could write in assembly pretty fluently after doing it for a few hours anyways. Debugging my own code is alot easier then trying to debug compiled C code since it uses a variety of complex commands, plus uses so many variables and RAM locations which make it really hard to follow.

Which processor option in Ghidra are you using?
Where ever there is a 'branch', this will typically create a new function, I believe you can force it to lump chunks together, Id have to check my notes... although that might of being with IDAPro.

Oh ok, that makes sense. That's pretty much where I was at with my Custom OS. It seems like there is too much overhead to figure out and get it working like you want vs. just writing it in asm.

This is processor I'm using.


Yeah it only seems to happen with the "b" branch instruction. It seems that "blr" is the instruction that is used normally, but perhaps "b" is used for non-return functions, so maybe it has a hard time distinguishing between them.

Either way, if you know of a way to override/correct it in Ghidra please let me know.

bubba2533 wrote:Oh ok, that makes sense. That's pretty much where I was at with my Custom OS. It seems like there is too much overhead to figure out and get it working like you want vs. just writing it in asm.

This is processor I'm using.


Yeah it only seems to happen with the "b" branch instruction. It seems that "blr" is the instruction that is used normally, but perhaps "b" is used for non-return functions, so maybe it has a hard time distinguishing between them.

Either way, if you know of a way to override/correct it in Ghidra please let me know.

Hmm, I think I did a graph view and just labelled all the functions to help understand it better.

But that right, branch is usually just done to jump to a piece of code, its not usually used for functions to return as that would get complex to keep track of the address it needs to return to. Its just needed to skip over a piece of code that might be in the way.

Tazzi wrote: But that right, branch is usually just done to jump to a piece of code, its not usually used for functions to return as that would get complex to keep track of the address it needs to return to. Its just needed to skip over a piece of code that might be in the way.

Ok, this jogged my brain and I discovered another mistake I made in my Kernel Test 9 that I made. I used a "b" instruction instead of a "bl" instruction so it didn't know the correct location to return to. So hopefully I can update that and test it again.

I've also took some more time looking for the SWT references and I still cannot find a single one.

Looks like that fixed it! It sends out my message and stays in the infinite loop.