CSL '0401' Program Binary Disassembly Notes

[heinzboehmer]

Yep that's exactly what I'm thinking. Ideally need to do it on both an HP and a non-HP, however I'd have to port the CAN logging to a non-HP version of the code :-)

That would be a fun exercise. Curious to know how stressed these things are (i.e. how much more stuff we can make them do).

I've got both a stock non-HP and a HW converted HP to test with, in case you end up porting the logging!

[karter16]

That would be a fun exercise. Curious to know how stressed these things are (i.e. how much more stuff we can make them do).

I've got both a stock non-HP and a HW converted HP to test with, in case you end up porting the logging!

Okay awesome I do need to do at least some disassembly of a non-HP program for something else I'm working on so it will be on the cards at some point. The DME bmwfnatic has sent arrived today as well so I now have a second DME for testing purposes too which is amazing!

[karter16]

Well this screenshot doesn't look like much, but it's a big milestone.



For some time I've been quietly working on reconstructing C source code from the disassembly work, initially with the primary goal of making the codebase easier to read and understand, but more recently with the goal of being able to compile the source into a binary.

Vast amounts of effort have yielded the ability to compile (from C code) a full binary that is address-exact with 0401. What I mean by that is that the compiled binary has every RAM variable and every tune parameter at the exact memory address it is located at in 0401 (by linking files and sections in the correct order, not by forcing the location of each variable manually. This means any intentional changes to the codebase will correctly reflow). The actual program code is not a byte-exact match with 0401 because I'm using modern GCC whereas I *think* in the 90's and 00's BMW used a Microtek compiler. The compilers have their own strategies and optimisations, hence the program code is not exactly the same in structure (although my goal is of course that actual behaviour is identical).

I reached the point this weekend where the next step was to do an initial test/validation. The approach I decided on was to BDM the full binary (bootloader, program and tune) onto the DME. I modified the boot mode variable at 0x4800 to prevent the bootloader from jumping to the main OS, this forces the bootloader to stay in boot mode and service DS2 communication from the bootloader (effectively limiting the scope of what I was testing).

The screenshot above shows the success. The DME booted into the bootloader, I was able to connect over DS2 (OBD cable) and identify the DME as you can see in the screenshot. My VIN, serial number, and AIF records are shown because I copied over these sections of EEPROM when I BDM'd as I didn't want to cause any EWS de-sync issues, etc.

I was then able to read off the tune from the DME as a test that the major DS2 functions in the bootloader are working.

To have got this far is incredible, but there's obviously a lot more work to be done. I'm not going to reflect on that too much right now and just be pleased with this milestone!

[Bry5on]

That is absolutely epic, man you must have been chugging on this in the shadows for quite some time! Great work!