533
edits
Changes
m
cleanup references to the 0x0DC0xxxx, they are used for (useless) calculations and nothing more.
Line 76:
Line 76:
=== Official ELF loaders ===
=== Official ELF loaders ===
−The [[boot2]] and [[IOS]] elf stub loaders seem to be position-independent: they can be loaded at any address and will still work, as long as it doesn't overlap with the destination of the ELF load. The code itself appears to reference pointers relative to 0x0dc00000 before calculating their addresses relative to the loader base.
+The [[boot2]] and [[IOS]] elf stub loaders seem to be position-independent: they can be loaded at any address and will still work, as long as it doesn't overlap with the destination of the ELF load.
−The official ELF loaders set up a stack and calculate their own address. Then they do the following:
+The official ELF loaders set up a stack and calculate their own address, switches to THUMB mode, and then they do the following:
<source lang="c">
<source lang="c">
Line 88:
Line 88:
This sets the [[Hollywood/Registers#HW_SRNPROT|HW_SRNPROT]] register to enable the [[Starlet/Main Memory|SRAM]] mirror at 0xFFFE0000.
This sets the [[Hollywood/Registers#HW_SRNPROT|HW_SRNPROT]] register to enable the [[Starlet/Main Memory|SRAM]] mirror at 0xFFFE0000.
−After this, it attempts to zero memory after <code>e_entry</code>, but the size of the range is 0, so no memory is cleared. This may be a crash fix, since most of the code appears to be translating addresses from a base of 0x0dc00000 to the actual base, but this does not occur here.
+After this, it loads the ELF file, and then '''zeroes out the memory area where the ELF file resides'''. Then it goes back to ARM mode and vectors to 0xFFFF0000 (the entrypoint of the ARM / vector table). The entire BOOT2 code seems to be position-independent: it can be loaded at any address and will still work, as long as it doesn't overlap with the destination of the ELF load. The entire BOOT2 file cleartext is loaded and then the loader is called, so the loader can calculate the offset of the header simply by subtracting 0x10 from the PC at its entrypoint.
After this, it loads the ELF file, and then '''zeroes out the memory area where most of the ELF loader resides'''. Then it goes back to ARM mode and vectors to 0xFFFF0000 (the entrypoint of the ARM / vector table). The entire BOOT2 file cleartext is loaded and then the loader is called, so the loader can calculate the offset of the header simply by subtracting 0x10 from the PC at its entrypoint.
After this, it loads the ELF file, and then '''zeroes out the memory area where most of the ELF loader resides'''. Then it goes back to ARM mode and vectors to 0xFFFF0000 (the entrypoint of the ARM / vector table). The entire BOOT2 file cleartext is loaded and then the loader is called, so the loader can calculate the offset of the header simply by subtracting 0x10 from the PC at its entrypoint.