Hi Alex, you are right - it was the UART PADDR driver. I had to WA it like I did in the kernel. But it only works when I disabling L1 data cache.
Now it looks like: .. Test BIND0001 passed Test suite passed. 202 tests passed. 202/202 tests passed. All is well in the universe. :-) So, some starting point for this board is made -- Thanks a lot for the support! - Wladi 2017-01-29 23:09 GMT+01:00 <[email protected]>: > 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 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)) 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: 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
