bubba2533 wrote:I mapped the FlexCAN memory locations and there are references to both A & B modules. I'm under the assumption that overriding any locations in RAM won't matter as there will be a reset when exiting the kernel.
The SWT memory range (0xFFF38000 - 0xFFF3BFFF) doesn't have any references at all. I even searched in memory for "FF F3" and still couldn't find anything valuable. This doesn't make me very confident that this is the correct reference manual. I was thinking maybe there is some code that wasn't disassembled so that's why I searched for ""FF F3", but I'm lost at the moment so maybe I should take a break and come back to it.
Also I found this online tool which has helped convert back and forth between hex and ASM. https://disasm.pro/
They could be using a base address minus an offset or something along those lines, so it might not show up directly.
You would do better searching for the sequence keys since they HAVE to be entered exactly like that: 0xA602 followed by 0xB480 or 0xC520 followed by 0xD928
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Tazzi wrote:
If you need help understand the canbus, more then happy to break it down.
I think I'm getting it now, but I'm sure there will be more questions I have.
Tazzi wrote:
But PPC with VLE is alot harder to follow/decode then Motorola as used with the P01/P59 ecus. I spent quite a few months going through examples, simulators and even uploading commands in a basic custom kernel to work out what specific opcodes were doing. VLE is still new to me, the commands themselves are basic but doesnt seem to decompile nicely sometimes.
This is definingly something I'm struggling with as well. If you have any resources please post them up. I'm relying so much on the decompile window that if it did something incorrect I don't think I would notice it.
Biggest thing for me was understanding common op codes like rlwinm (Rotate Left Word Immediate then AND with Mask), since this was used everywhere and cause massive headache. I did have a great link I use to reference too which broke down the commands nicely, but I cant seem to see it in my bookmarks.
IBM has great examples though: https://www.ibm.com/docs/en/aix/7.1?top ... nstruction
he following code rotates the contents of GPR 4 to the left by 2 bits and logically ANDs the result with a mask of 29 ones:
# Assume GPR 4 contains 0x9000 3000.
# Assume GPR 6 contains 0xFFFF FFFF.
rlwinm 6,4,2,0,0x1D
# GPR 6 now contains 0x4000 C000.
# Under the same conditions
# rlwinm 6,4,2,0xFFFFFFFC
# will produce the same result.
So it ends up looking like this: GP6 = (GP4<<2) && (0x1D).
Keeping in mind that the registers will wrap around when shifting, so bit 31 (counting from 0) will then move back to bit0 location is shifting by 1.
Next thing thing that blew my mind, is the data is stared in big ed format. This honestly kept breaking my head without examples. If you had the example of say, 0xC7, which in binary is 0x11000111. If you wanted to remove the lowest two bits, you would need to && this with a mask of 0 to 29 (0x3FFF FFFF), as this will have bits 30 and 31 as zero. Thus end result would be 0x11000100= C4.
My E38 thread.. is a chronical of a man slowly going mad working the above bullshit out.
This command has been the most difficult to understand. I think i got the hang of it. I need to run via the bdm setup and single step it to actually be 100% sure.
Tazzi wrote:
They could be using a base address minus an offset or something along those lines, so it might not show up directly.
You would do better searching for the sequence keys since they HAVE to be entered exactly like that: 0xA602 followed by 0xB480 or 0xC520 followed by 0xD928
I haven't been able to find any of these magic numbers in the disassembly, so that's a big roadblock for me. I know it has to be in there somewhere, but it's proven a little difficult to find.
I was thinking of getting SPS and doing a flash while logging with a logic analyzer to see what I can find, but I have never used SPS or any other GM tool for that matter.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
bubba2533 wrote:I haven't been able to find any of these magic numbers in the disassembly, so that's a big roadblock for me. I know it has to be in there somewhere, but it's proven a little difficult to find.
I was thinking of getting SPS and doing a flash while logging with a logic analyzer to see what I can find, but I have never used SPS or any other GM tool for that matter.
It could be saving these bytes to a separate location and then just referencing them maybe? Might need to double check I didn't screw up with those values from the reference manual. Those value do show up in the bin when just searching the bin directly with a hex editor, but haven't checked to see where they end up in the decompiled format.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
I decided to go looking for the watchdog service routine. I couldn't find it either. But I did find this in the reference manual:
Watchdog Service Code.This field is used to service the watchdog and to clear the soft lock bit
(SWT_MCR[SLK]). If the SWT_MCR[KEY] bit is set, two pseudorandom key values are written to service
the watchdog, see section Section 17.4, “Functional Description”, for details. Otherwise, the sequence
0xA602 followed by 0xB480 is written to the WSC field. To clear the soft lock bit (SWT_MCR[SLK]), the value
0xC520 followed by 0xD928 is written to the WSC field.
So maybe this thing is using the pseudorandom key to feed the watchdog, and that's why the static sequences don't seem to show up in the disassembly.
For whatever it's worth, the MPC5644A in the chassis control module I disassembled has the SWT in the same location. I can't find the service routine in that code either.
If I'm reading this right, both the core watchdog (WTE) and the software watchdog (SWT) are disabled entirely. The first two bytes in the ECM code are 00 5A. Maybe watchdog functionality is left entirely to the slave CPU?
The chassis module is set up the same way. It doesn't have a secondary CPU, but I haven't looked to see if it has some kind of hardware watchdog chip.
If I'm reading this right, both the core watchdog (WTE) and the software watchdog (SWT) are disabled entirely. The first two bytes in the ECM code are 00 5A. Maybe watchdog functionality is left entirely to the slave CPU?
The chassis module is set up the same way. It doesn't have a secondary CPU, but I haven't looked to see if it has some kind of hardware watchdog chip.
Weird, Iv never seen an OS intentionally disable the watchdog timers!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
it might restart them after boot. its likely watchdog isnt running in the boot recovery mode (if there is one). logic for that might be that if the boot code fails you have a brick, watchdog isnt going to help, and maybe even watchdog will cause problems due to an external factor like something connected to an interupt line stuck high. The main OS might turn them back on after an initial setup, after the boot code is finished. Just because it turns them off, doesnt mean it stays that way for operation. I have nothing to back any of this up, its just a thought and a reason to keep an open mind.