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

_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel

Reply via email to