2008-03-06 09:32:57     SPI not working with new kernel

Document created by Aaronwu Employee on Aug 5, 2013
Version 1Show Document
  • View in full screen mode

2008-03-06 09:32:57     SPI not working with new kernel

Øyvind Kaurstad (NORWAY)

Message: 52158    We have a custom board that is very similar to the BF537 STAMP. On this board there is a m25p64 spi flash chip, that has three partitions, one for u-boot, one for the kernel and one for a jffs2 file system.

 

We've been running a 2007R1-kernel and U-boot 1.1.6 for a long time, and we are booting from the flash chip.

 

Excerpt from the boot log:

 

m25p80 spi1.1: m25p64 (8192 Kbytes)

Creating 3 MTD partitions on "m25p80":

0x00000000-0x00020000 : "bootloader"

0x00020000-0x00420000 : "kernel"

0x00420000-0x00800000 : "file system"

 

Then I decided to try a new kernel, so I checked out everything from svn (revision 6339). I also checked out the toolchain and built that, of course.

 

Now, the problem is that SPI doesn't work. The new kernel boots nicely, but it doesn't detect the flash chip correctly. From the boot log:

 

m25p80 spi0.1: found m25p80, expected m25p64

bfin-spi bfin-spi.0: Blackfin BF5xx on-chip SPI Controller Driver, Version 1.0, regs_base@ffc00500, dma channel@7

 

As you can see, it says it detected a m25p80, but that's completely bogus. I used a scope to see if the kernel actually reads the chip, but it does not. The clock signal doesn't move at all during kernel boot (but it flickers like crazy when u-boot starts, of course). The chip select signal goes low briefly (and just once) during kernel boot.

 

The reason why it reports it has detected a m25p80 is obvious when looking in m25p80.c:

 

    /* ST Microelectronics -- newer production may have feature updates */

    { "m25p05",  0x202010,  32 * 1024, 2, },

    { "m25p10",  0x202011,  32 * 1024, 4, },

    { "m25p20",  0x202012,  64 * 1024, 4, },

    { "m25p40",  0x202013,  64 * 1024, 8, },

    { "m25p80",         0,  64 * 1024, 16, },

    { "m25p16",  0x202015,  64 * 1024, 32, },

    { "m25p32",  0x202016,  64 * 1024, 64, },

    { "m25p64",  0x202017,  64 * 1024, 128, },

    { "m25p128", 0x202018, 256 * 1024, 64, },

 

I don't know why the m25p80 has an ID of zero, but that explains why.

 

Here's the complete boot log in case that helps:

 

## Booting image at 01000000 ...

   Image Name:   Linux-2.6.24.3-ADI-2008R2-pre_te

   Created:      2008-03-06  14:15:40 UTC

   Image Type:   Blackfin Linux Kernel Image (gzip compressed)

   Data Size:    2431674 Bytes =  2.3 MB

   Load Address: 00001000

   Entry Point:  00179000

   Verifying Checksum ... OK

   Uncompressing Kernel Image ... OK

Starting Kernel at = 179000

Linux version 2.6.24.3-ADI-2008R2-pre_test_oyvind-svn4396 (oyvind@localhost.localdomain) (gcc version 4.1.2 (ADI svn)) #9 Thu Mar 6 15:15:35 CET 2008

Warning: limiting memory to 31MB due to hardware anomaly 05000263

Board Memory: 32MB

Kernel Managed Memory: 32MB

Memory map:

  fixedcode = 0x00000400-0x00000490

  text      = 0x00001000-0x00106a30

  rodata    = 0x00106b60-0x00156db8

  bss       = 0x00156dc0-0x0016494c

  data      = 0x0016494c-0x00178000

    stack   = 0x00176000-0x00178000

  init      = 0x00179000-0x00429000

  available = 0x00429000-0x01eff000

  DMA Zone  = 0x01f00000-0x02000000

Hardware Trace Active and Enabled

Blackfin support (C) 2004-2008 Analog Devices, Inc.

Compiled for ADSP-BF536 Rev 0.2

Blackfin Linux support by http://blackfin.uclinux.org/

Processor Speed: 300 MHz core clock and 100 MHz System Clock

Instruction Cache Enabled

Data Cache Enabled (write-through)

Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 7874

Kernel command line: root=/dev/mtdblock0 rw console=ttyBF0,57600

Configuring Blackfin Priority Driven Interrupts

PID hash table entries: 128 (order: 7, 512 bytes)

console [ttyBF0] enabled

Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)

Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)

Memory available: 27180k/32768k RAM, (2752k init code, 1046k kernel code, 458k data, 1024k dma, 308k reserved)

Blackfin Scratchpad data SRAM: 4 KB

Blackfin Instruction SRAM: 48 KB (41 KB free)

Security Framework initialized

Mount-cache hash table entries: 512

net_namespace: 64 bytes

NET: Registered protocol family 16

Blackfin GPIO Controller

Blackfin DMA Controller

stamp_init(): registering device resources

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 1024 (order: 1, 8192 bytes)

TCP bind hash table entries: 1024 (order: 0, 4096 bytes)

TCP: Hash tables configured (established 1024 bind 1024)

TCP reno registered

JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.

io scheduler noop registered

io scheduler anticipatory registered (default)

io scheduler cfq registered

Serial: Blackfin serial driver

bfin-uart.1: ttyBF0 at MMIO 0xffc00400 (irq = 18) is a BFIN-UART

bfin-uart.1: ttyBF1 at MMIO 0xffc02000 (irq = 20) is a BFIN-UART

bfin-sport-uart.0: ttySS0 at MMIO 0xffc00800 (irq = 12) is a SPORT0

bfin-sport-uart.1: ttySS1 at MMIO 0xffc00900 (irq = 14) is a SPORT1

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

bfin_mac_mdio: probed

bfin_mac: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, irq=-1, mdc_clk=2500000Hz(mdc_div=19)@sclk=100MHz)

bfin_mac: Version 1.1, Blackfin BF53[67] BF527 on-chip Ethernet MAC driver

m25p80 spi0.1: found m25p80, expected m25p64

bfin-spi bfin-spi.0: Blackfin BF5xx on-chip SPI Controller Driver, Version 1.0, regs_base@ffc00500, dma channel@7

rtc-bfin rtc-bfin: rtc core: registered rtc-bfin as rtc0

bfin-wdt: initialized: timeout=20 sec (nowayout=0)

TCP cubic registered

NET: Registered protocol family 1

NET: Registered protocol family 17

rtc-bfin rtc-bfin: setting system clock to 2008-03-06 15:20:32 UTC (1204816832)

Freeing unused kernel memory: 2752k freed

dma_alloc_init: dma_page @ 0x00637000 - 256 pages at 0x01f00000

                           _____________________________________

        a8888b.           / Welcome to the uClinux distribution \

       d888888b.         /       _     _                         \

       8P"YP"Y88        /       | |   |_|            __  __ (TM)  |

       8|o||o|88  _____/        | |    _ ____  _   _ \ \/ /       |

       8'    .88       \        | |   | |  _ \| | | | \  /        |

       8`._.' Y8.       \       | |__ | | | | | |_| | /  \        |

      d/      `8b.       \      \____||_|_| |_|\____|/_/\_\       |

     dP   .    Y8b.       \   For embedded processors including   |

    d8:'  "  `::88b        \    the Analog Devices Blackfin      /

   d8"         'Y88b        \___________________________________/

  :8P    '      :888

   8a.   :     _a88P         For further information, check out:

._/"Yaa_:   .| 88P|            - http://blackfin.uclinux.org/

\    YP"    `| 8P  `.          - http://docs.blackfin.uclinux.org/

/     \.___.d|    .'           - http://www.uclinux.org/

`--..__)8888P`._.'  jgs/a:f    - http://www.analog.com/blackfin

 

Have a lot of fun...

 

 

Can someone explain this? The hardware is obviously OK, since it all works with the old kernel. I am still using my original u-boot, but I don't suppose that has anything to do with it, as the kernel seems to boot normally.

 

-Øyvind

QuoteReplyEditDelete

 

 

2008-03-06 11:12:05     Re: SPI not working with new kernel

Mike Frysinger (UNITED STATES)

Message: 52164    are you suggesting changing the 0 fixes things ?  if you read the m25p_probe() function, the id field is only used after querying the spi flash

 

your board resources declares the spi device as a m25p64 right ?

QuoteReplyEditDelete

 

 

2008-03-06 13:00:22     Re: SPI not working with new kernel

Øyvind Kaurstad (NORWAY)

Message: 52171    No, I am not suggesting that changing the 0 fixes anything. I was merely saying that I thought the entry with 0 in it was "hit" because nothing was actually read from the device itself.

 

The (relevant) board resources are as follows:

 

#if defined(CONFIG_SPI_BFIN) || defined(CONFIG_SPI_BFIN_MODULE)

/* all SPI peripherals info goes here */

 

#if defined(CONFIG_MTD_M25P80) \

    || defined(CONFIG_MTD_M25P80_MODULE)

static struct mtd_partition bfin_spi_flash_partitions[] = {

    {

        .name = "bootloader",

        .size = 0x00020000,

        .offset = 0,

        .mask_flags = MTD_CAP_ROM

    },{

        .name = "kernel",

        .size = 0x400000,

        .offset = MTDPART_OFS_APPEND

    },{

        .name = "file system",

        .size = MTDPART_SIZ_FULL,

        .offset = MTDPART_OFS_APPEND,

    }

};

 

static struct flash_platform_data bfin_spi_flash_data = {

    .name = "m25p64",

    .parts = bfin_spi_flash_partitions,

    .nr_parts = ARRAY_SIZE(bfin_spi_flash_partitions),

    .type = "m25p64",

};

 

/* SPI flash chip (m25p64) */

static struct bfin5xx_spi_chip spi_flash_chip_info = {

    .enable_dma = 0,         /* use dma transfer with this chip*/

    .bits_per_word = 8,

};

#endif

 

static struct spi_board_info bfin_spi_board_info[] __initdata = {

#if defined(CONFIG_MTD_M25P80) \

    || defined(CONFIG_MTD_M25P80_MODULE)

    {

        /* the modalias must be the same as spi device driver name */

        .modalias = "m25p80", /* Name of spi_driver for this device */

        .max_speed_hz = 25000000,     /* max spi clock (SCK) speed in HZ */

        .bus_num = 0, /* Framework bus number */

        .chip_select = 1, /* Framework chip select. On STAMP537 it is SPISSEL1*/

        .platform_data = &bfin_spi_flash_data,

        .controller_data = &spi_flash_chip_info,

        .mode = SPI_MODE_3,

    },

#endif

 

/* SPI controller data */

static struct bfin5xx_spi_master bfin_spi0_info = {

    .num_chipselect = 8,

    .enable_dma = 1,  /* master has the ability to do dma transfer */

    .pin_req = {P_SPI0_SCK, P_SPI0_MISO, P_SPI0_MOSI, 0},

};

 

/* SPI (0) */

static struct resource bfin_spi0_resource[] = {

    [0] = {

        .start = SPI0_REGBASE,

        .end   = SPI0_REGBASE + 0xFF,

        .flags = IORESOURCE_MEM,

        },

    [1] = {

        .start = CH_SPI,

        .end   = CH_SPI,

        .flags = IORESOURCE_IRQ,

    },

};

 

static struct platform_device bfin_spi0_device = {

    .name = "bfin-spi",

    .id = 0, /* Bus number */

    .num_resources = ARRAY_SIZE(bfin_spi0_resource),

    .resource = bfin_spi0_resource,

    .dev = {

        .platform_data = &bfin_spi0_info, /* Passed to driver */

    },

};

#endif  /* spi master and devices */

 

I've really only modified (but in this post I snipped out some irrelevant stuff) the partitoning section, the rest is unchanged from the svn version. I will readily admit that I don't have a very good grasp of how all of this is actually chained together, but I am learning. With the 2007R1 it was very straightforward to get the SPI flash to work (basicly just set the partition information and enable relevant stuff in config), but now I am stumped. Obviously the hardware is OK, as U-Boot resides on the very same flash, and the CPU is able to boot from it. And it all works with the previous kernel, too...

 

Thanks for your help!

-Øyvind

QuoteReplyEditDelete

 

 

2008-03-06 13:13:28     Re: SPI not working with new kernel

Vitja Makarov (RUSSIAN FEDERATION)

Message: 52172    Hi!

 

Try the latest attached patch, it also fixes some bugs in spi.

That may be your if your spi driver is not module.

 

https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3943

 

vitja.

QuoteReplyEditDelete

 

 

2008-03-06 19:30:31     Re: SPI not working with new kernel

Øyvind Kaurstad (NORWAY)

Message: 52177    I wasn't sure if you meant that I should apply more than one of those patches, but after fooling around a bit with patching and reverting patches, I ended up applying just one of the patches (spi-fixes+dma-cachable.patch), and the good news is that it actually fixed my problem. Good job!

 

However, I find it slightly disturbing that someone has committed code to svn that actually seems to render spi totally unuseable. Is it usual to commit (presumably) untested code?

 

-Øyvind

QuoteReplyEditDelete

 

 

2008-03-07 00:44:30     Re: SPI not working with new kernel

Vitja Makarov (RUSSIAN FEDERATION)

Message: 52184    > However, I find it slightly disturbing that someone has committed code to svn that actually seems to render spi totally unuseable. Is it usual to commit (presumably) untested code?

 

If you build m25 driver as module it will work, otherwise no. In my case that was at45 bootable flash)

trunk is actually for testing and allways `unstable` branch. Especially after merging with mainline one.

 

vitja.

QuoteReplyEditDelete

 

 

2008-03-07 00:49:25     Re: SPI not working with new kernel

Vitja Makarov (RUSSIAN FEDERATION)

Message: 52185    Hi, again!

After applying spi-fixes+dma-cachable.patch, can you try to turn on m25 DMA mode, and test it for read/writes and so one.

(set enable_dma flag to 1 in spi_flash_chip_info structure in board file)

 

thanks,

vitja.

QuoteReplyEditDelete

 

 

2008-03-07 03:32:27     Re: SPI not working with new kernel

Øyvind Kaurstad (NORWAY)

Message: 52188    Well. I tried that, and the filesystem got totally messed up. I had some stuff there that I should have backed up, but as we all know, hindsight is 20-20...

 

So in short, it didn't work.

QuoteReplyEditDelete

 

 

2008-03-10 14:48:40     Re: SPI not working with new kernel

Mike Frysinger (UNITED STATES)

Message: 52272    that's an awfully large jump in logic ... a device on your board with your configuration doesnt work, therefore all devices in all configurations must be totally unusable ?  also, svn trunk is known to be actively in development and may be broken ... you cant expect it to be completely usable at all times.  if you want that, use a branch, not trunk.

 

please open a bug report in our tracker with information about your hardware setup so that the issue does not get lost.

Attachments

    Outcomes