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 ?
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
Thanks!
- Wladislav Wiebe
2017-01-19 10:50 GMT+01:00 Wladislav Wiebe
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
: 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
: 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
: 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
: 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...
- Alex Kroh
On Fri, 2017-01-13 at 01:22 +0000, Adrian.Danis@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