Page 19 of 24
Re: Colorado / H3 BCM hacking
Posted: Tue Jul 09, 2024 8:19 am
by 04colyZQ8
If someone has a script file sample for 36 with 4x that might help me get this to work
Re: Colorado / H3 BCM hacking
Posted: Tue Jul 09, 2024 11:45 am
by antus
4x and 1x is not relevant. The operating system has already initialised the DLC, and timing is controlled in hardware. The same kernel comms will operate at whatever speed the DLC was running at when it executed without any special DLC code for the speeds. In PCMHammer, the bus speed is set early in the process, there is nothing at all in the kernel different or configured on speed.
You may need more hardware configuration. This is PC memory controller mindset on my part, I don't know about the BCM, but because the addresses are so different the CPU might be configured to block execution from flash before it hands off to the kernel. If thats the case you'll have to figure out where and how to jump to the main flash. Certainly in some PCMs but not others, the output port mask needs to be changed in order to turn on VPP. And for BDM the init code in the cfg files sets up hardware by pokeing in to registers to configure its state to enable flash access. Just one idea, there is a lot of different things that could come in to play here. Getting running the first time is the hardest bit as unless you have a realtime debugger on the hardware you are flying blind until you get a response back and the hardware is unforgiving and with only limited public documentation. It took me years of trying to my first flash kernel to respond, after that it was not so hard.
Re: Colorado / H3 BCM hacking
Posted: Wed Jul 10, 2024 12:09 am
by 04colyZQ8
I'm confused why the factory only sends 6C 40 F0 34, but other programs send 6C 10 F0 34 00 10 00 FF 80 00
I tried 6C 40 F0 34 00 10 00 00 0B 82 and got 6C F0 40 7F 34 00 10 00 00 0B 12 NEG RESPONSE
Otherwise sending the bellow msg after tweaking the script to include a switch to vpw 4x*, I get a good positive 78 and 73 response!!
6D 40 F0 36 00 00 1E 00 0B 82...
*Universal patcher master script code to switch to vpw 4x (had to read the source code to find this!! Will suggest adding this to .txt sample script file:) )
Now if I change to bit 80. than I get a different ack: Is this bad?? Or good?
6D 40 F0 36 80 00 1E 00 0B 82......
RESPONSE
Re: Colorado / H3 BCM hacking
Posted: Wed Jul 10, 2024 12:18 am
by 04colyZQ8
antus wrote: ↑Tue Jul 09, 2024 11:45 am
4x and 1x is not relevant. The operating system has already initialised the DLC, and timing is controlled in hardware. The same kernel comms will operate at whatever speed the DLC was running at when it executed without any special DLC code for the speeds. In PCMHammer, the bus speed is set early in the process, there is nothing at all in the kernel different or configured on speed.
You may need more hardware configuration. This is PC memory controller mindset on my part, I don't know about the BCM, but because the addresses are so different the CPU might be configured to block execution from flash before it hands off to the kernel. If thats the case you'll have to figure out where and how to jump to the main flash. Certainly in some PCMs but not others, the output port mask needs to be changed in order to turn on VPP. And for BDM the init code in the cfg files sets up hardware by pokeing in to registers to configure its state to enable flash access. Just one idea, there is a lot of different things that could come in to play here. Getting running the first time is the hardest bit as unless you have a realtime debugger on the hardware you are flying blind until you get a response back and the hardware is unforgiving and with only limited public documentation. It took me years of trying to my first flash kernel to respond, after that it was not so hard.
True I guess I can do a forever loop? To see if my code is being executed? I'd need to feed the watch dog, which I do know how to do. In theory I should not see any class 2 messages until key off/on
Re: Colorado / H3 BCM hacking
Posted: Wed Jul 10, 2024 1:57 am
by 04colyZQ8
I give up nothing will allow code execution and pretty sure I am getting neg response when ever I try 36 80, maybe it is not defined the factory never sends that who knows how it knows when to jump to ram or not?
Re: Colorado / H3 BCM hacking
Posted: Wed Jul 10, 2024 4:09 am
by kur4o
You can use this as a template, fix ids and clean not needed stuff.
bcm may not allow execute, it may allow but needs specific address to allow execute, This bcm contains flash logic, so nothing is uploaded during flash, only mode ae to enter programming state.
There should be something left on table, but can be figured through a full disassembly.
With script you can use vpw console with avt and mdi tools. It is good to monitor actual bus communication.
When you execute sometimes module doesn`t send anything, sometimes it sends a confirmation and than jumps to code.
You can execute some branch to self infinite loop and watch for bcm crash and reset with some idle data flowing.
Re: Colorado / H3 BCM hacking
Posted: Wed Jul 10, 2024 8:20 am
by 04colyZQ8
kur4o wrote: ↑Wed Jul 10, 2024 4:09 am
You can use this as a template, fix ids and clean not needed stuff.
bcm may not allow execute, it may allow but needs specific address to allow execute, This bcm contains flash logic, so nothing is uploaded during flash, only mode ae to enter programming state.
There should be something left on table, but can be figured through a full disassembly.
With script you can use vpw console with avt and mdi tools. It is good to monitor actual bus communication.
When you execute sometimes module doesn`t send anything, sometimes it sends a confirmation and than jumps to code.
You can execute some branch to self infinite loop and watch for bcm crash and reset with some idle data flowing.
Ok great do I need to branch to my forever loop? I think I tried a 32 bit pointer instead of of my direct loop. I’m also feeding the watch dog each iteration maybe that’s causing the fast reset? I’m getting a reset after I send the 36 80.
Also I thought you can send the code in 36 00 then send an empty data 36 80 after that doesn’t like that at all!
I did:
6d 40 f0 36 80 00 1e 00 00 00 padded for 1e length
Also did :
6d 40 f0 36 80 00 10… padded zeros
And
6d 40 f0 36 80 00 All zeros
Nothing works, these three at give dreaded general reject code 12
I tried 8000ob2 factory pointer to kernel, and 8001b60 comman factory ram location as well nothing works:(
Re: Colorado / H3 BCM hacking
Posted: Wed Jul 10, 2024 8:21 am
by 04colyZQ8
If I don’t scratch watch dog then I doubt I’ll get more then 2sec before reset on forever loop?
Re: Colorado / H3 BCM hacking
Posted: Wed Jul 10, 2024 10:25 am
by Tazzi
Didnt you get this to work?
6D 40 F0 36 80 00 1E 00 0B 82
This is saying to execute code at location 0x001E000B
Re: Colorado / H3 BCM hacking
Posted: Wed Jul 10, 2024 10:37 am
by 04colyZQ8
Tazzi wrote: ↑Wed Jul 10, 2024 10:25 am
Didnt you get this to work?
6D 40 F0 36 80 00 1E 00 0B 82
This is saying to execute code at location 0x001E000B
Well if code 76 is a positive ack? I was not sure?
And it is? Isn’t it length 1e execute at location 0b82 pcm adds 3 byte 80 to make it 0x8000b82 that’s were my code should be