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 <alexander.k...@data61.csiro.au>: > 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 <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=[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 <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 >> >> 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 <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=/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=[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 Devel@sel4.systems https://sel4.systems/lists/listinfo/devel