In my current project I am re-writing a "BIOS" (in lack of a better term) system for an LPC1788. The idea is that the "BIOS" handles all the set-up of the display/touch-screen/ethernet/USB/SD-Card. Next the user code is loaded from the SD-Card and started.
Since my "BIOS" contains (a lot of) functions that the user might want to call from it's code (eg. all of LVGL). I'm looking for an efficient way to make a connection between the 2 pieces of code.
The current setup uses a thunk "jump-table" at a fixed location. Next in the header files for the user code, there is a struct pointing to this jump-table with all the functions and headers.
Since writing the jump-table and all the other code could be quite time consuming I am looking for an efficient way to create the header file(s) so the user code can call the BIOS code.
As an addition, as suggested by the-busybee. The "BIOS" resides (permanently) in flash and is not a true linked library.
My main question now becomes: How do I build the API (header files) from all the code so it behaves as if it was a statically linked application.
Related questions:
- LPC1788 - Bootloader and shared library Has the same issue, however no solution on how to provide the header files
- Share code between bootloader and application talks about providing a ROM map, however no way on how to do this
- Linker script: insert absolute address of the function to the generated code The closest I can find to an answer. The idea: generate an .inc file with PROVIDE() statements and use those to call the functions. Should technically work, however unclear (for me at least) is how to generate all the function prototypes as well as how to handle changes in the "BIOS". (Since V2 will have everything at different addresses.)
Edit: I just tested the PROVIDE() idea. However that crashes the controller with "UNDEFINSTR"