Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated Symbol Migration #175

Closed
2 tasks done
travisgoodspeed opened this issue Jul 12, 2016 · 4 comments
Closed
2 tasks done

Automated Symbol Migration #175

travisgoodspeed opened this issue Jul 12, 2016 · 4 comments
Assignees

Comments

@travisgoodspeed
Copy link
Owner

travisgoodspeed commented Jul 12, 2016

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:

  • Automatically identify the positions of symbols shared in Flash memory between different revisions.
  • Automatically identify the BL branches to these functions, so that we don't need to manually provide patch points in applet/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.

@travisgoodspeed
Copy link
Owner Author

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.

aeickho added a commit that referenced this issue Jul 17, 2016
hopefully build is possible on Clang  #175
@travisgoodspeed travisgoodspeed self-assigned this Jul 17, 2016
@travisgoodspeed
Copy link
Owner Author

I have a tool half-written for hooking of patch-points. It ought to be pushed tomorrow evening, or maybe Tuesday.

@travisgoodspeed
Copy link
Owner Author

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.

@aeickho
Copy link
Collaborator

aeickho commented Jul 20, 2016

I'll try to added d003.020 to your Automated Symbol Migration tool tomorrow.

tnx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants