search

seL4 / sel4test

Test suite for seL4.
http://sel4.systems
Other
25 stars 63 forks source link

‘Caught cap fault …’ while trying to read/write device register #67

Closed chenSevenHalf closed 2 years ago

chenSevenHalf commented 2 years ago

Hello: I have ported the sel4 to my im6ull board. It runs will before dropping to the user space. after that, serical com arise errors like:

Caught cap fault in send phase at address 0
while trying to handle:
vm fault on data at address 0x10076008 with status 0x1008
in thread 0xffeef200 “sel4test-driver” at address 0x5fdfc
With stack:
0x10074e38: 0x0
0x10074e3c: 0x513
0x10074e40: 0x1
0x10074e44: 0x0
0x10074e48: 0x5
0x10074e4c: 0x90820
0x10074e50: 0x0
0x10074e54: 0x907e8
0x10074e58: 0x1000
0x10074e5c: 0x10074e6c
0x10074e60: 0x1000
0x10074e64: 0x907e8
0x10074e68: 0x10074e84
0x10074e6c: 0x0
0x10074e70: 0x10074e84
0x10074e74: 0x5fab4

Errors trigger by Location file:sel4test/projects/sel4test/apps/sel4test-driver/src/main.c Errors tracing: main->main_continued->plat_init->clk_set_freq->_arm_set_freq->clk_get_freq(_arm_get_freq):uint32_t v = clk_regs.alg->pll_arm.val; then it jump to kernel like:arm_vector_table-> arm_data_abort_exception->c_handle_data_fault->c_handle_data_fault->c_handle_vm_fault->handleVMFaultEvent->handleFault->handleDoubleFault then the above error occurs.

How could I do? and the problem also occurs when init the GPT and UART. those device can be access correctly in the kernel but not the root server.

axel-h commented 2 years ago

Seem you are invoking plat_init() from sel4test-driver/src/plat/imx6/plat.c and clk_regs is not mapped properly. The i.MX6ull might be different to the i.MX6 Dual/Quad here.

chenSevenHalf commented 2 years ago

Well,It's OK when I do the same things On the aarch64 platform Cortex A55. This means the code is OK and caused by hardware problems. I have not succeed on IMX6UL(CORTEX A7) platform.

axel-h commented 2 years ago

What do you mean by working on "aarch64 platform Cortex A55". Are you building exactly the same target there and just deplay the same image on a Cortex-A55 system? Or are you building different target there with a different device tree and just different mapping?

axel-h commented 2 years ago

@chenSevenHalf: Is there any update here, could you fix this timer porting? I'd close this issue due to inactivity otherwise.

kent-mcleod commented 2 years ago

Closing due to inactivity.

kent-mcleod commented 2 years ago

In particular, this fault is an Synchronous external abort caused by the mapping of CCM_ANALOG in clock_sys_init. This MMIO region is defined as #define CCM_ANALOG_PADDR 0x020C8000 for all imx6 platforms. If your platform has a different physical address for these registers, or they have a different layout from the other imx6 platforms then this would cause the error you see.