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! -- WBR, Wladislav WIebe
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!
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
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.Kroh@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...
- 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
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.kw@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.Kroh@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...
- 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
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.kw@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.kw@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.Kroh@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...
- 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
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.kw@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.kw@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.Kroh@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...
- 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
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.Kroh@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.kw@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.kw@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.Kroh@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...
- 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
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 <wladislav.kw@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.Kroh@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.kw@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.kw@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.Kroh@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...
- 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
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.kw@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.Kroh@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.kw@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.kw@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.Kroh@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... > > - 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
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.Kroh@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.kw@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.Kroh@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.kw@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.kw@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.Kroh@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... >> >> - 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
participants (3)
-
Adrian.Danis＠data61.csiro.au -
Alexander.Kroh＠data61.csiro.au -
Wladislav Wiebe