Memory Corruption in Linux kernel MPC8347 revision 3

2007-07-17 Thread Boris Shteinbock
Hi Everyone.
I am working on the Linux port for MPC8347 revision 3 custom build board
with DDR2 memory.

I've successfully ported U-boot (latest git) and the kernel itself,
however during kernel boot I am encountering serious memory corruption
errors. The log for one of the examples is at the bottom of this
message.

Basically, the corruption is always happening somewhere at memory
management intensive tasks such as networking, JFFS2 mounting etc.

As far as I can see, it is not related to some specific driver, because
even it happens even at kernel configured at absolute minimum, ( console
serial driver only and even without it)
The place of the corruption depends on kernel configuration.

The DDR2 memory controller is configured correctly as far as I can tell,
since :
1. DDR2 controller register values are taken from VxWorks bootrom 
that works on this board without any problems.
2. u-boot mtest passes successfully
3. u-boot alternative mtest passes successfully
4. My own custom mem tests in u-boot pass successfully
5. If I manage two boot the board into shell prompt (with absolute
minimum configuration) memtester application is also successful. 

The minimum configuration that is one I am able to boot into shell is a
kernel configured with serial console and small busybox JFFS2 file
system in the flash. In this configuration, the boot fails the first
time JFFS2 root FS is mounted. However it does boot after reset.

I've tried different kernels with the same results  starting from, I
think, 2.6.16  up to 2.6.22
I tried the kernel that is provided by Freescale for 834x reference
boards. ( with my board support of course)

I tried booting both OF flat trees (powerpc) and bd_t based builds (ppc)

I've also tried all memory management options :
SLAB, SLOB and SLUB (in the latest kernel). They all failed at some
point of time, so the assumption is that the problem is not in the
memory management facilities.

The board manufacturer swears that DDR2 memory controller values are
correct and should work perfectly.

So now I almost out of options and I am seeking your help.
Any type of input on this issue would be greatly appreciated. 

Thanks,
Boris

PS. Note that an below example represents failure during DHCP
autoconfiguration. However the similar error happens even when
networking is disabled completely. just in a different place.

= bootm
## Booting image at 0040 ...
   Image Name:   Linux-.6.21.5
   Created:  2007-07-10  14:20:19 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:898361 Bytes = 877.3 kB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Current stack ends at 0x07FA3CF8 = set upper limit to 0x0080
## cmdline at 0x007FFF00 ... 0x007FFF41
bd address  = 0x07FA3FBC
memstart= 0x
memsize = 0x0800
flashstart  = 0xFE00
flashsize   = 0x0200
flashoffset = 0x00033000
sramstart   = 0x
sramsize= 0x
bootflags   = 0x0001
intfreq =528 MHz
busfreq =264 MHz
ethaddr = 00:04:9F:EF:23:35
eth1addr= 00:E0:0C:00:7E:25
IP addr = 10.2.222.20
baudrate= 115200 bps
No initrd
## Transferring control to Linux (at address ) ...
 of_flat_tree = 
Booting without OF Flat tree
Linux version .6.21.5 ([EMAIL PROTECTED]) (gcc version
4.0.0 (DENX ELDK 4.1 4.0.0)) #24 Tue Jul 10 17:20:09 IDT 2007
Zone PFN ranges:
  DMA 0 -32768
  Normal  32768 -32768
early_node_map[1] active PFN ranges
0:0 -32768
Built 1 zonelists.  Total pages: 32512
Kernel command line: console=ttyS0,115200 root=/dev/mtdblock1
rootfstype=jffs2 ip=dhcp
IPIC (128 IRQ sources, 8 External IRQs) at fe000700
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 127744k available (1584k kernel code, 444k data, 84k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Setup MTD partitions
Generic PHY: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing
disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 9) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 10) is a 16550A
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:04:9f:ef:23:35
eth0: Running with NAPI disabled
eth0: 64/64 RX/TX BD ring size

Linux kernel 2.6 on Embedded Planet 8248 board

2006-11-16 Thread Boris Shteinbock
Hi. I am trying to bring up Linux kernel 2.6.16 on EP8248 board
and I am having some serious problems with console driver there, which 
doesn't work (console on SMC).
The kernel hangs after console_init() and BDM shows exception that I was 
unable to trace to any specific point.

I've got access to Arabella Linux 2.4 for this board, but it also 
doesn't work at all unfortunately. Just
for reference, u-boot 1.1.6 works quite well after some chip-select 
patching. so I am sure that the board is
functional.

Linux-related information for this board is quite sparse and couldn't 
find anything useful for me.
If any of you had successfully booted 2.6.* kernels on this board, I'd 
really appreciate some
help or perhaps platform-specific files that you've used.

Thanks in advance

___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded


I2C Linux driver on 8260

2006-08-23 Thread Boris Shteinbock
Hi.

Is there any chance, that some of you, guys,
have a working version of I2C driver for 8260/CPM2
for the latest kernels. The driver posted last year
doesn't seem to work for me: the bus is not identified.

Thanks a lot,
Boris