Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi Andy,
On Tue, May 06, 2008 at 05:54:02PM -0500, Andy Fleming wrote:
Now back to the first an bigger problem :
currently, I have an old U-boot and I have written myself a dts file.
Problem is : ethernet does not work, but that's not a mac-address problem,
but something else that I do not understand yet. The symptom is I get
ip route add default via 192.168.85.33 dev eth0
RTNETLINK answers: Network is unreachable
I surmise this is because my eth0 does not become up, and I surmise
again this is because there is no driver selected to drive the phy.
In my arch/ppc setup this was automagically handled by [EMAIL PROTECTED]:1
IIRC
Is there something I can put in my dts file to activate a driver for my
phy ?
Best regards
This slipped under my radar, and I'm only just now finding it again. Have
your issues been resolved?
This has actually not been resolved as such, but we use now the newest
U-boot version which is dtb-aware, and linux-2.6.25-rc6, and that together
fixes the ethernet problem.
If not, could you send a bit more of the boot
log? There should be a little more if the PHY was not found. If you were
operating with a fixed PHY setup before, then the generic PHY driver (which
will automatically bind to your PHY) should suffice unless your MDIO bus is
broken.
Andy
Of course, the dts file also has changed, because it is now filled by
U-boot. I have attached it here for info.
Thanks
Philippe
PS:
What's the recommended way to make a powerpc patch (e.g. my defconfig) appear
in the official kernel sources ? Should I send it to linuxppc-dev@ozlabs.org,
lkml or somewhere else ?
/*
* MPC8540 ADS Device Tree Source - Modified by DEVELTECH for
MACQ_IMAGE_PROCESSOR
*
* Copyright 2006 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/ {
model = MACQ_IMAGE_PROCESSOR;
compatible = MPC8540ADS, MPC85xxADS;
#address-cells = 1;
#size-cells = 1;
aliases {
ethernet0 = enet0;
serial0 = serial0;
pci0 = pci0;
};
cpus {
#address-cells = 1;
#size-cells = 0;
PowerPC,[EMAIL PROTECTED] {
device_type = cpu;
reg = 0;
d-cache-line-size = 20; // 32 bytes
i-cache-line-size = 20; // 32 bytes
d-cache-size = 8000; // L1, 32K
i-cache-size = 8000; // L1, 32K
timebase-frequency = 0; // 33. MHz, from
uboot
bus-frequency = 0;// 166 MHz
clock-frequency = 0; // 666, 833 or 1000 MHz, from
uboot
};
};
memory {
device_type = memory;
reg = 1000; // 256M at 0x0
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
ranges = 0 e000 0010;
reg = e000 0010; // CCSRBAR 1M
bus-frequency = 0;
[EMAIL PROTECTED] {
compatible = fsl,8540-memory-controller;
reg = 2000 1000;
interrupt-parent = mpic;
interrupts = 12 2;
};
[EMAIL PROTECTED] {
compatible = fsl,8540-l2-cache-controller;
reg = 2 1000;
cache-line-size = 20; // 32 bytes
cache-size = 4; // L2, 256K
interrupt-parent = mpic;
interrupts = 10 2;
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
compatible = fsl-i2c;
reg = 3000 100;
interrupts = 2b 2;
interrupt-parent = mpic;
dfsrr;
[EMAIL PROTECTED] {
device_type = rtc;
compatible = stm,m41t81;
reg = 68;
};
[EMAIL PROTECTED] {
device_type = temp-sensor;
compatible = ns,lm63;
reg = 4c;
};
[EMAIL PROTECTED] {
device_type =
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi Philippe, On Wed, 7 May 2008 09:50:48 +0200 Philippe De Muyter [EMAIL PROTECTED] wrote: What's the recommended way to make a powerpc patch (e.g. my defconfig) appear in the official kernel sources ? Should I send it to linuxppc-dev@ozlabs.org, lkml or somewhere else ? linuxppc-dev would be the best place. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgppMxJsF6RMu.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Now back to the first an bigger problem : currently, I have an old U-boot and I have written myself a dts file. Problem is : ethernet does not work, but that's not a mac-address problem, but something else that I do not understand yet. The symptom is I get ip route add default via 192.168.85.33 dev eth0 RTNETLINK answers: Network is unreachable I surmise this is because my eth0 does not become up, and I surmise again this is because there is no driver selected to drive the phy. In my arch/ppc setup this was automagically handled by [EMAIL PROTECTED]:1 IIRC Is there something I can put in my dts file to activate a driver for my phy ? Best regards This slipped under my radar, and I'm only just now finding it again. Have your issues been resolved? If not, could you send a bit more of the boot log? There should be a little more if the PHY was not found. If you were operating with a fixed PHY setup before, then the generic PHY driver (which will automatically bind to your PHY) should suffice unless your MDIO bus is broken. Andy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi David, On Tue, Mar 11, 2008 at 11:32:49AM +1100, David Gibson wrote: On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote: Hi Ben, I now have a working linux on my mpc8540 based board, with support for the compactflash disk and the i2c rtc. The network tough, does not work yet. altough the the integrated ethernet controller (FEC) seems to be recognized. Could it be a problem with the phy ? I notice that I do not have an entry for gfar_interrupt in /proc/interrupts on my ethernet-missing linux, while I have one ont the working arch/ppc linux ? Do I need to give the phy type in the dts file, and how ? I would also like to know if it is possible to still get in linux the mac address known by uboot when using a dts file, and how ? This chiefly depends on whether you're using an old u-boot that doesn't know about the device tree, or a new u-boot which itself supplies a device tree to the kernel. If the old u-boot, you'll need to write a bootwrapper for your platform which reads the bd_t and pokes the right mac addresses into the device tree. If the new u-boot, u-boot itself should put the address into the device tree. If it's not, why it's not is a u-boot question rather than a device tree question. OK :( Now back to the first an bigger problem : currently, I have an old U-boot and I have written myself a dts file. Problem is : ethernet does not work, but that's not a mac-address problem, but something else that I do not understand yet. The symptom is I get ip route add default via 192.168.85.33 dev eth0 RTNETLINK answers: Network is unreachable I surmise this is because my eth0 does not become up, and I surmise again this is because there is no driver selected to drive the phy. In my arch/ppc setup this was automagically handled by [EMAIL PROTECTED]:1 IIRC Is there something I can put in my dts file to activate a driver for my phy ? Best regards Philippe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
On Tue, Mar 11, 2008 at 12:46:02PM +0100, Philippe De Muyter wrote: Hi David, On Tue, Mar 11, 2008 at 11:32:49AM +1100, David Gibson wrote: On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote: Hi Ben, I now have a working linux on my mpc8540 based board, with support for the compactflash disk and the i2c rtc. The network tough, does not work yet. altough the the integrated ethernet controller (FEC) seems to be recognized. Could it be a problem with the phy ? I notice that I do not have an entry for gfar_interrupt in /proc/interrupts on my ethernet-missing linux, while I have one ont the working arch/ppc linux ? Do I need to give the phy type in the dts file, and how ? I would also like to know if it is possible to still get in linux the mac address known by uboot when using a dts file, and how ? This chiefly depends on whether you're using an old u-boot that doesn't know about the device tree, or a new u-boot which itself supplies a device tree to the kernel. If the old u-boot, you'll need to write a bootwrapper for your platform which reads the bd_t and pokes the right mac addresses into the device tree. If the new u-boot, u-boot itself should put the address into the device tree. If it's not, why it's not is a u-boot question rather than a device tree question. OK :( Now back to the first an bigger problem : currently, I have an old U-boot and I have written myself a dts file. Problem is : ethernet does not work, but that's not a mac-address problem, but something else that I do not understand yet. The symptom is I get ip route add default via 192.168.85.33 dev eth0 RTNETLINK answers: Network is unreachable I surmise this is because my eth0 does not become up, and I surmise again this is because there is no driver selected to drive the phy. In my arch/ppc setup this was automagically handled by [EMAIL PROTECTED]:1 IIRC Is there something I can put in my dts file to activate a driver for my phy ? Probably, but how phy selection works is dependent on the ethernet driver, so I can't help you. You'll need someone familiar with the driver in question (or read the code and figure it out). -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote: Hi Ben, I now have a working linux on my mpc8540 based board, with support for the compactflash disk and the i2c rtc. The network tough, does not work yet. altough the the integrated ethernet controller (FEC) seems to be recognized. Could it be a problem with the phy ? I notice that I do not have an entry for gfar_interrupt in /proc/interrupts on my ethernet-missing linux, while I have one ont the working arch/ppc linux ? Do I need to give the phy type in the dts file, and how ? I would also like to know if it is possible to still get in linux the mac address known by uboot when using a dts file, and how ? This chiefly depends on whether you're using an old u-boot that doesn't know about the device tree, or a new u-boot which itself supplies a device tree to the kernel. If the old u-boot, you'll need to write a bootwrapper for your platform which reads the bd_t and pokes the right mac addresses into the device tree. If the new u-boot, u-boot itself should put the address into the device tree. If it's not, why it's not is a u-boot question rather than a device tree question. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi Ben, I now have a working linux on my mpc8540 based board, with support for the compactflash disk and the i2c rtc. The network tough, does not work yet. altough the the integrated ethernet controller (FEC) seems to be recognized. Could it be a problem with the phy ? I notice that I do not have an entry for gfar_interrupt in /proc/interrupts on my ethernet-missing linux, while I have one ont the working arch/ppc linux ? Do I need to give the phy type in the dts file, and how ? I would also like to know if it is possible to still get in linux the mac address known by uboot when using a dts file, and how ? Thanks for listening. Philippe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
On Sun, 2008-03-09 at 23:31 +0100, Philippe De Muyter wrote: Hi Ben, I now have a working linux on my mpc8540 based board, with support for the compactflash disk and the i2c rtc. The network tough, does not work yet. altough the the integrated ethernet controller (FEC) seems to be recognized. Could it be a problem with the phy ? I notice that I do not have an entry for gfar_interrupt in /proc/interrupts on my ethernet-missing linux, while I have one ont the working arch/ppc linux ? Do I need to give the phy type in the dts file, and how ? I would also like to know if it is possible to still get in linux the mac address known by uboot when using a dts file, and how ? I'll let the freescale people answer here as I don't know the gianfar driver at all. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi Ben,
On Thu, Mar 06, 2008 at 10:46:51AM +1100, Benjamin Herrenschmidt wrote:
From your .dts, I see you've been doing some swizzling of slots using
interrupts 1...4 ... do that correspond to EXTIRQ 58 ?
No, those correspond to the EXT1-4 that are the other side of the #ifdef
for this board in arch/ppc. :-)
Yes, that's what I was thinking. So that's what he got wrong in
his .dts.
Philippe, you need to fix those numbers so they map your EXTIRQ.
(that is 1 - 5, 2 - 6, etc... )
And of course you need to make sure you have the right routing to the
chip. it's funny the way you keep providing all sort of info but -never-
the one we actually asked for :-)
I did not have that. The board has been designed, and the original linux
port has been made, by a third-party, and the documentation is scarce :(
We basically, to help you, need to know for each PCI device connected to
the SoC, or PCI slot if you have such, which address line is used for
IDSEL, and to which MPIC interrupt inputs.
Well, i have finally an answer for IDSEL : it is connected to AD18 (18 is
decimal), but we knew that actually, because the chip appears as :00:12.0,
:00:12.1 and :00:12.2 in the kernel messages.
The pci4520 chip does not have pins labelled inta, intb, intc, or intd,
but pins labelled mfunc0, mfunc1 ... mfunc6.
The pci4520 datasheet does not seem very clear to me about the relation
between the mfunc0..6 pins and the inta..d interrupts :(
Luckily, the running linux kernel shows in /proc/interrupts :
55: 18797 OpenPIC Level yenta, ide0
54: 1 OpenPIC Level yenta
55: 79 OpenPIC Level ohci1394
I can thus deduce that each function of the pci4520 chip uses only
one interrupt line. With the kernel messages at startup, I also
know that the two yenta's are 12.0 and 12.1 and the ohci1394 is 12.2.
I wrote then the following in my dts file :
[EMAIL PROTECTED] {
/*
f800 masks idsel address line
07 masks (sub)function number
7 masks INTA, INTB, INTC or INTD
*/
interrupt-map-mask = ff00 0 0 7;
interrupt-map =
/* IDSEL 0x12 func 0 */
9000 0 0 1 mpic 5 1
9000 0 0 2 mpic 5 1
9000 0 0 3 mpic 5 1
9000 0 0 4 mpic 5 1
/* IDSEL 0x12 func 1 */
9100 0 0 1 mpic 6 1
9100 0 0 2 mpic 6 1
9100 0 0 3 mpic 6 1
9100 0 0 4 mpic 6 1
/* IDSEL 0x12 func 2 */
9200 0 0 1 mpic 7 1
9200 0 0 2 mpic 7 1
9200 0 0 3 mpic 7 1
9200 0 0 4 mpic 7 1
;
And it works :) : my board boots and finds its compact-flash disk. When
writing this, I realize I may simplify my interrupt-map and write
only one config line per function, thus :
interrupt-map-mask = ff00 0 0 0;
interrupt-map =
/* IDSEL 0x12 func 0 */
9000 0 0 0 mpic 5 1
/* IDSEL 0x12 func 1 */
9100 0 0 0 mpic 6 1
/* IDSEL 0x12 func 2 */
9200 0 0 0 mpic 7 1
;
Maybe you should explain in booting_without_of.txt the relation between
the idsel and the pci device notation used by lspci or the kernel, and
also document the function part ?
Once you have given us that, we'll be able to help.
It appears that just looking at the arch/ppc code is a bit too messy and
confusing (and not necessarily right).
In addition, you will also need to do proper interrupt routing for you
other devices (RTC, etc...) but we can look at that separately.
That's for tomorrow.
But I already noticed that the interrupt numbers that the arch/powerpc tree
uses for the parts that do already work (compact-flash and serials) are
different from the ones I saw on the running arch/ppc tree. e.g.,
the serial lines used irq 26 with the arch/ppc tree and now use 42 with
the powerpc tree. For the pci4520, irqs changed from 53, 54 and 55 in the
arch/ppc kernel to 17, 18 and 19 with the arch/powerpc kernel.
That's a little bit confusing.
There must be something hidden in the sources of the openpic driver to
explain that difference. Could it be fixed by a setting in the dts-file ?
Thanks for you help
Philippe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
On Fri, 2008-03-07 at 01:10 +0100, Philippe De Muyter wrote: But I already noticed that the interrupt numbers that the arch/powerpc tree uses for the parts that do already work (compact-flash and serials) are different from the ones I saw on the running arch/ppc tree. e.g., the serial lines used irq 26 with the arch/ppc tree and now use 42 with the powerpc tree. For the pci4520, irqs changed from 53, 54 and 55 in the arch/ppc kernel to 17, 18 and 19 with the arch/powerpc kernel. That's a little bit confusing. There must be something hidden in the sources of the openpic driver to explain that difference. Could it be fixed by a setting in the dts-file ? The interrupt numbers that you see in /proc/interrupts and that drivers see are virtual. They have no direct relationship to the hardware interrupt lines (well, the kernel attempts sometimes at keeping them the same but not always). Basially, when the kernel establishes interrupt routing when probing devices, it gets dynamically assigned numbers and that's what drivers and /proc/interrupts will see, and internally binds them to a given HW source on a given interrupt controller. This is done for several reasons, the main ones being that we have to routinely deal with multiple controllers each having it's own hardware number space, some systems have very large HW interrupt numbers not suitable for the irq_desc array, and we reserve virtual numbers 0 as always invalid and 1...15 for an ISA-type 8259 controller to avoid problems with x86-oirignated legacy junk that tries to hard code those numbers. There's an compile option to see the mapping between virtual numbers and HW numbers in debugfs, try enabling debugfs, CONFIG_VIRQ_DEBUG, and mount debugfs somewhere. You'll see a powerpc/virq_mapping file in there with the mapping. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi Ben, thanks for all the answers, On Wed, Mar 05, 2008 at 04:01:04PM +1100, Benjamin Herrenschmidt wrote: I also attach my current (not working) dts file attempt. It is actually a modified mpc8540ads.dts file. I now thinks that the ide-cs (hda) discovery or not depends on the cold or warm reboot. Here are the patches for my config (MEIP_8540) relative to a vanilla linux-2.6.24. I hacked the MPC8540ADS config. The PCI4520 is the multi-function chip from TI (dual-socket pc-card + iee1394 ohci and two-port phy) .../... +#ifdef CONFIG_MEIP_8540 + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 0 : nINTPFO + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 1 : nINTRTC + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 2 : nINTPLD + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 3 : nINTSTX + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 4 : nINTPHY +#if defined(CONFIG_PCI) + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 5 : PCI4520 MFUNC 0 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 6 : PCI4520 MFUNC 1 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 7 : PCI4520 MFUNC 2 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 8 : PCI4520 MFUNC 3 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 9 : PCI4520 MFUNC 4 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 10 : PCI4520 MFUNC 5 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 11 : PCI4520 MFUNC 6 */ +#else + 0x0,/* External 6: */ + 0x0,/* External 7: */ + 0x0,/* External 8: */ + 0x0,/* External 9: */ + 0x0,/* External 10: */ + 0x0,/* External 11: */ +#endif +#else 0x0,/* External 0: */ #if defined(CONFIG_PCI) (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 1: PCI slot 0 */ @@ -77,6 +100,7 @@ 0x0,/* External 9: */ 0x0,/* External 10: */ 0x0,/* External 11: */ +#endif }; Ok, so based on the above, I deduce that you have 12 external interrupt sources: 0...4 are those nINT* things. They correspond apparently do discrete devices on your board. You will have to create device nodes in your .dts for these with the appropriate interrupts property for each of these. The rest are ... hrm... weird. You -appear- to have 5 to 8 going to PCI, to PIRQA...D. Do that mean that you have wired your connectors on the board such that the interrupt does not depend on the actual slot number ? I asked the guy who designed the hardware, and if I understand correctly : - the i/o and memory resources of the pci device are connected to the pci bus - the interrupts are directly connected to the MPIC Can I describe that in the dts file ? Philippe Or are you doing some swizzling ? Also, I would need to know how those external IRQs are connected to the MPIC, I don't have the spec of that chip here. Hrm. Somebody from freescale can help him here ? It's also not clear to me what your interrupts 9 10 and 11 are since you seem to only talk about PIRQA...D which is only 4 lines .. So at this stage, that's not enough information. We need to know exactly how you have wired things on your board, and somebody from fsl needs to tell me how the ExtIrq are routed to the MPIC on that guy. Once that's done, you seem to have grasped the interrupt map... for any device or slot, you provide the mapping between idsel/pirq line on one side, and mpic interrupt sense on the other. For PCI, sense is always 1 for an mpic so you mostly have to check your actual MPIC source numbers. From your .dts, I see you've been doing some swizzling of slots using interrupts 1...4 ... do that correspond to EXTIRQ 58 ? Ben. /* */ --- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk2008-01-24 22:58:37.0 + +++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h 2008-02-20 16:36:07.0 + @@ -29,10 +29,17 @@ extern void mpc85xx_ads_map_io(void) __init; /* PCI interrupt controller */ +#ifdef CONFIG_MEIP_8540 +#define PIRQA MPC85xx_IRQ_EXT5 +#define PIRQB MPC85xx_IRQ_EXT6 +#define PIRQC MPC85xx_IRQ_EXT7 +#define PIRQD MPC85xx_IRQ_EXT8 +#else #define PIRQA MPC85xx_IRQ_EXT1 #define PIRQB MPC85xx_IRQ_EXT2
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Benjamin Herrenschmidt wrote: So at this stage, that's not enough information. We need to know exactly how you have wired things on your board, and somebody from fsl needs to tell me how the ExtIrq are routed to the MPIC on that guy. This part's easy -- the external IRQ is used as the mpic interrupt number as-is (internal IRQs start at 16). Once that's done, you seem to have grasped the interrupt map... for any device or slot, you provide the mapping between idsel/pirq line on one side, and mpic interrupt sense on the other. For PCI, sense is always 1 for an mpic so you mostly have to check your actual MPIC source numbers. From your .dts, I see you've been doing some swizzling of slots using interrupts 1...4 ... do that correspond to EXTIRQ 58 ? No, those correspond to the EXT1-4 that are the other side of the #ifdef for this board in arch/ppc. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
On Wed, 2008-03-05 at 17:15 +0100, Philippe De Muyter wrote: I asked the guy who designed the hardware, and if I understand correctly : - the i/o and memory resources of the pci device are connected to the pci bus - the interrupts are directly connected to the MPIC Can I describe that in the dts file ? Sure, you can describe pretty much any interrupt routing, provided that we know -how- (ie. where) they are connected. We also need to know the idsel of the devices. (The later we can deduce from lspci done in arch/ppc). Ben. Philippe Or are you doing some swizzling ? Also, I would need to know how those external IRQs are connected to the MPIC, I don't have the spec of that chip here. Hrm. Somebody from freescale can help him here ? It's also not clear to me what your interrupts 9 10 and 11 are since you seem to only talk about PIRQA...D which is only 4 lines .. So at this stage, that's not enough information. We need to know exactly how you have wired things on your board, and somebody from fsl needs to tell me how the ExtIrq are routed to the MPIC on that guy. Once that's done, you seem to have grasped the interrupt map... for any device or slot, you provide the mapping between idsel/pirq line on one side, and mpic interrupt sense on the other. For PCI, sense is always 1 for an mpic so you mostly have to check your actual MPIC source numbers. From your .dts, I see you've been doing some swizzling of slots using interrupts 1...4 ... do that correspond to EXTIRQ 58 ? Ben. /* */ --- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk2008-01-24 22:58:37.0 + +++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h 2008-02-20 16:36:07.0 + @@ -29,10 +29,17 @@ extern void mpc85xx_ads_map_io(void) __init; /* PCI interrupt controller */ +#ifdef CONFIG_MEIP_8540 +#define PIRQA MPC85xx_IRQ_EXT5 +#define PIRQB MPC85xx_IRQ_EXT6 +#define PIRQC MPC85xx_IRQ_EXT7 +#define PIRQD MPC85xx_IRQ_EXT8 +#else #define PIRQA MPC85xx_IRQ_EXT1 #define PIRQB MPC85xx_IRQ_EXT2 #define PIRQC MPC85xx_IRQ_EXT3 #define PIRQD MPC85xx_IRQ_EXT4 +#endif #define MPC85XX_PCI1_LOWER_IO 0x #define MPC85XX_PCI1_UPPER_IO 0x00ff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi Ben, On Thu, Mar 06, 2008 at 07:14:28AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2008-03-05 at 17:15 +0100, Philippe De Muyter wrote: I asked the guy who designed the hardware, and if I understand correctly : - the i/o and memory resources of the pci device are connected to the pci bus - the interrupts are directly connected to the MPIC Can I describe that in the dts file ? Sure, you can describe pretty much any interrupt routing, provided that we know -how- (ie. where) they are connected. We also need to know the They are connected directly to the pic-part of the mpc8540 just as described in the .c file in the other mail. idsel of the devices. (The later we can deduce from lspci done in arch/ppc). Does this (boot error messages in the not-working arch/powerpc kernel) : PCI: Cannot allocate resource region 0 of device :00:12.0 PCI: Cannot allocate resource region 0 of device :00:12.1 PCI: Cannot allocate resource region 0 of device :00:12.2 PCI: Cannot allocate resource region 1 of device :00:12.2 or this (/proc/bus/pci in the working arch/pcc kernel) Sorry, I am at home now and cannot access my board :) or this (boot info messages from working arch/pcc kernel) : ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[55] MMIO=[9f7fd800-9f7fdfff] Max Packet=[2048] IR/IT contexts=[4/8] ... Yenta: CardBus bridge found at :00:12.0 [:] ... Yenta TI: socket :00:12.0, mfunc 0x1b00, devctl 0x66 Yenta TI: socket :00:12.0 probing PCI interrupt failed, trying to fix Yenta TI: socket :00:12.0 falling back to parallel PCI interrupts Yenta TI: socket :00:12.0 parallel PCI interrupts ok Yenta: ISA IRQ mask 0x, PCI irq 53 ... pccard: PCMCIA card inserted into slot 0 cs: memory probe 0x8000-0x9fff: excluding 0x8000-0x807f 0x9f00-0x9fff pcmcia: registering new device pcmcia0.0 Yenta TI: socket :00:12.1 parallel PCI interrupts ok Yenta: ISA IRQ mask 0x, PCI irq 54 Socket status: 3086 or this (U-boot info message) : PCI Scan: Found Bus 0, Device 18, Function 0 00 12 104c ac46 0607 ff PCI Scan: Found Bus 0, Device 18, Function 1 00 12 104c ac46 0607 ff PCI Scan: Found Bus 0, Device 18, Function 2 00 12 104c 802a 0c00 00 and this (/proc/interrupts on a working system) CPU0 25: 0 OpenPIC Level gfar_interrupt 26:245 OpenPIC Level serial 27: 0 OpenPIC Level i2c-mpc 53: 18797 OpenPIC Level yenta, ide0 54: 1 OpenPIC Level yenta 55: 79 OpenPIC Level ohci1394 BAD: 0 help ? Philippe Or are you doing some swizzling ? Also, I would need to know how those external IRQs are connected to the MPIC, I don't have the spec of that chip here. Hrm. Somebody from freescale can help him here ? It's also not clear to me what your interrupts 9 10 and 11 are since you seem to only talk about PIRQA...D which is only 4 lines .. So at this stage, that's not enough information. We need to know exactly how you have wired things on your board, and somebody from fsl needs to tell me how the ExtIrq are routed to the MPIC on that guy. Once that's done, you seem to have grasped the interrupt map... for any device or slot, you provide the mapping between idsel/pirq line on one side, and mpic interrupt sense on the other. For PCI, sense is always 1 for an mpic so you mostly have to check your actual MPIC source numbers. From your .dts, I see you've been doing some swizzling of slots using interrupts 1...4 ... do that correspond to EXTIRQ 58 ? Ben. /* */ --- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk2008-01-24 22:58:37.0 + +++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h 2008-02-20 16:36:07.0 + @@ -29,10 +29,17 @@ extern void mpc85xx_ads_map_io(void) __init; /* PCI interrupt controller */ +#ifdef CONFIG_MEIP_8540 +#define PIRQA MPC85xx_IRQ_EXT5 +#define PIRQB MPC85xx_IRQ_EXT6 +#define PIRQC MPC85xx_IRQ_EXT7 +#define PIRQD MPC85xx_IRQ_EXT8 +#else #define PIRQA MPC85xx_IRQ_EXT1 #define PIRQB MPC85xx_IRQ_EXT2 #define PIRQC MPC85xx_IRQ_EXT3 #define PIRQD MPC85xx_IRQ_EXT4 +#endif #define MPC85XX_PCI1_LOWER_IO 0x #define MPC85XX_PCI1_UPPER_IO 0x00ff
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
From your .dts, I see you've been doing some swizzling of slots using interrupts 1...4 ... do that correspond to EXTIRQ 58 ? No, those correspond to the EXT1-4 that are the other side of the #ifdef for this board in arch/ppc. :-) Yes, that's what I was thinking. So that's what he got wrong in his .dts. Philippe, you need to fix those numbers so they map your EXTIRQ. (that is 1 - 5, 2 - 6, etc... ) And of course you need to make sure you have the right routing to the chip. it's funny the way you keep providing all sort of info but -never- the one we actually asked for :-) We basically, to help you, need to know for each PCI device connected to the SoC, or PCI slot if you have such, which address line is used for IDSEL, and to which MPIC interrupt inputs. Once you have given us that, we'll be able to help. It appears that just looking at the arch/ppc code is a bit too messy and confusing (and not necessarily right). In addition, you will also need to do proper interrupt routing for you other devices (RTC, etc...) but we can look at that separately. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi Scott, On Mon, Mar 03, 2008 at 03:55:26PM -0600, Scott Wood wrote: Philippe De Muyter wrote: The following seems important also : /* interrupts = 18 2; */ /* interrupts number are coded in hexa ! */ interrupts = 12 2 19 2 1a 2 1b 2 35 2 36 2 37 2; I have replaced the interrupts spec in comments by the longer interrupts spec below, Why? because of the error message regarding unhandled interrupt. As I wrote I do not know anything about dts files, just that it is needed to have one for a non OF board if I want to use the ARCH=powerpc tree. and it seems to have some positive effect, What kind of positive effect? I'd think the extra interrupts would just be ignored. The interrupts property for the PCI node itself is generally for error reporting. My compact-flash device is discovered, but interrupts still do not work. In the log, at the end of the boot, this : rtc-m41t80 0-0068: hctosys: invalid date/time Waiting 3sec before mounting root device... VFS: Cannot open root device hda1 or unknown-block(0,0) Please append a correct root= boot option; here are the available partitions: 1f00 1920 mtdblock0 (driver?) 1f01 1920 mtdblock1 (driver?) 1f02 1920 mtdblock2 (driver?) 1f03 1920 mtdblock3 (driver?) 1f04512 mtdblock4 (driver?) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Rebooting in 180 seconds.. is replaced by that : hda: TRANSCEND, CFA DISK drive ide0 at 0x000-0x007,0x00e on irq 18 hda: max request size: 128KiB hda: 8077104 sectors (4135 MB) w/1KiB Cache, CHS=8013/16/63 hda:4hda: lost interrupt [same message repeated] hda: lost interrupt hda1 ide-cs: hda: Vpp = 0.0 rtc-m41t80 0-0068: hctosys: invalid date/time Waiting 3sec before mounting root device... hda: lost interrupt [same message repeated] EXT2-fs warning (device hda1): ext2_fill_super: mounting ext3 filesystem as ext2 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 116k init hda: lost interrupt [same message repeated] I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the interrupts numbers that I had in the ARCH=ppc version. I added 18 because of the error message, but it did not help. What ARCH=ppc version? There are no device trees for non-OF boards in arch/ppc. With ARCH=ppc, all those interrupt's info's are hardcoded in the .c files. But I expected I could fill the dts file for ARCH=powerpc from info's I could collect in /proc on a running ARCH=ppc linux without dts file for the same board. Philippe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi Ben, On Tue, Mar 04, 2008 at 08:41:33AM +1100, Benjamin Herrenschmidt wrote: Thanks The following seems important also : /* interrupts = 18 2; */ /* interrupts number are coded in hexa ! */ interrupts = 12 2 19 2 1a 2 1b 2 35 2 36 2 37 2; I have replaced the interrupts spec in comments by the longer interrupts spec below, and it seems to have some positive effect, but I do not know precisely what I have described there. I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the interrupts numbers that I had in the ARCH=ppc version. I added 18 because of the error message, but it did not help. Where is this ? (What node ?) The above looks like the interrupt spec for a single device with 7 interrupts, is that what you are trying to do ? Well, the yenta device is a multi-function PCI peripheral that has two pcmcia/pccard/compactflash slots and one ohci1394 interface. Here's what uboot shows : PCI Scan: Found Bus 0, Device 18, Function 0 00 12 104c ac46 0607 ff PCI Scan: Found Bus 0, Device 18, Function 1 00 12 104c ac46 0607 ff PCI Scan: Found Bus 0, Device 18, Function 2 00 12 104c 802a 0c00 00 and here is what /proc/interrupts shows in my ARCH=ppc dts-less running linux : root:~# cat /proc/interrupts CPU0 25: 0 OpenPIC Level gfar_interrupt 26:245 OpenPIC Level serial 27: 0 OpenPIC Level i2c-mpc 55: 18797 OpenPIC Level yenta, ide0 54: 1 OpenPIC Level yenta 55: 79 OpenPIC Level ohci1394 BAD: 0 If not, then it's incorrect, you have to figure the interrupt-map out (it's really not -that- hard). If I knew where to look at, and what I must produce, I'd agree with you :) Philippe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
On Tue, 2008-03-04 at 09:08 +0100, Philippe De Muyter wrote: With ARCH=ppc, all those interrupt's info's are hardcoded in the .c files. But I expected I could fill the dts file for ARCH=powerpc from info's I could collect in /proc on a running ARCH=ppc linux without dts file for the same board. Rather, look at the C file. Send it and we can help figuring things out. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
On Tue, Mar 04, 2008 at 10:10:59AM +0100, Philippe De Muyter wrote:
Hi Ben,
On Tue, Mar 04, 2008 at 07:22:19PM +1100, Benjamin Herrenschmidt wrote:
These comments aren't relevant to the problems you're seeing, but
they're a good idea for writing device trees in general.
First, you may want to consider moving to the version 1 dts format
which uses C-style integer values throughout, instead of hex by
default.
[snip]
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
device_type = i2c;
device_type shouldn't be included here.
compatible = fsl-i2c;
reg = 3000 100;
interrupts = 2b 2;
interrupt-parent = mpic;
dfsrr;
[EMAIL PROTECTED] {
compatible = stm,m41t81;
reg = 68;
};
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
device_type = mdio;
compatible = gianfar;
[snip]
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
The binding for gianfar mdio and ethernet devices has been updated to
better fit conventions for use of device_type and compatible
properties. Check booting-without-of.txt for the details.
Can someone from freescale please go though and update the existing
device trees, so that people stop copying the old crap.
[snip]
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 24000 1000;
/*
* address is deprecated and will be removed
* in 2.6.25. Only recent versions of
* U-Boot support local-mac-address, however.
*/
address = [ 00 00 00 00 00 00 ];
And since this is a new port, you ought to be able to use a recent
u-boot and drop this backwards compatibility property.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
I also attach my current (not working) dts file attempt. It is actually a modified mpc8540ads.dts file. I now thinks that the ide-cs (hda) discovery or not depends on the cold or warm reboot. Here are the patches for my config (MEIP_8540) relative to a vanilla linux-2.6.24. I hacked the MPC8540ADS config. The PCI4520 is the multi-function chip from TI (dual-socket pc-card + iee1394 ohci and two-port phy) .../... +#ifdef CONFIG_MEIP_8540 + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 0 : nINTPFO + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 1 : nINTRTC + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 2 : nINTPLD + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 3 : nINTSTX + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), // External 4 : nINTPHY +#if defined(CONFIG_PCI) + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 5 : PCI4520 MFUNC 0 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 6 : PCI4520 MFUNC 1 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 7 : PCI4520 MFUNC 2 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 8 : PCI4520 MFUNC 3 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 9 : PCI4520 MFUNC 4 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 10 : PCI4520 MFUNC 5 */ + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 11 : PCI4520 MFUNC 6 */ +#else + 0x0,/* External 6: */ + 0x0,/* External 7: */ + 0x0,/* External 8: */ + 0x0,/* External 9: */ + 0x0,/* External 10: */ + 0x0,/* External 11: */ +#endif +#else 0x0,/* External 0: */ #if defined(CONFIG_PCI) (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* External 1: PCI slot 0 */ @@ -77,6 +100,7 @@ 0x0,/* External 9: */ 0x0,/* External 10: */ 0x0,/* External 11: */ +#endif }; Ok, so based on the above, I deduce that you have 12 external interrupt sources: 0...4 are those nINT* things. They correspond apparently do discrete devices on your board. You will have to create device nodes in your .dts for these with the appropriate interrupts property for each of these. The rest are ... hrm... weird. You -appear- to have 5 to 8 going to PCI, to PIRQA...D. Do that mean that you have wired your connectors on the board such that the interrupt does not depend on the actual slot number ? Or are you doing some swizzling ? Also, I would need to know how those external IRQs are connected to the MPIC, I don't have the spec of that chip here. Hrm. Somebody from freescale can help him here ? It's also not clear to me what your interrupts 9 10 and 11 are since you seem to only talk about PIRQA...D which is only 4 lines .. So at this stage, that's not enough information. We need to know exactly how you have wired things on your board, and somebody from fsl needs to tell me how the ExtIrq are routed to the MPIC on that guy. Once that's done, you seem to have grasped the interrupt map... for any device or slot, you provide the mapping between idsel/pirq line on one side, and mpic interrupt sense on the other. For PCI, sense is always 1 for an mpic so you mostly have to check your actual MPIC source numbers. From your .dts, I see you've been doing some swizzling of slots using interrupts 1...4 ... do that correspond to EXTIRQ 58 ? Ben. /* */ --- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk 2008-01-24 22:58:37.0 + +++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h2008-02-20 16:36:07.0 + @@ -29,10 +29,17 @@ extern void mpc85xx_ads_map_io(void) __init; /* PCI interrupt controller */ +#ifdef CONFIG_MEIP_8540 +#define PIRQAMPC85xx_IRQ_EXT5 +#define PIRQBMPC85xx_IRQ_EXT6 +#define PIRQCMPC85xx_IRQ_EXT7 +#define PIRQDMPC85xx_IRQ_EXT8 +#else #define PIRQAMPC85xx_IRQ_EXT1 #define PIRQBMPC85xx_IRQ_EXT2 #define PIRQCMPC85xx_IRQ_EXT3 #define PIRQDMPC85xx_IRQ_EXT4 +#endif #define MPC85XX_PCI1_LOWER_IO0x #define MPC85XX_PCI1_UPPER_IO0x00ff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi all,
I have a currently almost working ARCH=ppc linux-2.6.24 configuration for a
new mpc8540 board (except for a RTC chip connected to an i2c bus).
Knowing that ARCH=ppc will be removed, I try to make the ARCH=powerpc version
work, but that's not easy.
I have copied the mpc8540ads.dts file to a new dts file, and added the
following :
[EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
device_type = i2c;
compatible = fsl-i2c;
reg = 3000 100;
interrupts = 2b 2;
interrupt-parent = mpic;
dfsrr;
+
+ [EMAIL PROTECTED] {
+ compatible = stm,m41t81;
+ reg = 68;
+ };
};
and I see in the boot log that my RTC chip is now working.
My root device is on a compact-flash connected to a PCI yenta chip from TI,
and this one is not working, altough it seems to be discovered :
Yenta: CardBus bridge found at :00:12.0 [:]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket :00:12.0, mfunc 0x1b22, devctl 0x64
irq 18: nobody cared (try booting with the irqpoll option)
Call Trace:
[cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
[cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
[cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
[cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
but my boot finally fails with :
VFS: Cannot open root device hda1 or unknown-block(0,0)
Please append a correct root= boot option; here are the
available partitions:
1f00 8192 mtdblock0 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs
on unknown-block(0,0)
Is there an easy way to use values found in /proc or even in the sources
in my working ppc setup to put them in the dts file to make my new powerpc
configuration work ?
Thanks for listening
Philippe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
On Mon, Mar 3, 2008 at 7:47 AM, Philippe De Muyter [EMAIL PROTECTED] wrote: My root device is on a compact-flash connected to a PCI yenta chip from TI, and this one is not working, altough it seems to be discovered : Yenta: CardBus bridge found at :00:12.0 [:] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :00:12.0, mfunc 0x1b22, devctl 0x64 irq 18: nobody cared (try booting with the irqpoll option) Call Trace: [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable) [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8 but my boot finally fails with : VFS: Cannot open root device hda1 or unknown-block(0,0) Please append a correct root= boot option; here are the available partitions: 1f00 8192 mtdblock0 (driver?) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Is there an easy way to use values found in /proc or even in the sources in my working ppc setup to put them in the dts file to make my new powerpc configuration work ? It does not look like you are having dts problems. Once your in the PCI domain, Linux will probe the devices (as your boot log shows). Rather, your boot failure is due to the yenta device failure. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
On Mon, Mar 03, 2008 at 03:47:27PM +0100, Philippe De Muyter wrote: My root device is on a compact-flash connected to a PCI yenta chip from TI, and this one is not working, altough it seems to be discovered : Yenta: CardBus bridge found at :00:12.0 [:] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :00:12.0, mfunc 0x1b22, devctl 0x64 irq 18: nobody cared (try booting with the irqpoll option) Call Trace: [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable) [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8 Maybe your PCI interrupt-map is wrong... -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi Scott, On Mon, Mar 03, 2008 at 11:07:20AM -0600, Scott Wood wrote: On Mon, Mar 03, 2008 at 03:47:27PM +0100, Philippe De Muyter wrote: My root device is on a compact-flash connected to a PCI yenta chip from TI, and this one is not working, altough it seems to be discovered : Yenta: CardBus bridge found at :00:12.0 [:] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :00:12.0, mfunc 0x1b22, devctl 0x64 irq 18: nobody cared (try booting with the irqpoll option) Call Trace: [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable) [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8 Maybe your PCI interrupt-map is wrong... Is the PCI-interrupt map that part of the dts file : interrupt-map = /* IDSEL 0x02 */ 1000 0 0 1 mpic 1 1 1000 0 0 2 mpic 2 1 1000 0 0 3 mpic 3 1 1000 0 0 4 mpic 4 1 /* IDSEL 0x03 */ 1800 0 0 1 mpic 4 1 1800 0 0 2 mpic 1 1 1800 0 0 3 mpic 2 1 1800 0 0 4 mpic 3 1 ... I do not understand anything there :( Philippe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Philippe De Muyter wrote: Is the PCI-interrupt map that part of the dts file : interrupt-map = /* IDSEL 0x02 */ 1000 0 0 1 mpic 1 1 1000 0 0 2 mpic 2 1 1000 0 0 3 mpic 3 1 1000 0 0 4 mpic 4 1 /* IDSEL 0x03 */ 1800 0 0 1 mpic 4 1 1800 0 0 2 mpic 1 1 1800 0 0 3 mpic 2 1 1800 0 0 4 mpic 3 1 ... Yes. I do not understand anything there :( It maps PCI interrupts to mpic interrupts. The first three cells are the PCI address (only the device number is unmasked), then the PCI interrupt (INTA=1, INTB=2, etc.), then a phandle to the parent interrupt controller, then the interrupt specifier for the parent controller. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Hi Scott, On Mon, Mar 03, 2008 at 03:11:08PM -0600, Scott Wood wrote: Philippe De Muyter wrote: Is the PCI-interrupt map that part of the dts file : interrupt-map = /* IDSEL 0x02 */ 1000 0 0 1 mpic 1 1 1000 0 0 2 mpic 2 1 1000 0 0 3 mpic 3 1 1000 0 0 4 mpic 4 1 /* IDSEL 0x03 */ 1800 0 0 1 mpic 4 1 1800 0 0 2 mpic 1 1 1800 0 0 3 mpic 2 1 1800 0 0 4 mpic 3 1 ... Yes. I do not understand anything there :( It maps PCI interrupts to mpic interrupts. The first three cells are the PCI address (only the device number is unmasked), then the PCI interrupt (INTA=1, INTB=2, etc.), then a phandle to the parent interrupt controller, then the interrupt specifier for the parent controller. Thanks The following seems important also : /* interrupts = 18 2; */ /* interrupts number are coded in hexa ! */ interrupts = 12 2 19 2 1a 2 1b 2 35 2 36 2 37 2; I have replaced the interrupts spec in comments by the longer interrupts spec below, and it seems to have some positive effect, but I do not know precisely what I have described there. I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the interrupts numbers that I had in the ARCH=ppc version. I added 18 because of the error message, but it did not help. What should be described here and how ? Philippe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Maybe your PCI interrupt-map is wrong... Is the PCI-interrupt map that part of the dts file : interrupt-map = /* IDSEL 0x02 */ 1000 0 0 1 mpic 1 1 1000 0 0 2 mpic 2 1 1000 0 0 3 mpic 3 1 1000 0 0 4 mpic 4 1 /* IDSEL 0x03 */ 1800 0 0 1 mpic 4 1 1800 0 0 2 mpic 1 1 1800 0 0 3 mpic 2 1 1800 0 0 4 mpic 3 1 ... I do not understand anything there :( It's documented in booting-without-of.txt afaik... The interrupt-map goes along with the interrupt-map-mask. The later defines which bits of the map are relevant. The first part of the map is 3 cells containing a PCI address, followed by a cell containing a PCI IRQ line (1=A4=D). The next is the parent interrupt controller, followed by the IRQ specification, which for MPIC is the interrupt number on that controller, followed by an encoding of the interrupt polarity trigger type (1 for level-low). The first part, the PCI address, has a special format, which should be documented as well in the document I pointed out. For readability, we ommited the top 16 bits of the first cell, which are the address type and bus number, mostly irrelevant for interrupt mapping. The next bits are the device/function. Usually only the device part is unmasked. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Thanks The following seems important also : /* interrupts = 18 2; */ /* interrupts number are coded in hexa ! */ interrupts = 12 2 19 2 1a 2 1b 2 35 2 36 2 37 2; I have replaced the interrupts spec in comments by the longer interrupts spec below, and it seems to have some positive effect, but I do not know precisely what I have described there. I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the interrupts numbers that I had in the ARCH=ppc version. I added 18 because of the error message, but it did not help. Where is this ? (What node ?) The above looks like the interrupt spec for a single device with 7 interrupts, is that what you are trying to do ? If not, then it's incorrect, you have to figure the interrupt-map out (it's really not -that- hard). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
Philippe De Muyter wrote: The following seems important also : /* interrupts = 18 2; */ /* interrupts number are coded in hexa ! */ interrupts = 12 2 19 2 1a 2 1b 2 35 2 36 2 37 2; I have replaced the interrupts spec in comments by the longer interrupts spec below, Why? and it seems to have some positive effect, What kind of positive effect? I'd think the extra interrupts would just be ignored. The interrupts property for the PCI node itself is generally for error reporting. I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the interrupts numbers that I had in the ARCH=ppc version. I added 18 because of the error message, but it did not help. What ARCH=ppc version? There are no device trees for non-OF boards in arch/ppc. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
