Closed travisgoodspeed closed 8 years ago
I pushed a tool in 8748b4b to migrate 2.032's symbols to many of the other targets. It's written as a crappy shotgun parser in C, but it's rather effective. Only tested on Clang/OS X so far.
We still need a matching tool to identify patch points for BL instructions to these functions, and then we can close this issue and start configuring a bare-minimum configuration with just USB for bootstrapping on the new hardware branches.
I have a tool half-written for hooking of patch-points. It ought to be pushed tomorrow evening, or maybe Tuesday.
Both the hooking tool and the function symbol migration tools have been pushed, so we can now easily port features which are written entirely as C hooks to the firmware.
The next step is to switch over to this patching method while bootstrapping a second version, so I'm closing this issue and leaving #181 for future work on symbol portability. Hopefully we'll have it bootstrapped with USB later this week.
I'll try to added d003.020 to your Automated Symbol Migration tool tomorrow.
tnx
Howdy y'all,
We have a problem: Tytera now has FOUR, count that FOUR incompatible hardware types. They have FOUR different branches of the firmware, and have announced no immediate plans to merge them back to a single base.
The solution will be to automatically migrate symbols from one revision (2.032 for now) to other revisions, then manually patch up whatever can't be automated. In the process we'll have to scrap some of the more awkward patches, to minimize interaction with the older symbols.
Toward that end, we need to generate tools to do the following:
BL
branches to these functions, so that we don't need to manually provide patch points inapplet/merge.py
.Close this issue when we have scripts for those two parts of the migration. After that, we'll need a kernel configuration script to reduce our patches to a minimum, so that we can bootstrap on new targets with more complicated features disabled.