On Fri, Feb 3, 2023 at 8:26 AM Sam Leffler via Devel <devel@sel4.systems> wrote: > > 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)
Here is the referred to Jira issue, but it doesn't provide any additional context: https://sel4.atlassian.net/browse/SELFOUR-2335 shoehorn is attempting to calculate how the kernel and root server binaries will be unpacked into memory in order to place the elfloader's start address above the unpacked region. shoehorn calculates the region by iterating over the PT_LOAD segments from each ELF file. The elfloader then unpacks each ELF file at runtime by iterating over the PT_LOAD segments. For some reason, the two implementations don't agree. In your case, the offline calculation expects that the root server is loaded from [0x23b000, 0x335000) whereas the online calculation attempts: [0x23b000, 0x33bfff). Are you able to print the segment headers for the root server image you are loading? I'm guessing (from quickly looking at the code) the issue is that the shoehorn calculation only sums the p_memsz amounts for each PT_LOAD segment and isn't taking into account any gaps between segments in the virtual address space. A fudge-factor wouldn't be needed if these two calculations weren't out of sync. > 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). This seems fine to me. > > -Sam > _______________________________________________ > Devel mailing list -- devel@sel4.systems > To unsubscribe send an email to devel-leave@sel4.systems _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
