simple MPC5200B system

DISCUSSION André Schwarz 5 participants 15 messages Mar 16, 2008 – Mar 20, 2008

Share & tools

André Schwarz

author

2008-03-16 19:32 UTC #0 lore raw

All,

I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+=20 ... maybe someone could give me some hints.
Up to now the systems have been running on 2.6.19 without any problems.

This is what I've done so far :

- get a recent system with 2.6.19 running and keep the toolchain (gcc=20 4.0) including RFS uImage.
- latest bootloader (u-boot 1.3.2) is running fine with dtb support.
- Kernel and RFS images are available via bootp/tftp
- device tree blob seems ok, i.e. u-boot can display the blob and fill=20 in all clocks correctly.
- Kernel gets called with Kernel, RFS and dtb on suitable adresses=20 (0x100000, 0x600000, 0x5F0000).
- nothing more happens. It looks like the console isn't working properly=20
- maybe worse ...

We're using the latest git version from Wolfgang Denk.

The kernel has been build using the "MPC5200 simple" setup. I've added=20 our board identifier "mv,mvbluecougar" to the list of supported boards=20 in the "mpc52xx_simple.c" file. This identifier is used in the dtb as=20 well of course. This should be enough along with a valid device tree=20 blob, isn't it ? Did I miss anything already ?

As far as I did understand by reading the docs it should be possible=20 running a general MPC52xx kernel with a custom dtb ? Is this correct ?

The dts file has already been reduced to a minimum, i.e. only the cpu,=20 pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm,=20 pci, ata or "advanced" features like mtd partitions. All I want to get=20 working is the serial console on "/dev/ttyPSC0".

Are there any hidden stumbling blocks ?

Sorry for the "simple" questions but obviously there are many questions=20 coming up during move from "ppc" to "powerpc".

Any help is appreciated.

regards,
Andr=E9 Schwarz
Matrix Vision GmbH

MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Grant Likely

2008-03-16 20:01 UTC #1 lore raw

Quoted 8 lines · On Sun, Mar 16, 2008 at 1:15 PM, Andr=E9 Schwarz…

All,
I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+ ... maybe someone could give me some hints.
Up to now the systems have been running on 2.6.19 without any problems.
This is what I've done so far :

Quoted 10 lines

- get a recent system with 2.6.19 running and keep the toolchain (gcc 4.0) including RFS uImage.
- latest bootloader (u-boot 1.3.2) is running fine with dtb support.
- Kernel and RFS images are available via bootp/tftp
- device tree blob seems ok, i.e. u-boot can display the blob and fill in all clocks correctly.
- Kernel gets called with Kernel, RFS and dtb on suitable adresses (0x100000, 0x600000, 0x5F0000).
- nothing more happens. It looks like the console isn't working properly
- maybe worse ...

Can you either halt the processor or reset the board and access memory after this point? You should see if you can access __log_buf (Look in System.map for the address and subtract 0xc0000000 to get the physical
address). __log_buf should give you clues about how far booting
progresses.

Quoted 5 lines

The kernel has been build using the "MPC5200 simple" setup. I've added our board identifier "mv,mvbluecougar" to the list of supported boards in the "mpc52xx_simple.c" file. This identifier is used in the dtb as well of course. This should be enough along with a valid device tree blob, isn't it ? Did I miss anything already ?

Yes, this should be enough (on a side note; it should probably be "matrix-vision,bluecougar" unless of''mv' is your company's stock ticker symbol).

Quoted 3 lines

As far as I did understand by reading the docs it should be possible running a general MPC52xx kernel with a custom dtb ? Is this correct ?

That is correct.

Quoted 4 lines

The dts file has already been reduced to a minimum, i.e. only the cpu, pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm, pci, ata or "advanced" features like mtd partitions. All I want to get working is the serial console on "/dev/ttyPSC0".

Cheers,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

André Schwarz

author

2008-03-17 09:35 UTC #2 lore raw

Quoted 23 lines · Grant Likely

Quoted 8 lines · André Schwarz
All,
I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+ ... maybe someone could give me some hints.
Up to now the systems have been running on 2.6.19 without any problems.
This is what I've done so far :
Quoted 11 lines
- get a recent system with 2.6.19 running and keep the toolchain (gcc 4.0) including RFS uImage.
- latest bootloader (u-boot 1.3.2) is running fine with dtb support.
- Kernel and RFS images are available via bootp/tftp
- device tree blob seems ok, i.e. u-boot can display the blob and fill in all clocks correctly.
- Kernel gets called with Kernel, RFS and dtb on suitable adresses (0x100000, 0x600000, 0x5F0000).
- nothing more happens. It looks like the console isn't working properly
- maybe worse ...

Quoted 7 lines

Can you either halt the processor or reset the board and access memory after this point? You should see if you can access __log_buf (Look in System.map for the address and subtract 0xc0000000 to get the physical
address). __log_buf should give you clues about how far booting
progresses.

As soon as my abatron debugger is back I'll give it a try - currently it's out for an update ... Are there any restrictions for the memory locations of the kernel, initrd and dtb images ?

Thanks for the help. I'll post the __log_buf tomorrow ... propably.

Quoted 19 lines

Quoted 6 lines
The kernel has been build using the "MPC5200 simple" setup. I've added our board identifier "mv,mvbluecougar" to the list of supported boards in the "mpc52xx_simple.c" file. This identifier is used in the dtb as well of course. This should be enough along with a valid device tree blob, isn't it ? Did I miss anything already ?
Yes, this should be enough (on a side note; it should probably be "matrix-vision,bluecougar" unless of''mv' is your company's stock ticker symbol).
Quoted 3 lines
As far as I did understand by reading the docs it should be possible running a general MPC52xx kernel with a custom dtb ? Is this correct ?
That is correct.

Quoted 10 lines

Quoted 5 lines
The dts file has already been reduced to a minimum, i.e. only the cpu, pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm, pci, ata or "advanced" features like mtd partitions. All I want to get working is the serial console on "/dev/ttyPSC0".
Cheers,
g.

regards,
André

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Andre Schwarz

author

2008-03-18 08:49 UTC #3 lore raw

In reply to Grant Likely

Grant,

I've pulled the latest git and built a mpc5200_simple system with a minimal dts. There's not a single char put on the console ....

Quoted 23 lines · Grant Likely

Quoted 8 lines · André Schwarz
All,
I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+ ... maybe someone could give me some hints.
Up to now the systems have been running on 2.6.19 without any problems.
This is what I've done so far :
Quoted 11 lines
- get a recent system with 2.6.19 running and keep the toolchain (gcc 4.0) including RFS uImage.
- latest bootloader (u-boot 1.3.2) is running fine with dtb support.
- Kernel and RFS images are available via bootp/tftp
- device tree blob seems ok, i.e. u-boot can display the blob and fill in all clocks correctly.
- Kernel gets called with Kernel, RFS and dtb on suitable adresses (0x100000, 0x600000, 0x5F0000).
- nothing more happens. It looks like the console isn't working properly
- maybe worse ...

Quoted 7 lines

Can you either halt the processor or reset the board and access memory after this point? You should see if you can access __log_buf (Look in System.map for the address and subtract 0xc0000000 to get the physical
address). __log_buf should give you clues about how far booting
progresses.

(c033d4b4 b __log_buf) yields all zeroes - nothing logged at all.

Examining the CPU state with the bdi shows :

Target CPU : MPC8280/8220/5200 (Zeppo)
Target state : debug mode
Debug entry cause : COP halt

   Current PC        : 0xc000552c
   Current CR        : 0x48000042
   Current MSR       : 0x00009032
   Current LR        : 0xc00166c0

The program counter shows the adress of "irq_set_virq_count" which has a BUG() macro. Looks like this one evaluates to true.

What do you think ?

Quoted 19 lines

Quoted 6 lines
The kernel has been build using the "MPC5200 simple" setup. I've added our board identifier "mv,mvbluecougar" to the list of supported boards in the "mpc52xx_simple.c" file. This identifier is used in the dtb as well of course. This should be enough along with a valid device tree blob, isn't it ? Did I miss anything already ?
Yes, this should be enough (on a side note; it should probably be "matrix-vision,bluecougar" unless of''mv' is your company's stock ticker symbol).
Quoted 3 lines
As far as I did understand by reading the docs it should be possible running a general MPC52xx kernel with a custom dtb ? Is this correct ?
That is correct.

Quoted 10 lines

Quoted 5 lines
The dts file has already been reduced to a minimum, i.e. only the cpu, pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm, pci, ata or "advanced" features like mtd partitions. All I want to get working is the serial console on "/dev/ttyPSC0".
Cheers,
g.

regards,
Andre

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Andre Schwarz

author

2008-03-18 10:34 UTC #4 lore raw

Grant,

sorry for having troubled you. Looks like the build system has been in an invalid state...

After doing a git-pull and "make distclean" + "make mpc5200_defconfig" the system is finally up and running.

Using mpc5200-simple-platform machine description
Linux version 2.6.25-rc6-00978-g275c005-dirty (root@nova) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #9 Tue Mar 18 11:25:07 CET 2008
Found initrd at 0xc397a000:0xc3c00000
arch/powerpc/platforms/52xx/mpc52xx_common.c: Error mapping XLB in mpc52xx_setup_cpu(). Expect some abnormal behavior
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
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: root=/dev/ram ro rootfstype=squashfs ip=192.168.65.57::192.168.65.15:255.255.255.0 console=ttyPSC0,115200N8 e1000.TxDescriptors=1500 e1000.SmartPowerDownEnable=1 MPC52xx PIC is up and running!
PID hash table entries: 256 (order: 8, 1024 bytes)
clocksource: timebase mult[79364d9] shift[22] registered
console [ttyPSC0] enabled
....

regards,
Andre

Quoted 87 lines · Andre Schwarz

Grant,
I've pulled the latest git and built a mpc5200_simple system with a minimal dts. There's not a single char put on the console ....
Quoted 23 lines · Grant Likely
Quoted 8 lines · André Schwarz
All,
I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+ ... maybe someone could give me some hints.
Up to now the systems have been running on 2.6.19 without any problems.
This is what I've done so far :
Quoted 11 lines
- get a recent system with 2.6.19 running and keep the toolchain (gcc 4.0) including RFS uImage.
- latest bootloader (u-boot 1.3.2) is running fine with dtb support.
- Kernel and RFS images are available via bootp/tftp
- device tree blob seems ok, i.e. u-boot can display the blob and fill in all clocks correctly.
- Kernel gets called with Kernel, RFS and dtb on suitable adresses (0x100000, 0x600000, 0x5F0000).
- nothing more happens. It looks like the console isn't working properly
- maybe worse ...
Quoted 7 lines
Can you either halt the processor or reset the board and access memory after this point? You should see if you can access __log_buf (Look in System.map for the address and subtract 0xc0000000 to get the physical
address). __log_buf should give you clues about how far booting
progresses.
(c033d4b4 b __log_buf) yields all zeroes - nothing logged at all.
Examining the CPU state with the bdi shows :
    Target CPU        : MPC8280/8220/5200 (Zeppo)
    Target state      : debug mode
    Debug entry cause : COP halt
    Current PC        : 0xc000552c
    Current CR        : 0x48000042
    Current MSR       : 0x00009032
    Current LR        : 0xc00166c0
The program counter shows the adress of "irq_set_virq_count" which has a BUG() macro. Looks like this one evaluates to true.
What do you think ?
Quoted 19 lines
Quoted 6 lines
The kernel has been build using the "MPC5200 simple" setup. I've added our board identifier "mv,mvbluecougar" to the list of supported boards in the "mpc52xx_simple.c" file. This identifier is used in the dtb as well of course. This should be enough along with a valid device tree blob, isn't it ? Did I miss anything already ?
Yes, this should be enough (on a side note; it should probably be "matrix-vision,bluecougar" unless of''mv' is your company's stock ticker symbol).
Quoted 3 lines
As far as I did understand by reading the docs it should be possible running a general MPC52xx kernel with a custom dtb ? Is this correct ?
That is correct.
Quoted 10 lines
Quoted 5 lines
The dts file has already been reduced to a minimum, i.e. only the cpu, pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm, pci, ata or "advanced" features like mtd partitions. All I want to get working is the serial console on "/dev/ttyPSC0".
Cheers,
g.
regards,
Andre

Quoted 7 lines

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
------------------------------------------------------------------------
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Grant Likely

2008-03-18 14:31 UTC #5 lore raw

Quoted 8 lines · Andre Schwarz

Grant,
sorry for having troubled you. Looks like the build system has been in an
invalid state...
After doing a git-pull and "make distclean" + "make mpc5200_defconfig" the
system is finally up and running.

Heh; I hate it when that happens. :-)

Congratulations.

Signature · 2 lines

Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Andre Schwarz

author

2008-03-18 15:14 UTC #6 lore raw

Quoted 12 lines · Grant Likely

Quoted 8 lines · Andre Schwarz
Grant,
sorry for having troubled you. Looks like the build system has been in an
invalid state...
After doing a git-pull and "make distclean" + "make mpc5200_defconfig" the
system is finally up and running.

Quoted 8 lines

Heh; I hate it when that happens. :-)
Congratulations.
g.

Grant,

this leads to the next questions ... :-)

I've read some discussions about the "interrupt-map" attribute of the pci node. I tried to follow Ben and David in their explanations - obviously I didn't really get it. Looks like there are a lot of people outside who need some enlightenment ... including me, of course.

Maybe you can clarify this ?

Taken from motionpro.dts ...

interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot

                                c000 0 0 2 &mpc5200_pic 1 1 3
                                c000 0 0 3 &mpc5200_pic 1 2 3
                                c000 0 0 4 &mpc5200_pic 1 3 3

                                c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
                                c800 0 0 2 &mpc5200_pic 1 2 3
                                c800 0 0 3 &mpc5200_pic 1 3 3
                                c800 0 0 4 &mpc5200_pic 0 0 3>;

First parameter seems to be the slot number, i.e. IDSEL line of the PCI device. How is this value coded ? Are these the bits 15..11 of the configuration address ?

2nd + 3rd paramter : no clue ! can you explain ?

4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only INT_A. Do we need 4 entries in any case ?

5th : ok - parent pic

6th ... 8th : IRQ representation of the parent pic, which gives :

6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins
7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have
number 1..3 inside MAIN level.
8th : should be 3 = "level low" which is default for PCI.

regards,
Andre

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Grant Likely

2008-03-18 16:21 UTC #7 lore raw

Quoted 10 lines · Andre Schwarz

I've read some discussions about the "interrupt-map" attribute of the pci
node. I tried to follow Ben and David in their explanations - obviously I didn't really get it.
Looks like there are a lot of people outside who need some enlightenment
... including me, of course.
Maybe you can clarify this ?
Taken from motionpro.dts ...

First, you also need to look at interrupt-map-mask to interpret these values; from motionpro.dts:

interrupt-map-mask = <f800 0 0 7>;

which is applied to the unit interrupt specifier to figure out how to map onto the interrupt controller. The /size/ of this field is obtained by adding #address-cells with #interrupt-cells. (3+1=4).

'f8' refers to the upper 5 bits of the interrupt identifier which is a number from 0-31 which relates to the IDSEL line as you guessed. The '7' covers the lower 3 bits of the interrupt specifier which can be 1, 2, 3 or 4.

The 120 bits in the middle are irrelevant, so interrupt-map-mask leaves them as zeros.

Quoted 11 lines

     interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
                                  c000 0 0 2 &mpc5200_pic 1 1 3
                                  c000 0 0 3 &mpc5200_pic 1 2 3
                                  c000 0 0 4 &mpc5200_pic 1 3 3

                                  c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
                                  c800 0 0 2 &mpc5200_pic 1 2 3
                                  c800 0 0 3 &mpc5200_pic 1 3 3
                                  c800 0 0 4 &mpc5200_pic 0 0 3>;

Quoted 4 lines

First parameter seems to be the slot number, i.e. IDSEL line of the PCI
device.
How is this value coded ? Are these the bits 15..11 of the configuration
address ?

I don't remember how this is encoded. On the lite5200, idsel is wired to d0 and d1 for slots 1 and 2 respectively, yet these values suggest slots 24 and 25. I'll need to look at this again later.

Quoted 2 lines

2nd + 3rd paramter : no clue ! can you explain ?

first 3 cells are the unit address and is #address-cells large. Only the first cell contains real data.

Quoted 3 lines

4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only
INT_A. Do we need 4 entries in any case ?

you only need entries for irq lines that are wired up. If your board does not wire up _B, _C and _D, then don't have an entry for them. However, if they are wired up then you should describe them.

Quoted 2 lines

5th : ok - parent pic

Correct.

Quoted 7 lines

6th ... 8th : IRQ representation of the parent pic, which gives :
6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins
7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have
number 1..3 inside MAIN level.
8th : should be 3 = "level low" which is default for PCI.

Correct.

There is also some good information here:
http://playground.sun.com/1275/practice/imap/imap0_9d.pdf

Cheers,
g.

Signature · 2 lines

Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Andre Schwarz

author

2008-03-18 16:44 UTC #8 lore raw

Quoted 24 lines · Grant Likely

Quoted 11 lines · Andre Schwarz
I've read some discussions about the "interrupt-map" attribute of the pci
node. I tried to follow Ben and David in their explanations - obviously I didn't really get it.
Looks like there are a lot of people outside who need some enlightenment
... including me, of course.
Maybe you can clarify this ?
Taken from motionpro.dts ...
First, you also need to look at interrupt-map-mask to interpret these values; from motionpro.dts:
interrupt-map-mask = <f800 0 0 7>;
which is applied to the unit interrupt specifier to figure out how to map onto the interrupt controller. The /size/ of this field is obtained by adding #address-cells with #interrupt-cells. (3+1=4).

Quoted 9 lines

'f8' refers to the upper 5 bits of the interrupt identifier which is a number from 0-31 which relates to the IDSEL line as you guessed. The '7' covers the lower 3 bits of the interrupt specifier which can be 1, 2, 3 or 4.
The 120 bits in the middle are irrelevant, so interrupt-map-mask leaves them as zeros.

ok.

Quoted 17 lines

Quoted 11 lines

     interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
                                  c000 0 0 2 &mpc5200_pic 1 1 3
                                  c000 0 0 3 &mpc5200_pic 1 2 3
                                  c000 0 0 4 &mpc5200_pic 1 3 3

                                  c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
                                  c800 0 0 2 &mpc5200_pic 1 2 3
                                  c800 0 0 3 &mpc5200_pic 1 3 3
                                  c800 0 0 4 &mpc5200_pic 0 0 3>;

Quoted 5 lines

First parameter seems to be the slot number, i.e. IDSEL line of the PCI
device.
How is this value coded ? Are these the bits 15..11 of the configuration
address ?

Quoted 5 lines

I don't remember how this is encoded. On the lite5200, idsel is wired to d0 and d1 for slots 1 and 2 respectively, yet these values suggest slots 24 and 25. I'll need to look at this again later.

"pci info" from u-boot shows both devices (e1000 NIC + FPGA)

      00  0a  4d56  1000  ff00  03    -> bus "0" , slot "0a", "irq 3"
      00  0b  8086  1078  0200  02   -> bus "0" , slot "0b", "irq 2"

IDSEL mapping of MPC5200 is "0b0_1011" for slot 0xb and "0b0_1010" for slot 0xa. Using those 5 bits <<= 3 for the first cell gives "5800" and "5000"

Quoted 7 lines

Quoted 2 lines
2nd + 3rd paramter : no clue ! can you explain ?
first 3 cells are the unit address and is #address-cells large. Only the first cell contains real data.

ok.

Quoted 9 lines

Quoted 3 lines
4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only
INT_A. Do we need 4 entries in any case ?
you only need entries for irq lines that are wired up. If your board does not wire up _B, _C and _D, then don't have an entry for them. However, if they are wired up then you should describe them.

ok. I only have INT_A.

Quoted 14 lines

Quoted 2 lines
5th : ok - parent pic
Correct.
Quoted 7 lines
6th ... 8th : IRQ representation of the parent pic, which gives :
6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins
7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have
number 1..3 inside MAIN level.
8th : should be 3 = "level low" which is default for PCI.

Quoted 9 lines

Correct.
There is also some good information here:
http://playground.sun.com/1275/practice/imap/imap0_9d.pdf
Cheers,
g.

using the following "interrupt-map" give me two working PCI devices with working interrupts ... :-)

interrupt-map = <5800 0 0 1 &mpc5200_pic 1 2 3 // e1000

                            5000 0 0 1 &mpc5200_pic 1 3 3>;// FPGA

Thanks for your explanations !

regards,
Andre

MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Wolfgang Denk

2008-03-20 00:14 UTC #9 lore raw

In reply to Andre Schwarz

Quoted 4 lines · In message <[email protected]> you wrote:

I've pulled the latest git and built a mpc5200_simple system with a minimal dts.
There's not a single char put on the console ....

You did build your device tree with "-b 0", didn't you?

Best regards,

Wolfgang Denk

Signature · 4 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected]
EMACS belongs in <sys/errno.h>: Editor too big!

David Gibson

2008-03-20 00:21 UTC #10 lore raw

Quoted 7 lines · Wolfgang Denk

Quoted 4 lines · In message <[email protected]> you wrote:
I've pulled the latest git and built a mpc5200_simple system with a minimal dts.
There's not a single char put on the console ....
You did build your device tree with "-b 0", didn't you?

Ugh.. I really need to fix dtc to pick the default boot cpu value more sensibly, don't I.

Signature · 4 lines

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

André Schwarz

author

2008-03-20 07:48 UTC #11 lore raw

Quoted 10 lines · David Gibson

Quoted 5 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you wrote:
I've pulled the latest git and built a mpc5200_simple system with a=20 minimal dts.
There's not a single char put on the console ....
You did build your device tree with "-b 0", didn't you?
=20
Ugh.. I really need to fix dtc to pick the default boot cpu value more sensibly, don't I.
=20

I didn't specify "-b 0". This shouldn't be neccessary on a single=20 processor system ! After all it's an option ... "0" should be default.

-->"./dtc -I dts -O dtb -o /mnt/tftpboot/mvbc.dtb -S 8192 dts/mvbc.dts"

The system is running fine (please see discussions with Grant).

regards,
Andr=E9 Schwarz

MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

David Gibson

2008-03-20 08:20 UTC #12 lore raw

Quoted 6 lines · André Schwarz

Quoted 5 lines · David Gibson
Quoted 4 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you wrote:
I've pulled the latest git and built a mpc5200_simple system with a minimal dts.
There's not a single char put on the console ....

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
You did build your device tree with "-b 0", didn't you?
Ugh.. I really need to fix dtc to pick the default boot cpu value more sensibly, don't I.
I didn't specify "-b 0". This shouldn't be neccessary on a single processor system ! After all it's an option ... "0" should be default.

Should, yes. But dtc's pretty new, and a sensible default for -b is one thing that isn't there.

Signature · 4 lines

David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

André Schwarz

author

2008-03-20 09:12 UTC #13 lore raw

Quoted 5 lines · David Gibson

Quoted 4 lines · On Thu, Mar 20, 2008 at 08:48:42AM +0100, Andr=E9 Schwarz wrote:
Quoted 3 lines · David Gibson
Quoted 2 lines · Wolfgang Denk
Quoted 1 line · In message <[email protected]> you wrote:
I've pulled the latest git and built a mpc5200_simple system with a=

=20

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Quoted 2 lines
minimal dts.
There's not a single char put on the console ....
You did build your device tree with "-b 0", didn't you?
Ugh.. I really need to fix dtc to pick the default boot cpu value mor=

Quoted 2 lines

Quoted 2 lines
Quoted 1 line
sensibly, don't I.
I didn't specify "-b 0". This shouldn't be neccessary on a single proc=

essor=20

Quoted 5 lines

Quoted 1 line
system ! After all it's an option ... "0" should be default.
=20
Should, yes. But dtc's pretty new, and a sensible default for -b is one thing that isn't there.
=20

ok - but this has not caused my (solved) problem. dtc is working fine=20 for me :-)

MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Stefan Roese

2008-03-20 09:29 UTC #14 lore raw

In reply to David Gibson

Quoted 10 lines · David Gibson

Quoted 7 lines
Quoted 4 lines
Quoted 1 line
You did build your device tree with "-b 0", didn't you?
Ugh.. I really need to fix dtc to pick the default boot cpu value more sensibly, don't I.
I didn't specify "-b 0". This shouldn't be neccessary on a single processor system ! After all it's an option ... "0" should be default.
Should, yes. But dtc's pretty new, and a sensible default for -b is one thing that isn't there.

ACK. I have run into a problem on the Sequoia (440EPx) lately, where the FPU was not initialized correctly because of the missing "-b 0". Please add this as default.

Best regards,
Stefan