CakesFW: ARM11 Module Implementation
#Introduction Module is similar to plugin (e.g. In PSP, CFWs uses modules as plugins) . ARM11 module implementation allows the CFW to add many features as users want. Some CFW has already implemented several features on ARM11, but they are often unnecessary for most users. The modularization keeps both of the simplicity and extensibility.
The module loader is something like kernel. It manages loaded properties on the environment.
#Implementation CakesFW has DHS, something kind of debugger running on ARM11. The module loader will be implemented in the same way.
##Module Loader The module loader loads ELFs. The loader should take advantage of the format.
###Features The module loader supports several (unique) features.
####Relocator The module loader relocates ELFs statically and allows to run plugins in the best condition.
####Dynamic Linker The dynamic linker enables to share functions and save memory. It also enables to share handlers, which is the most essential part of the module loader. (e.g. NTR CFW implements its own dynamic linker, but it’s different from the generic format)
#####Preinstalled functions The module loader has the following functions. They are available via dynamic linking.
- cakeLoadExec
cakeLoadExec loads and executes a new module. This function will be used by init.elf, which I’ll explain later.
- __service_ptr
__service_ptr is a variable and compatible with ctrulib. It provides service handlers.
###Limitation The modules should be loaded memory aligned with 64KB. The restriction can be removed, but 3DS may be able to map memory at aligned virtual addresses. (I’m not sure that because I’m noob at 3DS.)
##init.elf The module loader loads init.elf when it boots. init.elf is responsible to load other modules. init.elf reads its configuration file and loads modules.