2008-12-22 19:56:45     Multiple SPI Devices, Interrupts on Chip Selects

2008-12-22 19:56:45     Multiple SPI Devices, Interrupts on Chip Selects

Ben Matthews (UNITED STATES)

Message: 67051   

We are having some trouble getting a board with four SPI devices talking to the BlackStamp motherboard (BF532, opensource design hosted here). After some debugging, it looks like the chipselects (PF4-PF7) are being configured as inputs and most have interrupts assigned to them. I suspect this is a kernel bug, but haven't been able to track down where these pins are being configured (we're wondering if u-boot is configuring them and the kerenel never reinitializes them).  Generally, if we try to toggle these lines (using debugfs to configure them as outputs/enable spi/configure them as spi chip selects) we get a panic similar to this one:

Data access CPLB miss                                                         

- Used by the MMU to signal a CPLB miss on a data access.                    

Kernel OOPS in progress                                                       

Deferred Exception context                                                    

CURRENT PROCESS:                                                              

COMM=echo PID=304                                                             

CPU = 0                                                                       

TEXT = 0x03380040-0x033c6e40        DATA = 0x033c6e50-0x033d8b90              

BSS = 0x033d8b90-0x033da4b0  USER-STACK = 0x033e2f80                         

                                                                              

return address: [0x00005a92]; contents of:                                    

0x00005a70:  6079  544b  42d0  4008  4900  0200  0010  0000                   

0x00005a80:  0031  4e20  3208  e14a  0019  e10a  f928  5e8a                   

0x00005a90:  9152 [9552] e14a  ffc0  e10a  0104  9510  60f8                   

0x00005aa0:  0801  1807  e14a  0024  e10a  3e44  9110  0040                   

                                                                              

SEQUENCER STATUS:               Not tainted                                   

SEQSTAT: 00062026  IPEND: 9030  SYSCFG: 0006                                 

  EXCAUSE   : 0x26                                                            

  physical IVG12 asserted : <0xffa08c78> { _evt_evt12 + 0x0 }                 

  physical IVG15 asserted : <0xffa08c90> { _evt_system_call + 0x0 }           

  logical irq   6 mapped  : <0xffa08330> { _timer_interrupt + 0x0 }           

  logical irq  14 mapped  : <0x00126704> { _bfin_rtc_interrupt + 0x0 }        

  logical irq  21 mapped  : <0x00110de8> { _bfin_serial_dma_rx_int + 0x0 }    

  logical irq  22 mapped  : <0x00111100> { _bfin_serial_dma_tx_int + 0x0 }    

RETE: <0x00000000> { _do_one_initcall + 0xfffff000 }                         

RETN: <0x03eddd58> /* kernel dynamic memory */                               

RETX: <0x00000480> /* Maybe fixed code section */                            

RETS: <0x00008b24> { _bfin_demux_gpio_irq + 0x48 }                           

PC  : <0x00005a92> { _get_gpiop_data + 0x12 }                                

DCPLB_FAULT_ADDR: <0x69726570> /* kernel dynamic memory */                    

ICPLB_FAULT_ADDR: <0x00005a92> { _get_gpiop_data + 0x12 }                     

                                                                              

PROCESSOR STATE:                                                              

R0 : 00000001    R1 : 0000001f    R2 : 00000005    R3 : 0000001f             

R4 : 00000005    R5 : 00000010    R6 : 00000027    R7 : 00000000             

P0 : 00000186    P1 : 00000001    P2 : 69726570    P3 : 033e2f8c             

P4 : 0000004f    P5 : 0023a53c    FP : 033e2dec    SP : 03eddc7c             

LB0: 03380179    LT0: 0338016c    LC0: 00000000                              

LB1: 03192255    LT1: 0319224e    LC1: 00000000                              

B0 : 00000000    L0 : 00000000    M0 : 00000000    I0 : 033e2e99             

B1 : 00000000    L1 : 00000000    M1 : 00000000    I1 : 03306004             

B2 : 00000000    L2 : 00000000    M2 : 00000000    I2 : 00000000             

B3 : 00000000    L3 : 00000000    M3 : 00000000    I3 : 00000000             

A0.w: 00000000   A0.x: 00000000   A1.w: 00000000   A1.x: 00000000             

USP : 033e2de0  ASTAT: 02002000                                               

                                                                              

No trace since you do not have CONFIG_DEBUG_BFIN_NO_KERN_HWTRACE enabled      

                                                                              

                                                                              

Kernel Stack                                                                  

Stack info:                                                                   

SP: [0x03eddf24] <0x03eddf24> /* kernel dynamic memory */                    

Memory from 0x03eddf20 to 03ede000                                           

03eddf20: 00000003 [0338277a] 00008000  00002000  00000000  03ede000  0338277a

03eddf40:<03395aac><ffa08cf4> 02003004  03192255  03380179  0319224e  0338016c

03eddf60: 00000000  00000000  00000000  00000000  00000000  00000000  00000000

03eddf80: 00000000  00000000  00000000  00000000  00000000  00000000  00000000

03eddfa0: 00000000  00000000  00000000  03306004  033e2e99  033e2de0  033e2dec

03eddfc0: 033d87fc  033e2f8c  033d87fc  033d942f  00000004  00000003  033d87fc

03eddfe0: 033999a4  00000000  00000003  033d942c  00000001  00000001  00000004

03ede000: 03eef900                                                            

Return addresses in stack:                                                    

    address : <0x03395aac> [ echo + 0x15a6c ]                                 

    address : <0xffa08cf4> { _evt_system_call + 0x64 }                        

Modules linked in:                                                            

Kernel panic - not syncing: Kernel exception                                  

                                                                              

The easiest way to reproduce this behavior is to start with the default configuration for the BlackStamp, add in simple-gpio and try to write "O1" to /dev/gpio5 (how the above panic was generated). Another way to do it, is to enable SPI in the SPI_CTL register and toggle one of the lines by changing the SPI_FLG register (we've been using debugfs and/or a custom kernel module).

We find that PF4 usually behaves as expected, as does our SPI flash on PF2,  but PF5-7 do not. Without any register adjustment, Chipselects 5-7 are always low.

We are using the latest kernel and distrubution from this site (pulled from git) and a toolchain which was built late last week (also from git).

We would greatly appreciate any help you can offer getting SPI going, and also if you could give us a hint as to where these registers (SPI_FLG,SPI_CTL,FIO_*) get initialized by the kernel. (unfortunatly, I don't have access to a JTAG debug hardware).

Thanks

QuoteReplyEditDelete

2008-12-22 20:55:36     Re: Multiple SPI Devices, Interrupts on Chip Selects

Mike Frysinger (UNITED STATES)

Message: 67052   

are you using the latest u-boot trunk code, or your older port ?  you can read the registers in u-boot by using like `md.w 0xffc00700 1` to check their values before you boot the kernel.

QuoteReplyEditDelete

2008-12-23 09:59:11     Re: Multiple SPI Devices, Interrupts on Chip Selects

Ben Matthews (UNITED STATES)

Message: 67069   

Thanks for the tip.

I'm running a build of u-boot-1.1.6 (git) from November. It looks like u-boot is setting those interrupt registers (though I can't think of a reason why it would), so I'll give the latest trunk version a shot. We hadn't upgraded yet because the makefile doesn't seem to generate a binary in a xspi friendly format (mcs or "raw hex").

Based on this, I'm assuming that the kernel never initializes the interrupt registers. Where would be a reasonable place to initialize them (reset them to the default state)?

QuoteReplyEditDelete

2008-12-23 11:27:54     Re: Multiple SPI Devices, Interrupts on Chip Selects

Ben Matthews (UNITED STATES)

Message: 67073   

It looks like the new u-boot isn't writing those registers (git trunk). SPI still isn't working quite right, but at least the kernel doesn't seem to be panicing... more debugging

QuoteReplyEditDelete

2008-12-23 14:40:54     Re: Multiple SPI Devices, Interrupts on Chip Selects

Mike Frysinger (UNITED STATES)

Message: 67076   

right ... this is the same issue i raised when you originally supported your board port

QuoteReplyEditDelete

2008-12-23 14:42:03     Re: Multiple SPI Devices, Interrupts on Chip Selects

Mike Frysinger (UNITED STATES)

Message: 67077   

if you can post examples of how to convert u-boot into a "xspi friendly format", then i can look at integrating it into u-boot itself

QuoteReplyEditDelete

2008-12-23 16:44:52     Re: Multiple SPI Devices, Interrupts on Chip Selects

Ben Matthews (UNITED STATES)

Message: 67078   

bfin-elf-objcopy -O ihex -I binary u-boot.ldr u-boot.hex

seems to work ok (stolen directly from one of the older u-boot makefiles)

Converting from the srecord format doesn't seem to work though (I used srec_cat) for reasons unknown to me.

On the SPI front, I was able to hack the driver to force SPI to keep control of the flag pins and get the driver working (on the scope... have yet to successfully talk to an actual device, but that seems like it shouldn't be hard). As it turns out, it looks like our daughter board may work with the unmodified driver after adding pullup resistors on the chipselect lines (trying that now).

Thanks again for the hints.

QuoteReplyEditDelete

2008-12-23 19:42:11     Re: Multiple SPI Devices, Interrupts on Chip Selects

Mike Frysinger (UNITED STATES)

Message: 67081   

you should just be able to do `make u-boot.ldr.hex` then

Related
Recommended