Re: [seL4] arm_data_abort_exception
could it be an TLB fault? For my understandig, based on http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0438g/BABFFDFD.html it is the DFSR = 0x7 -> b00111 Translation fault, 2nd level. Thanks! - Wladislav Wiebe 2017-01-24 15:42 GMT+01:00 Wladislav Wiebe <wladislav...@gmail.com>: > Hello, > > has somebody experience with running into arm_data_abort_exception > after enabling the MMU/paging and jumping to the kernel image: > .. > ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4 > paddr=[9000..904b041f] > ELF-loading image 'kernel' > paddr=[8000..80033fff] > vaddr=[f000..f0033fff] > virt_entry=f000 > ELF-loading image 'sel4test-driver' > paddr=[80034000..8042dfff] > vaddr=[1..409fff] > virt_entry=1e924 > Enabling MMU and paging > Jumping to kernel-image entry point... > > check_data_abort_exception() > DFAR = 0xfff01014 > DFSR = 0x7 > ADFSR = 0x0 > abort() called. > > I've dumped the DFAR/DFSR register -- > > 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 > > > Thanks in advance! > -- > WBR, Wladislav WIebe -- WBR, Wladislav WIebe ___ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
Re: [seL4] ARM LPAE?
cross-compiling the thing without VFT resolves the issue. .. ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4 paddr=[8200..8248841f] ELF-loading image 'kernel' paddr=[8000..8002] vaddr=[f000..f002] virt_entry=f000 ELF-loading image 'sel4test-driver' paddr=[8003..80410fff] vaddr=[1..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,0x >> >>> >> >>> 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
Re: [seL4] arm_data_abort_exception
Hello,
I wonder how to map a device to the kernel where the
first 3 bytes are not 0. Like the UART device which is
phyically connected to 0x02530c00.
The abort handler in pte_pte_small_new() get called
when the first 3 bytes are not 0 (on this SoC are the first 3 bytes
for the UART c00).
Any advice how to deal with this?
Thanks in advance!
- Wladi
2017-01-25 22:22 GMT+01:00 Wladislav Wiebe <wladislav...@gmail.com>:
> Hi Alex,
>
>> A trick that I use to overcome this problem is to introduce a global
>> variable that reflects the status of the PD. The UART driver then
>> switches between the physical and virtual address of the UART as
>> required.
>
> that's it - seems before kernel activates the PD, Kernel might run
> into assertion which wants to print.
> I've changed the UART driver like
> --- a/src/plat/keystone/machine/io.c
> +++ b/src/plat/keystone/machine/io.c
> @@ -18,14 +18,19 @@
> #define ULSR 0x14 /* UART Line Status Register */
> #define ULSR_THRE BIT(5) /* Transmit Holding Register Empty */
>
> -#define UART_REG(x) ((volatile uint32_t *)(UART0_PPTR + (x)))
> +#define UART_REG(x,uart_addr) ((volatile uint32_t *)(uart_addr + (x)))
>
> #if defined(CONFIG_PRINTING) || defined(CONFIG_DEBUG_BUILD)
> void
> putDebugChar(unsigned char c)
> {
> -while ((*UART_REG(ULSR) & ULSR_THRE) == 0);
> -*UART_REG(UTHR) = c;
> +if (status_activate_global_pd) {
> + while ((*UART_REG(ULSR, UART0_PPTR) & ULSR_THRE) == 0);
> + *UART_REG(UTHR,UART0_PPTR) = c;
> +} else {
> + while ((*UART_REG(ULSR, UART0_PADDR) & ULSR_THRE) == 0);
> + *UART_REG(UTHR,UART0_PADDR) = c;
> +}
> }
> #endif
>
>
> When running the machine now, I am at least able to see the assertion
> ..
> ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4
> paddr=[9000..9048841f]
> ELF-loading image 'kernel'
> paddr=[8000..8002]
> vaddr=[e000..e002]
> virt_entry=e000
> ELF-loading image 'sel4test-driver'
> paddr=[8003..80411fff]
> vaddr=[1..3f1fff]
> virt_entry=1e920
> Enabling MMU and paging
> Jumping to kernel-image entry point...
>
> seL4 failed assertion '(address & ~0xf000ul) == ((0 && (address &
> (1ul << 31))) ? 0x0 : 0)'
> at ./arch/object/structures_gen.h:2495 in function pte_pte_small_new
> halting...
>
>
> Thanks!
> - Wladi
>
>
>
> 2017-01-25 1:10 GMT+01:00 <alexander.k...@data61.csiro.au>:
>> Hi Wladislav,
>>
>> If the fault occurs before the activation of the kernel PD, this likely
>> means that you are trying to printf before the UART is mapped.
>>
>> If you are using printf for debugging before the PD is activated, you
>> will need to change your kernel UART driver to use the physical address
>> of the peripheral (the elfloader sets up unity mappings for
>> 0x0000-0xe000).
>>
>> A trick that I use to overcome this problem is to introduce a global
>> variable that reflects the status of the PD. The UART driver then
>> switches between the physical and virtual address of the UART as
>> required.
>>
>> - Alex
>>
>> On Tue, 2017-01-24 at 23:55 +0100, Wladislav Wiebe wrote:
>>> Hi Alex,
>>>
>>> thanks for pointing that out - I will double check the device mapping.
>>>
>>> - Wladislav Wiebe
>>>
>>> 2017-01-24 23:24 GMT+01:00 <alexander.k...@data61.csiro.au>:
>>> > A "Synchronous Data abort" occurs when a virtual memory translation
>>> > fails on load/store operations.
>>> > A "Prefetch abort" occurs when a virtual memory translation fails when
>>> > loading instructions into the CPU pipeline.
>>> > An "Asynchronous Data abort" occurs when a physical memory translation
>>> > fails (ie, no RAM or peripheral is mapped to the physical address)
>>> >
>>> > The address of the fault corresponds to a kernel device mapping. My
>>> > guess is that you are not mapping kernel devices correctly at boot time:
>>> > https://github.com/seL4/seL4/blob/master/include/plat/exynos5/plat/machine/devices.h#L15
>>> > https://github.com/seL4/seL4/blob/master/include/plat/exynos5/plat/machine/hardware.h#L26
>>> > https://github.com/seL4/seL4/blob/master/src/arch/arm/32/machine/hardware.c#L51
>>> >
>>> >
>>> > - Alex
>>> >
>>> > On Tue, 2017-01-24 at 17:17 +0100, Wladislav Wiebe wrote:
>>> >> could it be an TLB fault? For my understandig, based on
>>> >> http://infocenter.arm.com/help/index.jsp?topic=
[seL4] arm_data_abort_exception
Hello, has somebody experience with running into arm_data_abort_exception after enabling the MMU/paging and jumping to the kernel image: .. ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4 paddr=[9000..904b041f] ELF-loading image 'kernel' paddr=[8000..80033fff] vaddr=[f000..f0033fff] virt_entry=f000 ELF-loading image 'sel4test-driver' paddr=[80034000..8042dfff] vaddr=[1..409fff] virt_entry=1e924 Enabling MMU and paging Jumping to kernel-image entry point... check_data_abort_exception() DFAR = 0xfff01014 DFSR = 0x7 ADFSR = 0x0 abort() called. I've dumped the DFAR/DFSR register -- 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 Thanks in advance! -- WBR, Wladislav WIebe ___ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
Re: [seL4] ARM LPAE?
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,0x
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: 8000 2 GiB
>>
>> checking
>> [ 11.049] uboot# md 0x8000
>> [ 30.803] 8000: fffe bcdd 79bc 369b.y...6..
>> seems the memory is available and accessible.
>>
>> [ 30.912] uboot# md 0x8200
>> [ 96.775] 8200:
>> shows empty memory.
>>
>> I am setting up the
>> "keystone")
>> ENTRY_ADDR=0x82008000
>>
>> Configuring the linkerl.lds to
>> KERNEL_BASE = 0xe000;
>> PHYS_BASE = 0x8000;
>>
>>
>> and the hardware.h looks like:
>> #define physBase 0x8000
>> #define kernelBase0xe000
>>
>> 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 = */ 0x8000, /* .end = */ 0xf000 }
>> };
>>
>> 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 +, 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 inte
Re: [seL4] ARM LPAE?
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,0x
>>
>> 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: 8000 2 GiB
>> >>
>> >> checking
>> >> [ 11.049] uboot# md 0x8000
>> >> [ 30.803] 8000: fffe bcdd 79bc 369b
>> >> .y...6..
>> >> seems the memory is available and accessible.
>> >>
>> >> [ 30.912] uboot# md 0x8200
>> >> [ 96.775] 8200:
>> >>
>> >> shows empty memory.
>> >>
>> >> I am setting up the
>> >> "keystone")
>> >> ENTRY_ADDR=0x82008000
>> >>
>> >> Configuring the linkerl.lds to
>> >> KERNEL_BASE = 0xe000;
>> >> PHYS_BASE = 0x8000;
>> >>
>> >>
>> >> and the hardware.h looks like:
>> >> #define physBase 0x8000
>> >> #define kernelBase0xe000
>> >>
>> >> 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 = */ 0x8000, /* .end = */ 0xf000 }
>> >> };
>> >>
>> >> static const p_region_t BOOT_RODATA dev_p_regs[] = {
>> >> { /* .start = */ UART0_PADDR,/* .end = */ UART0_PADDR + (1 <<
>> >> PAGE_BITS) }
>> >> };
>> >>
>> >> Now starting:
>> >>
Re: [seL4] ARM LPAE?
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...@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,0x
>>>
>>> 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: 8000 2 GiB
>>> >>
>>> >> checking
>>> >> [ 11.049] uboot# md 0x8000
>>> >> [ 30.803] 8000: fffe bcdd 79bc 369b
>>> >> .y...6..
>>> >> seems the memory is available and accessible.
>>> >>
>>> >> [ 30.912] uboot# md 0x8200
>>> >> [ 96.775] 8200:
>>> >>
>>> >> shows empty memory.
>>> >>
>>> >> I am setting up the
>>> >> "keystone")
>>> >> ENTRY_ADDR=0x82008000
>>> >>
>>> >> Configuring the linkerl.lds to
>>> >> KERNEL_BASE = 0xe000;
>>> >> PHYS_BASE = 0x8000;
>>> >>
>>> >>
>>> >> and the hard
Re: [seL4] ARM timer driver and interrupts
Hi,
seems all other interrupt ID's comes also back with ID 1023 (spurious
interrupt).
A really dirty way to get it handled is to keep it in the kernel enabled and
hardcode it in getActiveIRQ to the wanted interrupt ID, instead of
mark it as invalid.
I did it at least to verify if it is the timer interrupt.
May ask about this magic in the TI e2e forum.
Thanks!
- Wladi
2017-02-27 16:59 GMT+01:00 Wladislav Wiebe <wladislav...@gmail.com>:
> Hi Alex,
>
> yes, you are right -- seems interrupt 27 is the virtual timer based on
> GIC 400 specification.
> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471b/DDI0471B_gic400_r0p1_trm.pdf
>
> May I will try to loop through all interrupts > 31 (after the PPI's)..
>
> Thanks!
> - Wladi
>
> 2017-02-26 12:58 GMT+01:00 <alexander.k...@data61.csiro.au>:
>> Hi Wladi,
>>
>> I am sorry to say that IRQ 27 might be the IRQ of the preemption timer
>> that the kernel uses. If not, it should at least be the IRQ of the ARM
>> private timers rather than a third-party peripheral.
>>
>> That being said, some vendors don't like to follow standards.
>>
>> Do you receive the 'Tick' even if you don't set the enable bit on your
>> timer?
>> Have you checked that the timer status bit is actually being asserted?
>>
>> - Alex
>>
>> On Sun, 2017-02-26 at 11:58 +0100, Wladislav Wiebe wrote:
>>> Hi Alex,
>>>
>>> I've found the magic IRQ number -> 27.
>>>
>>> Starting test suite sel4test
>>> Starting test 0: TEST_INTERRUPT0001
>>> TEST_INTERRUPT0001
>>> Running test INTERRUPT0001 (Test interrupts with timer)
>>> Tick
>>> Tick
>>> Tick
>>> Test INTERRUPT0001 passed
>>> Starting test 1: TEST_INTERRUPT00012
>>> TEST_INTERRUPT0001
>>> Running test INTERRUPT0001 (Test interrupts with timer)
>>> Tick
>>> Tick
>>> Tick
>>> Test INTERRUPT0001 passed
>>> Test suite passed. 2 tests passed.
>>>
>>> 2/2 tests passed.
>>> All is well in the universe.
>>>
>>>
>>> Special thanks again for the great support!
>>>
>>> - Wladi
>>>
>>>
>>>
>>>
>>>
>>> 2017-02-24 11:50 GMT+01:00 Wladislav Wiebe <wladislav...@gmail.com>:
>>> > Hi Alex,
>>> >
>>> > really great catch! When I am disabling interrupt 27 and 57 in
>>> > maskInterrupt
>>> > and keeping everything else enabled, like:
>>> > switch (irq) {
>>> > case 27: dist_enable_clr(irq); break;
>>> > case 57: dist_enable_clr(irq); break;
>>> > default: dist_enable_set(irq); break;
>>> > }
>>> >
>>> > I can see spurious interrupts from interrupt number 48
>>> > each second (depends on timer_periodic(env->timer->timer, 1 *
>>> > NS_IN_S);) setting.
>>> >
>>> > ..
>>> > Starting test suite sel4test
>>> > Starting test 0: TEST_INTERRUPT0001
>>> > TEST_INTERRUPT0001
>>> > Timer initialised
>>> > Running test INTERRUPT0001 (Test interrupts with timer)
>>> > <<seL4(CPU 0) [handleInterruptEntry/48 T0xffdfaf00 "" @e001086c]:
>>> > Spurious interrupt!>>
>>> > <<seL4(CPU 0) [handleInterruptEntry/48 T0xffdfaf00 "" @e001086c]:
>>> > Spurious interrupt!>>
>>> > <<seL4(CPU 0) [handleInterruptEntry/48 T0xffdfaf00 "" @e001086c]:
>>> > Spurious interrupt!>>
>>> > ..
>>> >
>>> > But for some reason, even when configuring the timer interrupt to nr. 48,
>>> > (in the kernel machine.h and userspace timer)
>>> > the interrupt handler doesn't get called and keeps firing spurious
>>> > interrupts.
>>> >
>>> > Let me know if you have an idea for this as well :-)
>>> >
>>> > Thanks a lot!
>>> > - Wladi
>>> >
>>> > 2017-02-24 0:21 GMT+01:00 <alexander.k...@data61.csiro.au>:
>>> >> Hi Wladi,
>>> >>
>>> >> Another problem could be that you are using the wrong IRQ number. The
>>> >> GIC handles two classes of IRQ: PPI and SPI. There are 32 PPIs. To
>>> >> ensure that each IRQ number is unique we offset each SPI by 32.
>>> >>
>>> >> The reported SPI IRQ number in technical manuals is not always
>>> >> consistent. Sometimes the SPI IRQ number is reported, somet
[seL4] ARM LPAE?
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 @ 0x84000 which is beyond 32 Bit - so, LPAE support is required. The physical RAM setup looks like: bank 0: addr: 0x84000 size: 0x17ec5000 (382 MB) bank 1: addr: 0x88000 size: 0x8000 (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 ___ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
