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.
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.