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 <[email protected]>: > > 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 <[email protected]>: > >> 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 <[email protected]>: > >>> > 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 <[email protected]>: > >>> >> 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 <[email protected]>: > >>> >>> > >>> >>> 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, [email protected] 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 > >>> >>>> [email protected] > >>> >>>> https://sel4.systems/lists/listinfo/devel > >>> >>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> WBR, Wladislav WIebe > >>> > > >>> > > >>> > > >>> > -- > >>> > WBR, Wladislav WIebe > >>> > >>> > >>> > >> > > > > > > > > -- > > WBR, Wladislav WIebe > > > _______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
