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
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
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
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
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,
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]