2010-11-18 13:39:46     DNP5370, NOR flash not detected

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

2010-11-18 13:39:46     DNP5370, NOR flash not detected

Andreas Schallenberg (GERMANY)

Message: 95953   

 

Hello,

 

I'm continuing with adding support for DNP/5370 for uClinux and switched to the

fresh 2010R1-RC3 uClinux release.

 

The NOR flash chip (async memory banks 0, 1 and 2) is not detected by the

kernel. The boot message is:

 

Starting Kernel at = 001adb94

Linux version 2.6.34.7-ADI-2010R1ASc (aschallenberg@GWS026Linux) (gcc version 4.3.5 (ADI-2010R1-RC4) ) #29 Thu Nov 18 19:03:34 CET 2010

register early platform devices

Found mtd parition at 0x001c1000, (len=0x800000), moving to 0x01700000

Board Memory: 32MB

Kernel Managed Memory: 32MB

Memory map:

  fixedcode = 0x00000400-0x00000490

  text      = 0x00001000-0x00127108

  rodata    = 0x00127108-0x0017a398

  bss       = 0x0017b000-0x00194de4

  data      = 0x00194de4-0x001aa000

    stack   = 0x001a8000-0x001aa000

  init      = 0x001aa000-0x001c1000

  available = 0x001c1000-0x01700000

  rootfs    = 0x01700000-0x01f00000

  DMA Zone  = 0x01f00000-0x02000000

Hardware Trace Active and Enabled

Boot Mode: 0

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

Compiled for ADSP-BF537 Rev 0.3

Blackfin Linux support by   blackfin.uclinux.org/

Processor Speed: 600 MHz core clock and 120 MHz System Clock

NOMPU: setting up cplb tables

Instruction Cache Enabled for CPU0

  External memory: cacheable in instruction cache

Data Cache Enabled for CPU0

  External memory: cacheable (write-back) in data cache

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

Kernel command line: console=ttyBF0,115200 root=/dev/mtdblock3 rootfstype=ext2

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

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

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

Memory available: 21468k/32768k RAM, (92k init code, 1176k kernel code, 524k data, 1024k dma, 292k reserved)

Hierarchical RCU implementation.

NR_IRQS:138

Configuring Blackfin Priority Driven Interrupts

console [ttyBF0] enabled

Calibrating delay loop... 1196.03 BogoMIPS (lpj=2392064)

Mount-cache hash table entries: 512

Blackfin Scratchpad data SRAM: 4 KB

Blackfin L1 Data A SRAM: 16 KB (16 KB free)

Blackfin L1 Data B SRAM: 16 KB (16 KB free)

Blackfin L1 Instruction SRAM: 48 KB (36 KB free)

NET: Registered protocol family 16

Blackfin DMA Controller

DNP/5370: registering device resources

DNP/5370: registering 2 SPI slave devices

DNP/5370: MAC 02:80:ad:21:4d:db

bio: create slab <bio-0> at 0

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

UDP hash table entries: 256 (order: 0, 4096 bytes)

UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)

NET: Registered protocol family 1

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

ROMFS MTD (C) 2007 Red Hat, Inc.

msgmni has been set to 41

io scheduler noop registered

io scheduler deadline registered (default)

bfin-jtag-comm: initialized

bfin-uart: Blackfin serial driver

brd: module loaded

loop: module loaded

uclinux[mtd]: RAM probe address=0x1700000 size=0x800000

Creating 1 MTD partitions on "RAM":

0x000000000000-0x000000800000 : "ROMfs"

mtd: Giving out device 0 to ROMfs

Generic platform RAM MTD, (c) 2004 Simtec Electronics

i2c /dev entries driver

NET: Registered protocol family 26

TCP cubic registered

NET: Registered protocol family 17

Warning: unable to open an initial console.

VFS: Cannot open root device "mtdblock3" or unknown-block(0,0)

Please append a correct "root=" boot option; here are the available partitions:

1f00            8192 mtdblock0 (driver?)

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Hardware Trace:

   0 Target : <0x00126f8c> { _dump_stack + 0x0 }

     Source : <0x00127002> { _panic + 0x3e } CALL pcrel

   1 Target : <0x00127002> { _panic + 0x3e }

     Source : <0x00127084> { _printk + 0x14 } RTS

   2 Target : <0x00127080> { _printk + 0x10 }

     Source : <0x00010342> { _vprintk + 0x2d6 } RTS

   3 Target : <0x00010336> { _vprintk + 0x2ca }

     Source : <0xffa00d02> { __common_int_entry + 0xca } RTI

   4 Target : <0xffa00ca0> { __common_int_entry + 0x68 }

     Source : <0xffa00af0> { _return_from_int + 0x58 } RTS

   5 Target : <0xffa00af0> { _return_from_int + 0x58 }

     Source : <0xffa00ac6> { _return_from_int + 0x2e } IF !CC JUMP pcrel

   6 Target : <0xffa00a98> { _return_from_int + 0x0 }

     Source : <0xffa00c9c> { __common_int_entry + 0x64 } JUMP.L

   7 Target : <0xffa00c9a> { __common_int_entry + 0x62 }

     Source : <0xffa003bc> { _asm_do_IRQ + 0x80 } RTS

   8 Target : <0xffa003ac> { _asm_do_IRQ + 0x70 }

     Source : <0x000132e2> { __local_bh_enable + 0x72 } RTS

   9 Target : <0x000132d0> { __local_bh_enable + 0x60 }

     Source : <0x000132b2> { __local_bh_enable + 0x42 } IF CC JUMP pcrel (BP)

  10 Target : <0x000132a2> { __local_bh_enable + 0x32 }

     Source : <0x00013284> { __local_bh_enable + 0x14 } IF CC JUMP pcrel (BP)

  11 Target : <0x00013270> { __local_bh_enable + 0x0 }

     Source : <0x000138d6> { ___do_softirq + 0xc2 } JUMP.L

  12 Target : <0x000138ce> { ___do_softirq + 0xba }

     Source : <0x000138c2> { ___do_softirq + 0xae } IF CC JUMP pcrel

  13 Target : <0x000138bc> { ___do_softirq + 0xa8 }

     Source : <0x000138b6> { ___do_softirq + 0xa2 } IF CC JUMP pcrel

  14 Target : <0x000138b0> { ___do_softirq + 0x9c }

     Source : <0x0002c168> { _rcu_bh_qs + 0x14 } RTS

  15 Target : <0x0002c154> { _rcu_bh_qs + 0x0 }

     Source : <0x000138ac> { ___do_softirq + 0x98 } JUMP.L

Stack info:

SP: [0x00809f3c] <0x00809f3c> /* kernel dynamic memory (maybe user-space) */

Memory from 0x00809f30 to 0080a000

00809f30: 00008001  00809f3c  001582a0 [00158394] 00127006  00955000  00158394  001803ce

00809f50: 001803ce  001803ce  00809f6c  001aaa88  00955000  00809f7c  00000080  00809f7c

00809f70: 00000001  00008001  00000000  6e6b6e75  2d6e776f  636f6c62  2c30286b  00002930

00809f90: 001aaabe  00000000  001aaade  001aac3a  0017b234  001b9a58  001b9a5c  00000000

00809fb0: 00000000  00000000  00809fbc  00000000  00000000  001aa1de  0017b018  001aa1ea

00809fd0: 0017b018  001bcef4  00000000  00000000  00000001  001d5ab8 <00001466> 00000000

00809ff0: 00000000  00000000  ffffffff  00000006

Return addresses in stack:

    address : <0x00001466> { _kernel_thread_helper + 0x6 }

 

The kernel settings are copied from 2009 uClinux and I found that CONFIG_ROMFS_MTD_FS (was "=y") is gone.

Instead, there is CONFIG_ROMFS_MTD_FS (now "=y").

 

For the board spec I looked at some other boards (ezkit, stamp) how the flash is specified there. The relevant parts

in dnp5370.c are:

 

 

#define CONFIG_MTD_PHYSMAP_LEN  0x300000

#if defined(CONFIG_MTD_PHYSMAP) || defined(CONFIG_MTD_PHYSMAP_MODULE)

static struct mtd_partition nor_partitions[] = {

        {

                .name       = "bootloader(nor)",

                .size       = 0x30000,

                .offset     = 0,

        }, {

                .name       = "linux kernel and rootfs(nor)",

                .size       = 0x300000 - 0x30000 - 0x10000,

                .offset     = MTDPART_OFS_APPEND,

        }, {

                .name       = "MAC address(nor)",

                .size       = 0x10000,

                .offset     = MTDPART_OFS_APPEND,

                .mask_flags = MTD_WRITEABLE,

        }

};

 

static struct physmap_flash_data nor_flash_data = {

        .width      = 1,

        .parts      = nor_partitions,

        .nr_parts   = ARRAY_SIZE(nor_partitions),

/*  Did some experiments here:

     .probe_type = "cfi_probe",

*/

};

 

static struct resource nor_flash_resource = {

        .start = 0x20000000,

        .end   = 0x202fffff,

        .flags = IORESOURCE_MEM,

};

 

static struct platform_device nor_flash_device = {

        .name          = "physmap-flash",

        .id            = 0,

        .dev = {

                .platform_data = &nor_flash_data,

        },

        .num_resources = 1,

        .resource      = &nor_flash_resource,

};

#endif

 

...

 

static struct platform_device *dnp5370_devices[] __initdata = {

...

#if defined(CONFIG_MTD_PHYSMAP) || defined(CONFIG_MTD_PHYSMAP_MODULE)

        &nor_flash_device,

#else

  #error MTD_PHYSMAP is essential for this board

#endif

};

 

Any idea how to find out why the kernel ignores the NOR flash?

 

Andreas

 

config

dnp5370.c~

TranslateQuoteReplyEditDelete

 

 

2010-11-18 14:24:54     Re: DNP5370, NOR flash not detected

Mike Frysinger (UNITED STATES)

Message: 95955   

 

MTD has a debugging option ... try enabling it and setting it to "3"

 

also, you set your width to "1" ... you sure it shouldnt be "2" ?

QuoteReplyEditDelete

 

 

2010-11-19 04:06:09     Re: DNP5370, NOR flash not detected

Andreas Schallenberg (GERMANY)

Message: 95989   

 

Mike, thanks for the answer.

 

I'm not sure which width to use since I don't have the blueprints of that board.

The "1" comes from the 2009 dnp5370.c and works there. So as long as it is

not ignored and overridden by another value, "1" should be ok.

Anyway, I tested "2" today and it didn't help.

 

Should I try certain values for .probe_type? Or do I need to specify things

for the CS signals with this release?

 

I attached the board file and kernel .config for the 2009 release, since I

can build a working system with these:

 

...

physmap platform flash device: 00300000 at 20000000

physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank

NOR chip too large to fit in mapping. Attempting to cope...

Amd/Fujitsu Extended Query Table at 0x0040

number of CFI chips: 1

cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.

Reducing visibility of 4096KiB chip to 3072KiB

cmdlinepart partition parsing not available

Searching for RedBoot partition table in physmap-flash.0 at offset 0x2f0000

No RedBoot partition table detected in physmap-flash.0

Using physmap partition information

Creating 3 MTD partitions on "physmap-flash.0":

0x00000000-0x00030000 : "bootloader(nor)"

0x00030000-0x002f0000 : "linux kernel and rootfs(nor)"

0x002f0000-0x00300000 : "MAC address(nor)"

uclinux[mtd]: RAM probe address=0x1700000 size=0x800000

Creating 1 MTD partitions on "RAM":

0x00000000-0x00800000 : "ROMfs"

Generic platform RAM MTD, (c) 2004 Simtec Electronics

mtd_dataflash spi0.2: AT45DB642x (8448 KBytes) pagesize 1056 bytes (OTP)

Creating 1 MTD partitions on "mtd_dataflash":

0x00000000-0x00840000 : "JFFS2 dataflash(nand)"

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

i2c /dev entries driver

i2c-bfin-twi i2c-bfin-twi.0: Blackfin BF5xx on-chip I2C TWI Contoller, regs_base@ffc01400

lm75 0-0048: hwmon0: sensor 'lm75'

mmc_spi spi0.1: ASSUMING 3.2-3.4 V slot power

mmc_spi spi0.1: SD/MMC host mmc0, no DMA, no WP, no poweroff

mmc_spi spi0.1: requested mode not fully supported

mmc_spi spi0.1: can't change chip-select polarity

...

 

 

Another idea: Does it make sense to try an uClinux release in-between of

2010R1-RC2 or RC3 and the working 2009?  Just to make the differences

smaller? Some sort of bisect... Or are the 2010R1 releases just different

in terms of bugfixes?

 

dnp5370.c

config

TranslateQuoteReplyEditDelete

 

 

2010-11-19 05:38:41     Re: DNP5370, NOR flash not detected

Mike Frysinger (UNITED STATES)

Message: 95998   

 

that config is the top level uclinux-dist config which isnt terribly interesting

 

you shouldnt have to specify the probe yourself.  the default kernel probe lists should be sufficient.

 

that kernel output shows that the width should be 2 (see the "x16")

 

i see you enabled redboot support.  you dont want that as you're using u-boot, not redboot.

 

you might want to try booting a kernel with an initramfs for now to help debug things ... that way you can poke around /sys/ to see what's going on

 

you should at least be seeing "physmap platform flash device: ....".  if you dont see that, then the drivers arent built in properly or the platform resources arent declared/registered properly.

 

if the verbose debugging isnt showing anything useful, the next step really would be to dig down and sprinkle more printk's in the physmap/mtd code to see where things are going wrong.

QuoteReplyEditDelete

 

 

2010-11-19 10:18:02     Re: DNP5370, NOR flash not detected

Andreas Schallenberg (GERMANY)

Message: 96013   

 

I hope I attached the right .config from 2009 kernel now

 

Some success: I used early_platform_add_devices() not just

in the early board init but also in the regular ("late"?) init function!

It was just that "early_" prefix....

 

 

Now the kernel sees the flash. But now it reboots later on:

 

...

--> physmap_init:289

--> physmap_flash_probe:109

physmap platform flash device: 00300000 at 20000000

physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank

NOR chip too large to fit in mapping. Attempting to cope...

Amd/Fujitsu Extended Query Table at 0x0040

number of CFI chips: 1

Reducing visibility of 4096KiB chip to 3072KiB

cmdlinepart partition parsing not available

RedBoot partition parsing not available

Using physmap partition information

Creating 3 MTD partitions on "physmap-flash.0":

0x000000000000-0x000000030000 : "bootloader(nor)"

--> add_mtd_device:280

mtd: Giving out device 0 to bootloader(nor)

0x000000030000-0x0000002f0000 : "linux kernel and rootfs(nor)"

--> add_mtd_device:280

mtd: Giving out device 1 to linux kernel and rootfs(nor)

0x0000002f0000-0x000000300000 : "MAC address(nor)"

--> add_mtd_device:280

mtd: Giving out device 2 to MAC address(nor)

--> physmap_init:296 err=0

uclinux[mtd]: RAM probe address=0x1700000 size=0x800000

Creating 1 MTD partitions on "RAM":

0x000000000000-0x000000800000 : "ROMfs"

--> add_mtd_device:280

mtd: Giving out device 3 to ROMfs

Generic platform RAM MTD, (c) 2004 Simtec Electronics

bfin_mii_bus: probed

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

bfin_mac bfin_mac.0: Blackfin on-chip Ethernet MAC driver, Version 1.1

i2c /dev entries driver

lm75 0-0048: hwmon0: sensor 'lm75'

NET: Registered protocol family 26

TCP cubic registered

NET: Registered protocol family 17

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

--> get_mtd_device:480

--> mtdblock_open:273

mtdblock_open

ok

mtdblock: read on "ROMfs" at 0x400, size 0x200

mtdblock: read on "ROMfs" at 0x600, size 0x200

mtdblock: read on "ROMfs" at 0x800, size 0x200

mtdblock: read on "ROMfs" at 0xa00, size 0x200

mtdblock: read on "ROMfs" at 0x1400, size 0x200

mtdblock: read on "ROMfs" at 0x1600, size 0x200

mtdblock: write on "ROMfs" at 0x400, size 0x200

mtdblock: write on "ROMfs" at 0x600, size 0x200

VFS: Mounted root (ext2 filesystem) on device 31:3.

Freeing unused kernel memory: 92k freed

mtdblock: read on "ROMfs" at 0x101400, size 0x200

mtdblock: read on "ROMfs" at 0x101600, size 0x200

mtdblock: read on "ROMfs" at 0x4000, size 0x200

mtdblock: read on "ROMfs" at 0x4200, size 0x200

mtdblock: read on "ROMfs" at 0x1ab800, size 0x200

--- omitted a lot of further "read on" messages here ----

mtdblock: read on "ROMfs" at 0x114600, size 0x200

mtdblock: read on "ROMfs" at 0x114800, size 0x200

mtdblock: read on

 

U-Boot 2010.09-svn2487 (ADI-2011R1-pre) (Nov 18 2010 - 11:36:13)

 

CPU:   ADSP bf537-0.3 (Detected Rev: 0.3) (bypass boot)

Board: SSV DilNet DNP5370

Clock: VCO: 600 MHz, Core: 600 MHz, System: 120 MHz

RAM:   32 MiB

Flash: 4 MiB

In:    serial

Out:   serial

Err:   serial

misc_init_r 0

misc_init_r 1

misc_init_r 2

misc_init_r 3

Net:   bfin_mac

bfin>    

 

The last successful read is not always on the same address. Another observation is

that it does not reboot when the debugger is connected to the module. The debugger

disables the external hardware watchdog. So it might be that some function touches

the watchdog disable pin. Without debugger, the board goes back to U-Boot,

with debugger, it boots on. However, it cannot really access the rootfs then:

 

...

mtdblock: read on "ROMfs" at 0x20dc00, size 0x200

mtdblock: read on "ROMfs" at 0x20de00, size 0x200

init: /sbin/syslogd respawning too fast

init: /sbin/syslogd respawning too fast

init: /bin/getty respawning too fast

init: /sbin/syslogd respawning too fast

...

 

config

TranslateQuoteReplyEditDelete

 

 

2010-11-19 18:24:18     Re: DNP5370, NOR flash not detected

Mike Frysinger (UNITED STATES)

Message: 96021   

 

i guess that's your problem.  why are you using early_platform_add_devices() at all ?  your board init function should be using platform_add_devices().

QuoteReplyEditDelete

 

 

2010-11-22 07:24:56     Re: DNP5370, NOR flash not detected

Andreas Schallenberg (GERMANY)

Message: 96089   

 

I used early_platform_add_devices() because the kernel didn't open the console before and I was unable to see the boot messages. Then I saw that at another board file. Now I did more experiments (moved it inside the list of devices to init etc.) and it works now without the early_platform_add_devices(). I can't really tell what the difference was.

 

Also it turned out that the reset issue and the reason for not displaying the login prompt were two independent issues. The login prompt simply was a problem in the userspace configuration and had nothing to do with the kernel. The device nodes were not created (mdev was missing).

 

The resets do not occur if I exclude the mii-bus and mac devices from the list of platform devices to be initialized. If I disable these, the system works. So we're down to an ethernet issue...again. I'll add printk's to the PHY/MII/MAC now. Maybe there is a certain function that causes the reset.

TranslateQuoteReplyEditDelete

 

 

2010-11-22 08:46:26     Re: DNP5370, NOR flash not detected

Andreas Schallenberg (GERMANY)

Message: 96091   

 

Finally, I found it. In the this release there are two things to set to RMII: The .phy_mode most be PHY_INTERFACE_MODE_RMII and  bfin_mac_peripherals[] must be P_RMII0. I knew the former one, the later one was new to me.

 

The pins for MII obviously include the pin used for the external hardware watchdog for this board.

Attachments

Outcomes