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
