The module files contain relocation tables to allow the module to be linked to the core CHDK at run time. This is loaded into a separate block of memory that is discarded after the module is loaded.
I see, so the needed space equals to the filesize of the module?
Another option might be to put text in ARAM and data/bss in the Canon or Exmem heap. These are all known addresses.
That sounds good, probably easier than splitting the menu stuff.
The menus & rbf fonts (which are only used in menus) aren't needed for booting CHDK. They are important of course; but could be loaded dynamically after startup. The issue is if a user doesn't have the module on the SD card they get an error instead of seeing the menu.
... and that's why they are important.
Moving the CHDK menus to a module would save a lot of core memory; but might cause issues for new users if the module is missing or does not match the core version. It also currently has a lot of conditionally compiled code that would need sorting out.
One of my (distant) plans is a packed CHDK-installer diskboot/fir which includes every needed file.
Not sure what you would gain with this. Just packing all the files together would be huge (380K for G1X & current modules) and would include all the overhead of each module. You would be better to create a monolithic build that just compiled everything into the core code like we did before the module system.
That would be an installer, it would replace itself on card with the unpacked real diskboot, and make sure all the other files are installed.
