• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 1070 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3354: Segmentation fault when GPMC accesses UHPI

Charlie Fan
Prodigy 70 points

Part Number: AM3354

Tool/software: Linux

Hi guys,

I'm trying to set up the communication between AM335x::GPMC(host) and TMS320C6746::UHPI(slave, asynchronous read/write). We have Linux 3.8.13 installed on the AM3354. In my driver for UHPI, I did the following in module init function:

1) called gpmc_cs_request() to request the chip select (CS = 2). Returns the physical address.

2) called request_mem_region() to request resources, returns non-NULL. Not sure if this is necessary, because gpmc_cs_request() has already done alloc_resource() stuff, but I did it anyway.

3) called ioremap() to map the physical address to virtual address. The requested memory size is 0x40. Returns the virtual address (not static).

4) read and write all HPI registers in concern (at system startup, in kernel space).

Actually all above were successful and I was able to print out both physical and virtual addresses. Physical address = 0x01000000 and virtual address = 0xe0898000.

After the board finished booting, I tried to access UHPI from user space. The application program is uhpi_burst_test, which calls the ioctl operation, which calls uhpi_ioctl() defined in the driver, but an error occured:

[ 1234.363885] Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0898030
[ 1234.371899] Internal error: : 1008 [#4] THUMB2
[ 1234.376542] Modules linked in:
[ 1234.379742] CPU: 0 Tainted: G D (3.8.13 #22)
[ 1234.385490] PC is at uhpi_ioctl+0x110/0x274
[ 1234.389869] LR is at do_vfs_ioctl+0x61/0x3f4
[ 1234.394329] pc : [<c04083b0>] lr : [<c0102b75>] psr: 20000033
[ 1234.394329] sp : df10de50 ip : 50c5387d fp : e0898000
[ 1234.406318] r10: 30003bfe r9 : df10de50 r8 : beea5b84
[ 1234.411774] r7 : df10ded8 r6 : 0000001f r5 : e0898034 r4 : e0898030
[ 1234.418591] r3 : df10de54 r2 : 00000020 r1 : e0898008 r0 : dd3aec80
[ 1234.425409] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user
[ 1234.433042] Control: 50c5387d Table: 9d10c019 DAC: 00000015
[ 1234.439042] Process uhpi_burst_test (pid: 347, stack limit = 0xdf10c238)
[ 1234.446039] Stack: (0xdf10de50 to 0xdf10e000)
[ 1234.450591] de40: df10c000 c04e18f9 df5685c8 c0274fe1
[ 1234.459137] de60: 000000a7 df10dfb0 00000001 c04e18b1 df10dfb0 c04e32a1 c04ebeb0 c04ebeb0
[ 1234.467683] de80: dd078580 df10de98 c08d4f68 df5685c8 00000200 00000000 c08d4f68 df048040
[ 1234.476228] dea0: c08a14dc ffffffff 00000000 c04e3507 00000000 a0000093 00000001 df10df08
[ 1234.484773] dec0: df10c000 c04e3527 00000001 c04e18bf dd078580 c004a409 dd078580 df10ded8
[ 1234.493317] dee0: a0000093 de968120 dd3aec80 00005452 00000003 dd3aec80 00000003 df3ec608
[ 1234.501859] df00: beea5b84 c0102b75 65581405 0000011f dd0de015 c000eba5 65c6033f 0000011f
[ 1234.510402] df20: df3ec608 00000101 00000001 dd3aec88 dd078580 df667600 00000003 df667624
[ 1234.518945] df40: dd3aec80 dd3aec88 df3ec608 00000020 00000001 c00f354b c089d434 00000000
[ 1234.527488] df60: beea5b84 8004f02a 00000000 dd3aec80 00000003 00000000 beea5c24 c0102f43
[ 1234.536030] df80: df10dfb0 00000000 beea5c24 beea5c38 00000000 00008390 00000036 c000ca48
[ 1234.544574] dfa0: df10c000 c000c841 beea5c38 00000000 00000003 8004f02a beea5b84 beea5b84
[ 1234.553116] dfc0: beea5c38 00000000 00008390 00000036 00000000 00000000 b6f2f000 beea5c24
[ 1234.561659] dfe0: 00010858 beea5b7c 00008640 b6e8efdc 80000010 00000003 00000000 00000000
[ 1234.570208] Code: 1e56 b172 f109 0304 (8822) f823
[ 1234.575214] ---[ end trace 92d675da0a3e0dc3 ]---
[ 1234.584904] Releasing UHPI device.

Segmentation fault

This really shouldn't happen because the virtual memory [0xe0898000, 0xe0898040) has been obtained via ioremap(), and that I have already accessed the UHPI device successfully at startup (i.e. in kernel space). However, things failed in user space.

Are there any possibilities that incur this bizzare segmentation fault? For example, device tree, clock or registers not correctly configured, etc. I'm totally clueless now. Appreciate your comments and suggestions.

Thanks,

Charlie

  • 0
    TI__Guru**** 161600 points
    Hi Charlie,

    I see that you're trying to write to a memory space with a start address 0xe0898030 (virtual address) and you've ioremapped up to 0xe0898040. Are you sure that the wire operation does NOT overlap with the address space that is not ioremapped (after 0xe0898040)? How many bytes are you writing?

    In your user app can you ioremap address space, which is larger than 0x40?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 70 points

    Hi Yordan,


    The UHPI device does not operate in a similar fashion to NAND FLASH. Only 4 address wires are used. (In my case, GPMC A2 through A5 are used. That is why 0x40 is enough for UHPI). I did try to apply for 0x400 but the segmentation fault never went away. I'm quite sure 0x40 is all that I need for UHPI device. 


    Once I even tried to print out the virtual addresses for every device registered by adding a trace in __arm_ioremap_pfn_caller(). Seemed like there's no overlapping among virtual addresses. In fact, right after the registration of UHPI device, the registration of FPGA device follows. FPGA device is also driven by GPMC but uses a different chip select space. (In my case, FPGA uses CS = 1 and UHPI uses CS = 2). The virtual space assigned to FPGA starts from 0xe089A000, which is far away from the UHPI boundary.


    I partially solved the problem by disabling the FPGA device (i.e. keep the CSVALID bit for CS = 1 low), but the GPMC CS space and virtual address space for FPGA are still there. So whenever I need the FPGA device I'll have to set the CSVALID bit manually, and also disable the CSVALID bit for UHPI. I guess this is not the final solution.

    Charlie