* RE: mpc8260 fcc enet transmit time out
From: Ho Jeffrey-r26191 @ 2006-01-10 2:26 UTC (permalink / raw)
To: 'hubert.loewenguth', Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 6248 bytes --]
On MPC8560 port of linuxppc-2.4, on the Gianfar driver for TSEC and FEC, there is a mode call phy polling mode can be enable.
In one of our hw, we are using realtek 10/100phy which don't have interrupt as well.
We config that phy to use the polling mode in Gianfar. We can do plug and unplug with no problem.
My suggetsion is to check how that driver do the polling and use it with your fcc_enet.
Regards,
Jeffrey Ho
Freescale Semiconductor HK Ltd
Tel: 852-26668050
_____
From: linuxppc-embedded-bounces@ozlabs.org [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of hubert.loewenguth
Sent: Tuesday, January 10, 2006 1:27 AM
To: Linuxppc-embedded@ozlabs.org
Subject: mpc8260 fcc enet transmit time out
hi the community.
I have already posted a question about my problem but it seems that nobody has encounter the same matter.
So I have made numerous tests and researches and seeing that I still have not succeed in solving it, I try again tyo send you my bug.
I use a MPC8260 with linux 2.4.20.
The problem is with the fcc_enet driver.
I have no MII phy interrupt line with my LXT971 Phy in front of the powerpc.
Seeing that I have no interrupt line, I have configured the driver to be in half duplex, and the LXT971 too.
I'm sure that the driver is in half-duplex mode an the LXT971 too, and the auto-negociation is ok.
Everything works fine, but, if I do successive plugs/unplugs during important data transfert, The driver enter into an infinite loop:
# NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f690.
Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
...
1c00 055c 011d486a
3c00 05ea 011d406a
Rx @base c019f608 :
9c00 0040 01f3e000
9c00 0040 01f3e800
...
9c00 0040 01f3d000
bc00 0040 01f2f800
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f698.
Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
1c00 05ea 011ce06a
.....
I have found, on the linux-embended forum, a personn who has the same problem:
http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html <http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html>
But I'm sure about my pin connections ans so the reponse to this personn doesn't solve my problem
More interresting this one :
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html <http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html>
This personn seems to have the same troubleshouting than me .
He has tried to apply the patch provided by freescale, but it doesn't seem to correct it.
So I have had just a little piece of trace in order to see when this infernal loop appear.
I have added some trace in the fcc_enet_start_xmit .
has you know, after some kind of transmit errors, the transmitter need to be restarted, and so I have added some traces to see when it is restarted
/* Some transmit errors cause the transmitter to shut
* down. We now issue a restart transmit. Since the
* errors close the BD and update the pointers, the restart
* _should_ pick up without having to reset any of our
* pointers either. Also, To workaround 8260 device erratum
* CPM37, we must disable and then re-enable the transmitter
* following a Late Collision, Underrun, or Retry Limit error.
*/
# UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
UNDERRUN ! ==> RESTART
CARRIER LOST !
........
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f778 tx_free 0 cur_rx c019f690.
Tx @base c019f708 :
1c02 055c 012cd86a
9c00 05ea 012cd06a
9c00 05ea 012f706a
9c00 05ea 012cf06a
9c00 05ea 012cf86a
9c00 05ea 0118506a
Some personns have said me to try with 2.6 drivers but it's exactly the same problem.
( even if I'm a little bit surprised to see that with the 2.6 version drivers seems to be uncompatible with boards wich use MDIO without PHY
interrupt.the #define PHY_INTERRUPT condition of the 2.4 drivers version has
disapeared => with this new drivers you can't use MDIO without PHY interrupt !!
it was possible in the 2.4 version.
- seeing that the "fep->link" value is enabled only on a PHY interrupt .
I can't have this condition OK without PHY interrupt.
"fep->link" can be asserted in the mii_parse_sr function, but has it is
indicated in the comment in the drivers :
"/* Somehow does the 971 tell me that the link is down
* the first read after power-up.
* read here to get a valid value in ack_int */"
That's true, the LXT 971A tell that the link is down, and seeing that I
have no interrupt, the fep->link is never asserted again.
So, I have commented the first lines of the fcc_enet_start_xmit function
which verify the value of fep->link.
I have added a #ifdef PHY_INTERRUPT condition before installing the ISR
for this interrupt.
And thanks to that, I have been able to test the new driver 2.6 .
But unfortunetly this doesn't solve my problem.)
So 2.6 driver is not the solution of my problem.
I'm asking myself if this can be due to CPM21, or CPM22, or CPM119 known bugs on mpc8260 ?
(see http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf <http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf> ) but I don't think so.
Perhaps, I imagine that in fact the MPC8260 transmitter doesn't restart correctly ?
(Also, To workaround 8260 device erratum
* CPM37, we must disable and then re-enable the transmitter
* following a Late Collision, Underrun, or Retry Limit error)
Is there anybody having encounter the same problem?
Is there anybody having done some test of numerous plug/unplug during important data transfert with a half-duplex connection on mpc8260?
Is there anybody having an idea to help me ?
Thanks to the community for any help, I'm really desepareted here
(PS : sorry for my bad english)
[-- Attachment #2: Type: text/html, Size: 9656 bytes --]
^ permalink raw reply
* RE: mpc8260 fec enet transmit time out
From: atul.sabharwal @ 2006-01-10 2:39 UTC (permalink / raw)
To: r26191, hubert.loewenguth, Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 7253 bytes --]
How do you know that the FEC MAC & PHY are connected correctly? Check
the CLK's generated by the PHY.
Any signal issues (with a scope) ? Can you read/write the Phy registers
using the MDIO channel?
Check the link register in the Phy if it gives any false link status?
Also, the driver might have auto switching
Of Ethernet interfaces or might have a timeout and stop any
transmit/receive which is causing the lockup.
Force the driver to re-initialize after a timeout might be a workaround.
--
Atul
________________________________
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Ho
Jeffrey-r26191
Sent: Monday, January 09, 2006 6:27 PM
To: 'hubert.loewenguth'; Linuxppc-embedded@ozlabs.org
Subject: RE: mpc8260 fcc enet transmit time out
On MPC8560 port of linuxppc-2.4, on the Gianfar driver for TSEC and FEC,
there is a mode call phy polling mode can be enable.
In one of our hw, we are using realtek 10/100phy which don't have
interrupt as well.
We config that phy to use the polling mode in Gianfar. We can do plug
and unplug with no problem.
My suggetsion is to check how that driver do the polling and use it with
your fcc_enet.
Regards,
Jeffrey Ho
Freescale Semiconductor HK Ltd
Tel: 852-26668050
________________________________
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
hubert.loewenguth
Sent: Tuesday, January 10, 2006 1:27 AM
To: Linuxppc-embedded@ozlabs.org
Subject: mpc8260 fcc enet transmit time out
hi the community.
I have already posted a question about my problem but it seems
that nobody has encounter the same matter.
So I have made numerous tests and researches and seeing that I
still have not succeed in solving it, I try again tyo send you my bug.
I use a MPC8260 with linux 2.4.20.
The problem is with the fcc_enet driver.
I have no MII phy interrupt line with my LXT971 Phy in front of
the powerpc.
Seeing that I have no interrupt line, I have configured the
driver to be in half duplex, and the LXT971 too.
I'm sure that the driver is in half-duplex mode an the LXT971
too, and the auto-negociation is ok.
Everything works fine, but, if I do successive plugs/unplugs
during important data transfert, The driver enter into an infinite loop:
# NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f690.
Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
...
1c00 055c 011d486a
3c00 05ea 011d406a
Rx @base c019f608 :
9c00 0040 01f3e000
9c00 0040 01f3e800
...
9c00 0040 01f3d000
bc00 0040 01f2f800
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f698.
Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
1c00 05ea 011ce06a
.....
I have found, on the linux-embended forum, a personn who has the
same problem:
http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html
But I'm sure about my pin connections ans so the reponse to this
personn doesn't solve my problem
More interresting this one :
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html
This personn seems to have the same troubleshouting than me .
He has tried to apply the patch provided by freescale, but it
doesn't seem to correct it.
So I have had just a little piece of trace in order to see when
this infernal loop appear.
I have added some trace in the fcc_enet_start_xmit .
has you know, after some kind of transmit errors, the
transmitter need to be restarted, and so I have added some traces to see
when it is restarted
/* Some transmit errors cause the transmitter to shut
* down. We now issue a restart transmit. Since the
* errors close the BD and update the pointers, the
restart
* _should_ pick up without having to reset any of our
* pointers either. Also, To workaround 8260 device
erratum
* CPM37, we must disable and then re-enable the
transmitter
* following a Late Collision, Underrun, or Retry Limit
error.
*/
# UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
UNDERRUN ! ==> RESTART
CARRIER LOST !
........
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f778 tx_free 0 cur_rx c019f690.
Tx @base c019f708 :
1c02 055c 012cd86a
9c00 05ea 012cd06a
9c00 05ea 012f706a
9c00 05ea 012cf06a
9c00 05ea 012cf86a
9c00 05ea 0118506a
Some personns have said me to try with 2.6 drivers but it's
exactly the same problem.
( even if I'm a little bit surprised to see that with the 2.6
version drivers seems to be uncompatible with boards wich use MDIO
without PHY
interrupt.the #define PHY_INTERRUPT condition of the 2.4 drivers
version has
disapeared => with this new drivers you can't use MDIO without
PHY interrupt !!
it was possible in the 2.4 version.
- seeing that the "fep->link" value is enabled only on a PHY
interrupt .
I can't have this condition OK without PHY interrupt.
"fep->link" can be asserted in the mii_parse_sr function, but
has it is
indicated in the comment in the drivers :
"/* Somehow does the 971 tell me that the link is down
* the first read after power-up.
* read here to get a valid value in ack_int */"
That's true, the LXT 971A tell that the link is down, and seeing
that I
have no interrupt, the fep->link is never asserted again.
So, I have commented the first lines of the fcc_enet_start_xmit
function
which verify the value of fep->link.
I have added a #ifdef PHY_INTERRUPT condition before installing
the ISR
for this interrupt.
And thanks to that, I have been able to test the new driver 2.6
.
But unfortunetly this doesn't solve my problem.)
So 2.6 driver is not the solution of my problem.
I'm asking myself if this can be due to CPM21, or CPM22, or
CPM119 known bugs on mpc8260 ?
(see
http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf ) but
I don't think so.
Perhaps, I imagine that in fact the MPC8260 transmitter doesn't
restart correctly ?
(Also, To workaround 8260 device erratum
* CPM37, we must disable and then re-enable the
transmitter
* following a Late Collision, Underrun, or Retry Limit
error)
Is there anybody having encounter the same problem?
Is there anybody having done some test of numerous plug/unplug
during important data transfert with a half-duplex connection on
mpc8260?
Is there anybody having an idea to help me ?
Thanks to the community for any help, I'm really desepareted
here
(PS : sorry for my bad english)
[-- Attachment #2: Type: text/html, Size: 15602 bytes --]
^ permalink raw reply
* [Problem] linux 2.6.14 kernel hang up after the uImage uncompressed successfully
From: Jonathan Qiang @ 2006-01-10 3:06 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]
Hi,
I am doing booting linux kernel 2.6.14.5 from kernel.org on a kind of
embedded ppc board, where the chip mpc8272 has been settled.
But after u-boot(1.1.4) finished booting itself and uncompressed the
uImage(2.6.14.5 based). the kernel can not boot
Successfully. It stop somewhere. the script is below:
U-Boot 1.1.4 (Jan 3 2006 - 15:00:41)
MPC8272 Reset Status: Check Stop, External Soft, External Hard
MPC8272 Clock Configuration
- Bus-to-Core Mult 5x, VCO Div 2, 60x Bus Freq 20-60 , Core Freq
100-300
- dfbrg 1, corecnf 0x1b, busdf 7, cpmdf 1, plldf 0, pllmf 7
- vco_out 528000000, scc_clk 132000000, brg_clk 33000000
- cpu_clk 330000000, cpm_clk 264000000, bus_clk 66000000
- pci_clk 22000000
CPU: MPC8272 (HiP7 Rev 14, Mask 1.0 1K50M) at 330 MHz
I2C: ready
DRAM: SDRAM configuration:
Refresh rate = 47, CAS latency = 3, Using Page Based Interleave
Total size: 32 MB
FLASH Dectected: FLASH MFP, new id is 0x0089, Device ID is 0x8922
32 MB
In: serial
Out: serial
Err: serial
Ethos version: ac21 (DEVID:ac2, DEVVER:1, MFGVER: 1)
CFG_CMXFCR_VALUE=0x00370000, CFG_CMXFCR_MASK=0x007F0000
Net: FCC2 ETHERNET
Hit any key to stop autoboot: 0
Using FCC2 ETHERNET device
## Booting image at 00200000 ...
Image Name: Linux-2.6.14.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 750080 Bytes = 732.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Then I have tried to use BDI2000 to debug the kernel, It seems that the
kernel can passed on console_init function. But still no message came
out even printk(KERN_NOTICE); and printk(linux_banner);
[-- Attachment #2: Type: text/html, Size: 13796 bytes --]
^ permalink raw reply
* patch add-vio_bus_type-probe-and-remove-methods.patch added to gregkh-2.6 tree
From: gregkh @ 2006-01-10 6:00 UTC (permalink / raw)
To: rmk, greg, gregkh, linuxppc-embedded, rmk+kernel
In-Reply-To: <20060105142951.13.14@flint.arm.linux.org.uk>
This is a note to let you know that I've just added the patch titled
Subject: [CFT 14/29] Add vio_bus_type probe and remove methods
to my gregkh-2.6 tree. Its filename is
add-vio_bus_type-probe-and-remove-methods.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>From rmk+greg=kroah.com@arm.linux.org.uk Thu Jan 5 06:37:30 2006
From: Russell King <rmk@arm.linux.org.uk>
CC: Greg K-H <greg@kroah.com>, PPC <linuxppc-embedded@ozlabs.org>
Subject: [CFT 14/29] Add vio_bus_type probe and remove methods
Date: Thu, 05 Jan 2006 14:36:47 +0000
Message-ID: <20060105142951.13.14@flint.arm.linux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/powerpc/kernel/vio.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- gregkh-2.6.orig/arch/powerpc/kernel/vio.c
+++ gregkh-2.6/arch/powerpc/kernel/vio.c
@@ -76,7 +76,7 @@ static void vio_bus_shutdown(struct devi
struct vio_dev *viodev = to_vio_dev(dev);
struct vio_driver *viodrv = to_vio_driver(dev->driver);
- if (viodrv->shutdown)
+ if (dev->driver && viodrv->shutdown)
viodrv->shutdown(viodev);
}
@@ -91,9 +91,6 @@ int vio_register_driver(struct vio_drive
/* fill in 'struct driver' fields */
viodrv->driver.bus = &vio_bus_type;
- viodrv->driver.probe = vio_bus_probe;
- viodrv->driver.remove = vio_bus_remove;
- viodrv->driver.shutdown = vio_bus_shutdown;
return driver_register(&viodrv->driver);
}
@@ -295,4 +292,7 @@ struct bus_type vio_bus_type = {
.name = "vio",
.uevent = vio_hotplug,
.match = vio_bus_match,
+ .probe = vio_bus_probe,
+ .remove = vio_bus_remove,
+ .shutdown = vio_bus_shutdown,
};
Patches currently in gregkh-2.6 which might be from rmk@arm.linux.org.uk are
driver/add-bttv-sub-bus_type-probe-and-remove-methods.patch
driver/add-bus_type-probe-remove-shutdown-methods..patch
driver/add-ccwgroup_bus_type-probe-and-remove-methods.patch
driver/add-dio_bus_type-probe-and-remove-methods.patch
driver/add-ecard_bus_type-probe-remove-shutdown-methods.patch
driver/add-gameport-bus_type-probe-and-remove-methods.patch
driver/add-i2c_bus_type-probe-and-remove-methods.patch
driver/add-ide_bus_type-probe-and-remove-methods.patch
driver/add-locomo-bus_type-probe-remove-methods.patch
driver/add-logic-module-bus_type-probe-remove-methods.patch
driver/add-macio_bus_type-probe-and-remove-methods.patch
driver/add-mcp-bus_type-probe-and-remove-methods.patch
driver/add-mmc_bus_type-probe-and-remove-methods.patch
driver/add-ocp_bus_type-probe-and-remove-methods.patch
driver/add-of_platform_bus_type-probe-and-remove-methods.patch
driver/add-parisc_bus_type-probe-and-remove-methods.patch
driver/add-pci_bus_type-probe-and-remove-methods.patch
driver/add-pcmcia_bus_type-probe-and-remove-methods.patch
driver/add-pnp_bus_type-probe-and-remove-methods.patch
driver/add-pseudo-lld-bus_type-probe-and-remove-methods.patch
driver/add-rio_bus_type-probe-and-remove-methods.patch
driver/add-sa1111-bus_type-probe-remove-methods.patch
driver/add-serio-bus_type-probe-and-remove-methods.patch
driver/add-sh_bus_type-probe-and-remove-methods.patch
driver/add-superhyway_bus_type-probe-and-remove-methods.patch
driver/add-tiocx-bus_type-probe-remove-methods.patch
driver/add-usb_serial_bus_type-probe-and-remove-methods.patch
driver/add-vio_bus_type-probe-and-remove-methods.patch
driver/add-zorro_bus_type-probe-and-remove-methods.patch
driver/remove-usb-gadget-generic-driver-methods.patch
^ permalink raw reply
* patch add-of_platform_bus_type-probe-and-remove-methods.patch added to gregkh-2.6 tree
From: gregkh @ 2006-01-10 6:00 UTC (permalink / raw)
To: rmk, greg, gregkh, linuxppc-embedded, rmk+kernel
In-Reply-To: <20060105142951.13.13@flint.arm.linux.org.uk>
This is a note to let you know that I've just added the patch titled
Subject: [CFT 13/29] Add of_platform_bus_type probe and remove methods
to my gregkh-2.6 tree. Its filename is
add-of_platform_bus_type-probe-and-remove-methods.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>From rmk+greg=kroah.com@arm.linux.org.uk Thu Jan 5 06:37:22 2006
From: Russell King <rmk@arm.linux.org.uk>
CC: Greg K-H <greg@kroah.com>, PowerPC <linuxppc-embedded@ozlabs.org>
Subject: [CFT 13/29] Add of_platform_bus_type probe and remove methods
Date: Thu, 05 Jan 2006 14:36:16 +0000
Message-ID: <20060105142951.13.13@flint.arm.linux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/powerpc/kernel/of_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- gregkh-2.6.orig/arch/powerpc/kernel/of_device.c
+++ gregkh-2.6/arch/powerpc/kernel/of_device.c
@@ -132,6 +132,8 @@ static int of_device_resume(struct devic
struct bus_type of_platform_bus_type = {
.name = "of_platform",
.match = of_platform_bus_match,
+ .probe = of_device_probe,
+ .remove = of_device_remove,
.suspend = of_device_suspend,
.resume = of_device_resume,
};
@@ -150,8 +152,6 @@ int of_register_driver(struct of_platfor
/* initialize common driver fields */
drv->driver.name = drv->name;
drv->driver.bus = &of_platform_bus_type;
- drv->driver.probe = of_device_probe;
- drv->driver.remove = of_device_remove;
/* register with core */
count = driver_register(&drv->driver);
Patches currently in gregkh-2.6 which might be from rmk@arm.linux.org.uk are
driver/add-bttv-sub-bus_type-probe-and-remove-methods.patch
driver/add-bus_type-probe-remove-shutdown-methods..patch
driver/add-ccwgroup_bus_type-probe-and-remove-methods.patch
driver/add-dio_bus_type-probe-and-remove-methods.patch
driver/add-ecard_bus_type-probe-remove-shutdown-methods.patch
driver/add-gameport-bus_type-probe-and-remove-methods.patch
driver/add-i2c_bus_type-probe-and-remove-methods.patch
driver/add-ide_bus_type-probe-and-remove-methods.patch
driver/add-locomo-bus_type-probe-remove-methods.patch
driver/add-logic-module-bus_type-probe-remove-methods.patch
driver/add-macio_bus_type-probe-and-remove-methods.patch
driver/add-mcp-bus_type-probe-and-remove-methods.patch
driver/add-mmc_bus_type-probe-and-remove-methods.patch
driver/add-ocp_bus_type-probe-and-remove-methods.patch
driver/add-of_platform_bus_type-probe-and-remove-methods.patch
driver/add-parisc_bus_type-probe-and-remove-methods.patch
driver/add-pci_bus_type-probe-and-remove-methods.patch
driver/add-pcmcia_bus_type-probe-and-remove-methods.patch
driver/add-pnp_bus_type-probe-and-remove-methods.patch
driver/add-pseudo-lld-bus_type-probe-and-remove-methods.patch
driver/add-rio_bus_type-probe-and-remove-methods.patch
driver/add-sa1111-bus_type-probe-remove-methods.patch
driver/add-serio-bus_type-probe-and-remove-methods.patch
driver/add-sh_bus_type-probe-and-remove-methods.patch
driver/add-superhyway_bus_type-probe-and-remove-methods.patch
driver/add-tiocx-bus_type-probe-remove-methods.patch
driver/add-usb_serial_bus_type-probe-and-remove-methods.patch
driver/add-vio_bus_type-probe-and-remove-methods.patch
driver/add-zorro_bus_type-probe-and-remove-methods.patch
driver/remove-usb-gadget-generic-driver-methods.patch
^ permalink raw reply
* patch add-macio_bus_type-probe-and-remove-methods.patch added to gregkh-2.6 tree
From: gregkh @ 2006-01-10 6:00 UTC (permalink / raw)
To: rmk, greg, gregkh, linuxppc-dev, rmk+kernel
In-Reply-To: <20060105142951.13.19@flint.arm.linux.org.uk>
This is a note to let you know that I've just added the patch titled
Subject: [CFT 19/29] Add macio_bus_type probe and remove methods
to my gregkh-2.6 tree. Its filename is
add-macio_bus_type-probe-and-remove-methods.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>From rmk+greg=kroah.com@arm.linux.org.uk Thu Jan 5 06:42:59 2006
From: Russell King <rmk@arm.linux.org.uk>
CC: Greg K-H <greg@kroah.com>, MAC <linuxppc-dev@ozlabs.org>
Subject: [CFT 19/29] Add macio_bus_type probe and remove methods
Date: Thu, 05 Jan 2006 14:39:24 +0000
Message-ID: <20060105142951.13.19@flint.arm.linux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/macintosh/macio_asic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- gregkh-2.6.orig/drivers/macintosh/macio_asic.c
+++ gregkh-2.6/drivers/macintosh/macio_asic.c
@@ -204,6 +204,9 @@ struct bus_type macio_bus_type = {
.name = "macio",
.match = macio_bus_match,
.uevent = macio_uevent,
+ .probe = macio_device_probe,
+ .remove = macio_device_remove,
+ .shutdown = macio_device_shutdown,
.suspend = macio_device_suspend,
.resume = macio_device_resume,
.dev_attrs = macio_dev_attrs,
@@ -487,9 +490,6 @@ int macio_register_driver(struct macio_d
/* initialize common driver fields */
drv->driver.name = drv->name;
drv->driver.bus = &macio_bus_type;
- drv->driver.probe = macio_device_probe;
- drv->driver.remove = macio_device_remove;
- drv->driver.shutdown = macio_device_shutdown;
/* register with core */
count = driver_register(&drv->driver);
Patches currently in gregkh-2.6 which might be from rmk@arm.linux.org.uk are
driver/add-bttv-sub-bus_type-probe-and-remove-methods.patch
driver/add-bus_type-probe-remove-shutdown-methods..patch
driver/add-ccwgroup_bus_type-probe-and-remove-methods.patch
driver/add-dio_bus_type-probe-and-remove-methods.patch
driver/add-ecard_bus_type-probe-remove-shutdown-methods.patch
driver/add-gameport-bus_type-probe-and-remove-methods.patch
driver/add-i2c_bus_type-probe-and-remove-methods.patch
driver/add-ide_bus_type-probe-and-remove-methods.patch
driver/add-locomo-bus_type-probe-remove-methods.patch
driver/add-logic-module-bus_type-probe-remove-methods.patch
driver/add-macio_bus_type-probe-and-remove-methods.patch
driver/add-mcp-bus_type-probe-and-remove-methods.patch
driver/add-mmc_bus_type-probe-and-remove-methods.patch
driver/add-ocp_bus_type-probe-and-remove-methods.patch
driver/add-of_platform_bus_type-probe-and-remove-methods.patch
driver/add-parisc_bus_type-probe-and-remove-methods.patch
driver/add-pci_bus_type-probe-and-remove-methods.patch
driver/add-pcmcia_bus_type-probe-and-remove-methods.patch
driver/add-pnp_bus_type-probe-and-remove-methods.patch
driver/add-pseudo-lld-bus_type-probe-and-remove-methods.patch
driver/add-rio_bus_type-probe-and-remove-methods.patch
driver/add-sa1111-bus_type-probe-remove-methods.patch
driver/add-serio-bus_type-probe-and-remove-methods.patch
driver/add-sh_bus_type-probe-and-remove-methods.patch
driver/add-superhyway_bus_type-probe-and-remove-methods.patch
driver/add-tiocx-bus_type-probe-remove-methods.patch
driver/add-usb_serial_bus_type-probe-and-remove-methods.patch
driver/add-vio_bus_type-probe-and-remove-methods.patch
driver/add-zorro_bus_type-probe-and-remove-methods.patch
driver/remove-usb-gadget-generic-driver-methods.patch
^ permalink raw reply
* Re: [Problem] linux 2.6.14 kernel hang up after the uImage uncompressed successfully
From: Wolfgang Denk @ 2006-01-10 8:23 UTC (permalink / raw)
To: Jonathan Qiang; +Cc: linuxppc-embedded
In-Reply-To: <32A7B31E4005134E8BA805EBAAFB9DCD9C7A1C@hellskitchen.haliplex.com.au>
In message <32A7B31E4005134E8BA805EBAAFB9DCD9C7A1C@hellskitchen.haliplex.com.au> you wrote:
>
> I am doing booting linux kernel 2.6.14.5 from kernel.org on a kind of
> embedded ppc board, where the chip mpc8272 has been settled.
> But after u-boot(1.1.4) finished booting itself and uncompressed the
> uImage(2.6.14.5 based). the kernel can not boot
> Successfully. It stop somewhere. the script is below:
Read a FAQ: http://www.denx.de/wiki/view/DULG/FaqLinux
Try a port mortem dump of the log buffer area.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"A fractal is by definition a set for which the Hausdorff Besicovitch
dimension strictly exceeds the topological dimension."
- Mandelbrot, _The Fractal Geometry of Nature_
^ permalink raw reply
* Exceptin occurs after execute activate_mm()
From: happa @ 2006-01-10 8:58 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3318 bytes --]
Hi,
I am booting my linux kernel via NFS.
Here is my environment:
CPU:Motorola ppc8245
Linux version 2.6.14
gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9)
The root file system is mounted via NFS, than it start to call "run_init_process("/sbin/init")".
After do this, the following error message will dump.
Oops: kernel access of bad area, sig: 11 [#2]
NIP: 00153884 LR: 0003AC7C SP: 00581390 REGS: 005812e0 TRAP: 0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 11000F5A, DSISR: 08000000
TASK = 0057f730[1] 'init' THREAD: 00580000
Last syscall: 11
GPR00: 11000F5A 00581390 0057F730 00000003 00586000 00581420 00581460 0000000A
GPR08: 00274000 11000F00 00000000 00290000 0057F900 50482121 10016DB4 10016DB4
GPR16: 00000000 0A3421AD 00000000 00000801 00000074 00000000 0000007C 005D2AA0
GPR24: 00581420 00581420 00000003 00000003 00274060 00000000 00586000 005D2AA0
NIP [00153884] ipg_interrupt_handler+0x1c/0x114
LR [0003ac7c] __do_IRQ+0x164/0x214
Call trace:
[0003ac7c] __do_IRQ+0x164/0x214
[00006280] do_IRQ+0x3c/0x9c
[00005050] ret_from_except+0x0/0x14
[00005328] die+0x94/0x98
[0000e6cc] bad_page_fault+0x48/0x5c
[00004e30] handle_page_fault+0x7c/0x80
[001797e8] __alloc_skb+0x64/0x12c
[0018f9d0] qdisc_restart+0x100/0x1fc
[00180a04] dev_queue_xmit+0x10c/0x258
[0019eda4] ip_output+0x238/0x2a0
[0019e82c] ip_push_pending_frames+0x334/0x438
[001be790] udp_push_pending_frames+0x1dc/0x200
[001bd78c] udp_sendmsg+0x528/0x600
[001c6168] inet_sendmsg+0xb4/0xc8
[00173510] sock_sendmsg+0xac/0xcc
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
>From dump messages I ckeck the source code in function "ipg_interrupt_handler+0x1c/0x114", the exception
is cause by access PCI memory space of my NIC device, but this access is fine before run_init_process("/sbin/init")
is called.
Here is my NIC device logical and physical mappping.
The physical base address of this NIC is assign to 0xbffcff00
The virtual memory is map to 0x11000F00
I also trace call stack for run_init_process("/sbin/init").
run_init_process("/sbin/init")
|
v
...wait until the file got from NFS .....
|
v
load_elf_binary()
|
v
flush_old_exec()
|
v
exec_mmap()
|
v
activate_mm() ---> After this function is called, to access PCI memory space of my NIC device the excepton will occur.
I have also check "Segment Regiser" of mpc8245.
Before the activate_mm() called the "Segment Regiser" is list as follow:
SR0 : 20000000
SR1 : 20000111
SR2 : 20000222
SR3 : 20000333
SR4 : 20000444
SR5 : 20000555
SR6 : 20000666
SR7 : 20000777
SR8 : 20000888
SR9 : 20000999
SR10 : 20000AAA
SR11 : 20000BBB
SR12 : 20000CCC
SR13 : 20000DDD
SR14 : 20000EEE
SR15 : 20000FFF
After the activate_mm() called the "Segment Regiser" is list as follow:
SR0 : 60003810
SR1 : 60003921
SR2 : 60003A32
SR3 : 60003B43
SR4 : 60003C45
SR5 : 60003D65
SR6 : 60003E76
SR7 : 60003F87
SR8 : 20000888
SR9 : 20000999
SR10 : 20000AAA
SR11 : 20000BBB
SR12 : 20000CCC
SR13 : 20000DDD
SR14 : 20000EEE
SR15 : 20000FFF
I think the memory translate have problem after call "activate_mm()".
Is my MMU setting have problems, or someone would tell me which setting or configure I need to check?
/Wen
^ permalink raw reply
* Re: [Problem] linux 2.6.14 kernel hang up after the uImage uncompressed successfully
From: Vitaly Bordug @ 2006-01-10 9:32 UTC (permalink / raw)
To: Jonathan Qiang; +Cc: linuxppc-embedded
In-Reply-To: <32A7B31E4005134E8BA805EBAAFB9DCD9C7A1C@hellskitchen.haliplex.com.au>
Jonathan Qiang wrote:
> Hi,
>
>
>
> I am doing booting linux kernel 2.6.14.5 from kernel.org on a kind of
> *embedded ppc board, where the chip mpc8272 has been settled.*
>
> *But after u-boot(1.1.4) finished booting itself and uncompressed the
> uImage(2.6.14.5 based). the kernel can not boot*
>
This looks like odd or incomplete bootargs. Please search the list for relevant issues,
the likewise questions has been answered several times by me at least.
> *Successfully. It stop somewhere. the script is below: *
>
> * *
>
> * *
>
> U-Boot 1.1.4 (Jan 3 2006 - 15:00:41)
>
>
>
> MPC8272 Reset Status: Check Stop, External Soft, External Hard
>
>
>
> MPC8272 Clock Configuration
>
> - Bus-to-Core Mult 5x, VCO Div 2, 60x Bus Freq 20-60 , Core Freq 100-300
>
> - dfbrg 1, corecnf 0x1b, busdf 7, cpmdf 1, plldf 0, pllmf 7
>
> - vco_out 528000000, scc_clk 132000000, brg_clk 33000000
>
> - cpu_clk 330000000, cpm_clk 264000000, bus_clk 66000000
>
> - pci_clk 22000000
>
>
>
> CPU: MPC8272 (HiP7 Rev 14, Mask 1.0 1K50M) at 330 MHz
>
> I2C: ready
>
> DRAM: SDRAM configuration:
>
> Refresh rate = 47, CAS latency = 3, Using Page Based Interleave
>
> Total size: 32 MB
>
> FLASH Dectected: FLASH MFP, new id is 0x0089, Device ID is 0x8922
>
> 32 MB
>
> In: serial
>
> Out: serial
>
> Err: serial
>
> Ethos version: ac21 (DEVID:ac2, DEVVER:1, MFGVER: 1)
>
> CFG_CMXFCR_VALUE=0x00370000, CFG_CMXFCR_MASK=0x007F0000
>
> Net: FCC2 ETHERNET
>
> Hit any key to stop autoboot: 0
>
> Using FCC2 ETHERNET device
>
> ## Booting image at 00200000 ...
>
> Image Name: Linux-2.6.14.5
>
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
>
> Data Size: 750080 Bytes = 732.5 kB
>
> Load Address: 00000000
>
> Entry Point: 00000000
>
> Verifying Checksum ... OK
>
> Uncompressing Kernel Image ... OK
>
>
>
> Then I have tried to use BDI2000 to debug the kernel, It seems that the
> kernel can passed on console_init function. But still no message came
> out even printk(KERN_NOTICE); and printk(linux_banner);
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Enable a PCMCIA Bluetooth card in custom MPC860 system
From: Vitaly Bordug @ 2006-01-10 9:40 UTC (permalink / raw)
To: Lo Chun Chung; +Cc: linuxppc-embedded
In-Reply-To: <20060110013947.66617.qmail@web53712.mail.yahoo.com>
Lo Chun Chung wrote:
> Thanks for your hint. But the file is just for Linux Kernel Version 2.6,
> is this also OK for me? (I am using a 2.4 kernel)
>
That's just for reference.
> But I doubt that same technique can be applied since the Bluetooth
> should only be enabled when I loaded the pcmcia drivers (pcmcia_core.o,
> m8xx_pcmcia.o and ds.o), so ....
>
The way I know is to configure serial stuff before serial.o insmoded, so it could get right offsets and other stuff.
Look at the serial code, and if the only way to do mentioned is to configure it compile-time, than you'll have to implement
something. But I beleive another serial PCMCIA exist, that does it right way.
> how can I pre-set some settings during boot-time that I have not yet
> insert the pcmcia modules into the kernel?
>
> Also the last thing is, since there is not "hotplug" in my system and
> resources allocation is different from standard PCs, so I cannot let my
> embedded system to auto-detect a standard uart has been added during the
> PCMCIA bluetooth card is plugged in (while standard PC will)
>
> or can anybody tell me that how can I realize hotplug in my system? (is
> this can be worked out?)
>
I don't know hotplug stuff very well, but I guess to find the way to solve your problem
will be easier.
> Thanks
>
> */Vitaly Bordug <vbordug@ru.mvista.com>/* 說：
>
> Lo Chun Chung wrote:
> > Dear all,
> >
> > I am a student from Hong Kong. Now I am doing a project about
> enabling a
> > Bluetooth PCMCIA card (Billionton PCBTC1A-B) in a custom MPC860PC.
> >
> > (The custom MPC860 system is constructed by a MPC860 Processor
> Card and
> > a custom made PCB to adding a PCMCIA interface to the processor
> Card.)
> >
> > Now my stage is: the LINUX (Linux Kernel 2.4.25 from ELDK 3.1 for
> > powerpc) can recognise the card by cardctl, and here are the
> screen dump:
> >
> > / # cardctl ident
> > Socket 0:
> > product info: "PCMCIA", "Bluetooth Card", "", ""
> > manfid: 0x0279, 0x950b
> > function: 2 (serial)
> > / # cardctl status
> > Socket 0:
> > 5V 16-bit PC Card
> > function 0: [ready], [bat dead], [bat low]
> >! / # cardctl info
> > PRODID_1="PCMCIA"
> > PRODID_2="Bluetooth Card"
> > PRODID_3=""
> > PRODID_4=""
> > MANFID=0279,950b
> > FUNCID=2
> > / # cardct! l config
> > Socket 0:
> > Vcc 5.0V Vpp1 5.0V Vpp2 5.0V
> >
> > but after I load all the modules needed (should be these?)
> >
> > / # lsmod
> > Module Size Used by Not tainted
> > hci_uart 14836 0 (unused)
> > l2cap 22956 0 (unused)
> > bluez 43856 0 [hci_uart l2cap]
> > ds 8060 0
> > m8xx_pcmcia 5164 1
> > pcmcia_core 39520 0 [ds m8xx_pcmcia]
> >
> > my bluetooth still cannot get working ...
> >
> > then I try to insert "serial_cs" as my bluetooth card is a uart base
> > card. but some message given out:
> >
> > / # insmod serial_cs
> > Using /lib/modules/2.4.25/serial_cs.o
> > insmod: unresolved symbol unregister_serial
> > insmod: unresolved symbol register_serial
> >
> > so I realize that I sho! uld also insert "serial.o" into the
> linux, but
> > crashes ...
> >
> > / # insmod serial
> > Using /lib/modules/2.4.25/serial.o
> > Serial driver version 5.05c (2001-07-08) with MANY_PORTS
> SHARE_IRQ enabled
> > Machine check in kernel mode.
> > Caused by (from SRR1=1032): Transfer error ack signal
> > ! Oops: machine check, sig: 7
> > NIP: C3040078 XER: 00000000 LR: C3044724 SP: C1CC1D60 REGS: c1cc1cb0
> > TRAP: 0200 No
> > t tainted
> > MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
> > TASK = c1cc0000[33] 'busybox' Last syscall: 128
> > last math 00000000 last altivec 00000000
> > GPR00: 00000000 C1CC1D60 C1CC0000 C1CC1D70 00000004 00000001
> 00000B4B
> > C015378B
> > GPR08: 00000000 800003FC 00000003 C1CC1C70 C0170000 10084438
> 00000000
> > 00000000
> > GPR16: 00000000 00000000 00000000 00000000 00009032 1016EDB0
> C1D3A000
> > C1CC1EA0
> > GPR24: C1F6B760 00000006 C304973C C1CC1D70 C3040000 00000000
> 00000000
> > C3046348
> > Call backtrace:
> > C3044718 C3045188 C0012440 C00043BC 10080000 10021DF0 100238CC
> > 1000457C 100041A0 1000436C 1000457C 100041A0 0FE70EF4 00000000
> >
> > I only knows when i insert the serial.o, this driver will try to
> access
> > the standard uart which is not available in my system (my system
> only
> > has one uart by SMC1), then the system will crash eac! h time the
> > driver wants to access the registers does not available ...
> >
> > The project deadline is near ... so I ask here ...
> >
> > can anyone helps me or give me some clues?
> >
> You should take a look for instance how 8349 does this job
> (arch/ppc/syslib/ppc83xx_setup.c) - it also has "standard" UART, but
> some stuff needs to be set up
> prior to serial.o. Of course that is not complete solution for your
> case, just a hint...
> > Thanks all
> >
> >
> >
> >
> > Best regards,
> > Chung
> >
> > _______________________________________
> > YM - 離線訊息
> > 就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看
> 到，任何
> > 說話都冇走失。
> > http://messenger.yahoo.com.hk
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> --
> Sincerely,
> Vitaly
>
>
>
>
> Best regards,
> Chung
>
> _______________________________________
> YM - 離線訊息
> 就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何
> 說話都冇走失。
> http://messenger.yahoo.com.hk
>
--
Sincerely,
Vitaly
^ permalink raw reply
* RES: [Problem] linux 2.6.14 kernel hang up after the uImage uncompressedsuccessfully
From: Sugeno, Otavio Isamu @ 2006-01-10 9:56 UTC (permalink / raw)
To: Jonathan Qiang; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2806 bytes --]
Hi.
I suggest you check the bd_info structure, if they are the same at u-boot and linux kernel.
See also the link below, it is always a good source to solve problems:
http://www.denx.de/wiki/bin/view/DULG/LinuxHangsAfterUncompressingKernel
If it is the bd_info is ok, so probably your problem is with some configuration in you board or something that it is not working properly.
Try to compile a linux kernel only with basic features that you need, for example, serial and ethernet and check what happens.
Otavio I. Sugeno
Information & Communication
Com EN PSY DA
Phone: +55 41 341-5883
Fax: +55 41 341-5594
email: otavio.sugeno@siemens.com
Siemens Brasil 2005 * 100 ANOS
________________________________
De: linuxppc-embedded-bounces@ozlabs.org [mailto:linuxppc-embedded-bounces@ozlabs.org] Em nome de Jonathan Qiang
Enviada em: terça-feira, 10 de janeiro de 2006 01:06
Para: linuxppc-embedded@ozlabs.org
Assunto: [Problem] linux 2.6.14 kernel hang up after the uImage uncompressedsuccessfully
Hi,
I am doing booting linux kernel 2.6.14.5 from kernel.org on a kind of embedded ppc board, where the chip mpc8272 has been settled.
But after u-boot(1.1.4) finished booting itself and uncompressed the uImage(2.6.14.5 based). the kernel can not boot
Successfully. It stop somewhere. the script is below:
U-Boot 1.1.4 (Jan 3 2006 - 15:00:41)
MPC8272 Reset Status: Check Stop, External Soft, External Hard
MPC8272 Clock Configuration
- Bus-to-Core Mult 5x, VCO Div 2, 60x Bus Freq 20-60 , Core Freq 100-300
- dfbrg 1, corecnf 0x1b, busdf 7, cpmdf 1, plldf 0, pllmf 7
- vco_out 528000000, scc_clk 132000000, brg_clk 33000000
- cpu_clk 330000000, cpm_clk 264000000, bus_clk 66000000
- pci_clk 22000000
CPU: MPC8272 (HiP7 Rev 14, Mask 1.0 1K50M) at 330 MHz
I2C: ready
DRAM: SDRAM configuration:
Refresh rate = 47, CAS latency = 3, Using Page Based Interleave
Total size: 32 MB
FLASH Dectected: FLASH MFP, new id is 0x0089, Device ID is 0x8922
32 MB
In: serial
Out: serial
Err: serial
Ethos version: ac21 (DEVID:ac2, DEVVER:1, MFGVER: 1)
CFG_CMXFCR_VALUE=0x00370000, CFG_CMXFCR_MASK=0x007F0000
Net: FCC2 ETHERNET
Hit any key to stop autoboot: 0
Using FCC2 ETHERNET device
## Booting image at 00200000 ...
Image Name: Linux-2.6.14.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 750080 Bytes = 732.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Then I have tried to use BDI2000 to debug the kernel, It seems that the kernel can passed on console_init function. But still no message came out even printk(KERN_NOTICE); and printk(linux_banner);
[-- Attachment #2: Type: text/html, Size: 17393 bytes --]
^ permalink raw reply
* port linux to prpmc610 kernel-2.4.25 with MVME2100 patch
From: siman @ 2006-01-10 12:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060110082311.B29B1689DF@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 987 bytes --]
Hi All:
I still work for port the Linux to the prpmc610 board. I get the MVME2100
patch on the kernel-2.4.25, so I port base it, because the MVME2100 have the
MPC8240 CPU similar the MPC8245, they all have 603e core.
I use the light a LED on the prpmc610 to trace the kernel code. I start at
the "head's", I found it will be dead on CPU initial. The detail
information is dead on the file "cpu_setup_6xx.S" function below:
setup_common_caches:
mfspr r11,HID0
andi. r0,r11,HID0_DCE
ori r11,r11,HID0_ICE|HID0_DCE
ori r8,r11,HID0_ICFI
bne 1f /* don't invalidate the D-cache */
ori r8,r8,HID0_DCI /* unless it wasn't enabled */
1: sync
mtspr HID0,r8 /* enable and invalidate caches */
sync
mtspr HID0,r11 /* enable caches */
sync
isync
blr
it will be dead on the "mtspr HID0,r8 /* enable and
invalidate caches */" ,
who has any experience for this, Please tell me, Thank you so much.
The attached is MVME2100 patch file.
Any very good man may tell me why dead?
[-- Attachment #2: mvme2100-linux-2.4.25.patch.bz2 --]
[-- Type: application/octet-stream, Size: 9130 bytes --]
^ permalink raw reply
* [2.6 patch] arch/powerpc/Kconfig: fix GENERIC_TBSYNC dependencies
From: Adrian Bunk @ 2006-01-10 13:02 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel, Jean-Luc Leger
This patch fixes the dependencies of GENERIC_TBSYNC (this bug was found
by Jean-Luc Leger <reiga@dspnet.fr.eu.org>).
Additionally, it removes the superfluous "default n".
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.15-mm2-full/arch/powerpc/Kconfig.old 2006-01-10 13:59:33.000000000 +0100
+++ linux-2.6.15-mm2-full/arch/powerpc/Kconfig 2006-01-10 13:59:57.000000000 +0100
@@ -406,8 +406,7 @@
config GENERIC_TBSYNC
bool
- default y if CONFIG_PPC32 && CONFIG_SMP
- default n
+ default y if PPC32 && SMP
source "drivers/cpufreq/Kconfig"
^ permalink raw reply
* [DRM] How is the agp_special_page implemented for kernel 2.6(uninorth-agp) PPC?
From: dabby bentam @ 2006-01-10 15:27 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Im having more luck with the articiaS agpgart driver, 90% nearly there!
I noticed the uninorth agp uses the agp_special_page function, as ppc
architecture works different to i386 when remapping memory across the
aperture (gatt).
I saw this patch for Xfree86 4.3.0
http://dev.gentoo.org/~spyderous/xfree/patchsets/4.3.0/patch/5114_all_4.3.0-radeon-drm-ioremapagp.patch
I'm assuming this is for kernel 2.4? How does kernel 2.6 use this functions?
As i would like to use this code for the articiaS agpgart driver. But i
need to add #define for specific ppc boards i.e amigaone and pegasos 1.
Thanks for any help or info
Pegxlin DEV (aka dabby bentam)
PegXlin Developer
Pegxmac, Pegxlin
Versatile LIVE CD's for Pegasos Mainboards
http://pegxmac.zftp.com
http://www.pegasosppc.com
^ permalink raw reply
* Error: Three ML403 boards
From: Paula Saameño @ 2006-01-10 16:20 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
Hello,
I have 3 Xilinx ML403 boards. I have implemented a 2.4 kernel with a basic
configuration, with network support, systemACE, IIC... and it works
perfectly in one of them.
However, when I put the ACE card, without making any change, in other ML403
board, it does not work. The .ace file is loaded ok but then the network
leds (6 leds) start blinking and nothing else happens.
I have tried with two ML403 different boards, and I have no idea of where
the problem is. They should work in the same way, don't they?
Any help would be great.
Also, I am trying to load a 2.6 kernel, but I am still on the way. I will
let you know if I get it working.
Thanks a lot!
Paula
[-- Attachment #2: Type: text/html, Size: 750 bytes --]
^ permalink raw reply
* [PATCH] dtc: Update flat OF doc for new mdio properties
From: Becky Bruce @ 2006-01-10 19:16 UTC (permalink / raw)
To: david; +Cc: linuxppc-dev
Add device-type and compatible as required fields for mdio node; add eTSEC
to ethernet model options.
Signed-off-by: Becky Bruce <Becky.bruce@freescale.com>
---
commit 411a8d127af0305a9f81b893bb8e64a94031ec4f
tree d88ace9ae751e7ef53b1171230cd1bfe8d446fab
parent 986c272d66da52a952758c0d1c9f58f67e2b2251
author Becky Bruce <becky.bruce@freescale.com> Tue, 10 Jan 2006 13:04:31 -0600
committer Becky Bruce <becky.bruce@freescale.com> Tue, 10 Jan 2006 13:04:31 -0600
Documentation/booting-without-of.txt | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/booting-without-of.txt b/Documentation/booting-without-of.txt
index 1be1760..60d5b7a 100644
--- a/Documentation/booting-without-of.txt
+++ b/Documentation/booting-without-of.txt
@@ -1162,6 +1162,9 @@ platforms are moved over to use the flat
Required properties:
- reg : Offset and length of the register set for the device
+ - device_type : Should be "mdio"
+ - compatible : Should define the compatible device type for the
+ mdio. Currently, this is most likely to be "gianfar"
Example:
@@ -1179,7 +1182,7 @@ platforms are moved over to use the flat
Required properties:
- device_type : Should be "network"
- - model : Model of the device. Can be "TSEC" or "FEC"
+ - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
- compatible : Should be "gianfar"
- reg : Offset and length of the register set for the device
- address : List of bytes representing the ethernet address of
@@ -1317,6 +1320,8 @@ not necessary as they are usually the sa
mdio@24520 {
reg = <24520 20>;
+ device_type = "mdio";
+ compatible = "gianfar";
ethernet-phy@0 {
linux,phandle = <2452000>
^ permalink raw reply related
* [PATCH] enable the RTC driver in ppc64_defconfig
From: Olaf Hering @ 2006-01-10 20:57 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Enable the RTC driver.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/configs/ppc64_defconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.15-olh/arch/powerpc/configs/ppc64_defconfig
===================================================================
--- linux-2.6.15-olh.orig/arch/powerpc/configs/ppc64_defconfig
+++ linux-2.6.15-olh/arch/powerpc/configs/ppc64_defconfig
@@ -878,7 +878,7 @@ CONFIG_HVCS=m
#
# CONFIG_WATCHDOG is not set
# CONFIG_RTC is not set
-# CONFIG_GEN_RTC is not set
+CONFIG_GEN_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: 2.6.15-mm2
From: Serge E. Hallyn @ 2006-01-10 21:20 UTC (permalink / raw)
To: Andrew Morton, lkml; +Cc: linuxppc-dev
In-Reply-To: <20060107052221.61d0b600.akpm@osdl.org>
Quoting Andrew Morton (akpm@osdl.org):
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15/2.6.15-mm2/
With both this and 2.6.15-mm1, but not with 2.6.15, I get the following
error:
mm/built-in.o(*ABS*+0x39c3c7ac): In function `__crc___handle_mm_fault':
slab.c: multiple definition of `__crc___handle_mm_fault'
make: *** [.tmp_vmlinux1] Error 1
The culprit appears to be that there are two places where
__handle_mm_fault is EXPORT_SYMBOL_GPLed. The following trivial patch
fixes it for me.
Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Index: linux-2.6.15/arch/powerpc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.15.orig/arch/powerpc/kernel/ppc_ksyms.c 2006-01-10 04:59:11.000000000 -0600
+++ linux-2.6.15/arch/powerpc/kernel/ppc_ksyms.c 2006-01-10 09:07:40.000000000 -0600
@@ -240,8 +240,6 @@ EXPORT_SYMBOL(next_mmu_context);
EXPORT_SYMBOL(set_context);
#endif
-EXPORT_SYMBOL_GPL(__handle_mm_fault);
-
#ifdef CONFIG_PPC_STD_MMU_32
extern long mol_trampoline;
EXPORT_SYMBOL(mol_trampoline); /* For MOL */
thanks,
-serge
^ permalink raw reply
* Re: Error: Three ML403 boards
From: Peter Ryser @ 2006-01-10 22:10 UTC (permalink / raw)
To: Paula Saameño; +Cc: linuxppc-embedded
In-Reply-To: <259581790601100820s42d1a311ye40bfcf4ba6c9bd5@mail.gmail.com>
Paula,
please verify that you are not running into the problem described in=20
Xilinx Answer Record 22179=20
(http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=3D1&iCountryI=
D=3D1&getPagePath=3D22179).
- Peter
Paula Saame=F1o wrote:
> Hello,
>
> I have 3 Xilinx ML403 boards. I have implemented a 2.4 kernel with a=20
> basic configuration, with network support, systemACE, IIC... and it=20
> works perfectly in one of them.
>
> However, when I put the ACE card, without making any change, in other=20
> ML403 board, it does not work. The .ace file is loaded ok but then the=20
> network leds (6 leds) start blinking and nothing else happens.
>
> I have tried with two ML403 different boards, and I have no idea of=20
> where the problem is. They should work in the same way, don't they?
>
> Any help would be great.
>
> Also, I am trying to load a 2.6 kernel, but I am still on the way. I=20
> will let you know if I get it working.
>
> Thanks a lot!
> Paula
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [PATCH] powerpc: fix large nvram access
From: Olaf Hering @ 2006-01-10 22:13 UTC (permalink / raw)
To: linuxppc-dev, arndb
In-Reply-To: <200601091916.k09JGMJY004116@hera.kernel.org>
On Mon, Jan 09, Linux Kernel Mailing List wrote:
> tree da8f883f72d08f9534e9eca3bba662413b9bd865
> parent d52771fce4e774fa786097d34412a057d487c697
> author Arnd Bergmann <arnd@arndb.de> Fri, 09 Dec 2005 19:21:44 +0100
> committer Paul Mackerras <paulus@samba.org> Mon, 09 Jan 2006 14:53:31 +1100
>
> [PATCH] powerpc: fix large nvram access
>
> /dev/nvram uses the user-provided read/write size
> for kmalloc, which fails, if a large number is passed.
> This will always use a single page at most, which
> can be expected to succeed.
>
> Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
>
> arch/powerpc/kernel/nvram_64.c | 114 +++++++++++++++++++----------------------
this change breaks my nvsetenv binary on JS20.
(none):/# mount proc ; nvsetenv
Error reading /dev/nvram: Success
(none):/# strace -f nvsetenv
execve("/sbin/nvsetenv", ["nvsetenv"], [/* 61 vars */]) = 0
brk(0) = 0x10014000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fe0000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=171714, ...}) = 0
mmap(NULL, 171714, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7fb6000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\325"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1569515, ...}) = 0
mmap(0xfe99000, 1401836, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xfe99000
madvise(0xfe99000, 1401836, MADV_SEQUENTIAL|0x1) = 0
mprotect(0xffd8000, 65536, PROT_NONE) = 0
mmap(0xffe8000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13f000) = 0xffe8000
mmap(0xffed000, 9196, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffed000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fb5000
mprotect(0xffe8000, 4096, PROT_READ) = 0
munmap(0xf7fb6000, 171714) = 0
brk(0) = 0x10014000
brk(0x10035000) = 0x10035000
open("/proc/device-tree/compatible", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=13, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fdf000
read(3, "IBM,1234-123\0", 1024) = 13
read(3, "", 1024) = 0
close(3) = 0
munmap(0xf7fdf000, 4096) = 0
open("/dev/nvram", O_RDONLY) = 3
read(3, "P\347\0\34of-config\0\0\0", 16) = 16
lseek(3, 432, SEEK_CUR) = 448
read(3, "p\375\2\0common\0\0\0\0\0\0", 16) = 16
read(3, "ibm,fw-phandle-enable?=false\0lit"..., 8176) = 4096
dup(2) = 4
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
fstat64(4, {st_mode=S_IFCHR|0600, st_rdev=makedev(5, 1), ...}) = 0
ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0
mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fc0000
_llseek(4, 0, 0xffd63fd8, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(4, "Error reading /dev/nvram: Succes"..., 34Error reading /dev/nvram: Success
) = 34
close(4) = 0
munmap(0xf7fc0000, 131072) = 0
exit_group(1) = ?
(none):/#
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] powerpc: fix large nvram access
From: Andreas Schwab @ 2006-01-10 23:22 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, arndb
In-Reply-To: <20060110221313.GA24246@suse.de>
Olaf Hering <olh@suse.de> writes:
> this change breaks my nvsetenv binary on JS20.
>
> (none):/# mount proc ; nvsetenv
> Error reading /dev/nvram: Success
It was broken to begin with.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] powerpc: fix large nvram access
From: Arnd Bergmann @ 2006-01-10 23:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: arndb, Olaf Hering
In-Reply-To: <20060110221313.GA24246@suse.de>
Am Dienstag, 10. Januar 2006 23:13 schrieb Olaf Hering:
> On Mon, Jan 09, Linux Kernel Mailing List wrote:
> > tree da8f883f72d08f9534e9eca3bba662413b9bd865
> > parent d52771fce4e774fa786097d34412a057d487c697
> > author Arnd Bergmann <arnd@arndb.de> Fri, 09 Dec 2005 19:21:44 +0100
> > committer Paul Mackerras <paulus@samba.org> Mon, 09 Jan 2006 14:53:31
> > +1100
> >
> > [PATCH] powerpc: fix large nvram access
> >
> > /dev/nvram uses the user-provided read/write size
> > for kmalloc, which fails, if a large number is passed.
> > This will always use a single page at most, which
> > can be expected to succeed.
> >
> > Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
> > Signed-off-by: Paul Mackerras <paulus@samba.org>
> >
> > arch/powerpc/kernel/nvram_64.c | 114
> > +++++++++++++++++++----------------------
>
> this change breaks my nvsetenv binary on JS20.
>
I think this has uncovered a bug that has been in nvsetenv for a long time.
> open("/dev/nvram", O_RDONLY) = 3
> read(3, "P\347\0\34of-config\0\0\0", 16) = 16
> lseek(3, 432, SEEK_CUR) = 448
> read(3, "p\375\2\0common\0\0\0\0\0\0", 16) = 16
> read(3, "ibm,fw-phandle-enable?=false\0lit"..., 8176) = 4096
This is where my patch changed the behavior of the driver. It used to return all the data in one chunk, now it returns 4096 bytes at most.
> dup(2) = 4
> fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
> fstat64(4, {st_mode=S_IFCHR|0600, st_rdev=makedev(5, 1), ...}) = 0
> ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fc0000
> _llseek(4, 0, 0xffd63fd8, SEEK_CUR) = -1 ESPIPE
> (Illegal seek)
> write(4, "Error reading /dev/nvram: Succes"..., 34Error reading /dev/nvram: Success ) = 34
> close(4) = 0
> munmap(0xf7fc0000, 131072) = 0
> exit_group(1) = ?
> (none):/#
And then it got here:
| if (lseek(nvfd, NVSTART, 0) < 0
| || read(nvfd, &nvbuf, NVSIZE) != NVSIZE) {
| perror("Error reading /dev/nvram");
| exit(EXIT_FAILURE);
| }
I'm pretty sure that the failing _llseek is part of the perror
implementation and not the real problem, as we were first thinking.
The problem is that nvsetenv bails out on a short read, while according
to the man page, "It is not an error if this number is smaller than the
number of bytes requested". Of course, character devices often differ
in their behavior from what is in the man pages for file I/O.
I'd suggest we change both ends: nvsetenv should really be able to deal
with a short read, and we can double the size of the kmalloc buffer
for the kernel implementation. Please test the patch below.
---
Subject: powerpc: fix nvsetenv regression with fixed nvram read/write
reading from /dev/nvram was recently fixed to not try to allocate the
user-defined amount of kernel memory. This broke the nvsetenv tool
which relied on never getting short reads from /dev/nvram.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index fd7db8d..8da6e57 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -34,6 +34,15 @@
#undef DEBUG_NVRAM
+/*
+ * Old nvsetenv versions expect us to be able to return 8kb
+ * of data in a single read, so use that as a limit for short
+ * reads.
+ * We can't simply use the requested size because large
+ * kmalloc allocations often fail.
+ */
+#define NVRAM_ALLOC_SIZE 8192
+
static int nvram_scan_partitions(void);
static int nvram_setup_partition(void);
static int nvram_create_os_partition(void);
@@ -94,7 +103,7 @@ static ssize_t dev_nvram_read(struct fil
goto out;
count = min_t(size_t, count, size - *ppos);
- count = min(count, PAGE_SIZE);
+ count = min(count, NVRAM_ALLOC_SIZE);
ret = -ENOMEM;
tmp = kmalloc(count, GFP_KERNEL);
@@ -131,7 +140,7 @@ static ssize_t dev_nvram_write(struct fi
goto out;
count = min_t(size_t, count, size - *ppos);
- count = min(count, PAGE_SIZE);
+ count = min(count, NVRAM_ALLOC_SIZE);
ret = -ENOMEM;
tmp = kmalloc(count, GFP_KERNEL);
^ permalink raw reply related
* Re: patch add-macio_bus_type-probe-and-remove-methods.patch added to gregkh-2.6 tree
From: Benjamin Herrenschmidt @ 2006-01-11 1:55 UTC (permalink / raw)
To: gregkh; +Cc: greg, rmk+kernel, rmk, linuxppc-dev
In-Reply-To: <1EwCY8-1zu-00@press.kroah.org>
On Mon, 2006-01-09 at 22:00 -0800, gregkh@suse.de wrote:
> This is a note to let you know that I've just added the patch titled
>
> Subject: [CFT 19/29] Add macio_bus_type probe and remove methods
>
> to my gregkh-2.6 tree. Its filename is
>
> add-macio_bus_type-probe-and-remove-methods.patch
>
> This tree can be found at
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> drivers/macintosh/macio_asic.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> --- gregkh-2.6.orig/drivers/macintosh/macio_asic.c
> +++ gregkh-2.6/drivers/macintosh/macio_asic.c
> @@ -204,6 +204,9 @@ struct bus_type macio_bus_type = {
> .name = "macio",
> .match = macio_bus_match,
> .uevent = macio_uevent,
> + .probe = macio_device_probe,
> + .remove = macio_device_remove,
> + .shutdown = macio_device_shutdown,
> .suspend = macio_device_suspend,
> .resume = macio_device_resume,
> .dev_attrs = macio_dev_attrs,
> @@ -487,9 +490,6 @@ int macio_register_driver(struct macio_d
> /* initialize common driver fields */
> drv->driver.name = drv->name;
> drv->driver.bus = &macio_bus_type;
> - drv->driver.probe = macio_device_probe;
> - drv->driver.remove = macio_device_remove;
> - drv->driver.shutdown = macio_device_shutdown;
>
> /* register with core */
> count = driver_register(&drv->driver);
>
>
> Patches currently in gregkh-2.6 which might be from rmk@arm.linux.org.uk are
>
> driver/add-bttv-sub-bus_type-probe-and-remove-methods.patch
> driver/add-bus_type-probe-remove-shutdown-methods..patch
> driver/add-ccwgroup_bus_type-probe-and-remove-methods.patch
> driver/add-dio_bus_type-probe-and-remove-methods.patch
> driver/add-ecard_bus_type-probe-remove-shutdown-methods.patch
> driver/add-gameport-bus_type-probe-and-remove-methods.patch
> driver/add-i2c_bus_type-probe-and-remove-methods.patch
> driver/add-ide_bus_type-probe-and-remove-methods.patch
> driver/add-locomo-bus_type-probe-remove-methods.patch
> driver/add-logic-module-bus_type-probe-remove-methods.patch
> driver/add-macio_bus_type-probe-and-remove-methods.patch
> driver/add-mcp-bus_type-probe-and-remove-methods.patch
> driver/add-mmc_bus_type-probe-and-remove-methods.patch
> driver/add-ocp_bus_type-probe-and-remove-methods.patch
> driver/add-of_platform_bus_type-probe-and-remove-methods.patch
> driver/add-parisc_bus_type-probe-and-remove-methods.patch
> driver/add-pci_bus_type-probe-and-remove-methods.patch
> driver/add-pcmcia_bus_type-probe-and-remove-methods.patch
> driver/add-pnp_bus_type-probe-and-remove-methods.patch
> driver/add-pseudo-lld-bus_type-probe-and-remove-methods.patch
> driver/add-rio_bus_type-probe-and-remove-methods.patch
> driver/add-sa1111-bus_type-probe-remove-methods.patch
> driver/add-serio-bus_type-probe-and-remove-methods.patch
> driver/add-sh_bus_type-probe-and-remove-methods.patch
> driver/add-superhyway_bus_type-probe-and-remove-methods.patch
> driver/add-tiocx-bus_type-probe-remove-methods.patch
> driver/add-usb_serial_bus_type-probe-and-remove-methods.patch
> driver/add-vio_bus_type-probe-and-remove-methods.patch
> driver/add-zorro_bus_type-probe-and-remove-methods.patch
> driver/remove-usb-gadget-generic-driver-methods.patch
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc: Updated Kconfig and Makefiles for 83xx support
From: Kumar Gala @ 2006-01-11 3:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
Updated Kconfig & Makefiles in prep for adding support for the Freescale
MPC83xx family of processors to arch/powerpc. Moved around some config
options that are more globally applicable to other PowerPC processors.
Added a temporary config option (83xx) to match existh arch/ppc support
for the MPC83xx line.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 2c80aa14abcccdfdef2998ba78c299c33999c621
tree 980e516b488d408d93402dbdbe3749e48996bb81
parent 6d26108d8631afcb31faa6d63cab7bee8d35871c
author Kumar Gala <galak@kernel.crashing.org> Tue, 10 Jan 2006 21:49:06 -0600
committer Kumar Gala <galak@kernel.crashing.org> Tue, 10 Jan 2006 21:49:06 -0600
arch/powerpc/Kconfig | 83 +++++++++++++++++-----------
arch/powerpc/platforms/83xx/Kconfig | 26 +++++++++
arch/powerpc/platforms/83xx/Makefile | 4 +
arch/powerpc/platforms/Makefile | 1
arch/powerpc/platforms/embedded6xx/Kconfig | 18 ------
arch/powerpc/sysdev/Makefile | 2 -
arch/ppc/Kconfig | 4 +
7 files changed, 85 insertions(+), 53 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 935d965..01feed0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -71,15 +71,39 @@ config ARCH_MAY_HAVE_PC_FDC
bool
default y
+config PPC_OF
+ def_bool y
+
+config PPC_UDBG_16550
+ bool
+ default n
+
+config CRASH_DUMP
+ bool "kernel crash dumps (EXPERIMENTAL)"
+ depends on PPC_MULTIPLATFORM
+ depends on EXPERIMENTAL
+ help
+ Build a kernel suitable for use as a kdump capture kernel.
+ The kernel will be linked at a different address than normal, and
+ so can only be used for Kdump.
+
+ Don't change this unless you know what you are doing.
+
+config GENERIC_TBSYNC
+ bool
+ default y if PPC32 && SMP
+ default n
+
menu "Processor support"
choice
prompt "Processor Type"
depends on PPC32
default 6xx
-config 6xx
+config CLASSIC32
bool "6xx/7xx/74xx"
select PPC_FPU
+ select 6xx
help
There are four families of PowerPC chips supported. The more common
types (601, 603, 604, 740, 750, 7400), the Motorola embedded
@@ -93,12 +117,20 @@ config 6xx
config PPC_52xx
bool "Freescale 52xx"
+ select 6xx
+ select PPC_FPU
config PPC_82xx
bool "Freescale 82xx"
+ select 6xx
+ select PPC_FPU
config PPC_83xx
bool "Freescale 83xx"
+ select 6xx
+ select FSL_SOC
+ select 83xx
+ select PPC_FPU
config 40x
bool "AMCC 40x"
@@ -134,6 +166,13 @@ config POWER4
depends on PPC64
def_bool y
+config 6xx
+ bool
+
+# this is temp to handle compat with arch=ppc
+config 83xx
+ bool
+
config PPC_FPU
bool
default y if PPC64
@@ -166,7 +205,7 @@ config PHYS_64BIT
config ALTIVEC
bool "AltiVec Support"
- depends on 6xx || POWER4
+ depends on CLASSIC32 || POWER4
---help---
This option enables kernel support for the Altivec extensions to the
PowerPC processor. The kernel currently supports saving and restoring
@@ -239,7 +278,7 @@ endmenu
source "init/Kconfig"
menu "Platform support"
- depends on PPC64 || 6xx
+ depends on PPC64 || CLASSIC32
choice
prompt "Machine type"
@@ -330,9 +369,6 @@ config PPC_CELL
select MMIO_NVRAM
select PPC_UDBG_16550
-config PPC_OF
- def_bool y
-
config XICS
depends on PPC_PSERIES
bool
@@ -375,26 +411,11 @@ config MPIC_BROKEN_U3
depends on PPC_MAPLE
default y
-config PPC_UDBG_16550
- bool
- default n
-
config CELL_IIC
depends on PPC_CELL
bool
default y
-config CRASH_DUMP
- bool "kernel crash dumps (EXPERIMENTAL)"
- depends on PPC_MULTIPLATFORM
- depends on EXPERIMENTAL
- help
- Build a kernel suitable for use as a kdump capture kernel.
- The kernel will be linked at a different address than normal, and
- so can only be used for Kdump.
-
- Don't change this unless you know what you are doing.
-
config IBMVIO
depends on PPC_PSERIES || PPC_ISERIES
bool
@@ -410,11 +431,6 @@ config PPC_MPC106
bool
default n
-config GENERIC_TBSYNC
- bool
- default y if PPC32 && SMP
- default n
-
source "drivers/cpufreq/Kconfig"
config CPU_FREQ_PMAC
@@ -495,6 +511,7 @@ endmenu
source arch/powerpc/platforms/embedded6xx/Kconfig
source arch/powerpc/platforms/4xx/Kconfig
+source arch/powerpc/platforms/83xx/Kconfig
source arch/powerpc/platforms/85xx/Kconfig
source arch/powerpc/platforms/8xx/Kconfig
source arch/powerpc/platforms/cell/Kconfig
@@ -718,7 +735,7 @@ config PPC_I8259
config PPC_INDIRECT_PCI
bool
depends on PCI
- default y if 40x || 44x || 85xx || 83xx
+ default y if 40x || 44x || 85xx
default n
config EISA
@@ -727,13 +744,16 @@ config EISA
config SBUS
bool
+config FSL_SOC
+ bool
+
# Yes MCA RS/6000s exist but Linux-PPC does not currently support any
config MCA
bool
config PCI
- bool "PCI support" if 40x || CPM2 || 83xx || 85xx || PPC_MPC52xx || (EMBEDDED && PPC_ISERIES)
- default y if !40x && !CPM2 && !8xx && !APUS && !83xx && !85xx
+ bool "PCI support" if 40x || CPM2 || PPC_83xx || 85xx || PPC_MPC52xx || (EMBEDDED && PPC_ISERIES)
+ default y if !40x && !CPM2 && !8xx && !APUS && !PPC_83xx && !85xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx && APUS
default PCI_QSPAN if !4xx && !CPM2 && 8xx
help
@@ -746,11 +766,6 @@ config PCI_DOMAINS
bool
default PCI
-config MPC83xx_PCI2
- bool " Supprt for 2nd PCI host controller"
- depends on PCI && MPC834x
- default y if MPC834x_SYS
-
config PCI_QSPAN
bool "QSpan PCI"
depends on !4xx && !CPM2 && 8xx
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
new file mode 100644
index 0000000..b20812d
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -0,0 +1,26 @@
+menu "Platform support"
+ depends on PPC_83xx
+
+choice
+ prompt "Machine Type"
+ default MPC834x_SYS
+
+config MPC834x_SYS
+ bool "Freescale MPC834x SYS"
+ help
+ This option enables support for the MPC 834x SYS evaluation board.
+
+ Be aware that PCI buses can only function when SYS board is plugged
+ into the PIB (Platform IO Board) board from Freescale which provide
+ 3 PCI slots. The PIBs PCI initialization is the bootloader's
+ responsiblilty.
+
+endchoice
+
+config MPC834x
+ bool
+ select PPC_UDBG_16550
+ select PPC_INDIRECT_PCI
+ default y if MPC834x_SYS
+
+endmenu
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
new file mode 100644
index 0000000..9d8b28e
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for the PowerPC 83xx linux kernel.
+#
+obj-$(CONFIG_MPC834x_SYS) += mpc834x_sys.o pci.o
diff --git a/arch/powerpc/platforms/Makefile b/arch/powerpc/platforms/Makefile
index 8836b3a..04073fd 100644
--- a/arch/powerpc/platforms/Makefile
+++ b/arch/powerpc/platforms/Makefile
@@ -7,6 +7,7 @@ endif
endif
obj-$(CONFIG_PPC_CHRP) += chrp/
obj-$(CONFIG_4xx) += 4xx/
+obj-$(CONFIG_PPC_83xx) += 83xx/
obj-$(CONFIG_85xx) += 85xx/
obj-$(CONFIG_PPC_PSERIES) += pseries/
obj-$(CONFIG_PPC_ISERIES) += iseries/
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index 8125009..4fdbc9a 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -144,16 +144,6 @@ config LITE5200
much but it's only been tested on this board version. I think this
board is also known as IceCube.
-config MPC834x_SYS
- bool "Freescale MPC834x SYS"
- help
- This option enables support for the MPC 834x SYS evaluation board.
-
- Be aware that PCI buses can only function when SYS board is plugged
- into the PIB (Platform IO Board) board from Freescale which provide
- 3 PCI slots. The PIBs PCI initialization is the bootloader's
- responsiblilty.
-
config EV64360
bool "Marvell-EV64360BP"
help
@@ -192,14 +182,6 @@ config 8272
The MPC8272 CPM has a different internal dpram setup than other CPM2
devices
-config 83xx
- bool
- default y if MPC834x_SYS
-
-config MPC834x
- bool
- default y if MPC834x_SYS
-
config CPM2
bool
depends on 8260 || MPC8560 || MPC8555
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 14b9abd..0ae8413 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -6,4 +6,4 @@ obj-$(CONFIG_BOOKE) += dcr.o
obj-$(CONFIG_40x) += dcr.o
obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
-obj-$(CONFIG_83xx) += ipic.o
+obj-$(CONFIG_PPC_83xx) += ipic.o
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
index e396f45..d658101 100644
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -743,6 +743,10 @@ config MPC834x
bool
default y if MPC834x_SYS
+config PPC_83xx
+ bool
+ default y if 83xx
+
config CPM1
bool
depends on 8xx
^ permalink raw reply related
* [PATCH] powerpc: Add some missing .gitignore's
From: Kumar Gala @ 2006-01-11 4:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
ignore generated files under arch/powerpc
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 4ef3ebb801e686338c5a8c87863887c54b2af02e
tree 384eb9502d8d4ef5d5452cfe7f43906366230454
parent 2c80aa14abcccdfdef2998ba78c299c33999c621
author Kumar Gala <galak@kernel.crashing.org> Tue, 10 Jan 2006 22:17:28 -0600
committer Kumar Gala <galak@kernel.crashing.org> Tue, 10 Jan 2006 22:17:28 -0600
arch/powerpc/boot/.gitignore | 20 ++++++++++++++++++++
arch/powerpc/kernel/vdso32/.gitignore | 1 +
arch/powerpc/kernel/vdso64/.gitignore | 1 +
3 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
new file mode 100644
index 0000000..45c9ad2
--- /dev/null
+++ b/arch/powerpc/boot/.gitignore
@@ -0,0 +1,20 @@
+addnote
+infblock.c
+infblock.h
+infcodes.c
+infcodes.h
+inffast.c
+inffast.h
+inflate.c
+inftrees.c
+inftrees.h
+infutil.c
+infutil.h
+kernel-vmlinux.strip.c
+kernel-vmlinux.strip.gz
+uImage
+zImage
+zImage.vmode
+zconf.h
+zlib.h
+zutil.h
diff --git a/arch/powerpc/kernel/vdso32/.gitignore b/arch/powerpc/kernel/vdso32/.gitignore
new file mode 100644
index 0000000..e45fba9
--- /dev/null
+++ b/arch/powerpc/kernel/vdso32/.gitignore
@@ -0,0 +1 @@
+vdso32.lds
diff --git a/arch/powerpc/kernel/vdso64/.gitignore b/arch/powerpc/kernel/vdso64/.gitignore
new file mode 100644
index 0000000..3fd18cf
--- /dev/null
+++ b/arch/powerpc/kernel/vdso64/.gitignore
@@ -0,0 +1 @@
+vdso64.lds
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox