muram in device tree for mpc8250 in arch/powerpc

muram in device tree for mpc8250 in arch/powerpc

[James Black]

I am porting a proprietary mpc8250 board to 2.6.24. I have the 2.6.19
kernel from denx working. I have ported to u-boot 1.3.2 and have the
platform setup within the 2.6.24 kernel and used pq2fads.dts as an
example of the device tree.

Everything in u-boot is working. u-boot doesn't complain about the
device tree and fills in the clocks and memory using the "fdt
boardsetup" command. In fact, u-boot 1.3.2 can boot the 2.6.29 kernel,
no problem.

I turned on early kernel debugging in 2.6.24 and it looks like all the
device tree parsing is working. The boot hangs and or crashes while
trying to setup the paging. I drilled down the code from init/main.c
and found that it seems the muram device node is killing the
allocator.

I tried to fully describe the segments in muram node and it seems to
mess things up even worse. Can anyone give some pointers to help me
work out this issue?

I wanted to start with as simple a description as possible. The
following tree describes the flash, SDRAM, SCC1, SCC3 and FCC1.


/*
* Device Tree for the CTA5000S board with an MPC8250 chip.
* Device Tree for the PQ2FADS-ZU board with an MPC8280 chip.
*
* Copyright 2007 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/

/ {

model = "cta5000s";
compatible = "fsl,cta5000s";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8250@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>;
i-cache-line-size = <20>;
d-cache-size = <4000>;
i-cache-size = <4000>;
timebase-frequency = <0>;
clock-frequency = <0>;
};

};

memory {
device_type = "memory";
reg = <0 0>;
};

localbus@f0010100 {
compatible = "fsl,mpc8250-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <f0010100 60>;
ranges = <0 0 fe000000 00200000>;
flash@fe000000,0 {
compatible = "amd", "cfi-flash";
reg = <0 fe000000 00200000>;
bank-width = <2>;
device-width = <1>;
};

};

soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8250", "fsl,pq2-soc";
ranges = <00000000 f0000000 00014000>;
// Temporary -- will go away once kernel uses ranges for get_immrbase().
reg = <f0000000 00014000>;
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8250-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;

muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;

data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0 4000 8000 4000>;
};

};

brg@119f0 {
compatible = "fsl,mpc8250-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};

serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8250-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
};

serial@11a40 {
device_type = "serial";
compatible = "fsl,mpc8250-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a40 20 8200 100>;
interrupts = <2a 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <5>;
fsl,cpm-command = <11800000>;
};


ethernet@11300 {
device_type = "network";
compatible = "fsl,mpc8250-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11300 20 8400 100>;
interrupts = <20 8>;
interrupt-parent = <&PIC>;
linux,network-index = <0>;
fsl,cpm-command = <14000300>;
};

};

PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
compatible = "fsl,mpc8250-pic", "fsl,cpm2-pic";
};

};

chosen {
linux,stdout-path = "/soc/cpm/serial@11a00";
};

};

Re: muram in device tree for mpc8250 in arch/powerpc

[Scott Wood]

On Wed, Mar 19, 2008 at 11:06:02AM -0600, James Black wrote:
> I turned on early kernel debugging in 2.6.24 and it looks like all the
> device tree parsing is working. The boot hangs and or crashes while
> trying to setup the paging. I drilled down the code from init/main.c
> and found that it seems the muram device node is killing the
> allocator.

That's strange... how in particular was it killing it?  Which allocator?

Do you know which particular line of code is crashing?

> I tried to fully describe the segments in muram node and it seems to
> mess things up even worse.

What do you mean?  What changes did you make, and what was the result?

> / {
> 
> model = "cta5000s";
> compatible = "fsl,cta5000s";
> #address-cells = <1>;
> #size-cells = <1>;
> cpus {

It'd be a lot more readable if indentation were kept intact...

> localbus@f0010100 {
> compatible = "fsl,mpc8250-localbus",
> "fsl,pq2-localbus";
> #address-cells = <2>;
> #size-cells = <1>;
> reg = <f0010100 60>;
> ranges = <0 0 fe000000 00200000>;
> flash@fe000000,0 {
> compatible = "amd", "cfi-flash";

"amd" isn't a valid compatible name.

> cpm@119c0 {
> #address-cells = <1>;
> #size-cells = <1>;
> #interrupt-cells = <2>;
> compatible = "fsl,mpc8250-cpm", "fsl,cpm2";
> reg = <119c0 30>;
> ranges;
> 
> muram@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0 10000>;
> 
> data@0 {
> compatible = "fsl,cpm-muram-data";
> reg = <0 4000 8000 4000>;
> };
> 
> };

reg for 8250 should be <0 4000>.  Otherwise, the muram node looks fine
(well, the unit address shouldn't be there, but that won't affect
anything).

> serial@11a40 {
> device_type = "serial";
> compatible = "fsl,mpc8250-scc-uart",
> "fsl,cpm2-scc-uart";
> reg = <11a40 20 8200 100>;
> interrupts = <2a 8>;
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <5>;
> fsl,cpm-command = <11800000>;

cpm-command should be <08c00000>.

> };
> 
> 
> ethernet@11300 {
> device_type = "network";
> compatible = "fsl,mpc8250-fcc-enet",
> "fsl,cpm2-fcc-enet";
> reg = <11300 20 8400 100>;
> interrupts = <20 8>;
> interrupt-parent = <&PIC>;
> linux,network-index = <0>;
> fsl,cpm-command = <14000300>;

cpm-command should be <12000300>.

-Scott

Re: muram in device tree for mpc8250 in arch/powerpc

[James Black]

Scott,

>  > That's strange... how in particular was it killing it?  Which allocato=
r?
>  >
>  > Do you know which particular line of code is crashing?
>  >

I made the changes you suggested to the device tree and recompiled and
still get the same problem. The line that code execution stops is in


arch/powerpc/mm/mem.c: paging_init(),line 256, calls
                                    : free_area_init_nodes(), line 284, cal=
ls
                                    : free_area_init_node(), line 3902, cal=
ls
                                    : alloc_node_mem_map(), line 3460
<-- never returns

This is the device tree command line. If I don't pad the device tree
to 0x1000, then
I get this complaint from u-boot.

   Loading Device Tree to 007ff000, end 007ff909 ... OK
fdt_chosen: FDT_ERR_NOSPACE
ERROR: /chosen node create failed - must RESET the bo

I've also compiled without the -b option.
dtc -I dts -O dtb -S 0x1000 -b 0
../../linux-2.6.24/arch/powerpc/boot/dts/cta5000s.dts -o cta5000s.dtb


The following is the early kernel debugging output with debug turned
on in prom.c.


U-Boot 1.3.2 (Mar 14 2008 - 10:36:25)

MPC8250 Reset Status: External Soft, External Hard

MPC8250 Clock Configuration
 - Bus-to-Core Mult 2x, VCO Div 2, 60x Bus Freq  50-150, Core Freq 100-300
 - dfbrg 1, corecnf 0x04, busdf 3, cpmdf 1, plldf 0, pllmf 1, pcidf 3
 - vco_out  264000000, scc_clk   66000000, brg_clk   16500000
 - cpu_clk  132000000, cpm_clk  132000000, bus_clk   66000000

CPU:   MPC8250 (HiP4 Rev 14, Mask C.0 5K25A) at 132 MHz
Manuf: Aztek Networks, Inc.
Board: CTA5000S
       Watchdog enabled
DRAM:  64 MB
FLASH:  2 MB
In:    serial
Out:   serial
Err:   serial
Net:   FCC1 ETHERNET
IDE:   Bus 0: not available
Hit any key to stop autoboot:  0
Using FCC1 ETHERNET device
TFTP from server 192.168.1.20; our IP address is 192.168.1.10
Filename 'uImage'.
Load address: 0x2000000
Loading: #################################################################
         ######
done
Bytes transferred =3D 1035332 (fcc44 hex)
Using FCC1 ETHERNET device
TFTP from server 192.168.1.20; our IP address is 192.168.1.10
Filename 'uRamdisk'.
Load address: 0x2200000
Loading: #################################################################
         #####################################################
done
Bytes transferred =3D 1731966 (1a6d7e hex)
Using FCC1 ETHERNET device
TFTP from server 192.168.1.20; our IP address is 192.168.1.10
Filename 'cta5000s.dtb'.
Load address: 0x2400000
Loading: #
done
Bytes transferred =3D 4096 (1000 hex)
## Booting image at 02000000 ...
   Image Name:   Linux-2.6.24.2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1035268 Bytes =3D 1011 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02200000 ...
   Image Name:   Simple Embedded Linux Framework
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    1731902 Bytes =3D  1.7 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Booting using the fdt at 0x2400000
   Loading Ramdisk to 039d9000, end 03b7fd3e ... OK
   Loading Device Tree to 007fe000, end 007fefff ... OK
Xid mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
 -> early_init_devtree(c07fe000)
search "chosen", depth: 0, uname:
search "chosen", depth: 1, uname: cpus
search "chosen", depth: 2, uname: PowerPC,8250@0
search "chosen", depth: 1, uname: memory
search "chosen", depth: 1, uname: localbus@f0010100
search "chosen", depth: 2, uname: flash@fe000000,0
search "chosen", depth: 1, uname: soc@f0000000
search "chosen", depth: 2, uname: cpm@119c0
search "chosen", depth: 3, uname: muram@0
search "chosen", depth: 4, uname: data@0
search "chosen", depth: 3, uname: brg@119f0
search "chosen", depth: 3, uname: serial@11a00
search "chosen", depth: 3, uname: serial@11a40
search "chosen", depth: 3, uname: ethernet@11300
search "chosen", depth: 2, uname: interrupt-controller@10c00
search "chosen", depth: 1, uname: chosen
Looking for initrd properties... <3>initrd_start=3D0xc39d9000  initrd_end=
=3D0xc3b7fe
Command line is:
dt_root_size_cells =3D 1
dt_root_addr_cells =3D 1
memory scan node memory, reg size 8, data: 0 4000000 2 1,
 - 0 ,  4000000
reserving: 39d9000 -> 1a6d3f
Phys. mem: 4000000
-> move_device_tree
<- move_device_tree
Scanning CPUs ...
boot cpu: logical 0 physical 0
 <- early_init_devtree()
Using Aztek Networks cta5000s machine description
Linux version 2.6.24.2 (jblack@jblack.azteknetworks.net) (gcc version 4.2.2=
) #38
 -> unflatten_device_tree()
  size is bd4, allocating...
  unflattening c3fff428...
fixed up name for  ->
fixed up name for cpus -> cpus
fixed up name for PowerPC,8250@0 -> PowerPC,8250
fixed up name for memory -> memory
fixed up name for localbus@f0010100 -> localbus
fixed up name for flash@fe000000,0 -> flash
fixed up name for soc@f0000000 -> soc
fixed up name for cpm@119c0 -> cpm
fixed up name for muram@0 -> muram
fixed up name for data@0 -> data
fixed up name for brg@119f0 -> brg
fixed up name for serial@11a00 -> serial
fixed up name for serial@11a40 -> serial
fixed up name for ethernet@11300 -> ethernet
fixed up name for interrupt-controller@10c00 -> interrupt-controller
fixed up name for chosen -> chosen
 <- unflatten_device_tree()
Found initrd at 0xc39d9000:0xc3b7fd3e
console [udbg0] enabled
setup_arch: bootmem
cta5000s_setup_arch(): entry
cpm_muran_init(): entry
cpm_muran_init(): exit
init_ioports(): empty
cta5000s_setup_arch(): exit
setup_arch: exit
Zone PFN ranges:
  DMA             0 ->    16384
  Normal      16384 ->    16384
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    16384
Unable to handle kernel paging request for data at address 0xe001a000
Faulting instruction address: 0xc00e1a6c
Oops: Kernel access of bad area, sig: 11 [#1]
Unable to handle kernel paging request for data at address 0x401c1ae0
Faulting instruction address: 0xc00e6254
Oops: Kernel access of bad area, sig: 11 [#2]
Unable to handle kernel paging request for data at address 0x401c1ae0
Faulting instruction address: 0xc00e6254
Recursive die() failure, output suppressed
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill the idle task!

>  > > I tried to fully describe the segments in muram node and it seems to
>  > > mess things up even worse.
>  >
>  > What do you mean?  What changes did you make, and what was the result?

I changed the muram node description to describe all the segments in
the dual port ram of the immr for the 8250. The thinking was that I
needed to describe the non-contiguous portions in the immr. The user
manual (page 3-1) shows the immr to be defined as:

0x00000=960x03FFF Dual-port RAM (DPRAM1) R/W 16 Kbytes
0x04000=960x05FFF Dual-port RAM (microcode only) (DPRAM)1 R/W 8 Kbytes
0x06000=960x07FFF Reserved =97 8 Kbytes
0x08000=960x08FFF Dual-port RAM (DPRAM2) R/W 4 Kbytes
0x09000=960x0AFFF Reserved =97 8 Kbytes
0x0B000=960x0BFFF Dual-port RAM (DPRAM3) R/W 4 Kbytes
0x0C000=960x0FFFF Reserved =97 16 Kbytes

muram@0 {
   #address-cells =3D <1>;
   #size-cells =3D <1>;
   ranges =3D <0 0 10000>;

   data@0 {
      compatible =3D "fsl,cpm-muram-data";
      reg =3D <0 4000 8000 1000 B000 1000>;
   };
};

Sometimes I get a stack trace, sometimes I don't.

Unable to handle kernel paging request for data at address 0xde7ebbe7
Faulting instruction address: 0xc00114fc
Oops: Kernel access of bad area, sig: 11 [#1]

[c023ff20] [c001a498] printk+0x50/0x60 (unreliable)
[c023ff40] [c01110a0] of_get_property+0x10/0x34
[c023ff50] [c01110e8] of_device_is_compatible+0x24/0xa0
[c023ff80] [c01111dc] of_find_compatible_node+0x78/0xc4
[c023ffa0] [c0211020] cta5000s_pic_init+0x24/0x6c
[c023ffb0] [c020c880] init_IRQ+0x24/0x34
[c023ffc0] [c0206948] start_kernel+0x17c/0x2b8
[c023fff0] [00003438] 0x3438

Re: muram in device tree for mpc8250 in arch/powerpc

[Scott Wood]

James Black wrote:
> Zone PFN ranges:
>   DMA             0 ->    16384
>   Normal      16384 ->    16384
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
>     0:        0 ->    16384
> Unable to handle kernel paging request for data at address 0xe001a000
> Faulting instruction address: 0xc00e1a6c

What function is 0xc00e1a6c in?

Is it possible that you have an SMC device initialized by your firmware 
that is corrupting parameter RAM?

> muram@0 {
>    #address-cells = <1>;
>    #size-cells = <1>;
>    ranges = <0 0 10000>;
> 
>    data@0 {
>       compatible = "fsl,cpm-muram-data";
>       reg = <0 4000 8000 1000 B000 1000>;

You can't use all of 0x8000-0x8fff; there is device parameter RAM in 
there.  If you can figure out the portions that aren't in use, you can 
use those, but I wouldn't bother unless you really need the extra muram.

-Scott

Re: muram in device tree for mpc8250 in arch/powerpc

[James Black]

On Thu, Mar 20, 2008 at 12:20 PM, Scott Wood <scottwood@freescale.com> wrote:
> James Black wrote:
>  > Zone PFN ranges:
>  >   DMA             0 ->    16384
>  >   Normal      16384 ->    16384
>  > Movable zone start PFN for each node
>  > early_node_map[1] active PFN ranges
>  >     0:        0 ->    16384
>  > Unable to handle kernel paging request for data at address 0xe001a000
>  > Faulting instruction address: 0xc00e1a6c
>
>  What function is 0xc00e1a6c in?
Drilled down into the source and find that mm/bootmem.c:line 232

           : find_next_zero_bit()
may be the culprit. When I put printks in, the line moves around a bit.

JB

>  Is it possible that you have an SMC device initialized by your firmware
>  that is corrupting parameter RAM?
No other devices have been configured except FCC1, SCC1, SCC3. The
unused gpio pins have been set as outputs.

>  > muram@0 {
>  >    #address-cells = <1>;
>  >    #size-cells = <1>;
>  >    ranges = <0 0 10000>;
>  >
>  >    data@0 {
>  >       compatible = "fsl,cpm-muram-data";
>  >       reg = <0 4000 8000 1000 B000 1000>;
>
>  You can't use all of 0x8000-0x8fff; there is device parameter RAM in
>  there.  If you can figure out the portions that aren't in use, you can
>  use those, but I wouldn't bother unless you really need the extra muram.

So, are you are saying that the muram node is giving the ram to the
kernel and is no longer available for devices to use as buffer
descriptors? I imagined the opposite. I thought I was telling the
kernel where the parameter ram and buffer descriptors live. I am going
to turn on the MCC2 device eventually and will need all of the dpram
for buffer descriptors.

The memory map in my mind right now is
0x0000 - 0x3FFF --> buffer descriptors for SCCx and MCC2.
0x8000 - 0x8FFF --> paramter ram for SCCx and MCC2, et al. (reserved)
0xB000 - 0xB8FF --> FCCx specific (reserved)

In my case, I shouldn't define any of the dual port ram for the kernel?


Jim Black


>
>  -Scott
>

Re: muram in device tree for mpc8250 in arch/powerpc

[Scott Wood]

On Thu, Mar 20, 2008 at 05:02:35PM -0600, James Black wrote:
> On Thu, Mar 20, 2008 at 12:20 PM, Scott Wood <scottwood@freescale.com> wrote:
> > James Black wrote:
> >  > Zone PFN ranges:
> >  >   DMA             0 ->    16384
> >  >   Normal      16384 ->    16384
> >  > Movable zone start PFN for each node
> >  > early_node_map[1] active PFN ranges
> >  >     0:        0 ->    16384
> >  > Unable to handle kernel paging request for data at address 0xe001a000
> >  > Faulting instruction address: 0xc00e1a6c
> >
> >  What function is 0xc00e1a6c in?
> Drilled down into the source and find that mm/bootmem.c:line 232
> 
>            : find_next_zero_bit()
> may be the culprit. When I put printks in, the line moves around a bit.

Is it node_bootmem_map, eidx, or i that is bad?  What is end_pfn?  What is
calling alloc_bootmem?

> >  You can't use all of 0x8000-0x8fff; there is device parameter RAM in
> >  there.  If you can figure out the portions that aren't in use, you can
> >  use those, but I wouldn't bother unless you really need the extra muram.
> 
> So, are you are saying that the muram node is giving the ram to the
> kernel and is no longer available for devices to use as buffer
> descriptors?

No.

> I imagined the opposite. I thought I was telling the
> kernel where the parameter ram and buffer descriptors live.

It's telling the kernel where available muram is, to be allocated by CPM
drivers for buffer descriptors.

> I am going to turn on the MCC2 device eventually and will need all of the
> dpram for buffer descriptors.
> 
> The memory map in my mind right now is
> 0x0000 - 0x3FFF --> buffer descriptors for SCCx and MCC2.
> 0x8000 - 0x8FFF --> paramter ram for SCCx and MCC2, et al. (reserved)
> 0xB000 - 0xB8FF --> FCCx specific (reserved)
> 
> In my case, I shouldn't define any of the dual port ram for the kernel?

You shouldn't define any of the reserved areas as general purpose muram.

-Scott

Re: muram in device tree for mpc8250 in arch/powerpc

[James Black]

PiAgSXMgaXQgbm9kZV9ib290bWVtX21hcCwgZWlkeCwgb3IgaSB0aGF0IGlzIGJhZD8gIFdoYXQg
aXMgZW5kX3Bmbj8gIFdoYXQgaXMKPiAgY2FsbGluZyBhbGxvY19ib290bWVtPwoKVGhlIGNhbGwg
c3RhcnRzIGluIGluaXQvbWFpbi5jIHdpdGggcGFnaW5nX2luaXQoKSBhbmQgZW5kcyB1cCBpbgpt
bS9ib290bWVtLmM6YWxsb2NfYm9vdG1lbV9ub2RlKCkuCkkgaGF2ZSBiZWVuIG1vdmluZyB0aGUg
cHJpbnRrIGFyb3VuZCB0cnlpbmcgdG8gZmluZCBleGFjdGx5IHdoZXJlIHRoaXMKdGhpbmcgZmFp
bHMuIEl0IG5vdyBzZWVtcyB0aGF0IHRoZSBwcm9ibGVtIGlzIGFsc28gbW92aW5nLiBUaGUgbGF0
ZXN0Cm91dHB1dCBsb29rcyBsaWtlIGl0IGdvdCB0aHJvdWdoIHRoZSBwYWdlIGFsbG9jYXRpb24u
IEkgZ3JlcGVkIHRoZSBlbGYKZmlsZSBhbmQgdGhlIGZhdWx0aW5nIGFkZHJlc3MgaW5zdHJ1Y3Rp
b24gIDB4YzAwMTEyMTggaXMgaW4gc3RyY21wLgpbamJsYWNrQGpibGFjayBsaW51eC0yLjYuMjRd
JCBubSB2bWxpbnV4IHxncmVwIGMwMDExMjEKYzAwMTEyMTAgVCBzdHJjbXAKCkkndmUgYm9vdGVk
IHNldmVyYWwgdGltZXMgbm93IGFuZCB0aGUgcHJvYmxlbSBtb3ZlcyB3aXRoIHRoZSBwcmludGsu
CkJ1dCwgd2hlbiBJIGRpc2FibGUgZWFybHkgZGVidWdnaW5nIHRoZSBwcm9ibGVtIGNvbWVzIGJh
Y2sgYW5kIHRoZQpib290IGhhbmdzIG9yIGNyYXNoZXMgYXMgdXN1YWwuIEhlcmUgYXJlIGEgY291
cGxlIG9mIG91dHB1dHMgdGhhdCBzaG93Cml0IGlzIGdldHRpbmcgdGhyb3VnaCB0aGUgcGZuIGFs
bG9jYXRpb25zLiBTb21ldGhpbmcgaXNuJ3QgZGVjbGFyZWQKcmlnaHQgb3IgY29uZmlndXJlZCBy
aWdodC4gQnV0IHdoZXJlIHRvIGxvb2s/CgpJJ3ZlIGNvbXBpbGVkIHRoZSBrZXJuZWwgd2l0aCBn
Y2MgNC4wLjAgYW5kICA0LjIuMiBib3RoIHZlcnNpb25zIGhhdmUKdGhlIHNhbWUgcHJvYmxlbS4g
U2hvdWxkIEkgdHJ5IHRoZSAyLjYuMjUga2VybmVsIHNpbmNlIHRoZSAyLjYuMTkKd29ya3MganVz
dCBmaW5lLiBJJ3ZlIHN0cmlwcGVkIHRoZSBrZXJuZWwgb3B0aW9ucyBkb3duIGFsbW9zdCBhcyBm
YXIKYXMgSSBjYW4gZ28uCgpzZXR1cF9hcmNoOiBleGl0ClpvbmUgUEZOIHJhbmdlczoKICBETUEg
ICAgICAxMzQyMTc3MjggLT4gICAgMTYzODQKICBOb3JtYWwgICAgICAxNjM4NCAtPiAgICAxNjM4
NApNb3ZhYmxlIHpvbmUgc3RhcnQgUEZOIGZvciBlYWNoIG5vZGUKZWFybHlfbm9kZV9tYXBbMV0g
YWN0aXZlIFBGTiByYW5nZXMKICAyMDk3MTUyOiAxMzQyMTc3MjggLT4gICAgMTYzODQKQ291bGQg
bm90IGZpbmQgc3RhcnRfcGZuIGZvciBub2RlIDAKZnJlZV9hcmVhX2luaXRfbm9kZXMoKTogcGdk
YXQ6IGMwMWNhZGMwCm5vZGVfYm9vdG1lbV9tYXAoYWRkcik6IGMzZmZlMDAwCmVpZHgoc2l6ZSk6
IDE2Mzg0Cmkob2Zmc2V0KTogMAplbmRfcGZuOiAxNjM4NApnb2FsOiAxMDczNzQxODIzCnByZWZl
cnJlZDogMApub2RlX2Jvb3RtZW1fbWFwKGFkZHIpOiBjM2ZmZTAwMAplaWR4KHNpemUpOiAxNjM4
NAppKG9mZnNldCk6IDAKZW5kX3BmbjogMTYzODQKZ29hbDogMTA3Mzc0MTgyMwpwcmVmZXJyZWQ6
IDAKQnVpbHQgMSB6b25lbGlzdHMgaW4gWm9uZSBvcmRlciwgbW9iaWxpdHkgZ3JvdXBpbmcgb2Zm
LiAgVG90YWwgcGFnZXM6CjAKS2VybmVsIGNvbW1hbmQgbGluZTogL2Rldi9yb290PS9kZXYvcmFt
IHI3IHJhbWRpc2tfc2l6ZT00MDk2ClVuYWJsZSB0byBoYW5kbGUga2VybmVsIHBhZ2luZyByZXF1
ZXN0IGZvciBkYXRhIGF0IGFkZHJlc3MgMHgwMDAwMDAwMApGYXVsdGluZyBpbnN0cnVjdGlvbiBh
ZGRyZXNzOiAweGMwMDExMjE4Ck9vcHM6IEtlcm5lbCBhY2Nlc3Mgb2YgYmFkIGFyZWEsIHNpZzog
MTEgWyMxXQpBenRlayBOZXR3b3JrcyBjdGE1MDAwcwpOSVA6IGMwMDExMjE4IExSOiBjMDBmMGRh
MCBDVFI6IGMwMWFkZWM0ClJFR1M6IGMwMWQzZTcwIFRSQVA6IDAzMDAgICBOb3QgdGFpbnRlZCAg
KDIuNi4yNC4yKQpNU1I6IDAwMDAxMDMyIDxNRSxJUixEUj4gIENSOiA0NDA0MjA0OCAgWEVSOiAy
MDAwMDAwMApEQVI6IDAwMDAwMDAwLCBEU0lTUjogMjAwMDAwMDAKVEFTSyA9IGMwMWMyNTcwWzBd
ICdzd2FwcGVyJyBUSFJFQUQ6IGMwMWQyMDAwCkdQUjAwOiAwMDAwMDA2MyBjMDFkM2YyMCBjMDFj
MjU3MCAwMDAwMDAwMCBjMDE5MzYwNyBmZmZmZmZmZiBjMDFlMjM5OAowMDAwMDAwMApHUFIwODog
MDAwMDAwMDAgMDAwMDAwNzAgYzAxY2NiYjAgYzA3ZmQwN2EgMjQwNDIwNDggMjA4MDIwMTAgMDNm
ZmYwMDAKMDA3ZmZmMDAKR1BSMTY6IDAzYmJjZDNlIDAwMWE2ZDNlIDAyMjAwMDQwIDAzYTE2MDAw
IDAwN2ZmZWIwIDAzZmY5OGU0IDAwMDAwMDAwCjAwMDAwMDA0CkdQUjI0OiAwMDAwMDAwMCAwMjQw
MDAwMCA0MDAwMDAwMCBjMDFkOWQxNCAwMDAwMDAwMCBjMDFkM2Y1OCBjMDE5MzYwOApjM2ZmZTJm
MApDYWxsIFRyYWNlOgpbYzAxZDNmNDBdIFtjMDBmMGRlMF0KW2MwMWQzZjUwXSBbYzAwZjBlMjhd
CgpzZXR1cF9hcmNoOiBleGl0ClpvbmUgUEZOIHJhbmdlczoKICBETUEgICAgICAgICAgICAgMCAt
PiAgICAxNjM4NAogIE5vcm1hbCAgICAgIDE2Mzg0IC0+ICAgIDE2Mzg0Ck1vdmFibGUgem9uZSBz
dGFydCBQRk4gZm9yIGVhY2ggbm9kZQplYXJseV9ub2RlX21hcFsxXSBhY3RpdmUgUEZOIHJhbmdl
cwogICAgMDogICAgICAgIDAgLT4gICAgMTYzODQKbm9kZV9ib290bWVtX21hcChhZGRyKTogYzNm
ZmUwMDAKZWlkeChzaXplKTogMTYzODQKaShvZmZzZXQpOiAwCmVuZF9wZm46IDE2Mzg0CmdvYWw6
IDEwNzM3NDE4MjMKcHJlZmVycmVkOiAwCl9fYWxsb2NfYm9vdG1lbV9ub2RlKCk6IHB0cjogYzAx
ZTkwMDAKbm9kZV9ib290bWVtX21hcChhZGRyKTogYzNmZmUwMDAKZWlkeChzaXplKTogMTYzODQK
aShvZmZzZXQpOiAwCmVuZF9wZm46IDE2Mzg0CmdvYWw6IDEwNzM3NDE4MjMKcHJlZmVycmVkOiAw
Cl9fYWxsb2NfYm9vdG1lbV9ub2RlKCk6IHB0cjogYzAxMzEwMDAKbm9kZV9ib290bWVtX21hcChh
ZGRyKTogYzNmZmUwMDAKZWlkeChzaXplKTogMTYzODQKaShvZmZzZXQpOiAwCmVuZF9wZm46IDE2
Mzg0CmdvYWw6IDEwNzM3NDE4MjMKcHJlZmVycmVkOiAwCl9fYWxsb2NfYm9vdG1lbV9ub2RlKCk6
IHB0cjogYzAxNzEwMDAKbm9kZV9ib290bWVtX21hcChhZGRyKTogYzNmZmUwMDAKZWlkeChzaXpl
KTogMTYzODQKaShvZmZzZXQpOiAwCmVuZF9wZm46IDE2Mzg0CmdvYWw6IDEwNzM3NDE4MjMKcHJl
ZmVycmVkOiAwCm5vZGVfYm9vdG1lbV9tYXAoYWRkcik6IGMzZmZlMDAwCmVpZHgoc2l6ZSk6IDE2
Mzg0Cmkob2Zmc2V0KTogMAplbmRfcGZuOiAxNjM4NApnb2FsOiAxMDczNzQxODIzCnByZWZlcnJl
ZDogMApCdWlsdCAxIHpvbmVsaXN0cyBpbiBab25lIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBv
bi4gIFRvdGFsIHBhZ2VzOgoxNjI1NgpLZXJuZWwgY29tbWFuZCBsaW5lOiAvZGVyb290PS9kZXYv
cu+/vW0gcncgcmFtZGlza19zaXplPTQwOTYKVW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgcGFnaW5n
IHJlcXVlc3QgZm9yIGRhdGEgYXQgYWRkcmVzcyAweDAwMDAwMDAwCkZhdWx0aW5nIGluc3RydWN0
aW9uIGFkZHJlc3M6IDB4YzAwMTEyMTgKT29wczogS2VybmVsIGFjY2VzcyBvZiBiYWQgYXJlYSwg
c2lnOiAxMSBbIzgxOTNdCkF6dGVrIE5ldHdvcmtzIGN0YTUwMDBzCk5JUDogYzAwMTEyMTggTFI6
IGMwMGYwZGEwIENUUjogYzAxYWRlYzQKUkVHUzogYzAxZDNlNzAgVFJBUDogMDMwMCAgIE5vdCB0
YWludGVkICAoMi42LjI0LjIpCk1TUjogMDAwMDEwMzIgPE1FLElSLERSPiAgQ1I6IDQ0MDQyMDI4
ICBYRVI6IDIwMDAwMDAwCkRBUjogMDAwMDAwMDAsIERTSVNSOiAyMDAwMDAwMApUQVNLID0gYzAx
YzI1NzBbMF0gJ3N3YXBwZXInIFRIUkVBRDogYzAxZDIwMDAKR1BSMDA6IDAwMDAwMDYzIGMwMWQz
ZjIwIGMwMWMyNTcwIDAwMDAwMDAwIGMwMTkzNjA3IGZmZmZmZmZmIGMwMWUyMzk4CjAwMDAwMDAw
CkdQUjA4OiBjMDFhMTJlMCBjMDFlMDAwMCBjMDE5MTcwMCBjMDFlMjM4NCAyNDA0MjAyOCAyNDg4
NjAxMiAwM2ZmZjAwMAowMDdmZmYwMApHUFIxNjogMDNiYmNkM2UgMDAxYTZkM2UgMDIyMDAwNDAg
MDNhMTYwMDAgMDA3ZmZlYjAgMDNmZjk4ZTQgMDAwMDAwMDAKMDAwMDAwMDQKR1BSMjQ6IDAwMDAw
MDAwIDAyNDAwMDAwIDQwMDAwMDAwIGMwMWQ5ZDE0IDAwMDAwMDAwIGMwMWQzZjU4IGMwMTkzNjA4
CmMzYmZmMTc0CkNhbGwgVHJhY2U6CltjMDFkM2Y0MF0gW2MwMGYwZGUwXQpbYzAxZDNmNTBdIFtj
MDBmMGUyOF0KW2MwMWQzZjgwXSBbYzAwZjBmMWNdCltjMDFkM2ZhMF0gW2MwMWFkZWU4XQpbYzAx
ZDNmYjBdIFtjMDFhOTg1NF0KW2MwMWQzZmMwXSBbYzAxYTM5MGNdCltjMDFkM2ZmMF0gWzAwMDAz
NDM4XQpJbnN0cnVjdGlvbiBkdW1wOgozODg0ZmZmZiA4YzA1MDAwMSAyYzAwMDAwMCA0MDgyZmZm
OCAzOGE1ZmZmZiA4YzA0MDAwMSAyYzAwMDAwMAo5YzA1MDAwMQo0MDgyZmZmNCA0ZTgwMDAyMCAz
OGEzZmZmZiAzODg0ZmZmZiA8OGM2NTAwMDE+IDJjODMwMDAwIDhjMDQwMDAxCjdjNjAxODUxCi0t
LVsgZW5kIHRyYWNlIDg2NDBhYmU2OWEzMTZkZWUgXS0tLQpLZXJuZWwgcGFuaWMgLSBub3Qgc3lu
Y2luZzogQXR0ZW1wdGVkIHRvIGtpbGwgdGhlIGlkbGUgdGFzayEKUmVib290aW5nIGluIDE4MCBz
ZWNvbmRzLi4K

Re: muram in device tree for mpc8250 in arch/powerpc

[Scott Wood]

James Black wrote:
> I've compiled the kernel with gcc 4.0.0 and  4.2.2 both versions have
> the same problem. Should I try the 2.6.25 kernel since the 2.6.19
> works just fine.

It's worth a try.  Also, since it seems to be a random corruption issue, 
make sure that no DMA is left running by the firmware (try resetting the 
CPM (though you'll have to turn off the early udbg output)), that you're 
not trying to use more memory than you have, etc.  Try dumping various 
registers to see if anything significant is different compared to 2.6.19.

If none of that helps, then I'm out of ideas as far as debug-by-email 
goes...

> I've stripped the kernel options down almost as far
> as I can go.

You turned off too much. :-)
Turn kallsyms back on, so you get symbols in crash dumps.

-Scott

Re: muram in device tree for mpc8250 in arch/powerpc

[James Black]

Thanks much for the help Scott. Do you feel that the dts is correct
now and probably not the culprit? Do you have 2.6.24.2 running on
other boards? I've been checking u-boot to make sure that nothing over
there is messing me up. I noticed that there are new CFG_.. I'm using

#define CONFIG_OF_LIBFDT
#define CONFIG_OF_BOARD_SETUP
#define CONFIG_OF_HAS_UBOOT_ENV
#define CONFIG_OF_HAS_BD_T
#define CONFIG_OF_BOARD_SETUP
#define CONFIG_OF_BOOT_CPU      0

#define OF_CPU  "PowerPC,8250@0"
#define OF_SOC  "soc0@f0000000"
#define OF_TBCLK        (bd->bi_busfreq / 4)
#define OF_STDOUT_PATH  "/soc/cpm/serial@11a00"


/*
 * Device Tree for the CTA5000S board with an MPC8250 chip.
 * Device Tree for the PQ2FADS-ZU board with an MPC8280 chip.
 *
 * Copyright 2007 Freescale Semiconductor Inc.
 *
 * This program is free software; you can redistribute  it and/or modify it
 * under  the terms of  the GNU General  Public License as published by the
 * Free Software Foundation;  either version 2 of the  License, or (at your
 * option) any later version.
 */

/ {
	model = "cta5000s";
	compatible = "fsl,cta5000s";
	#address-cells = <1>;
	#size-cells = <1>;

	cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		PowerPC,8250@0 {
			device_type = "cpu";
			reg = <0>;
			d-cache-line-size = <20>;
			i-cache-line-size = <20>;
			d-cache-size = <4000>;
			i-cache-size = <4000>;
			timebase-frequency = <0>;
			clock-frequency = <0>;
		};
	};

	memory {
		device_type = "memory";
		reg = <0 0>;
	};

	localbus@f0010100 {
		compatible = "fsl,mpc8250-localbus",
                   "fsl,pq2-localbus";

		#address-cells = <2>;
		#size-cells = <1>;
		reg = <f0010100 60>;
		ranges = <0 0 fe000000 00200000>;

		flash@fe000000,0 {
			compatible = "cfi-flash";
			reg = <0 fe000000  00200000>;
			bank-width = <2>;
			device-width = <1>;
		};
	};

	soc@f0000000 {
		#address-cells = <1>;
		#size-cells = <1>;
		device_type = "soc";
		compatible = "fsl,mpc8250", "fsl,pq2-soc";
		ranges = <00000000 f0000000 00014000>;

		// Temporary -- will go away once kernel uses ranges for get_immrbase().
		reg = <f0000000 00014000>;

		cpm@119c0 {
			#address-cells = <1>;
			#size-cells = <1>;
			#interrupt-cells = <2>;
			compatible = "fsl,mpc8250-cpm", "fsl,cpm2";
			reg = <119c0 30>;
			ranges;

			muram@0 {
				#address-cells = <1>;
				#size-cells = <1>;
				ranges = <0 0 10000>;

				data{
					compatible = "fsl,cpm-muram-data";
					reg = <0 4000>;
				};
			};

			brg@119f0 {
				compatible = "fsl,mpc8250-brg",
				             "fsl,cpm2-brg",
				             "fsl,cpm-brg";
				reg = <119f0 10>;
			};

			serial@11a00 {
				device_type = "serial";
				compatible = "fsl,mpc8250-scc-uart",
				             "fsl,cpm2-scc-uart";
				reg = <11a00 20 8000 100>;
				interrupts = <28 8>;
				interrupt-parent = <&PIC>;
				fsl,cpm-brg = <1>;
				fsl,cpm-command = <00800000>;
			};

			serial@11a40 {
				device_type = "serial";
				compatible = "fsl,mpc8250-scc-uart",
				             "fsl,cpm2-scc-uart";
				reg = <11a40 20 8200 100>;
				interrupts = <2a 8>;
				interrupt-parent = <&PIC>;
				fsl,cpm-brg = <5>;
				fsl,cpm-command = <08c00000>;
			};

			ethernet@11300 {
				device_type = "network";
				compatible = "fsl,mpc8250-fcc-enet",
				             "fsl,cpm2-fcc-enet";
				reg = <11300 20 8400 100>;
				interrupts = <20 8>;
				interrupt-parent = <&PIC>;
				linux,network-index = <0>;
				fsl,cpm-command = <12000300>;
			};
		};

		PIC: interrupt-controller@10c00 {
			#interrupt-cells = <2>;
			interrupt-controller;
			reg = <10c00 80>;
			compatible = "fsl,mpc8250-pic", "fsl,cpm2-pic";
		};

	};

	chosen {
		linux,stdout-path = "/soc/cpm/serial@11a00";
	};
};

I think I'll try fresh source in 2.6.24, if I get the same result,
I'll give 2.6.25 a shot.

Again Thanks much...

Jim Black


On Fri, Mar 21, 2008 at 2:34 PM, Scott Wood <scottwood@freescale.com> wrote:
> James Black wrote:
>  > I've compiled the kernel with gcc 4.0.0 and  4.2.2 both versions have
>  > the same problem. Should I try the 2.6.25 kernel since the 2.6.19
>  > works just fine.
>
>  It's worth a try.  Also, since it seems to be a random corruption issue,
>  make sure that no DMA is left running by the firmware (try resetting the
>  CPM (though you'll have to turn off the early udbg output)), that you're
>  not trying to use more memory than you have, etc.  Try dumping various
>  registers to see if anything significant is different compared to 2.6.19.
>
>  If none of that helps, then I'm out of ideas as far as debug-by-email
>  goes...
>
>
>  > I've stripped the kernel options down almost as far
>  > as I can go.
>
>  You turned off too much. :-)
>  Turn kallsyms back on, so you get symbols in crash dumps.
>
>  -Scott
>

Re: muram in device tree for mpc8250 in arch/powerpc

[Scott Wood]

James Black wrote:
> Thanks much for the help Scott. Do you feel that the dts is correct
> now and probably not the culprit? Do you have 2.6.24.2 running on
> other boards?

I just booted 2.6.24.2 on pq2fads (using cuImage, since I don't have a 
devtree-aware u-boot on this board).

> 	localbus@f0010100 {
> 		compatible = "fsl,mpc8250-localbus",
>                    "fsl,pq2-localbus";
> 
> 		#address-cells = <2>;
> 		#size-cells = <1>;
> 		reg = <f0010100 60>;
> 		ranges = <0 0 fe000000 00200000>;
> 
> 		flash@fe000000,0 {
> 			compatible = "cfi-flash";
> 			reg = <0 fe000000  00200000>;
> 			bank-width = <2>;
> 			device-width = <1>;
> 		};

This is wrong; the flash will not translate since you didn't provide a 
window at the address reg is at.

The first cell of the reg should be the chipselect, and the second cell 
the offset.

> 			brg@119f0 {
> 				compatible = "fsl,mpc8250-brg",
> 				             "fsl,cpm2-brg",
> 				             "fsl,cpm-brg";
> 				reg = <119f0 10>;
> 			};

BRG should be <119f0 10 115f0 10>.

-Scott

Re: muram in device tree for mpc8250 in arch/powerpc

[James Black]

I started from scratch and am trying to build the cuImage. I get this
compiler error.

arch/powerpc/boot/cuboot-pq2.c:14:20: error: bitops.h: No such file or directory
arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
arch/powerpc/boot/cuboot-pq2.c:205: warning: implicit declaration of
function '__ilog2_u32'

I looks as though cuboot-pq2.c expects bitops.h to be in the same
directory, but it has moved to
linux/include/asm-powerpc/bitops.h

Did you run into this problem?

JB

On Mon, Mar 24, 2008 at 10:52 AM, Scott Wood <scottwood@freescale.com> wrote:
> James Black wrote:
>  > Thanks much for the help Scott. Do you feel that the dts is correct
>  > now and probably not the culprit? Do you have 2.6.24.2 running on
>  > other boards?
>
>  I just booted 2.6.24.2 on pq2fads (using cuImage, since I don't have a
>  devtree-aware u-boot on this board).
>
>
>  >       localbus@f0010100 {
>  >               compatible = "fsl,mpc8250-localbus",
>  >                    "fsl,pq2-localbus";
>  >
>  >               #address-cells = <2>;
>  >               #size-cells = <1>;
>  >               reg = <f0010100 60>;
>  >               ranges = <0 0 fe000000 00200000>;
>  >
>  >               flash@fe000000,0 {
>  >                       compatible = "cfi-flash";
>  >                       reg = <0 fe000000  00200000>;
>  >                       bank-width = <2>;
>  >                       device-width = <1>;
>  >               };
>
>  This is wrong; the flash will not translate since you didn't provide a
>  window at the address reg is at.
>
>  The first cell of the reg should be the chipselect, and the second cell
>  the offset.
>
>
>  >                       brg@119f0 {
>  >                               compatible = "fsl,mpc8250-brg",
>  >                                            "fsl,cpm2-brg",
>  >                                            "fsl,cpm-brg";
>  >                               reg = <119f0 10>;
>  >                       };
>
>  BRG should be <119f0 10 115f0 10>.
>
>  -Scott
>
>

Re: muram in device tree for mpc8250 in arch/powerpc

[Scott Wood]

James Black wrote:
> I started from scratch and am trying to build the cuImage. I get this
> compiler error.
> 
> arch/powerpc/boot/cuboot-pq2.c:14:20: error: bitops.h: No such file or directory
> arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
> arch/powerpc/boot/cuboot-pq2.c:205: warning: implicit declaration of
> function '__ilog2_u32'
> 
> I looks as though cuboot-pq2.c expects bitops.h to be in the same
> directory, but it has moved to
> linux/include/asm-powerpc/bitops.h

I don't see any reference to bitops.h in cuboot-pq2.c...
Line 14 includes "ops.h".

-Scott

Re: muram in device tree for mpc8250 in arch/powerpc

[James Black]

OK, you are right. I was looking at my old copy I was trying to fix.
The error is,

arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
arch/powerpc/boot/cuboot-pq2.c:204: warning: implicit declaration of
function '__ilog2_u32'


On Mon, Mar 24, 2008 at 3:53 PM, Scott Wood <scottwood@freescale.com> wrote:
> James Black wrote:
>  > I started from scratch and am trying to build the cuImage. I get this
>  > compiler error.
>  >
>  > arch/powerpc/boot/cuboot-pq2.c:14:20: error: bitops.h: No such file or directory
>  > arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
>  > arch/powerpc/boot/cuboot-pq2.c:205: warning: implicit declaration of
>  > function '__ilog2_u32'
>  >
>  > I looks as though cuboot-pq2.c expects bitops.h to be in the same
>  > directory, but it has moved to
>  > linux/include/asm-powerpc/bitops.h
>
>  I don't see any reference to bitops.h in cuboot-pq2.c...
>  Line 14 includes "ops.h".
>
>  -Scott
>
>

Re: muram in device tree for mpc8250 in arch/powerpc

[Scott Wood]

James Black wrote:
> OK, you are right. I was looking at my old copy I was trying to fix.
> The error is,
> 
> arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
> arch/powerpc/boot/cuboot-pq2.c:204: warning: implicit declaration of
> function '__ilog2_u32'

It's defined as an inline function in ops.h.  Do you have an old ops.h?

-Scott

Re: muram in device tree for mpc8250 in arch/powerpc

[James Black]

I must have the old one. I don't see '__ilog2_u32' defined. This is
the kernel I got from denx eldk 4.2. I'll grab the kernel from
kernel.org and check there. Thanks.

JB

On Mon, Mar 24, 2008 at 4:05 PM, Scott Wood <scottwood@freescale.com> wrote:
> James Black wrote:
>  > OK, you are right. I was looking at my old copy I was trying to fix.
>  > The error is,
>  >
>  > arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
>  > arch/powerpc/boot/cuboot-pq2.c:204: warning: implicit declaration of
>  > function '__ilog2_u32'
>
>  It's defined as an inline function in ops.h.  Do you have an old ops.h?
>
>  -Scott
>

Re: muram in device tree for mpc8250 in arch/powerpc

[James Black]

That was it. It seems that the eldk/4.2 is missing the ilog2_u32
declaration. Makes me wonder what else is missing. I'll start again
with the kernel.org version and see what happens.

I'll send an email when this work gets done. Good catch.

JB

On Mon, Mar 24, 2008 at 4:09 PM, James Black <jblack547@gmail.com> wrote:
> I must have the old one. I don't see '__ilog2_u32' defined. This is
>  the kernel I got from denx eldk 4.2. I'll grab the kernel from
>  kernel.org and check there. Thanks.
>
>  JB
>
>
>
>  On Mon, Mar 24, 2008 at 4:05 PM, Scott Wood <scottwood@freescale.com> wrote:
>  > James Black wrote:
>  >  > OK, you are right. I was looking at my old copy I was trying to fix.
>  >  > The error is,
>  >  >
>  >  > arch/powerpc/boot/cuboot-pq2.c: In function 'fixup_pci':
>  >  > arch/powerpc/boot/cuboot-pq2.c:204: warning: implicit declaration of
>  >  > function '__ilog2_u32'
>  >
>  >  It's defined as an inline function in ops.h.  Do you have an old ops.h?
>  >
>  >  -Scott
>  >
>