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 _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
