For Bootloader Customizer kit we charge 8 support hours.
We implemented the bootloader kit as a callback function that is called multiple times during the boot process, more or less like a Window Procedure in Windows.
The idea behind this is that in this way adding new “hook” points inside the bootloader will not require any change in existing integration, not even rebuilding and adding a dummy stub.
When you don’t process a message you can just return 0, this will let the bootloader behave in the standard way.
The downside is that you’ll have a long switch statement (obviously it may be splitted in functions) and that you may need to cast input parameters for some of the sub-functions (more or less what happens with LPARAM in Windows).
Since the loader is built by linking the blkit and another static lib containing the bootloader code you’ll be able to access function, globals etc. inside it.
For example to change configuration parameters etc.
Gpios can be controlled using the same API we implemented for apps. Only interrupts are not supported.
I included an header file with the “messages” that I already implemented. Let me know if you see something missing or something that may be improved.
- Usually, we don’t recommend using the bootloader kit if not really necessary, as we have added your issue in the roadmap. If you can wait for some time then it would be better.
- If you want us to implement bootloader silent feature at earliest in that case we would ask for 4 support hours and within ONE week after successful payment, we can build a new bootloader having bootloader silent feature implemented.
The bootloader must be build by WEC7 platform builder(it uses ARMv4 assembly and the WEC2013 assembler does weird things on it).