Re: Device Tree setup for 8272-based board

Re: Device Tree setup for 8272-based board

[Daniel Ng]

Hi Scott,

> Scott Wood freescale.com> writes:
> > Yes, if u-boot is providing junk, then you'll probably want to hack up
> > the wrapper to ignore it. Or just upgrade u-boot to one that works.

So, I've gotten the latest u-boot installed and working. Here's my boot
sequence-

## Booting kernel from Legacy Image at 00200000 ...
Image Name: Linux-2.6.27-xxx
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1337540 Bytes = 1.3 MB
Load Address: 00400000
Entry Point: 00400b8c
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory <- <0x0 0x2000000> (32MB)
CPU clock-frequency <- 0x13ab6680 (330MHz)
CPU timebase-frequency <- 0xfbc520 (17MHz)
CPU bus-frequency <- 0x3ef1480 (66MHz)

zImage starting: loaded at 0x00400000 (sp: 0x01f789c8)
Allocating 0x2c96d0 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x006c6e28)...done 0x2a819c bytes

Linux/PowerPC load: root=/dev/mtdblock4 rw rootfstype=cramfs
mtdparts=flash:256K(ub
oot),128K(env1),128K(env2),1536K(linux1),6144K(root1),4096K(app1),1536K
(linux2),614
4K(root2),4096K(app2),1536K(usr),-(usb) panic=1 console=ttyCPM0 mem=32M usbid=1
Finalizing device tree... flat tree at 0x40ad90


-after that everything seems to freeze. There is no more console output, and
pings to the board fail.

What sort of debug output is available to me at this point?

I've tried various values for 'console' but I'm quite certain 'ttyCPM0' is the
one to use (just a reminder that it is a PPC-8272-based board).

I've even tried enabling the 'Early serial debugging for Freescale CPM-based
serial ports' option in the Kernel config. Unfortunately this doesn't result
in any noticeable difference.

Can you explain why my board is freezing?

Here is my Device Tree. It is a stripped-down version of mpc8272ads.dts (PCI
has been removed among many others). I have tried to minimise the tree just to
keep things simple.

Perhaps I removed something I shouldn't have?-

/dts-v1/;

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

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

PowerPC,8272@0 {
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <32>;
i-cache-line-size = <32>;
d-cache-size = <16384>;
i-cache-size = <16384>;
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
};
};
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8272", "fsl,pq2-soc";
ranges = <0x0 0xf0000000 0x53000>;

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

cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <0x119c0 0x30>;
ranges;

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

data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0x0 0x2000 0x9800 0x800>;
};
};

serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a00 0x20 0x8000 0x100>;
interrupts = <40 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x800000>;
};

};

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

};

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



Cheers,
Daniel

Device Tree setup for 8272-based board

[Daniel Ng]

Hi Scott,

> Scott Wood freescale.com> writes:
> > Yes, if u-boot is providing junk, then you'll probably want to hack up
> > the wrapper to ignore it. Or just upgrade u-boot to one that works.

So, I've gotten the latest u-boot installed and working. Here's my boot
sequence-

## Booting kernel from Legacy Image at 00200000 ...
Image Name: Linux-2.6.27-xxx
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1337540 Bytes = 1.3 MB
Load Address: 00400000
Entry Point: 00400b8c
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory <- <0x0 0x2000000> (32MB)
CPU clock-frequency <- 0x13ab6680 (330MHz)
CPU timebase-frequency <- 0xfbc520 (17MHz)
CPU bus-frequency <- 0x3ef1480 (66MHz)

zImage starting: loaded at 0x00400000 (sp: 0x01f789c8)
Allocating 0x2c96d0 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x006c6e28)...done 0x2a819c bytes

Linux/PowerPC load: root=/dev/mtdblock4 rw rootfstype=cramfs
mtdparts=flash:256K(ub
oot),128K(env1),128K(env2),1536K(linux1),6144K(root1),4096K(app1),1536K
(linux2),614
4K(root2),4096K(app2),1536K(usr),-(usb) panic=1 console=ttyCPM0 mem=32M usbid=1
Finalizing device tree... flat tree at 0x40ad90


-after that everything seems to freeze. There is no more console output, and
pings to the board fail.

What sort of debug output is available to me at this point?

I've tried various values for 'console' but I'm quite certain 'ttyCPM0' is the
one to use as this is what I was using when it was working with Linux 2.6.14
and an old (pre-Device Tree) version of u-boot.

I've even tried enabling the 'Early serial debugging for Freescale CPM-based
serial ports' option in the Kernel config. Unfortunately this doesn't result
in any noticeable difference.

Can you explain why my board is freezing?

Here is my Device Tree. It is a stripped-down version of mpc8272ads.dts (PCI
has been removed among many others). I have tried to minimise the tree just to
keep things simple.

Perhaps I removed something I shouldn't have?-

/dts-v1/;

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

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

PowerPC,8272@0 {
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <32>;
i-cache-line-size = <32>;
d-cache-size = <16384>;
i-cache-size = <16384>;
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
};
};
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8272", "fsl,pq2-soc";
ranges = <0x0 0xf0000000 0x53000>;

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

cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <0x119c0 0x30>;
ranges;

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

data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0x0 0x2000 0x9800 0x800>;
};
};

serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a00 0x20 0x8000 0x100>;
interrupts = <40 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x800000>;
};

};

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

};

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


NB: I'm using cuboot-pq2.c

Cheers,
Daniel

Re: Device Tree setup for 8272-based board

[Scott Wood]

On Fri, Jan 16, 2009 at 02:40:03PM +1100, Daniel Ng wrote:
> I've tried various values for 'console' but I'm quite certain 'ttyCPM0' is the
> one to use as this is what I was using when it was working with Linux 2.6.14
> and an old (pre-Device Tree) version of u-boot.

Yes, that is correct.  You can also leave it out and rely on
/chosen/linux,stdout-path.

> I've even tried enabling the 'Early serial debugging for Freescale CPM-based
> serial ports' option in the Kernel config. Unfortunately this doesn't result
> in any noticeable difference.
> 
> Can you explain why my board is freezing?
> 
> Here is my Device Tree. It is a stripped-down version of mpc8272ads.dts (PCI
> has been removed among many others). I have tried to minimise the tree just to
> keep things simple.
> 
> Perhaps I removed something I shouldn't have?-

You removed the brg node, but early debug output should still work
without it.

> /dts-v1/;
> 
> / {
> model = "HPXRED";
> compatible = "fsl,mpc8272ads";

Is it 100% compatible?  If not, change the compatible to something else
(and make sure your board code matches it).

Do you currently have mpc8272ads support enabled in the kernel?  If the
kernel doesn't find a matching ppc_md, you won't get any debug output. 

You can use udbg_printf() directly after the call to udbg_early_init()
though.

-Scott

Re: Device Tree setup for 8272-based board

[Daniel Ng]

Hi Scott,
On Sat, Jan 17, 2009 at 5:14 AM, Scott Wood <scottwood@freescale.com> wrote:
>
>> /dts-v1/;
>>
>> / {
>> model = "HPXRED";
>> compatible = "fsl,mpc8272ads";
>
> Is it 100% compatible?  If not, change the compatible to something else
> (and make sure your board code matches it).

My board is similar to the mpc8272ads, so it is not 100% compatible. So I guess
I will have to define my own DTS, correct?

How would I be able to tell if I need my own cuboot-*.c file as well?

>
> Do you currently have mpc8272ads support enabled in the kernel?  If the
> kernel doesn't find a matching ppc_md, you won't get any debug output.

No, since it is not an mpc8272ads board. What exactly are we matching here?
Is it just the Platform Name in the .config file eg. CONFIG_MPC8272_ADS?
If I use [compatible = "fsl,hpxred";] this doesn't seem to make a difference
in the behaviour.

Is the ppc_md generated from the Device Tree? Can you please point me to
the relevant file/s to see how this is done?

Also, which kernel file deals with searching for/reading the ppc_md?

>
> You can use udbg_printf() directly after the call to udbg_early_init()
> though.

Would I use these in cuboot-*.c? If so, how? Including <asm/udbg.h>
results in a 'file not found' compile error- I notice all the #includes
in the cuboot-*.c files are of the form #include "blah.h" rather than
#include <blah.h>

Overall, I just want to get my board up and running via the cuboot method.
Hopefully I'm asking the right questions! Is there anything else I might
need to know?

Thanks again for your continuing assistance.

Daniel

Re: Device Tree setup for 8272-based board

[Scott Wood]

On Mon, Jan 19, 2009 at 12:58:41PM +1100, Daniel Ng wrote:
> Hi Scott,
> On Sat, Jan 17, 2009 at 5:14 AM, Scott Wood <scottwood@freescale.com> wrote:
> >
> >> /dts-v1/;
> >>
> >> / {
> >> model = "HPXRED";
> >> compatible = "fsl,mpc8272ads";
> >
> > Is it 100% compatible?  If not, change the compatible to something else
> > (and make sure your board code matches it).
> 
> My board is similar to the mpc8272ads, so it is not 100% compatible. So I guess
> I will have to define my own DTS, correct?

Yes.

> How would I be able to tell if I need my own cuboot-*.c file as well?

The separate cuboot files are based on separate bd_t layouts -- if bd_t
is the same, you don't need a new file.  That said, if you're dealing
with modern u-boot, it'd be better to just pass a device tree and use
uImage.

> > Do you currently have mpc8272ads support enabled in the kernel?  If the
> > kernel doesn't find a matching ppc_md, you won't get any debug output.
> 
> No, since it is not an mpc8272ads board.

But the device tree claims that it is.

> What exactly are we matching here?
> Is it just the Platform Name in the .config file eg. CONFIG_MPC8272_ADS?
> If I use [compatible = "fsl,hpxred";] this doesn't seem to make a difference
> in the behaviour.

In order for the kernel to boot, there has to be platform code built in
whose probe() function recognizes the device tree as one that it
supports.

> Is the ppc_md generated from the Device Tree? Can you please point me to
> the relevant file/s to see how this is done?

ppc_md is in platform files such as
arch/powerpc/platforms/82xx/mpc8272_ads.c.

> Also, which kernel file deals with searching for/reading the ppc_md?

probe_machine() in arch/powerpc/kernel/setup-common.c.

> > You can use udbg_printf() directly after the call to udbg_early_init()
> > though.
> 
> Would I use these in cuboot-*.c?

No, this is in the kernel, not the bootwrapper.

-Scott

Re: Device Tree setup for 8272-based board

[Daniel Ng]

Hi Scott,

By #defining DEBUG in setup-32.c and setting the following in my kernel con=
fig-
CONFIG_PPC_EARLY_DEBUG=3Dy
CONFIG_PPC_EARLY_DEBUG_CPM=3Dy
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=3D0xf0001ff8

-I have been able to get the following boot messages:

## Booting kernel from Legacy Image at 00200000 ...
   Image Name:   Linux-2.6.27-xxx
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1337583 Bytes =3D  1.3 MB
   Load Address: 00400000
   Entry Point:  004006f0
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Memory <- <0x0 0x2000000> (32MB)
CPU clock-frequency <- 0x13ab6680 (330MHz)
CPU timebase-frequency <- 0xfbc520 (17MHz)
CPU bus-frequency <- 0x3ef1480 (66MHz)

zImage starting: loaded at 0x00400000 (sp: 0x01f789c8)
Allocating 0x2cb6d0 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x006c8e60)...done 0x2aa19c bytes

Linux/PowerPC load: root=3D/dev/mtdblock4 rw rootfstype=3Dcramfs
mtdparts=3Dflash:256K(ub
oot),128K(env1),128K(env2),1536K(linux1),6144K(root1),4096K(app1),1536K(lin=
ux2),614
4K(root2),4096K(app2),1536K(usr),-(usb) panic=3D1 console=3DttyCPM0 mem=3D3=
2M usbid=3D1
Finalizing device tree... flat tree at 0x40acb0
Probing machine type ...
  HPXRED ... match !
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Using HPXRED machine description
Linux version 2.6.27-xxx (dng@hellsforge) (gcc version 4.2.4) #19 PREEM
PT Tue Jan 20 17:46:59 EST 2009
console [udbg0] enabled
setup_arch: bootmem
hpxred_setup_arch()
No hpxred-bcsr in device tree
arch: exit
Top of RAM: 0x2000000, Total RAM: 0x2000000
Memory hole size: 0MB
Zone PFN ranges:
  DMA      0x00000000 -> 0x00002000
  Normal   0x00002000 -> 0x00002000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00002000
On node 0 totalpages: 8192
free_area_init_node: node 0, pgdat c02a1f7c, node_mem_map c02cc000
  DMA zone: 8128 pages, LIFO batch:0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
Kernel command line: root=3D/dev/mtdblock4 rw rootfstype=3Dcramfs
mtdparts=3Dflash:256K(u
boot),128K(env1),128K(env2),1536K(linux1),6144K(root1),4096K(app1),1536K(li=
nux2),61
44K(root2),4096K(app2),1536K(usr),-(usb) panic=3D1 console=3DttyCPM0 mem=3D=
32M usbid=3D1
PID hash table entries: 128 (order: 7, 512 bytes)
time_init: decrementer frequency =3D 16.500000 MHz
time_init: processor frequency   =3D 330.000000 MHz
clocksource: timebase mult[f26c9b2] shift[22] registered
clockevent: decrementer mult[439] shift[16] cpu[0]
Console: colour dummy =FC

-at this point the board just reboots.

Is there anything in the above logs that might signify why the reboot happe=
ned?


I thought it might have been to do with:

'No hpxred-bcsr in device tree'

If I add in a 'BCSR' node to my Device Tree I get the following:

console [udbg0] enabled
setup_arch: bootmem
hpxred_setup_arch()
Machine check in kernel mode.
Caused by (from SRR1=3D41030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
PREEMPT HPXRED
NIP: c0273804 LR: c02737f4 CTR: 00000000
REGS: c02a5ee0 TRAP: 0200   Not tainted  (2.6.27-800-OS-03050107)
MSR: 00041030 <ME,IR,DR>  CR: 22044028  XER: 20000000
TASK =3D c028c578[0] 'swapper' THREAD: c02a4000
GPR00: c02737f4 c02a5f90 c028c578 00000000 c000d260 00000000 c02ccffc 00000=
2c0
GPR08: c02ccffc 7c3203a6 00000000 f45005a9 22044042 ffdfffff 01ff8000 00000=
000
GPR16: 01fed694 01ff56f0 00000000 00000000 00000000 00000000 00000000 01ff2=
cd0
GPR24: 00000000 00000000 40000000 00000000 006d4ff0 fdfff000 c02ac4cc c1fff=
970
NIP [c0273804] hpxred_setup_arch+0xf0/0x1dc
LR [c02737f4] hpxred_setup_arch+0xe0/0x1dc
Call Trace:
[c02a5f90] [c02737f4] hpxred_setup_arch+0xe0/0x1dc (unreliable)
[c02a5fb0] [c026f63c] setup_arch+0x130/0x168
[c02a5fc0] [c026c67c] start_kernel+0xa0/0x2c0
[c02a5ff0] [00003438] 0x3438
Instruction dump:
4bf03c3d 7c7f1b79 418200d4 38800000 4bd97425 7c7d1b78 7fe3fb78 4bd99491
2f9d0000 419e00d8 7c0004ac 813d0004 <0c090000> 4c00012c 3c00f4ff 6000ffff
---[ end trace 31fd0ba7d8756001 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180 seconds..

Which leads me to think BCSR is irrelevant for my board. What is BCSR?

Here's the current Device Tree:

/dts-v1/;

/ {
  model =3D "HPXRED";
  compatible =3D "hpxred";
  #address-cells =3D <1>;
  #size-cells =3D <1>;

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

    PowerPC,8272@0 {
      device_type =3D "cpu";
      reg =3D <0x0>;
      d-cache-line-size =3D <32>;
      i-cache-line-size =3D <32>;
      d-cache-size =3D <16384>;
      i-cache-size =3D <16384>;
      timebase-frequency =3D <0>;
      bus-frequency =3D <0>;
      clock-frequency =3D <0>;
    };
  };

  memory {
    device_type =3D "memory";
    reg =3D <0x0 0x0>;
  };

  soc@f0000000 {
    #address-cells =3D <1>;
    #size-cells =3D <1>;
    device_type =3D "soc";
    compatible =3D "fsl,mpc8272", "fsl,pq2-soc";
    ranges =3D <0x0 0xf0000000 0x53000>;

    // Temporary -- will go away once kernel uses ranges for get_immrbase()=
.
    reg =3D <0xf0000000 0x53000>;

    cpm@119c0 {
      #address-cells =3D <1>;
      #size-cells =3D <1>;
      #interrupt-cells =3D <2>;
      compatible =3D "fsl,mpc8272-cpm", "fsl,cpm2";
      reg =3D <0x119c0 0x30>;
      ranges;

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

        data@0 {
          compatible =3D "fsl,cpm-muram-data";
          reg =3D <0x0 0x2000 0x9800 0x800>;
        };
      };

      brg@119f0 {
        compatible =3D "fsl,mpc8272-brg",
                     "fsl,cpm2-brg",
                     "fsl,cpm-brg";
        reg =3D <0x119f0 0x10 0x115f0 0x10>;
      };

      serial@11a00 {
        device_type =3D "serial";
        compatible =3D "fsl,mpc8272-scc-uart",
                     "fsl,cpm2-scc-uart";
        reg =3D <0x11a00 0x20 0x8000 0x100>;
        interrupts =3D <40 8>;
        interrupt-parent =3D <&PIC>;
        fsl,cpm-brg =3D <1>;
        fsl,cpm-command =3D <0x800000>;
      };

  };

    PIC: interrupt-controller@10c00 {
      #interrupt-cells =3D <2>;
      interrupt-controller;
      reg =3D <0x10c00 0x80>;
      compatible =3D "fsl,mpc8272-pic", "fsl,cpm2-pic";
    };

  };

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



For BCSR, I tried adding the following immediately below the 'memory'
node, just as in mpc8272ads.dts:

  localbus@f0010100 {
    compatible =3D "fsl,mpc8272-localbus",
                 "fsl,pq2-localbus";
    #address-cells =3D <2>;
    #size-cells =3D <1>;
    reg =3D <0xf0010100 0x40>;

    ranges =3D <0x0 0x0 0xfe000000 0x2000000
              0x1 0x0 0xf4500000 0x8000
              0x3 0x0 0xf8200000 0x8000>;

    board-control@1,0 {
      reg =3D <0x1 0x0 0x20>;
      compatible =3D "fsl,mpc8272ads-bcsr";
    };
  };


Another possibility might be that I have set the following in the kernel-

CONFIG_HZ=3D250

-this is in contrast to the above reported 330Mhz. When I had 2.6.14
working with an old version of u-boot, this was not a problem. Could
it be causing me troubles now?

In the "2.6.14+old u-boot" setup, I had also configured u-boot such
that the memory was set to 64MB, but I told the kernel it was either
32MB or 64MB depending on what was physically available. This was so I
could use the same u-boot for boards with either 32MB or 64MB. Is it
still possible to do this for the new u-boot and kernel 2.6.27?

Re: Device Tree setup for 8272-based board

[Scott Wood]

On Tue, Jan 20, 2009 at 06:23:08PM +1100, Daniel Ng wrote:
> PID hash table entries: 128 (order: 7, 512 bytes)
> time_init: decrementer frequency = 16.500000 MHz
> time_init: processor frequency   = 330.000000 MHz
> clocksource: timebase mult[f26c9b2] shift[22] registered
> clockevent: decrementer mult[439] shift[16] cpu[0]
> Console: colour dummy ü
> 
> -at this point the board just reboots.

Looks like something goes wrong when the real serial driver kicks in.

> I thought it might have been to do with:
> 
> 'No hpxred-bcsr in device tree'
> 
> If I add in a 'BCSR' node to my Device Tree I get the following:

Don't add random nodes unless they correspond to hardware that's actually
there.

> Which leads me to think BCSR is irrelevant for my board. What is BCSR?

Board control and status registers.

> Another possibility might be that I have set the following in the kernel-
> 
> CONFIG_HZ=250
> 
> -this is in contrast to the above reported 330Mhz.

Those are two different things.  CONFIG_HZ is the frequency of timer
interrupts that Linux requests.

> In the "2.6.14+old u-boot" setup, I had also configured u-boot such
> that the memory was set to 64MB, but I told the kernel it was either
> 32MB or 64MB depending on what was physically available. This was so I
> could use the same u-boot for boards with either 32MB or 64MB. Is it
> still possible to do this for the new u-boot and kernel 2.6.27?

Yes, but it would be much better if u-boot could figure this out
dynamically.

-Scott

Re: Device Tree setup for 8272-based board

[Daniel Ng]

Hi Scott,

On Wed, Jan 21, 2009 at 3:41 AM, Scott Wood <scottwood@freescale.com> wrote=
:
> On Tue, Jan 20, 2009 at 06:23:08PM +1100, Daniel Ng wrote:
>> PID hash table entries: 128 (order: 7, 512 bytes)
>> time_init: decrementer frequency =3D 16.500000 MHz
>> time_init: processor frequency   =3D 330.000000 MHz
>> clocksource: timebase mult[f26c9b2] shift[22] registered
>> clockevent: decrementer mult[439] shift[16] cpu[0]
>> Console: colour dummy =FC
>>
>> -at this point the board just reboots.
>
> Looks like something goes wrong when the real serial driver kicks in.

I've managed to enable more debug and see the following boot sequence:

cpm_uart_init_port()
OF: ** translation for device /soc@f0000000/cpm@119c0/serial@11a00 **
OF: bus is default (na=3D1, ns=3D1) on /soc@f0000000/cpm@119c0
OF: translating address: 00011a00
OF: parent bus is default (na=3D1, ns=3D1) on /soc@f0000000
OF: no ranges, 1:1 translation
OF: parent translation for: 00000000
OF: with offset: 11a00
OF: one level translation: 00011a00
OF: parent bus is default (na=3D1, ns=3D1) on /
OF: walking ranges...
OF: default map, cp=3D0, s=3D53000, da=3D11a00
OF: parent translation for: f0000000
OF: with offset: 11a00
OF: one level translation: f0011a00
OF: reached root node
OF: ** translation for device /soc@f0000000/cpm@119c0/serial@11a00 **
OF: bus is default (na=3D1, ns=3D1) on /soc@f0000000/cpm@119c0
OF: translating address: 00008000
OF: parent bus is default (na=3D1, ns=3D1) on /soc@f0000000
OF: no ranges, 1:1 translation
OF: parent translation for: 00000000
OF: with offset: 8000
OF: one level translation: 00008000
OF: parent bus is default (na=3D1, ns=3D1) on /
OF: walking ranges...
OF: default map, cp=3D0, s=3D53000, da=3D8000
OF: parent translation for: f0000000
OF: with offset: 8000
OF: one level translation: f0008000
OF: reached root node
of_irq_map_one: dev=3D/soc@f0000000/cpm@119c0/serial@11a00, index=3D0
 intsize=3D2 intlen=3D2
of_irq_map_raw:
par=3D/soc@f0000000/interrupt-controller@10c00,intspec=3D[0x00000028 0x
00000008...],ointsize=3D2
of_irq_map_raw: ipar=3D/soc@f0000000/interrupt-controller@10c00, size=3D2
 -> addrsize=3D1
 -> got it !
irq: irq_create_mapping(0xc02d1320, 0x28)
irq: -> using host @c02d1320
irq: -> obtained virq 40
cpm2_pic_host_map(40, 0x28)
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
of_get_gpio exited with status -2
cpm_uart_request_port()
CPM uart[=FE

I think the of_get_gpio() error messages are a result of the following
code in cpm_uart_init_port()-

  for (i =3D 0; i < NUM_GPIOS; i++)
    pinfo->gpios[i] =3D of_get_gpio(np, i);

-why is this code here? Is it for processing modem control lines? I
know our board doesn't make use of the modem control lines for
ttyCPM0. Therefore, have I misconfigured something in the Device Tree?

Here's the relevant part of the Device Tree-

    cpm@119c0 {
      #address-cells =3D <1>;
      #size-cells =3D <1>;
      #interrupt-cells =3D <2>;
      compatible =3D "fsl,mpc8272-cpm", "fsl,cpm2";
      reg =3D <0x119c0 0x30>;
      ranges;

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

        data@0 {
          compatible =3D "fsl,cpm-muram-data";
          reg =3D <0x0 0x2000 0x9800 0x800>;
        };
      };

      brg@119f0 {
        compatible =3D "fsl,mpc8272-brg",
                     "fsl,cpm2-brg",
                     "fsl,cpm-brg";
        reg =3D <0x119f0 0x10 0x115f0 0x10>;
      };

      serial@11a00 {
        device_type =3D "serial";
        compatible =3D "fsl,mpc8272-scc-uart",
                     "fsl,cpm2-scc-uart";
        reg =3D <0x11a00 0x20 0x8000 0x100>;
        interrupts =3D <40 8>;
        interrupt-parent =3D <&PIC>;
        fsl,cpm-brg =3D <1>;
        fsl,cpm-command =3D <0x800000>;
      };

  };

    PIC: interrupt-controller@10c00 {
      #interrupt-cells =3D <2>;
      interrupt-controller;
      reg =3D <0x10c00 0x80>;
      compatible =3D "fsl,mpc8272-pic", "fsl,cpm2-pic";
    };


Would you please explain what the following lines mean, so I can use
some more appropriate values for my particular board?-

1) In the serial@11a00 node-

a) reg =3D <0x11a00 0x20 0x8000 0x100>;
b) interrupts =3D <40 8>;
c) fsl,cpm-brg =3D <1>;
d) fsl,cpm-command =3D <0x800000>;


2) In the brg@119f0 node-
reg =3D <0x119f0 0x10 0x115f0 0x10>;


3) In the PIC: interrupt-controller@10c00 node-
reg =3D <0x10c00 0x80>;


I have read the relevant documentation under Documentation/powerpc and
Documentation/powerpc/dts-bindings, but these do not seem to go into
enough detail eg.
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt says the
following about the reg property-

- reg : There may be an arbitrary number of reg resources; BRG
  numbers are assigned to these in order.

-> does this mean that each number represents a BRG register? So there
can be a maximum of 1+8=3D9 reg values, since there are 8 BRG registers?

As for Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt, there
is no explanation at all for what the 'reg', 'interrupts', 'brg' and
'command' values mean... Am I missing something obvious?

Similarly for Documentation/powerpc/dts-bindings/fsl/cpm_qe/pic.txt,
there is no explanation of the 'reg' value. Also, it mentions a
'second interrupt cell' but I only see one in the example it gives.
Here is what it says-

* Interrupt Controllers

Currently defined compatibles:
- fsl,cpm1-pic
  - only one interrupt cell
- fsl,pq1-pic
- fsl,cpm2-pic
  - second interrupt cell is level/sense:
    - 2 is falling edge
    - 8 is active low

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


Does the level/sense refer to ALL interrupts?

Cheers,
Daniel

Re: Device Tree setup for 8272-based board

[Scott Wood]

On Wed, Jan 21, 2009 at 06:37:32PM +1100, Daniel Ng wrote:
> I think the of_get_gpio() error messages are a result of the following
> code in cpm_uart_init_port()-
> 
>   for (i = 0; i < NUM_GPIOS; i++)
>     pinfo->gpios[i] = of_get_gpio(np, i);
> 
> -why is this code here? Is it for processing modem control lines?

Yes.

> I know our board doesn't make use of the modem control lines for
> ttyCPM0. Therefore, have I misconfigured something in the Device Tree?

No, those are just not-found errors from the code that is checking the
device tree to see if the control lines are there or not.  It's harmless.

>       brg@119f0 {
>         compatible = "fsl,mpc8272-brg",
>                      "fsl,cpm2-brg",
>                      "fsl,cpm-brg";
>         reg = <0x119f0 0x10 0x115f0 0x10>;
>       };

Is clock-frequency getting filled in?

Note that there's another thread about this exact issue;
see "[MPC8272ADS]Cannot start my Linux Kernel".

> Would you please explain what the following lines mean, so I can use
> some more appropriate values for my particular board?-
> 
> 1) In the serial@11a00 node-
> 
> a) reg = <0x11a00 0x20 0x8000 0x100>;

IMMR offset and length of the SCC1 registers, followed by offset and
length of the parameter RAM registers.

> b) interrupts = <40 8>;

Interrupt number, followed by level/sense information (see
dts-bindings/fsl/cpm_qe/cpm/pic.txt).

> c) fsl,cpm-brg = <1>;

BRG number that this serial port uses.

> d) fsl,cpm-command = <0x800000>;

Value to put in the CPM command register for SCC1.

> 2) In the brg@119f0 node-
> reg = <0x119f0 0x10 0x115f0 0x10>;

Offset and length of two blocks of BRG registers.

> 3) In the PIC: interrupt-controller@10c00 node-
> reg = <0x10c00 0x80>;

Offset and length of PIC registers.

> I have read the relevant documentation under Documentation/powerpc and
> Documentation/powerpc/dts-bindings, but these do not seem to go into
> enough detail eg.
> Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt says the
> following about the reg property-
> 
> - reg : There may be an arbitrary number of reg resources; BRG
>   numbers are assigned to these in order.
> 
> -> does this mean that each number represents a BRG register? So there
> can be a maximum of 1+8=9 reg values, since there are 8 BRG registers?

No, there can be multiple BRGs per register block.

> As for Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt, there
> is no explanation at all for what the 'reg', 'interrupts', 'brg' and
> 'command' values mean... Am I missing something obvious?

brg and command are defined in dts-bindings/fsl/cpm_qe/cpm.txt.  reg and
interrupts are standard properties that are defined in
Documentation/powerpc/booting-without-of.txt, as well as in the ePAPR
document.

The device-specific bindings are only meant to explain things that are
specific to that device, not things that are common to all device trees.

> Similarly for Documentation/powerpc/dts-bindings/fsl/cpm_qe/pic.txt,
> there is no explanation of the 'reg' value. Also, it mentions a
> 'second interrupt cell' but I only see one in the example it gives.
> Here is what it says-

The example is of the interrupt controller node, not of an interrupt
underneath it.  There are no interrupt cells in that node, but
#interrupt-cells *is* 2.

> Does the level/sense refer to ALL interrupts?

I don't follow.  Interrupt specifiers have the second cell if, and only
if, the interrupt controller has #interrupt-cells = <2>.  For PQ2, that
is the case.

-Scott

Re: Device Tree setup for 8272-based board

[Daniel Ng]

On Thu, Jan 22, 2009 at 4:52 AM, Scott Wood <scottwood@freescale.com> wrote:
>> 3) In the PIC: interrupt-controller@10c00 node-
>> reg = <0x10c00 0x80>;
>
> Offset and length of PIC registers.

Thanks Scott. What is the meaning of the Ethernet reg field?:

reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;

Is it-

0x11300-> GFMR1 ie. the GFMR for FCC1?
0x20-> GFMR1 Fields are a total of 32 bits?
0x8400-> initial value of bits 0-15 of GFMR1?
0x100-> initial value of bits 16-31 of GFMR1?
0x11390-> GFEMR1?
0x1-> length of GFEMR1 is 1 bit in size?? (this doesn't make sense
because it's a 3-bit field)
Where would we specify the initial value of GFEMR1?

Cheers,
Daniel

Re: Device Tree setup for 8272-based board

[Scott Wood]

On Thu, Jan 22, 2009 at 06:47:01PM +1100, Daniel Ng wrote:
> Thanks Scott. What is the meaning of the Ethernet reg field?:
> 
> reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
> 
> Is it-
> 
> 0x11300-> GFMR1 ie. the GFMR for FCC1?
> 0x20-> GFMR1 Fields are a total of 32 bits?
> 0x8400-> initial value of bits 0-15 of GFMR1?
> 0x100-> initial value of bits 16-31 of GFMR1?
> 0x11390-> GFEMR1?
> 0x1-> length of GFEMR1 is 1 bit in size?? (this doesn't make sense
> because it's a 3-bit field)
> Where would we specify the initial value of GFEMR1?

No, it's 3 pairs of offset/length (reg is *always* a list of
address/size pairs, with the number of cells per address or size
component depending on #address-cells/#size-cells in the parent node). 
Length is in bytes, not bits.

The first is the FCC register block, the second is the parameter RAM, and
the third is GFEMR.

There are no "initial values" in the device tree -- it describes what the
hardware is, not how to program it.  fsl,cpm-command may seem like the
latter, but it describes how a specific device is identified to the CPM
core.

-Scott

Re: Device Tree setup for 8272-based board

[Daniel Ng]

Scott Wood <scottwood <at> freescale.com> writes:
> Yes, if u-boot is providing junk, then you'll probably want to hack up 
> the wrapper to ignore it.  Or just upgrade u-boot to one that works. 
> 

Thanks for your advice Scott. Looks like upgrading u-boot will be the easiest 
way forward.

Re: Device Tree setup for 8272-based board

[Scott Wood]

Daniel Ng wrote:
> Scott Wood <scottwood <at> freescale.com> writes:
>> cuboot-824x is for 8240, 8245, and similar chips.  You want cuboot-pq2.
> 
> Hi Scott et al,
> 
> I seem to get further with the cuboot-824x file- with the cuboot-pq2 file 

Nonetheless, cuboot-pq2 is the correct one.

> the boot sequence doesn't even reach the 'zImage starting' stage. The machine 
> reboots just before it should be printing out 'zImage starting'. 

What does it print before it reboots?  Try disabling the PCI and 
localbus setup.

> Is there a way I can get more detailed debug to see what's happening?

printf(). :-)

> Do settings from bd_info struct override the settings from the DTS file?

Yes.

> Also, a lot of the settings passed from u-boot in our 2.6.14 environment are 
> plain wrong eg. wrong memory, wrong processor speed. In this case, the correct 
> settings are set elsewhere (for memory, it is a kernel parameter ie. mem=32M, 
> and the processor speed is set in the 2.6.14 'make menuconfig'). Therefore, 
> the machine still boots into Linux correctly. For 2.6.27, would these 
> incorrect settings be causing my problems?

Yes, if u-boot is providing junk, then you'll probably want to hack up 
the wrapper to ignore it.  Or just upgrade u-boot to one that works. :-)

-Scott

Re: Device Tree setup for 8272-based board

[Daniel Ng]

Scott Wood <scottwood <at> freescale.com> writes:
> cuboot-824x is for 8240, 8245, and similar chips.  You want cuboot-pq2.

Hi Scott et al,

I seem to get further with the cuboot-824x file- with the cuboot-pq2 file the 
boot sequence doesn't even reach the 'zImage starting' stage. The machine 
reboots just before it should be printing out 'zImage starting'. 

Is there a way I can get more detailed debug to see what's happening?

Do settings from bd_info struct override the settings from the DTS file?

Also, a lot of the settings passed from u-boot in our 2.6.14 environment are 
plain wrong eg. wrong memory, wrong processor speed. In this case, the correct 
settings are set elsewhere (for memory, it is a kernel parameter ie. mem=32M, 
and the processor speed is set in the 2.6.14 'make menuconfig'). Therefore, 
the machine still boots into Linux correctly. For 2.6.27, would these 
incorrect settings be causing my problems?

Daniel

Re: Device Tree setup for 8272-based board

[Scott Wood]

Daniel Ng wrote:
> Thanks for your helpful responses Scott and Ming Qian. Now, from reading the 
> docco can you please verify my understanding is correct?- 
> 
> First, I need a basic DTS file which will give me a basic Device Tree. The 
> cuboot*.c file takes care of adding other parameters to the Device Tree passed 
> from u-boot via the old bd_info struct. 
> 
> Is this correct? 

Yes.

> If so, would it be possible to do away with the DTS file 
> altogether?

How, other than by encoding all the information about the board in code 
rather than data, which would be a step backwards?

> On the other hand, would it be possible to do away with the 
> cuboot*.c file by providing a complete DTS file?

Yes, though that eliminates the ability to dynamically set certain 
parameters from the firmware.  Better is to use an up-to-date u-boot, 
and have u-boot fill in the dynamic fields (MAC address, clocks, command 
line, etc) directly.

-Scott

Re: Device Tree setup for 8272-based board

[Daniel Ng]

Scott Wood <scottwood <at> freescale.com> writes:

> The cuboot file defines things like TARGET_CPM2 or TARGET_824x, which 
> influences the compilation of the bd_t struct.  It's messy, which is why 
> we use device trees now. 
> 


Thanks for your helpful responses Scott and Ming Qian. Now, from reading the 
docco can you please verify my understanding is correct?- 

First, I need a basic DTS file which will give me a basic Device Tree. The 
cuboot*.c file takes care of adding other parameters to the Device Tree passed 
from u-boot via the old bd_info struct. 

Is this correct? If so, would it be possible to do away with the DTS file 
altogether? On the other hand, would it be possible to do away with the 
cuboot*.c file by providing a complete DTS file?

Cheers,
Daniel

Re: Device Tree setup for 8272-based board

[Scott Wood]

Daniel Ng wrote:
> We are migrating our PowerPC 8272-based board from 2.6.14 to 2.6.27.
> 
> One of the big changes is the need for a Device Tree for bootup.
> 
> So far, my bootup looks like the below (using u-boot).
> 
> I am just using arch/powerpc/boot/cuboot-824x.c 

cuboot-824x is for 8240, 8245, and similar chips.  You want cuboot-pq2.

> When I change the settings in mpc8272ads.dts and do a fresh recompile, the 
> settings do not change. However, if I use another cuboot*.c file, I get a 
> different set of printed settings eg. 2 ethernet ports instead of 1. This is 
> fine, but I don't see where in the cuboot*.c file these settings are 
> specified. Can someone suggest where these might be?

The cuboot file defines things like TARGET_CPM2 or TARGET_824x, which 
influences the compilation of the bd_t struct.  It's messy, which is why 
we use device trees now. :-)

-Scott

Re: Device Tree setup for 8272-based board

[mingqian]

SGkgRGFuaWVsLA0KICAgIEkgdGhpbmsgeW91J2QgYmV0dGVyIHJlYWQgRG9jdW1lbnRhdGlvbi9w
b3dlcnBjL2Jvb3R3cmFwcGVyLnR4dCwgYW5kIGNob29zZSB0aGUgYXBwcm9wcmlhdGUgaW1hZ2Ug
dGFyZ2V0Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KRnJvbTogIkRhbmllbCBOZyIgPGRhbmllbF9uZzExQGx5Y29zLmNvbT4NClNlbnQ6IEZy
aWRheSwgRGVjZW1iZXIgMTksIDIwMDggMjozMSBQTQ0KVG86IDxsaW51eHBwYy1lbWJlZGRlZEBv
emxhYnMub3JnPg0KU3ViamVjdDogRGV2aWNlIFRyZWUgc2V0dXAgZm9yIDgyNzItYmFzZWQgYm9h
cmQNCg0KPiBIaSwNCj4gDQo+IFdlIGFyZSBtaWdyYXRpbmcgb3VyIFBvd2VyUEMgODI3Mi1iYXNl
ZCBib2FyZCBmcm9tIDIuNi4xNCB0byAyLjYuMjcuDQo+IA0KPiBPbmUgb2YgdGhlIGJpZyBjaGFu
Z2VzIGlzIHRoZSBuZWVkIGZvciBhIERldmljZSBUcmVlIGZvciBib290dXAuDQo+IA0KPiBTbyBm
YXIsIG15IGJvb3R1cCBsb29rcyBsaWtlIHRoZSBiZWxvdyAodXNpbmcgdS1ib290KS4NCj4gDQo+
IEkgYW0ganVzdCB1c2luZyBhcmNoL3Bvd2VycGMvYm9vdC9jdWJvb3QtODI0eC5jIA0KPiBhbmQg
L2FyY2gvcG93ZXJwYy9ib290L2R0cy9tcGM4MjcyYWRzLmR0cyBmb3Igbm93LiBUaGVyZWZvcmUs
IGFsbCB0aGUgc2V0dGluZ3MgDQo+IGFzIHByaW50ZWQgYmVsb3cgYXJlIHdyb25nIGllLiBNZW1v
cnksIEVORVQwIG1hYywgQ1BVIGNsb2NrIGZyZXEsIGV0Yy4NCj4gDQo+IFdoZW4gSSBjaGFuZ2Ug
dGhlIHNldHRpbmdzIGluIG1wYzgyNzJhZHMuZHRzIGFuZCBkbyBhIGZyZXNoIHJlY29tcGlsZSwg
dGhlIA0KPiBzZXR0aW5ncyBkbyBub3QgY2hhbmdlLiBIb3dldmVyLCBpZiBJIHVzZSBhbm90aGVy
IGN1Ym9vdCouYyBmaWxlLCBJIGdldCBhIA0KPiBkaWZmZXJlbnQgc2V0IG9mIHByaW50ZWQgc2V0
dGluZ3MgZWcuIDIgZXRoZXJuZXQgcG9ydHMgaW5zdGVhZCBvZiAxLiBUaGlzIGlzIA0KPiBmaW5l
LCBidXQgSSBkb24ndCBzZWUgd2hlcmUgaW4gdGhlIGN1Ym9vdCouYyBmaWxlIHRoZXNlIHNldHRp
bmdzIGFyZSANCj4gc3BlY2lmaWVkLiBDYW4gc29tZW9uZSBzdWdnZXN0IHdoZXJlIHRoZXNlIG1p
Z2h0IGJlPw0KPiANCj4gQ2hlZXJzLA0KPiBEYW5pZWwNCj4gDQo+IA0KPiAjIyBCb290aW5nIGlt
YWdlIGF0IDAwMjAwMDAwIC4uLg0KPiAgIEltYWdlIE5hbWU6ICAgTGludXgtMi42LjI3LW15YnVp
bGQNCj4gICBJbWFnZSBUeXBlOiAgIFBvd2VyUEMgTGludXggS2VybmVsIEltYWdlIChnemlwIGNv
bXByZXNzZWQpDQo+ICAgRGF0YSBTaXplOiAgICAxNDc3MjMzIEJ5dGVzID0gIDEuNCBNQg0KPiAg
IExvYWQgQWRkcmVzczogMDA0MDAwMDANCj4gICBFbnRyeSBQb2ludDogIDAwNDAwNTk0DQo+ICAg
VmVyaWZ5aW5nIENoZWNrc3VtIC4uLiBPSw0KPiAgIFVuY29tcHJlc3NpbmcgS2VybmVsIEltYWdl
IC4uLiBPSw0KPiBNZW1vcnkgPC0gPDB4MCAweDQwMDAwMDA+ICg2NE1CKQ0KPiBFTkVUMDogbG9j
YWwtbWFjLWFkZHJlc3MgPC0gYzA6YTg6MDE6NGI6N2U6MTMNCj4gQ1BVIGNsb2NrLWZyZXF1ZW5j
eSA8LSAweGExNzVjMTAwICgyNzA5TUh6KQ0KPiBDUFUgdGltZWJhc2UtZnJlcXVlbmN5IDwtIDB4
NGVhZDlhMCAoODNNSHopDQo+IENQVSBidXMtZnJlcXVlbmN5IDwtIDB4MTNhYjY2ODAgKDMzME1I
eikNCj4gDQo+IHpJbWFnZSBzdGFydGluZzogbG9hZGVkIGF0IDB4MDA0MDAwMDAgKHNwOiAweDAz
ZjdjOWM4KQ0KPiBBbGxvY2F0aW5nIDB4MzE2ZThjIGJ5dGVzIGZvciBrZXJuZWwgLi4uDQo+IGd1
bnppcHBpbmcgKDB4MDAwMDAwMDAgPC0gMHgwMDQwYzAwMDoweDAwNzEzNjdjKS4uLmRvbmUgMHgy
ZjQxYTAgYnl0ZXMNCj4gDQo+IExpbnV4L1Bvd2VyUEMgbG9hZDoNCj4gRmluYWxpemluZyBkZXZp
Y2UgdHJlZS4uLiBmbGF0IHRyZWUgYXQgMHg0MGFjZDgNCj4gDQo+ICh0aGVyZSBpcyBubyBtb3Jl
IG91dHB1dCBhZnRlciB0aGlzKQ0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMaW51eHBwYy1lbWJlZGRlZCBtYWlsaW5nIGxp
c3QNCj4gTGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZw0KPiBodHRwczovL296bGFicy5vcmcv
bWFpbG1hbi9saXN0aW5mby9saW51eHBwYy1lbWJlZGRlZA0KPiA=

Device Tree setup for 8272-based board

[Daniel Ng]

Hi,

We are migrating our PowerPC 8272-based board from 2.6.14 to 2.6.27.

One of the big changes is the need for a Device Tree for bootup.

So far, my bootup looks like the below (using u-boot).

I am just using arch/powerpc/boot/cuboot-824x.c 
and /arch/powerpc/boot/dts/mpc8272ads.dts for now. Therefore, all the settings 
as printed below are wrong ie. Memory, ENET0 mac, CPU clock freq, etc.

When I change the settings in mpc8272ads.dts and do a fresh recompile, the 
settings do not change. However, if I use another cuboot*.c file, I get a 
different set of printed settings eg. 2 ethernet ports instead of 1. This is 
fine, but I don't see where in the cuboot*.c file these settings are 
specified. Can someone suggest where these might be?

Cheers,
Daniel


## Booting image at 00200000 ...
   Image Name:   Linux-2.6.27-mybuild
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1477233 Bytes =  1.4 MB
   Load Address: 00400000
   Entry Point:  00400594
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Memory <- <0x0 0x4000000> (64MB)
ENET0: local-mac-address <- c0:a8:01:4b:7e:13
CPU clock-frequency <- 0xa175c100 (2709MHz)
CPU timebase-frequency <- 0x4ead9a0 (83MHz)
CPU bus-frequency <- 0x13ab6680 (330MHz)

zImage starting: loaded at 0x00400000 (sp: 0x03f7c9c8)
Allocating 0x316e8c bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x0071367c)...done 0x2f41a0 bytes

Linux/PowerPC load:
Finalizing device tree... flat tree at 0x40acd8

(there is no more output after this)