simple MPC5200B system

simple MPC5200B system

[André Schwarz]

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

Re: simple MPC5200B system

[Grant Likely]

On Sun, Mar 16, 2008 at 1:15 PM, Andr=E9 Schwarz
<Andre.Schwarz@matrix-vision.de> wrote:
> 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 :
>
>  - 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.

>  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).

>
>  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.

>  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.

Re: simple MPC5200B system

[André Schwarz]

[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]

Grant Likely wrote:
> On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz
> <Andre.Schwarz@matrix-vision.de> wrote:
>   
>> 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 :
>>
>>  - 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.
>
>   
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.

>>  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).
>
>   
>>  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.
>
>   
>>  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

[-- Attachment #2: Type: text/html, Size: 3550 bytes --]

Re: simple MPC5200B system

[Andre Schwarz]

[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]

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 ....



Grant Likely schrieb:
> On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz
> <Andre.Schwarz@matrix-vision.de> wrote:
>   
>> 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 :
>>
>>  - 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.
>
>   
(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 ?

>>  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).
>
>   
>>  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.
>
>   
>>  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

[-- Attachment #2: Type: text/html, Size: 4324 bytes --]

Re: simple MPC5200B system

[Andre Schwarz]

[-- Attachment #1: Type: text/plain, Size: 4976 bytes --]

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


Andre Schwarz schrieb:
> 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 ....
>
>
>
> Grant Likely schrieb:
>> On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz
>> <Andre.Schwarz@matrix-vision.de> wrote:
>>   
>>> 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 :
>>>
>>>  - 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.
>>
>>   
> (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 ?
>
>>>  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).
>>
>>   
>>>  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.
>>
>>   
>>>  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
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> 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

[-- Attachment #2: Type: text/html, Size: 6666 bytes --]

Re: simple MPC5200B system

[Grant Likely]

On Tue, Mar 18, 2008 at 4:34 AM, Andre Schwarz
<andre.schwarz@matrix-vision.de> wrote:
>
>  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.

g.


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

Re: simple MPC5200B system

[Andre Schwarz]

[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]

Grant Likely schrieb:
> On Tue, Mar 18, 2008 at 4:34 AM, Andre Schwarz
> <andre.schwarz@matrix-vision.de> wrote:
>   
>>  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.
>
> 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

[-- Attachment #2: Type: text/html, Size: 4089 bytes --]

Re: simple MPC5200B system

[Grant Likely]

On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz
<andre.schwarz@matrix-vision.de> wrote:
>  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.

>      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 ?

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.

>
>  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.

>
>  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.

>
>  5th : ok - parent pic

Correct.

>
>  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.

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

Re: simple MPC5200B system

[Andre Schwarz]

[-- Attachment #1: Type: text/plain, Size: 4010 bytes --]

Grant Likely schrieb:
> On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz
> <andre.schwarz@matrix-vision.de> wrote:
>   
>>  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.
>
>   

ok.
>>      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 ?
>>     
>
> 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"

>>  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.
>>  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.
>>  5th : ok - parent pic
>>     
>
> Correct.
>
>   
>>  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.
>
>   
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

[-- Attachment #2: Type: text/html, Size: 5899 bytes --]

Re: simple MPC5200B system

[Wolfgang Denk]

In message <47DF821B.6090600@matrix-vision.de> 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

-- 
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: wd@denx.de
EMACS belongs in <sys/errno.h>: Editor too big!

Re: simple MPC5200B system

[David Gibson]

On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
> In message <47DF821B.6090600@matrix-vision.de> 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.

-- 
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

Re: simple MPC5200B system

[André Schwarz]

David Gibson schrieb:
> On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
>> In message <47DF821B.6090600@matrix-vision.de> 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

Re: simple MPC5200B system

[David Gibson]

On Thu, Mar 20, 2008 at 08:48:42AM +0100, André Schwarz wrote:
> David Gibson schrieb:
>> On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
>>> In message <47DF821B.6090600@matrix-vision.de> 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.
>
> 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.

-- 
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

Re: simple MPC5200B system

[André Schwarz]

David Gibson schrieb:
> On Thu, Mar 20, 2008 at 08:48:42AM +0100, Andr=E9 Schwarz wrote:
>> David Gibson schrieb:
>>> On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
>>>> In message <47DF821B.6090600@matrix-vision.de> 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?
>>> Ugh.. I really need to fix dtc to pick the default boot cpu value mor=
e
>>> sensibly, don't I.
>> I didn't specify "-b 0". This shouldn't be neccessary on a single proc=
essor=20
>> 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

Re: simple MPC5200B system

[Stefan Roese]

On Thursday 20 March 2008, David Gibson wrote:
> >>> 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