Re: [seL4] arm_data_abort_exception

[Alexander.Kroh]

Hi Wladi,

seL4test is the foundation of our regression tests. If you have made it
this far in the boot process, the issue is likely to reside in your
platform dependent user space timer or UART driver.

  0x805 corresponds with a level 1 translation fault. This means that
there is no virtual address mapping for that address.

The question is, why is sel4test calling memset on address 0xdf7fefff?
You may need to follow the call stack further to find out.


Another possible problem may be a creative platform-dependent cache
configuration. If the address does have a mapping, perhaps it is not
observable by the translation hardware.
A quick way to rule this problem out is to disable caches. This can be
done via a configuration parameter that can be changed with `make
menuconfig`.

 - Alex Kroh



On Sun, 2017-01-29 at 21:22 +0100, Wladislav Wiebe wrote:
> Hi Alex,
> 
> when configuring the device like:
> devices.h
> #define UART0_PPTR  0xfff01c00
> #define UART0_PADDR 0x0253
> 
> hardware.h
> UART0_PADDR,
> UART0_PPTR,
> 
> io.c
> putDebugChar(unsigned char c)
> {
> if (status_activate_global_pd) {
> while ((*UART_REG(ULSR, (UART0_PPTR)) & ULSR_THRE) == 0);
> *UART_REG(UTHR,(UART0_PPTR)) Wladi= c;
> } else {
> while ((*UART_REG(ULSR, (UART0_PADDR + 0xc00)) & ULSR_THRE) == 0);
> *UART_REG(UTHR,(UART0_PADDR + 0xc00)) = c;
> }
> }
> 
> I can the the kernel successfully booting, but there is pretty early
> an crash in the userspace - memset():
> seL4test/libs/libmuslc/src/string/memset.c:14
>14930:   e5431001strbr1, [r3, #-1]
> 
> So, I am still not sure if the device is correctly configured?
> 
> ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4
>   paddr=[c0008000..c049441f]
> ELF-loading image 'kernel'
>   paddr=[8100..8102efff]
>   vaddr=[e000..e002efff]
>   virt_entry=e000
> ELF-loading image 'sel4test-driver'
>   paddr=[8102f000..81411fff]
>   vaddr=[1..3f2fff]
>   virt_entry=1e8d4
> Enabling MMU and paging
> Jumping to kernel-image entry point...
> 
> Bootstrapping kernel
> 
> Caught cap fault in send phase at address 0x0
> while trying to handle:
> vm fault on data at address 0xdf7fefff with status 0x805
> in thread 0xffdfad00 "sel4test-driver" at address 0x14930
> With stack:
> 0x2f2278: 0x7
> 0x2f227c: 0x1
> 0x2f2280: 0x2f22d0
> 0x2f2284: 0x2f2290
> 0x2f2288: 0x2d9ea4
> 0x2f228c: 0xdf7fe000
> 0x2f2290: 0x1
> 0x2f2294: 0x443
> 0x2f2298: 0x2dda68
> 0x2f229c: 0x5
> 0x2f22a0: 0xc
> 0x2f22a4: 0x0
> 0x2f22a8: 0x2d9ea4
> 0x2f22ac: 0x4f
> 0x2f22b0: 0x0
> 0x2f22b4: 0x1ba40
> 
> 
> Thanks in advance!
> - Wladi
> 
> 
> 2017-01-27 21:52 GMT+01:00  :
> > Hi Wladi,
> >
> >   The addresses must be aligned to the size of the frame to be mapped.
> > For a small page, it must be aligned to 0x1000. This is a requirement of
> > the ARM hardware rather than the seL4 kernel.
> >
> > The simple workaround is to add an additional offset to the mapped
> > address. You can see how the issue was solved for imx6:
> > https://github.com/seL4/seL4/blob/master/include/plat/imx6/plat/machine/devices.h#L31
> >
> >  - Alex
> >
> >
> >
> > On Fri, 2017-01-27 at 16:40 +0100, Wladislav Wiebe wrote:
> >> 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 :
> >> > 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 {

Re: [seL4] arm_data_abort_exception

[Alexander.Kroh]

Hi Wladi,

  The addresses must be aligned to the size of the frame to be mapped.
For a small page, it must be aligned to 0x1000. This is a requirement of
the ARM hardware rather than the seL4 kernel.

The simple workaround is to add an additional offset to the mapped
address. You can see how the issue was solved for imx6:
https://github.com/seL4/seL4/blob/master/include/plat/imx6/plat/machine/devices.h#L31

 - Alex



On Fri, 2017-01-27 at 16:40 +0100, Wladislav Wiebe wrote:
> 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 :
> > 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  :
> >> 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
> >> 0x-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  :
> >>> > 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
> >>> >> 

Re: [seL4] arm_data_abort_exception

[Wladislav Wiebe]

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 :
> 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  :
>> 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
>> 0x-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  :
>>> > 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=/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 :
>>> >> > 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
>>> >> > 

Re: [seL4] arm_data_abort_exception

[Alexander.Kroh]

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
0x-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  :
> > 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=/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 :
> >> > 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_data_abort_exception

[Alexander.Kroh]

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=/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 :
> > 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_data_abort_exception

[Wladislav Wiebe]

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 :
> 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

[seL4] arm_data_abort_exception

[Wladislav Wiebe]

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