04colyZQ8 wrote:Ok I found another 2004 bcm, that the eeprom was still intact, so you can compare the ram of this on with the earlier post and see were the copy of the eeprom is stored, it is not exactly the same as the eeprom, but very close!
I also posted an exact read of the eeprom via chip clip.
posted the flash of this bcm, and it can be compared to the previous 04 dump. They have different segments
also posted what I think is the registers ? Some small random code I read.
I have tried addresses from 0 to 10000000 and these are the only files I can find, so this is all the unprotected data!
This was sweet!! And how did you compile up the kernel? Was it how I suggested? Using the utility file
And the log file to pull out the segments and properly put it together?
The utility file itself tells you where all the segments go. I had a log, but I only used it to double check my work.
So how’s you discover the entry point? And the pointers? Do we need to do something similar
To correctly disassemble the flash as well?
Educated guess. Four locations right at the top of the file that looked like address pointers turned out to be....address pointers.
The main flash is going to take a lot more work. I'll post my Ghidra archive later today. I've got a lot of the diagnostic stuff fleshed out, but not much else.
Ok that would be sweet!!
Can we trace some of these things?
Like the diagnosis for input output control from tech 2?
At the end of the day if we can test lock unlock, head light on off etc.
that class 2 tool command must trace back to the bcm, and section of code that
Controls that input output, or at least what address at the processor controls that output?
Here's my work thus far. It's mostly diagnostic stuff. Go into the function window and search for "C2_". That's what I used to prefix the class 2 stuff. My idea was to figure out the known diagnostics, then backtrack from there into the memory used for the DTCs. Once I figured out what memory was used for each DTC, I could find the code that wrote those values and from there, find the IO and functionality for each system that had DTCs associated with it. That was the idea anyway. I got lost in the multitude of bytes used for each DTC, and I couldn't come at it from the hardware side since we don't have an accurate user's manual for the chip.
The board won't allow Ghidra .gar files, so just take the .txt extension off.
Gatecrasher wrote:Here's my work thus far. It's mostly diagnostic stuff. Go into the function window and search for "C2_". That's what I used to prefix the class 2 stuff. My idea was to figure out the known diagnostics, then backtrack from there into the memory used for the DTCs. Once I figured out what memory was used for each DTC, I could find the code that wrote those values and from there, find the IO and functionality for each system that had DTCs associated with it. That was the idea anyway. I got lost in the multitude of bytes used for each DTC, and I couldn't come at it from the hardware side since we don't have an accurate user's manual for the chip.
The board won't allow Ghidra .gar files, so just take the .txt extension off.
Good luck.
Thanks!! I don't seem to be able to open it? project files are .gdr I think instead of .gar. do I change that? or how do I import it? BTW you are brilliant!!
04colyZQ8 wrote:Ok I found another 2004 bcm, that the eeprom was still intact, so you can compare the ram of this on with the earlier post and see were the copy of the eeprom is stored, it is not exactly the same as the eeprom, but very close!
I also posted an exact read of the eeprom via chip clip.
posted the flash of this bcm, and it can be compared to the previous 04 dump. They have different segments
also posted what I think is the registers ? Some small random code I read.
I have tried addresses from 0 to 10000000 and these are the only files I can find, so this is all the unprotected data!
Was this flash read starting at address 8000?
You are bang on there, and how you discover that? it was actually input as a decimal in the program as 32768, but That is 8000 hex, so not sure about how that is getting translated bjut anyway I believe you are right! but still the boot loader in the OS sems like the addresses are way off!
04colyZQ8 wrote:Ok I found another 2004 bcm, that the eeprom was still intact, so you can compare the ram of this on with the earlier post and see were the copy of the eeprom is stored, it is not exactly the same as the eeprom, but very close!
I also posted an exact read of the eeprom via chip clip.
posted the flash of this bcm, and it can be compared to the previous 04 dump. They have different segments
also posted what I think is the registers ? Some small random code I read.
I have tried addresses from 0 to 10000000 and these are the only files I can find, so this is all the unprotected data!
Was this flash read starting at address 8000?
You are bang on there, and how you discover that? it was actually input as a decimal in the program as 32768, but That is 8000 hex, so not sure about how that is getting translated bjut anyway I believe you are right! but still the boot loader in the OS sems like the addresses are way off!
The vector table for the tms370 16 bit starts at 0x8000. They are words not bytes. So if you double them they are the address for each vector. 0x8002 is the power up vector. The address for each calibration section is in the beginning of OS. You have to double the value and that is the address. So the OS has 0x5000 stored as its location. But is at 0xA000 double the stored value.
The vector table for the tms370 16 bit starts at 0x8000. They are words not bytes. So if you double them they are the address for each vector. 0x8002 is the power up vector. The address for each calibration section is in the beginning of OS. You have to double the value and that is the address. So the OS has 0x5000 stored as its location. But is at 0xA000 double the stored value.
OH My goodness, bless you my friend!
So.. OS = 5000h x2 = A000 - 8000 (offset) = 2000 and that's exactly where it is!!
next segment is (4C00 x2) - 8000 = 1800, and that's exactly where it is!
I'm sorry I feel dumb, but this is what I get? also asked if it is a single file or not? I say single then set arm 7 big endian 32 bit. This looks strange
Ghidra_ gg 2022-10-05 3_00_42 PM.png (9.85 KiB) Viewed 2066 times
