cross-compiling the thing without VFT resolves the issue. .. ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4 paddr=[82000000..8248841f] ELF-loading image 'kernel' paddr=[80000000..8002ffff] vaddr=[f0000000..f002ffff] virt_entry=f0000000 ELF-loading image 'sel4test-driver' paddr=[80030000..80410fff] vaddr=[10000..3f0fff] virt_entry=1e8d4 Enabling MMU and paging Jumping to kernel-image entry point...
Now it stay here - but that's some other issue I need to double check. Thanks! - Wladi 2017-01-20 0:27 GMT+01:00 <alexander.k...@data61.csiro.au>: > Hi Wladislay, > > > On Thu, 2017-01-19 at 12:19 +0100, Wladislav Wiebe wrote: >> Hi Alex, >> >> > Regardless, seL4 does not support it. >> ignore my last mail - just saw you pointed to the fact that sel4 >> doesn't support VFT. >> >> But I am still wondering about cross compiling the project - >> Is it enough to set CONFIG_KERNEL_CFLAGS and CONFIG_USER_CFLAGS ? > > You can compile with `make V=3` and check each invocation of the > compiler to ensure that the flags are correct. > >> >> > The appropriate args should be >> > passed to your compiler to prevent its use. >> Btw. do you have an good alternative? The toolchain is currently >> configured with --with-fpu=neon-vfpv4 > > The best alternative that I can suggest is to use the supported > toolchain for seL4: > https://sel4.systems/Info/GettingStarted/DebianToolChain.pml > > > - Alex > > >> >> >> Thanks! >> - Wladislav Wiebe >> >> 2017-01-19 10:50 GMT+01:00 Wladislav Wiebe <wladislav...@gmail.com>: >> > Hi Alex, >> > >> > I've checked how a working Linux image looks like and it seems it is >> > compiled with >> > $ arm-cortexa15-linux-gnueabihf-readelf -A -n vmlinux >> > .. >> > Tag_CPU_name: "7-A" >> > Tag_CPU_arch: v7 >> > Tag_CPU_arch_profile: Application >> > Tag_ARM_ISA_use: Yes >> > Tag_THUMB_ISA_use: Thumb-2 >> > Tag_FP_arch: VFPv2 >> > .. >> > compiled with -msoft-float -mfpu=vfp. >> > >> > >> > Adding >> > CONFIG_KERNEL_CFLAGS="-marm -mtune=cortex-a15 -march=armv7-a >> > -msoft-float -mfpu=vfp -mtls-dialect=gnu -g -std=gnu11 -ffreestanding >> > -fno-stack-protector" >> > CONFIG_USER_CFLAGS="-D_XOPEN_SOURCE=700 -marm -mtune=cortex-a15 >> > -march=armv7-a -msoft-float -mfpu=vfp -mtls-dialect=gnu -g -std=gnu11 >> > -ffreestanding -fno-stack-protector" >> > >> > will cause linker issues >> > ld: error: elfloader.o uses VFP register arguments, >> > /stage/arm/keystone/lib/libcpio.a(cpio.o) does not >> > >> > Is there some more other config parameter which needs to be considered as >> > well? >> > >> > Thanks! >> > - Wladislav Wiebe >> > >> > >> > 2017-01-19 1:27 GMT+01:00 <alexander.k...@data61.csiro.au>: >> >> Hi Wladislav, >> >> >> >> Does the architecture support the VFP extension? >> >> >> >> Regardless, seL4 does not support it. The appropriate args should be >> >> passed to your compiler to prevent its use. >> >> >> >> - Alex >> >> >> >> >> >> >> >> On Wed, 2017-01-18 at 13:19 +0100, Wladislav Wiebe wrote: >> >>> I attached the Lauterbach and it seems when executing >> >>> elf_getMemoryBounds() >> >>> it jumps to invalid memory region when initializing >> >>> uint64_t mem_min = UINT64_MAX; >> >>> >> >>> Disassembled it seems it happens when executing this instruction: >> >>> vmov.64 d16,0xFFFFFFFFFFFFFFFF >> >>> >> >>> Does somebody has an idea whats going wrong in that case? >> >>> Same thing happens when executing such code e.g. in platform_init(). >> >>> >> >>> >> >>> Thanks! >> >>> Wladislav Wiebe >> >>> >> >>> 2017-01-16 14:17 GMT+01:00 Wladislav Wiebe <wladislav...@gmail.com>: >> >>> > another interesting thing is, even putting a debug print to: >> >>> > diff --git a/elfloader-tool/src/arch-arm/elf/elf.c >> >>> > b/elfloader-tool/src/arch-arm/elf/elf.c >> >>> > index 1751c5c..f16492d 100644 >> >>> > --- a/elfloader-tool/src/arch-arm/elf/elf.c >> >>> > +++ b/elfloader-tool/src/arch-arm/elf/elf.c >> >>> > @@ -267,7 +267,7 @@ elf_getMemoryBounds(void *elfFile, int phys, >> >>> > uint64_t *min, uint64_t *max) >> >>> > uint64_t mem_min = UINT64_MAX; >> >>> > uint64_t mem_max = 0; >> >>> > int i; >> >>> > - >> >>> > + printf("init elf_getMemoryBounds\n"); >> >>> > >> >>> > >> >>> > >> >>> > will not be visible in the startup anymore .. >> >>> > >> >>> > >> >>> > 2017-01-13 15:06 GMT+01:00 Wladislav Wiebe <wladislav...@gmail.com>: >> >>> >> Hi Alex, >> >>> >> >> >>> >> I am right now stopping u-boot before it changes to LPAE. >> >>> >> Boot log from u-boot shows: >> >>> >> [ 8.638] RAM Configuration: >> >>> >> [ 8.641] Bank #0: 80000000 2 GiB >> >>> >> >> >>> >> checking >> >>> >> [ 11.049] uboot# md 0x80000000 >> >>> >> [ 30.803] 80000000: fffffffe ffffbcdd ffff79bc ffff369b >> >>> >> .........y...6.. >> >>> >> seems the memory is available and accessible. >> >>> >> >> >>> >> [ 30.912] uboot# md 0x82000000 >> >>> >> [ 96.775] 82000000: 00000000 00000000 00000000 00000000 >> >>> >> ................ >> >>> >> shows empty memory. >> >>> >> >> >>> >> I am setting up the >> >>> >> "keystone") >> >>> >> ENTRY_ADDR=0x82008000 >> >>> >> >> >>> >> Configuring the linkerl.lds to >> >>> >> KERNEL_BASE = 0xe0000000; >> >>> >> PHYS_BASE = 0x80000000; >> >>> >> >> >>> >> >> >>> >> and the hardware.h looks like: >> >>> >> #define physBase 0x80000000 >> >>> >> #define kernelBase 0xe0000000 >> >>> >> >> >>> >> static const kernel_frame_t BOOT_RODATA kernel_devices[] = { >> >>> >> { >> >>> >> /* UART */ >> >>> >> UART0_PADDR, >> >>> >> UART0_PPTR, >> >>> >> true /* armExecuteNever */ >> >>> >> } >> >>> >> }; >> >>> >> >> >>> >> static const p_region_t BOOT_RODATA avail_p_regs[] = { >> >>> >> /* 2 GiB -1 page to prevent uin32_t overflow */ >> >>> >> { /* .start = */ 0x80000000, /* .end = */ 0xfffff000 } >> >>> >> }; >> >>> >> >> >>> >> static const p_region_t BOOT_RODATA dev_p_regs[] = { >> >>> >> { /* .start = */ UART0_PADDR, /* .end = */ UART0_PADDR + (1 << >> >>> >> PAGE_BITS) } >> >>> >> }; >> >>> >> >> >>> >> Now starting: >> >>> >> >> >>> >> [ 42.255] uboot# bootelf >> >>> >> [ 84.351] ## Starting application at 0x82008000 ... >> >>> >> >> >>> >> ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4 >> >>> >> paddr=[82008000..8232c41f] >> >>> >> load_images() >> >>> >> Load kernel >> >>> >> Load kernel - OK >> >>> >> elf_checkFile >> >>> >> elf_checkFile - OK >> >>> >> elf_getMemoryBounds >> >>> >> >> >>> >> >> >>> >> I added some debug prints to elfloader and seems to stop >> >>> >> again at elf_getMemoryBounds() >> >>> >> >> >>> >> >> >>> >> Let me know if you further suggestions on debugging this. >> >>> >> >> >>> >> Thanks! >> >>> >> - Wladislav Wiebe >> >>> >> >> >>> >> >> >>> >> 2017-01-13 3:59 GMT+01:00 <alexander.k...@data61.csiro.au>: >> >>> >>> >> >>> >>> Hi Wladislav, >> >>> >>> >> >>> >>> I don't have much experience with this platform, but can RAM be >> >>> >>> remapped >> >>> >>> to a lower physical address range by using the MPAX? >> >>> >>> >> >>> >>> Although you might have problems later regarding LPAE, your current >> >>> >>> issue might be unrelated. It could be memory corruption caused by >> >>> >>> conflicting/aliasing addresses for the bootloader, elfloader or their >> >>> >>> associated stacks. >> >>> >>> >> >>> >>> You could try changing the address at which the elfloader is loaded >> >>> >>> and >> >>> >>> executed: >> >>> >>> https://github.com/seL4/seL4_tools/blob/master/elfloader-tool/gen_boot_image.sh#L29 >> >>> >>> >> >>> >>> - Alex Kroh >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> On Fri, 2017-01-13 at 01:22 +0000, adrian.da...@data61.csiro.au >> >>> >>> wrote: >> >>> >>>> Hi Wladislav, >> >>> >>>> >> >>> >>>> The short answer is that LPAE is not currently used or supported by >> >>> >>>> seL4 and so you will not be able to describe physical memory that >> >>> >>>> resides above 4gb to it. >> >>> >>>> >> >>> >>>> Adrian >> >>> >>>> >> >>> >>>> On Fri 13-Jan-2017 12:20 AM, Wladislav Wiebe wrote: >> >>> >>>> >> >>> >>>> > Hello, >> >>> >>>> > >> >>> >>>> > I am trying to integrate TI Keystone 2 platform to seL4. >> >>> >>>> > What I have done so far is basically an initial port of the >> >>> >>>> > Kernel/libs/elfloader/Platform components >> >>> >>>> > and introducing a new keystone defconfig. >> >>> >>>> > >> >>> >>>> > Relevant config parts about the setup: >> >>> >>>> > CONFIG_ARCH_ARM_V7A=y >> >>> >>>> > CONFIG_ARCH_ARM=y >> >>> >>>> > CONFIG_ARCH_AARCH32=y >> >>> >>>> > CONFIG_ARM_CORTEX_A15=y >> >>> >>>> > CONFIG_PLAT_KEYSTONE=y >> >>> >>>> > >> >>> >>>> > At the end I am able to generate an image which looks like: >> >>> >>>> > >> >>> >>>> > $ arm-cortexa15-linux-gnueabihf-readelf -e >> >>> >>>> > images/sel4test-driver-image-arm-keystone >> >>> >>>> > ELF Header: >> >>> >>>> > Class: ELF32 >> >>> >>>> > .. >> >>> >>>> > Entry point address: 0xc0008000 >> >>> >>>> > .. >> >>> >>>> > (I am using the same entry point as Linux use it) >> >>> >>>> > >> >>> >>>> > >> >>> >>>> > So far, it stops booting in the elfloader -- output log: >> >>> >>>> > .. >> >>> >>>> > [ 29.705] ## Starting application at 0xc0008000 ... >> >>> >>>> > >> >>> >>>> > ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4 >> >>> >>>> > paddr=[c0008000..c032841f] >> >>> >>>> > >> >>> >>>> > -> Stop here <- >> >>> >>>> > >> >>> >>>> > Seems it stops loading @ elf_getMemoryBounds(). >> >>> >>>> > >> >>> >>>> > I suppose it is related to fact that the physical start address >> >>> >>>> > starts @ 0x840000000 which is beyond 32 Bit - so, LPAE support is >> >>> >>>> > required. >> >>> >>>> > >> >>> >>>> > The physical RAM setup looks like: >> >>> >>>> > bank 0: >> >>> >>>> > addr: 0x840000000 >> >>> >>>> > size: 0x17ec5000 (382 MB) >> >>> >>>> > >> >>> >>>> > bank 1: >> >>> >>>> > addr: 0x880000000 >> >>> >>>> > size: 0x80000000 (2048 MB) >> >>> >>>> > >> >>> >>>> > Do you have an idea if this is supposed to be supported on seL4? >> >>> >>>> > What should be the "physBase" and the "kernelBase" for such a >> >>> >>>> > setup? >> >>> >>>> > How should the "static const p_region_t BOOT_RODATA avail_p_regs" >> >>> >>>> > looks like? >> >>> >>>> > >> >>> >>>> > Thanks in advance! >> >>> >>>> >> >>> >>>> _______________________________________________ >> >>> >>>> Devel mailing list >> >>> >>>> Devel@sel4.systems >> >>> >>>> https://sel4.systems/lists/listinfo/devel >> >>> >>> >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> WBR, Wladislav WIebe >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > WBR, Wladislav WIebe >> >>> >> >>> >> >>> >> >> >> > >> > >> > >> > -- >> > WBR, Wladislav WIebe >> >> >> > -- WBR, Wladislav WIebe _______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
