topic Re: DSPI drive usage in Linux Side in Vybrid Processors

DSPI drive usage in Linux Side

helderhdw — Thu, 07 Nov 2013 16:33:56 GMT

Hello,

I´m using the DSPI0 in Linux side (A5), but I need to change to DSPI3. how do I do that?

regards,

Francisco

Re: DSPI drive usage in Linux Side

karina_valencia — Thu, 07 Nov 2013 16:37:04 GMT

timesyssupport can you help on this case?

Re: DSPI drive usage in Linux Side

timesyssupport — Thu, 07 Nov 2013 19:17:20 GMT

Hello Francisco,

You will want to initialize the DSPI3 pads that you posted in Re: SPI Driver on Linux Side:

MVF600_PAD89_PTD10__DSPI3_PCS0,

MVF600_PAD90_PTD11__DSPI3_SIN,

MVF600_PAD91_PTD12__DSPI3_SOUT,

MVF600_PAD92_PTD13__DSPI3_SCK,

In your board definition file, you will also want to change mvf_spi_board_info.bus_num from 0 to 3, change the first argument to mvf_add_dspi() from 0 to 3, and update the chip select if necessary. If you require additional help, please send the full source file with the changes you have made.

Thank you,

Timesys Support

Re: Re: DSPI drive usage in Linux Side

helderhdw — Thu, 07 Nov 2013 19:49:20 GMT

Helo,

I initialized the DSPI3 pads, and I changed mvf_spi_board_info.bus_num from 0 to 3, and the argument in mvf_add_dspi() from 0 to 3. in attach my change. I compiled the kernel without MTD_25P80 and SPI_MVF_QSPI. below the linux start:

======

Serial: MVF driver

imx-uart.1: ttymxc1 at MMIO 0x40028000 (irq = 94) is a IMX

console [ttymxc1] enabled

imx-uart.2: ttymxc2 at MMIO 0x40029000 (irq = 95) is a IMX

brd: module loaded

at24 2-0050: 4096 byte at24 EEPROM, writable, 32 bytes/write

FSL NFC MTD nand Driver 1.0

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xcc (Micron NAND 512MiB 3,3V 16-bit)

Registering NAND as whole device

mvf-dspi mvf-dspi.3: unable to get clock

Trying to free nonexistent resource <0000000000000066-0000000000000066>

FEC Ethernet Driver

fec_enet_mii_bus: probed

=======

regards

Francisco

Re: DSPI drive usage in Linux Side

timesyssupport — Thu, 07 Nov 2013 20:44:01 GMT

Hello Francisco,

It looks like you will also need to make a new clock entry for DSPI3. This can be done in your kernel source directory, at arch/arm/mach-mvf/clock.c. You can model your entry based off the entry in dspi_clk[] in clock.c, which is for DSPI0. Make sure to add the entry to the lookups[] array as well.

Thanks, and let me know if you have any questions.

Timesys Support

Re: Re: DSPI drive usage in Linux Side

helderhdw — Fri, 08 Nov 2013 18:05:54 GMT

Helo,

I initialized a new clock entry for DSPI, as show below:

static struct clk dspi_clk[] = {

{

__INIT_CLK_DEBUG(dspi0_clk)

.id = 0,

.parent = &ipg_clk,

.enable_reg = MXC_CCM_CCGR0,

.enable_shift = MXC_CCM_CCGRx_CG12_OFFSET,

.enable = _clk_enable,

.disable = _clk_disable,

{

__INIT_CLK_DEBUG(dspi1_clk)

.id = 1,

.enable_reg = MXC_CCM_CCGR0,

.enable_shift = MXC_CCM_CCGRx_CG13_OFFSET,

.enable = _clk_enable,

.disable = _clk_disable,

{

__INIT_CLK_DEBUG(dspi2_clk)

.id = 2,

.parent = &ipg_clk,

.enable_reg = MXC_CCM_CCGR6,

.enable_shift = MXC_CCM_CCGRx_CG12_OFFSET,

.enable = _clk_enable,

.disable = _clk_disable,

{

__INIT_CLK_DEBUG(dspi3_clk)

.id = 3,

.parent = &ipg_clk,

.enable_reg = MXC_CCM_CCGR6,

.enable_shift = MXC_CCM_CCGRx_CG13_OFFSET,

.enable = _clk_enable,

.disable = _clk_disable,

};

_REGISTER_CLOCK("mvf-dspi.3", NULL, dspi_clk[3]),

------------------------------------

after this, I made a test in spi drive, but dont work

# cd /home/fsantos/

# ./spidev-test -D /dev/spidev3.1

spi mode: Unhandled fault: imprecise external abort (0xc06) at 0x2abf0018

Internal error: : c06 [#1]

Modules linked in:

CPU: 0 Not tainted (3.0.15-ts-armv7l #127)

PC is at pump_transfers+0x188/0x204

LR is at tasklet_action+0x64/0x100

pc : [<80248ee4>] lr : [<8004d0cc>] psr: 60000013

sp : 86035f48 ip : 00000000 fp : 00000000

r10: 00000000 r9 : 804b1620 r8 : 804b1620

r7 : 864473c0 r6 : 864b3ed4 r5 : 864a81c0 r4 : 8612b540

r3 : 8880e000 r2 : 80ff0c00 r1 : 60000013 r0 : 8612b540

Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel

Control: 10c53c7d Table: 864f4059 DAC: 00000015

Process ksoftirqd/0 (pid: 3, stack limit = 0x860342e8)

Stack: (0x86035f48 to 0x86036000)

5f40: 00000001 00000000 804b7600 80489cac 804b1620 8004d0cc

5f60: 8004d068 00000001 804b7658 00000018 804b765c 00000006 86034000 8004d968

5f80: 86035fb4 80350ba0 00000100 0000000a 00000000 804b7600 86034000 00000001

5fa0: 00000000 00000000 00000000 00000000 00000000 8004db10 8602df44 00000000

5fc0: 8004da80 00000013 00000000 800620b0 00000000 00000000 00000000 00000000

5fe0: 86035fe0 86035fe0 8602df44 80062030 800334a0 800334a0 ffbf355c 389ce7ff

[<80248ee4>] (pump_transfers+0x188/0x204) from [<8004d0cc>] (tasklet_action+0x64/0x100)

[<8004d0cc>] (tasklet_action+0x64/0x100) from [<8004d968>] (__do_softirq+0xa4/0x1bc)

[<8004d968>] (__do_softirq+0xa4/0x1bc) from [<8004db10>] (run_ksoftirqd+0x90/0xf4)

[<8004db10>] (run_ksoftirqd+0x90/0xf4) from [<800620b0>] (kthread+0x80/0x88)

[<800620b0>] (kthread+0x80/0x88) from [<800334a0>] (kernel_thread_exit+0x0/0x8)

Code: e5903008 e5972000 e5832000 f57ff04f (e5d0206d)

---[ end trace 8f243397b17eeaf2 ]---

Kernel panic - not syncing: Fatal exception in interrupt

[<80036d18>] (unwind_backtrace+0x0/0xf8) from [<8034d850>] (panic+0x5c/0x174)

[<8034d850>] (panic+0x5c/0x174) from [<80035c5c>] (die+0x220/0x284)

[<80035c5c>] (die+0x220/0x284) from [<8002d248>] (do_DataAbort+0x88/0x98)

[<8002d248>] (do_DataAbort+0x88/0x98) from [<8003276c>] (__dabt_svc+0x4c/0x60)

Exception stack(0x86035f00 to 0x86035f48)

5f00: 8612b540 60000013 80ff0c00 8880e000 8612b540 864a81c0 864b3ed4 864473c0

5f20: 804b1620 804b1620 00000000 00000000 00000000 86035f48 8004d0cc 80248ee4

5f40: 60000013 ffffffff

[<8003276c>] (__dabt_svc+0x4c/0x60) from [<80248ee4>] (pump_transfers+0x188/0x204)

[<80248ee4>] (pump_transfers+0x188/0x204) from [<8004d0cc>] (tasklet_action+0x64/0x100)

[<8004d0cc>] (tasklet_action+0x64/0x100) from [<8004d968>] (__do_softirq+0xa4/0x1bc)

[<8004d968>] (__do_softirq+0xa4/0x1bc) from [<8004db10>] (run_ksoftirqd+0x90/0xf4)

[<8004db10>] (run_ksoftirqd+0x90/0xf4) from [<800620b0>] (kthread+0x80/0x88)

[<800620b0>] (kthread+0x80/0x88) from [<800334a0>] (kernel_thread_exit+0x0/0x8)

regards,

Francisco

Re: Re: DSPI drive usage in Linux Side

timesyssupport — Fri, 08 Nov 2013 22:23:03 GMT

Hello Francisco,

Unfortunately, the 'imprecise external abort' error can have many causes - there does not appear to be a specific reason in the information you have shared. Timesys will be able to better assist with this issue under a services agreement. Please let us know if this is something you would be interested in.

Regards,

Timesys Support

Re: DSPI drive usage in Linux Side

helderhdw — Tue, 12 Nov 2013 13:17:37 GMT

Hello,

I´m using phyCore-Vybrid. I made to test with DSPI0 and worked (I can see by oscilloscope the SCK, MOSI, and CS), But when I switch to (DSPI3) the pins (MVF600_PAD89_PTD10__DSPI3_PCS0, MVF600_PAD90_PTD11__DSPI3_SIN, MVF600_PAD91_PTD12__DSPI3_SOUT, MVF600_PAD92_PTD13__DSPI3_SCK), the driver (DSPI3) initialize, and when I try to send data the following erro accore .

-----------------------

# ./spidev-test -D /dev/spidev3.0

phUnhandled fault: external abort on non-linefetch (0x008) at 0x8882200c

ase Internal error: : 8 [#1]

pModules linked in:hase mcc 2

phaCPU: 0 Not tainted (3.0.15-ts-armv7l #32)

se 3PC is at write+0x20/0x244

phLR is at pump_transfers+0x128/0x258

ase pc : [<802146f8>] lr : [<80214fc8>] psr: 80000093

sp : 86035ee0 ip : 86035f18 fp : 86035f14

spi r10: 8047c100 r9 : 00000006 r8 : 86290280

moder7 : 00000003 r6 : 80000013 r5 : 862efe9c r4 : 8616f158

r3 : 88822000 r2 : 00000003 r1 : 000f4240 r0 : 8616f158

bitFlags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel

s peControl: 10c53c7d Table: 86298059 DAC: 00000015

r woProcess ksoftirqd/0 (pid: 3, stack limit = 0x860342e8)

rd: Stack: (0x86035ee0 to 0x86036000)

5ee0: 00000002 00000003 00000005 00000000 862efe9c 80000013 00000003 86290280

5f00: 00000006 8047c100 86035f3c 86035f18 80214fc8 802146e4 80214ea0 00000000

5f20: 8044f3bc 8047c100 00000000 8047c124 86035f5c 86035f40 8004dde4 80214eac

5f40: 00000001 8047c13c 86034000 00000100 86035f9c 86035f60 8004dfd0 8004dd88

5f60: 8602a540 8047c100 86034000 0000000a 00000000 8047c100 86034000 00000000

5f80: 00000000 00000000 00000000 00000000 86035fbc 86035fa0 8004e0f8 8004df44

5fa0: 8602df10 00000000 8004e060 00000013 86035ff4 86035fc0 80061524 8004e06c

5fc0: 8602df10 00000000 00000000 00000000 86035fd0 86035fd0 00000000 8602df10

5fe0: 80061498 8004bc50 00000000 86035ff8 8004bc50 800614a4 cd58013c 0202741a

Backtrace:

[<802146d8>] (write+0x0/0x244) from [<80214fc8>] (pump_transfers+0x128/0x258)

[<80214ea0>] (pump_transfers+0x0/0x258) from [<8004dde4>] (tasklet_action+0x68/0xcc)

r8:8047c124 r7:00000000 r6:8047c100 r5:8044f3bc r4:00000000

r3:80214ea0

[<8004dd7c>] (tasklet_action+0x0/0xcc) from [<8004dfd0>] (__do_softirq+0x98/0x128)

r7:00000100 r6:86034000 r5:8047c13c r4:00000001

[<8004df38>] (__do_softirq+0x0/0x128) from [<8004e0f8>] (run_ksoftirqd+0x98/0x128)

[<8004e060>] (run_ksoftirqd+0x0/0x128) from [<80061524>] (kthread+0x8c/0x94)

r7:00000013 r6:8004e060 r5:00000000 r4:8602df10

[<80061498>] (kthread+0x0/0x94) from [<8004bc50>] (do_exit+0x0/0x660)

r6:8004bc50 r5:80061498 r4:8602df10

Code: e5d0206d e1a04000 e5903008 e2822003 (e7933102)

---[ end trace 931e58262a528079 ]---

Kernel panic - not syncing: Fatal exception in interrupt

Backtrace:

[<80037ddc>] (dump_backtrace+0x0/0x10c) from [<8034ce34>] (dump_stack+0x18/0x1c)

r6:802146fa r5:00000000 r4:804777e0 r3:ffffffff

[<8034ce1c>] (dump_stack+0x0/0x1c) from [<8034d01c>] (panic+0x64/0x178)

[<8034cfb8>] (panic+0x0/0x178) from [<800381c8>] (die+0x228/0x284)

r3:00000100 r2:0000251a r1:00000000 r0:803eb5d8

r7:00000001

[<80037fa0>] (die+0x0/0x284) from [<80038244>] (arm_notify_die+0x20/0x58)

[<80038224>] (arm_notify_die+0x0/0x58) from [<8002f24c>] (do_DataAbort+0x90/0xa0)

[<8002f1bc>] (do_DataAbort+0x0/0xa0) from [<800348ec>] (__dabt_svc+0x4c/0x60)

Exception stack(0x86035e98 to 0x86035ee0)

5e80: 8616f158 000f4240

5ea0: 00000003 88822000 8616f158 862efe9c 80000013 00000003 86290280 00000006

5ec0: 8047c100 86035f14 86035f18 86035ee0 80214fc8 802146f8 80000093 ffffffff

r7:00000003 r6:80000013 r5:86035ecc r4:ffffffff

[<802146d8>] (write+0x0/0x244) from [<80214fc8>] (pump_transfers+0x128/0x258)

[<80214ea0>] (pump_transfers+0x0/0x258) from [<8004dde4>] (tasklet_action+0x68/0xcc)

r8:8047c124 r7:00000000 r6:8047c100 r5:8044f3bc r4:00000000

r3:80214ea0

[<8004dd7c>] (tasklet_action+0x0/0xcc) from [<8004dfd0>] (__do_softirq+0x98/0x128)

r7:00000100 r6:86034000 r5:8047c13c r4:00000001

[<8004df38>] (__do_softirq+0x0/0x128) from [<8004e0f8>] (run_ksoftirqd+0x98/0x128)

[<8004e060>] (run_ksoftirqd+0x0/0x128) from [<80061524>] (kthread+0x8c/0x94)

r7:00000013 r6:8004e060 r5:00000000 r4:8602df10

[<80061498>] (kthread+0x0/0x94) from [<8004bc50>] (do_exit+0x0/0x660)

r6:8004bc50 r5:80061498 r4:8602df10

---------------------------------------

What do you think about the problem?

Att,

Francisco

Re: DSPI drive usage in Linux Side

timesyssupport — Tue, 12 Nov 2013 21:16:44 GMT

Hello Francisco,

The external abort may be caused by a memory access error. It is possible that DSPI3 has not been powered for some reason, and perhaps memory is causing issues. If you are booting both an MQX image and Linux, try booting just Linux to make sure there is not some conflict between the two OSes.

Thanks,

Timesys Support

Re: DSPI drive usage in Linux Side

helderhdw — Tue, 12 Nov 2013 21:33:52 GMT

Hello,

I'm booting only Linux image. I think this problem is related to use SPI with DMA, where the DMA was enabled to use DSPI0. what do you think about this?

Att,

Francisco

Re: Re: DSPI drive usage in Linux Side

timesyssupport — Tue, 12 Nov 2013 22:12:39 GMT

Hi Francisco,

Acutally, it appears that this is at least a part of the problem. In drivers/spi/spi_mvf_dspi.c in your kernel source tree, try updating the DSPI_DMA_RX_TCD and DSPI_DMA_TX_TCD macros for DSPI3.

You could also try disabling DMA for SPI by disabling CONFIG_SPI_MVF_DSPI_EDMA in your kernel configuration, to rule out this being a DMA issue.

Regards,

Timesys Support

Re: DSPI drive usage in Linux Side

helderhdw — Tue, 12 Nov 2013 22:29:00 GMT

Hi timesys,

this is the SPI configuration, but have the DMA side. I cant disabling DSPI_EDMA, cause the DMA is used in the other features..But I have a question. The DMA is used by the SPI only full-duplex case? because I'm calling the ioctl function to full-duplex...

Att,

Francisco

Re: DSPI drive usage in Linux Side

timesyssupport — Tue, 12 Nov 2013 23:04:43 GMT

Hello Francisco,

There is a note at line 939 in the SPI driver (drivers/spi/spi_mvf_dspi.c), that seems to indicate that half-duplex mode is used, so this may be related to your issue as well.

Regards,

Timesys Support

Re: DSPI drive usage in Linux Side

helderhdw — Tue, 19 Nov 2013 11:50:15 GMT

Hi timesys,

The problem is in the base address for SPI2 and SPI3 in the mvf.h file. They are wrong. Currently, the variables are:

#define MVF_DSPI2_BASE_ADDR (MVF_AIPS1_BASE_ADDR - 0x80000 + 0x000AC0000) = 0x40AC0000

#define MVF_DSPI3_BASE_ADDR (MVF_AIPS1_BASE_ADDR - 0x80000 + 0x000AD0000) = 0x40AD0000

but the correct is:

#define MVF_DSPI2_BASE_ADDR (MVF_AIPS1_BASE_ADDR - 0x80000 + 0x000AC000) = 0x400AC000

#define MVF_DSPI3_BASE_ADDR (MVF_AIPS1_BASE_ADDR - 0x80000 + 0x000AD000) = 0x400AD000

after fixed this base address, the SPI3 works.

Att,

Francisco

ps: please, include this fix in the next patch

Re: DSPI drive usage in Linux Side

timesyssupport — Tue, 19 Nov 2013 17:59:47 GMT

Hi Francisco,

Thank you for sharing your fix with us. We will incorporate this into our next weekly Factory release (for Monday, November 25).

Regards,

Timesys Support