Hi Ted,

On 03/12/15 19:24, Ted Victorio wrote:
Your patch works! The m5329.c compiled.
But I got 2 additional undefined errors ref to nand_ecc.c, so I
corrected by adding MTD_NAND_ECC to linux config:
     # Disk-On-Chip Device Drivers
     #
     CONFIG_MTD_NAND_ECC=y
     CONFIG_MTD_NAND_M5329=y
     CONFIG_MTD_NAND=y
     CONFIG_MTD_NAND_IDS=y

And I added these two lines to
uClinux-dist/vendors/Freescale/M5329EVB/Makefile (as I did to make
uClinux-dist-20080808 work)
     mtd0,c,90,0 mtd1,c,90,2 mtd2,c,90,4 \
     mtdblock0,b,31,0 mtdblock1,b,31,1 mtdblock2,b,31,2 \

The image.bin was succesfully built. However, the problem now is the
image.bin booting has stopped at 0x000000000000-0x00000016e000 : "ROMfs"
(see captured display below)

I noticed differences between 2015 and 2008:
(1) Is m53xx compatible to m532x?  [2015] uClinux/COLDFIRE(m53xx)  vs
[2008] uClinux/COLDFIRE(m532x)

Yes, that is the intention. 53xx is meant to cater for similar
parts such as the 5329 and 537x families.


(2) Why different sizes for RAM probe?  [2015] uclinux[mtd]: probe
address=0x4029bc20 size=0x16e000  vs  [2008] uclinux[mtd]: RAM probe
address=0x401c83b8 size=0x3f7000

How big is your images/romfs.img file?
This size should match that (rounded to 4k I think).
Perhaps the default user space tool set is quite different,
thus producing a quite different size romfs (root filesystem).


(3) Why does 2015 not display NAND found like in 2008?  [2008] NAND
device: Manufacturer ID: 0x20, Chip ID: 0x73 (ST Micro NAND 16MiB 3,3V
8-bit)

My first guess is that this probing is where the kernel is stuck.
So without the nand enabled do you get a complete all the way up boot
of 20150808?


(3) MTD partition creation? [2015] Creating 1 MTD partitions on "ram":
0x000000000000-0x00000016e000 : "ROMfs"  vs  [2008] Creating 1 MTD
partitions on "NAND 16MiB 3,3V 8-bit": 0x00000000-0x01000000 : "M5329
flash partition 1"

Any clues to solve this?

I would suggest adding some more printk trace in the m5239.c nand
driver to see where it is possibly getting stuck.

Regards
Greg


---------------------------
dBUG> go 0x40020000
Linux version 4.0.0-uc0 (root@RHEL6) (gcc version 4.5.1 (GCC) ) #9 Wed
Dec 2 20:51:10 PST 2015

uClinux/COLDFIRE(m53xx)
COLDFIRE port done by Greg Ungerer, g...@snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4080
Kernel command line: console=ttyS0,19200 rootfstype=romfs
PID hash table entries: 2048 (order: 0, 8192 bytes)
Dentry cache hash table entries: 4096 (order: 1, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Memory: 28416K/32768K available (1945K kernel code, 118K rwdata, 328K
rodata, 72K init, 79K bss, 4352K reserved, 0K cma-reserved)
Virtual kernel memory layout:
     vector  : 0x40000000 - 0x40000400   (   1 KiB)
     kmap    : 0x00000000 - 0xffffffff   (4095 MiB)
     vmalloc : 0x00000000 - 0xffffffff   (4095 MiB)
     lowmem  : 0x40000000 - 0x42000000   (  32 MiB)
       .init : 0x40276000 - 0x40288000   (  72 KiB)
       .text : 0x40020000 - 0x40206490   (1946 KiB)
       .data : 0x40206490 - 0x40275e00   ( 447 KiB)
       .bss  : 0x40288000 - 0x4029bc20   (  80 KiB)
SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
NR_IRQS:256
Console: colour dummy device 80x25
Calibrating delay loop... 159.12 BogoMIPS (lpj=795648)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
NET: Registered protocol family 16
Switched to clocksource tmr
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 0, 8192 bytes)
TCP bind hash table entries: 2048 (order: 0, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP: reno registered
UDP hash table entries: 512 (order: 0, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 0, 8192 bytes)
NET: Registered protocol family 1
jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
io scheduler noop registered (default)
Initing M532x Framebuffer
Console: switching to colour frame buffer device 100x37
fb0: M532x FB frame buffer device @0x41a00000
ColdFire internal UART serial driver
mcfuart.0: ttyS0 at MMIO 0xfc060000 (irq = 90, base_baud = 5000000) is a
ColdFire UART
console [ttyS0] enabled
mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91, base_baud = 5000000) is a
ColdFire UART
mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92, base_baud = 5000000) is a
ColdFire UART
brd: module loaded
loop: module loaded
nbd: registered device at major 43
uclinux[mtd]: probe address=0x4029bc20 size=0x16e000
uclinux[mtd]: set ROMfs to be root filesystem
Creating 1 MTD partitions on "ram":
0x000000000000-0x00000016e000 : "ROMfs"
---------------------------


On Wednesday, December 2, 2015 4:06 PM, Greg Ungerer <g...@uclinux.org>
wrote:

Hi Cristobal,

On 03/12/15 01:13, Cristobal Chaves wrote:
 > First of all you have to compile the drivers if you wanna add the
drivers, then you have to modify the kconfig file adding the names of
the divers files *.o and *.c. Once you have added the files to the
configure file you can patch the kernel and finally add the drivers
configuring the kernel graphically or manually. Just follow the steps of
bellow:

This really makes no sense. And it seems unnecessary given the
original poster was clearly already compiling the driver in
the kernel tree. The m5329.c driver source in that tree is
broken - the compile error messages give that.

You don't add *.c or *.o names into a Kconfig. They would only
ever go into a Makefile.

Regards
Greg

 > 1) Compile drivers
 > 2) Add names of files *.o and *.c to the respective KCONFIG
 > 3) Patch Kernel using Diff tool
 > 4) Compile Kernel
 > 5) Add drivers to the configuration of custom kernel
 > 6) Compile Kernel
 > 7) Done, you have your custom kernel with new drivers added.
 >
 > BR,
 >
 > Cristobal
 >
 >> To: uclinux-dev@uclinux.org
 >> From: g...@uclinux.org
 >> Date: Thu, 3 Dec 2015 00:33:30 +1000
 >> Subject: Re: [uClinux-dev] Configure M5329 NAND for Freescale
MCF5329EVB (uClinux-dist-20150808)
 >>
 >> Hi Ted,
 >>
 >> On 02/12/15 06:56, Ted Victorio wrote:
 >> > I am unable to compile for the M5329 NAND using the configuration
below.
 >> >
 >> > Distro: uClinux-dist-20150808
 >> > Tool: m68k-uclinux-tools-20101118
 >> > Platform: Freescale MCF5329EVB
 >> >
 >> > # Linux/m68k 4.0.0-uc0 Kernel Configuration
 >> [snip]
 >> >
 >>
 >> The definitions for register addresses were sanitized for Coldfire
 >> hardware a few kernel revisions back. They are now all register
 >> addresses (or offsets) - not access macros as some were.
 >>
 >> You will need the patch below to fix this driver (compile tested
 >> only). The include of mtdcore is a little ugly, but it should get
 >> you going for now.
 >>
 >> Regards
 >> Greg








_______________________________________________



_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to