On Fri, Feb 3, 2023 at 10:29 AM Sam Leffler <sleff...@google.com> wrote: > > On Thu, Feb 2, 2023 at 1:56 PM Kent Mcleod <kent.mcleo...@gmail.com> wrote: >> >> 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. > > > Yes, that appears to be the issue. readelf of capdl-loader shows: > > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 > 0x00000000000a9130 0x00000000000a9130 RWE 0x1000 > LOAD 0x0000000000000000 0x00000000004b0000 0x00000000004b0000 > 0x0000000000000000 0x0000000000050168 RW 0x1000 > > so there's a gap between the two load segments that isn't accounted for. > Attached is a change that seems to DTRT. It also appears to eliminate the > need for fudge_factor (in quick testing). You'll probably want to write your > own fix as my python fu is basic.
Thanks for this fix Sam, This seems to be an appropriate fix. If https://github.com/seL4/seL4_tools/pull/158 passes the test suite then I'll try and get the fix merged. Can I use your commit and sign-off the certificate of originality or would you prefer I rewrite it? >> >> >> 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
