Hi Alex,
when configuring the device like:
devices.h
#define UART0_PPTR 0xfff01c00
#define UART0_PADDR 0x02530000
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)) = 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: e5431001 strb r1, [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=[81000000..8102efff]
vaddr=[e0000000..e002efff]
virt_entry=e0000000
ELF-loading image 'sel4test-driver'
paddr=[8102f000..81411fff]
vaddr=[10000..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 <[email protected]>:
> 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 <[email protected]>:
>> > 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=[90000000..9048841f]
>> > ELF-loading image 'kernel'
>> > paddr=[80000000..8002ffff]
>> > vaddr=[e0000000..e002ffff]
>> > virt_entry=e0000000
>> > ELF-loading image 'sel4test-driver'
>> > paddr=[80030000..80411fff]
>> > vaddr=[10000..3f1fff]
>> > virt_entry=1e920
>> > Enabling MMU and paging
>> > Jumping to kernel-image entry point...
>> >
>> > seL4 failed assertion '(address & ~0xfffff000ul) == ((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 <[email protected]>:
>> >> 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
>> >> 0x00000000-0xe0000000).
>> >>
>> >> 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 <[email protected]>:
>> >>> > 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 <[email protected]>:
>> >>> >> > 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=[90000000..904b041f]
>> >>> >> > ELF-loading image 'kernel'
>> >>> >> > paddr=[80000000..80033fff]
>> >>> >> > vaddr=[f0000000..f0033fff]
>> >>> >> > virt_entry=f0000000
>> >>> >> > ELF-loading image 'sel4test-driver'
>> >>> >> > paddr=[80034000..8042dfff]
>> >>> >> > vaddr=[10000..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
>>
>>
>>
>
--
WBR, Wladislav WIebe
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel
