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
