I have a target platform with only 4M of memory. When the system image is generated and the shoehorn helper script is used to find a place in memory to load the build artifacts it tacks on an extra 4M of memory use (aka fudge_factor). The comment in the code https://github.com/AmbiML/sparrow-seL4_tools/blame/master/cmake-tool/helpers/shoehorn.py#L209 says this is to accommodate sel4test_driver. Needless to say this breaks on my 4M target platform. So I made the fudge-factor settable from the cmd line with a default of 0 and changed the sel4test build glue to set 4M when building elfloader. Works fine for my target platform. But this change breaks building a bootable image for rpi3 (AARCH64=1 bcm28367)--shoehorn places elfloader s.t. it overlaps the image; e.g.
ELF-loader started on CPU: ARM Ltd. Cortex-A53 r0p4
paddr=[335000..51a0ff] No DTB passed in from boot loader. Looking for DTB in CPIO archive...found at 378778. Loaded DTB from 378778. paddr=[237000..23afff] ELF-loading image 'kernel' to 0 paddr=[0..236fff] vaddr=[ffffff8000000000..ffffff8000236fff] virt_entry=ffffff8000000000 ELF-loading image 'capdl-loader' to 23b000 paddr=[23b000..33bfff] vaddr=[400000..500fff] virt_entry=4009a8 ERROR: image load address overlaps with ELF-loader! ERROR: Physical address range invalid ERROR: Could not load user image ELF
Debug output of shoehorn for this case:
shoehorn: debug: found CPIO identifying sequence b'070701' at offset 0x40
in /usr/local/google/home/sleffler/shodan/out/cantrip/aarch64-unknown-elf/release/elfloader/archive.o shoehorn: debug: encountered CPIO entry name: kernel.elf shoehorn: debug: encountered CPIO entry name: kernel.dtb shoehorn: debug: encountered CPIO entry name: capdl-loader shoehorn: debug: setting marker to 0x0 (region 0 start) shoehorn: debug: setting marker to 0x237000 (kernel_end) shoehorn: debug: setting marker to 0x23b000 (dtb_end) shoehorn: debug: setting marker to 0x335000 (end of rootserver)
So two questions: 1. Where is the 4M under-count of sel4test_driver? (the code indicates this might be explained in JIRA SELFOUR-2335 but I couldn't locate it) 2. Should zero'ing fudge_factor work? If yes, where should I look to remedy the above?
I looked upstream for changes that might address this issue but didn't see anything.
I suspect I can invert my logic and default fudge_factor to some value and then override as needed (e.g. 0 for my sparrow platform & 4M for sel4test builds).
-Sam