* Trouble with SCC UART ports when moving from ppc to powerpc
From: Laurent Pinchart @ 2008-03-07 14:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]
Hi everybody,
I'm trying to move from ARCH=ppc to ARCH=powerpc on an MPC8272 based board.
I updated my bootloader (U-Boot) to get FDT support, wrote a device tree and
compiled a powerpc kernel with CONFIG_PPC_CPM_NEW_BINDING set. No problem so
far (well, no problem I haven't been able to solve).
I then tried to get the serial console on SCC1 to work. The serial port was
silent, and the kernel hanged in cpm_uart_console_write while waiting for the
CPM to clear the ready bit in tx buffer descriptors.
After checking the SCC1 configuration registers, parameter RAM and buffer
descriptors, I found out that something was overwriting the buffer
descriptors were stored in the DPRAM at offset 0.
Right after initializing the rx buffer descriptors, dumping the rx bds dpram
with the BDI2000 gave me
90000088 003518e0 90000008 00351900
90000000 00351911 b5400000 2dace564
while I was expecting
90000088 003518e0 90000008 00351900
90000000 00351920 b0000000 00351940
Some data was clearly being overwritten by something.
The CPM dual port ram was defined in the device tree as follows (copied from
the MPC8272ADS board device tree).
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 9800 800>;
};
};
Changing the reg property to
reg = <80 1f80 9800 800>;
fixed my problem.
Does anyone have any clue regarding what could write to the dpram ? I thought
about some CPM peripheral set up by the boot loader, but my board
initialization code calls cpm2_reset() long before initializing SCC1.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: Kumar Gala @ 2008-03-07 14:35 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <20080307002730.GB24142@localhost.localdomain>
On Mar 6, 2008, at 6:27 PM, David Gibson wrote:
> [snip]
>> + bcsr@1,0 {
>> + reg = <1 0x0 0x8000>;
>> + compatible = "fsl,mpc837xmds-bcsr";
>> + };
>> +
>> + nand@3,0 {
>
> This isn't a problem with this device tree, but it's probably time we
> started establishing some conventional generic names for nand flash
> and board-control devices.
>
> So, to start the ball rolling, I've seen several names for nand flash
> nodes, I'd suggest we standardise on "nand-flash".
This seems reasonable.
> I've seen several variants for board control devices (cpld, bcsr,
> fpga, etc.) I suggest we standardise on "board-control"
I don't see any reason for this. If I have a cpld or fpga why not
just call it that. I don't see what calling it 'board-control' gets
us. There may be non-board control functionality in an fpga than what
do we call it?
- k
^ permalink raw reply
* Re: [POWERPC] 8xx: fix swap
From: Kumar Gala @ 2008-03-07 14:46 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras, LKML
In-Reply-To: <20080306135330.6d5462d2@vitb.ru.mvista.com>
On Mar 6, 2008, at 4:53 AM, Vitaly Bordug wrote:
> This makes swap routines operate correctly on the ppc_8xx based
> machines.
> Code has been revalidated on mpc885ads (8M sdram) with recent
> kernel. Based
> on patch from Yuri Tikhonov <yur@emcraft.com> to do the same on arch/
> ppc
> instance.
>
> Recent kernel's size makes swap feature very important on low-memory
> platforms,
> those are actually non-operable without it.
>
> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
>
> arch/powerpc/kernel/head_8xx.S | 30 ++++++++++++++++++++++++++
> +++-
> include/asm-powerpc/pgtable-ppc32.h | 8 --------
> 2 files changed, 29 insertions(+), 9 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH] Fix wrapper platform for adder875, and combine defconfigs.
From: Kumar Gala @ 2008-03-07 14:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080220183338.GA9282@loki.buserror.net>
On Feb 20, 2008, at 12:33 PM, Scott Wood wrote:
> This fixes the following bug:
> http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051979.html
>
> Separate defconfigs are no longer needed now that CONFIG_DEVICE_TREE
> is gone.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/boot/wrapper | 6 +-
> arch/powerpc/configs/adder875-uboot_defconfig | 798
> --------------------
> ...der875-redboot_defconfig => adder875_defconfig} | 61 +-
> 3 files changed, 43 insertions(+), 822 deletions(-)
> delete mode 100644 arch/powerpc/configs/adder875-uboot_defconfig
> rename arch/powerpc/configs/{adder875-redboot_defconfig =>
> adder875_defconfig} (95%)
applied.
- k
^ permalink raw reply
* Re: [PATCH v2] 82xx: MGCOGE support
From: Kumar Gala @ 2008-03-07 14:55 UTC (permalink / raw)
To: hs; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <47D13F37.6070504@denx.de>
On Mar 7, 2008, at 7:12 AM, Heiko Schocher wrote:
> Hello Scott,
>
> Scott Wood wrote:
>> Heiko Schocher wrote:
>>> The following patch adds support for the mpc8247 based
>>> board MGCOGE from keymile.
>>>
>>> changes to the previous patchset:
>>>
>>> - Added the suggestions from Scott Wood:
>>> http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050957.html
>>>
>>> - The patch
>>> http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050931.html
>>> is no longer needed.
>>>
>>> Signed-off-by: Heiko Schocher <hs@denx.de>
>>
>> Acked-by: Scott Wood <scottwood@freescale.com>
>
> I have some changes for this Hardware (a second Flash is now there),
> how should I post this change?
>
> a) The complete board support again, with the new Flash.
> b) as an incremental Patch against the patch I postet in this Thread.
>
> (I vote for option a, and we throw away the "v2 Patch")
>
> thanks for helping
go a head w/a since we haven't applied a version of this to any tree
yet.
- k
^ permalink raw reply
* RE: Xilinx Temac link detect
From: Koss, Mike (Mission Systems) @ 2008-03-07 14:29 UTC (permalink / raw)
To: John Linn, khollan, linuxppc-embedded
In-Reply-To: <20080306221446.4509A1118051@mail123-sin.bigfish.com>
Here's a snippet from a program I use to debug an ethernet driver that I
have using ioctl's. The ethernet ioctl interface is slightly different
from a "normal" ioctl in that it uses sockets and not a file descriptor.
The ioctl's I use are added to the ioctl interface in the driver, using
the defined device-specific range (that was supposed to disappear in
2.5.x or 2.6.x). With this I read/write my phy register's to test out
the interface between my TEMAC and my PHY.=20
#include <sys/types.h>
#include <sys/ioctl.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>
#include <net/if.h>
#include <linux/sockios.h>
int main (int argc, char **argv)
{
int driver_fd =3D -1;
int cmd =3D 0;
int res;
char* buffer =3D NULL;
struct ifreq ifr;
if (argc < 3)
{
printf ("Usage %s <devname> <ioctl>\n", argv [0]);
exit (1);
}
driver_fd =3D socket(AF_INET, SOCK_DGRAM, 0);
if (driver_fd =3D=3D -1)
{
printf ("Could not open %s: %s\n", TEMAC_DRIVER_NAME, strerror
(errno));
exit (1);
}
memset(&ifr, 0, sizeof(struct ifreq));
strcpy(ifr.ifr_name, argv[1]);
cmd =3D atoi (argv [2]);
if (SIOCDEVPRIVATE + 3 =3D=3D cmd) {
if (argc !=3D 4) {
printf("usage %s <devname> 35315 <phy reg>\n", argv[0]);
exit(1);
}
ifr.ifr_ifindex =3D atoi(argv[3]);
}
if (SIOCDEVPRIVATE + 4 =3D=3D cmd) {
if (argc !=3D 5) {
printf("usage %s <devname> 35316 <phy reg> <val>\n", argv[0]);
exit(1);
}
ifr.ifr_ifindex =3D atoi(argv[3]) << 16;
ifr.ifr_ifindex |=3D atoi(argv[4]);
}
printf("Performing ioctl %d:\n", cmd);
res =3D ioctl(driver_fd, cmd, &ifr);
if (res =3D=3D -1)
{
printf ("Error from %d: %s\n", driver_fd, strerror (errno));
exit (1);
}
return 0;
}
-----Original Message-----
From: John Linn [mailto:John.Linn@xilinx.com]=20
Sent: Thursday, March 06, 2008 5:15 PM
To: khollan; linuxppc-embedded@ozlabs.org
Subject: RE: Xilinx Temac link detect
Hi Kevin,
I couldn't find any example laying around, so I took a shot at it based
on other non-network examples we had. I've not personally done it so
bear that in mind.
I have not tried to compile any of this, just stole parts for places and
pasted in.
Hope it helps,
John
#include <ioctl.h>
/*
* FD of the IIC device opened.
*/
int Fdtemac;
struct mii_ioctl_data ioctl_data;=09
/*
* Open the device.
*/
Fdtemac =3D open("/dev/TBD", O_RDWR);
if(Fdtemac < 0)
{
printf("Cannot open the temac device\n");
return -1;
}
/* setup the inputs to the ioctl call */
ioctl_data.phy_num =3D TBD;
ioctl_data.reg_num =3D TBD;
=09
/*
* Read the phy register
*/
Register =3D ioctl(Fdtemac, SIOCGMIIREG, &ioctl_data);
if(Status < 0)
{
/* failure */
return 0;
}
/* results should be in ioctl_data.val_out I think
}
>From the temac linux adapter, a snippet showing the the ioctl function.
xenet_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) {
struct mii_ioctl_data *data =3D (struct mii_ioctl_data *)
&rq->ifr_data;
case SIOCGMIIREG: /* Read GMII PHY register. */
ret =3D XTemac_PhyRead(&lp->Emac, data->phy_id,
data->reg_num, &data->val_out); }
from linux/mii.h
/* This structure is used in all SIOCxMIIxxx ioctl calls */ struct
mii_ioctl_data {
__u16 phy_id;
__u16 reg_num;
__u16 val_in;
__u16 val_out;
};
from linux/if.h
struct ifreq
{
#define IFHWADDRLEN 6
union
{
char ifrn_name[IFNAMSIZ]; /* if name, e.g.
"en0" */
} ifr_ifrn;
=09
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
struct sockaddr ifru_netmask;
struct sockaddr ifru_hwaddr;
short ifru_flags;
int ifru_ivalue;
int ifru_mtu;
struct ifmap ifru_map;
char ifru_slave[IFNAMSIZ]; /* Just fits the size */
char ifru_newname[IFNAMSIZ];
void __user * ifru_data;
struct if_settings ifru_settings;
} ifr_ifru;
};
-----Original Message-----
From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org] On
Behalf Of khollan
Sent: Thursday, March 06, 2008 1:44 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Xilinx Temac link detect
I figure I could write a C program to talk to the ioctl in the TEMAC
driver and read the PHY register. Does anyone have example code for
talking to network ioctl's?
Thanks
Kevin
--
View this message in context:
http://www.nabble.com/Xilinx-Temac-link-detect-tp15616042p15883376.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] fs_enet: Remove unused fields in the fs_mii_bb_platform_info structure.
From: Kumar Gala @ 2008-03-07 15:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080228185034.GA3897@loki.buserror.net>
On Feb 28, 2008, at 12:50 PM, Scott Wood wrote:
> On Thu, Feb 28, 2008 at 01:49:01PM +0100, Laurent Pinchart wrote:
>> On Friday 15 February 2008 14:27, Laurent Pinchart wrote:
>>> The mdio_port, mdio_bit, mdc_port and mdc_bit fields in the
>>> fs_mii_bb_platform_info structure are left-overs from the move to
>>> the Phy
>>> Abstraction Layer subsystem. They can be safely removed.
>>>
>>> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
>> [snip]
>>
>> Is there something wrong with the patch ?
>
> No, the patch looks OK. However, note that non-PPC_CPM_NEW_BINDING
> code
> should go away altogether soon.
also any such patch should normally go via netdev as its to a network
driver.
- k
^ permalink raw reply
* Re: Trouble with SCC UART ports when moving from ppc to powerpc
From: Timur Tabi @ 2008-03-07 15:00 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803071521.00383.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> Does anyone have any clue regarding what could write to the dpram ? I thought
> about some CPM peripheral set up by the boot loader, but my board
> initialization code calls cpm2_reset() long before initializing SCC1.
I'm not familar with the CPM, but in cpm_common.c are a bunch of functions to
manage memory allocated of the DPRAM. You might want to see who's using those
functions, and how.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/2] fix wrong USB phy type in mpc837xmds dts
From: Kumar Gala @ 2008-03-07 14:47 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, paulus
In-Reply-To: <1204800146-11591-1-git-send-email-leoli@freescale.com>
On Mar 6, 2008, at 4:42 AM, Li Yang wrote:
> Due to chip constraint MPC837x USB DR module can only use
> ULPI and serial PHY interfaces. The patch fixes the wrong
> type in dts.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8377_mds.dts | 4 ++--
> arch/powerpc/boot/dts/mpc8378_mds.dts | 4 ++--
> arch/powerpc/boot/dts/mpc8379_mds.dts | 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
applied.
- k
^ permalink raw reply
* Please pull from 'for-2.6.25' branch
From: Kumar Gala @ 2008-03-07 15:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
These are fixes to forward on to linus (based on his tree).
to receive the following updates:
arch/powerpc/boot/dts/mpc8377_mds.dts | 70 ++
arch/powerpc/boot/dts/mpc8378_mds.dts | 70 ++
arch/powerpc/boot/dts/mpc8379_mds.dts | 70 ++
arch/powerpc/boot/wrapper | 6
arch/powerpc/configs/adder875-redboot_defconfig | 798 -----------------------
arch/powerpc/configs/adder875-uboot_defconfig | 798 -----------------------
arch/powerpc/configs/adder875_defconfig | 813 ++++++++++++++++++++++++
arch/powerpc/kernel/head_8xx.S | 30
arch/powerpc/platforms/83xx/mpc837x_mds.c | 8
arch/powerpc/sysdev/qe_lib/qe.c | 2
include/asm-powerpc/pgtable-ppc32.h | 8
11 files changed, 1055 insertions(+), 1618 deletions(-)
Li Yang (2):
[POWERPC] 83xx: Fix wrong USB phy type in mpc837xmds dts
[POWERPC] 83xx: Add local bus device nodes to MPC837xMDS device trees.
Scott Wood (1):
[POWERPC] 8xx: Fix wrapper platform for adder875, and combine defconfigs.
Timur Tabi (1):
[POWERPC] QE: Fix QE firmware uploading limit
Vitaly Bordug (1):
[POWERPC] 8xx: fix swap
^ permalink raw reply
* Re: [PATCH] fix QE firmware uploading limit
From: Kumar Gala @ 2008-03-07 15:06 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1204564290-18283-1-git-send-email-timur@freescale.com>
On Mar 3, 2008, at 11:11 AM, Timur Tabi wrote:
> Fix a typo in qe_upload_firmware() that prevented uploading firmware
> on
> systems with more than one RISC core.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> This patch is for 2.6.25.
>
> arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH 1/4] Emerson KSI8560 base support
From: Kumar Gala @ 2008-03-07 15:07 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080306151716.GB25251@ru.mvista.com>
On Mar 6, 2008, at 9:17 AM, Alexandr Smirnov wrote:
> The KSI8560 is a single compact, mid-, or full-size Advanced =20
> Mezzanine Card
> (AdvancedMC=99) based on the Freescale=99 Semiconductor MPC8560 =20
> PowerQUICC III=99
> microprocessor. This product will serve in data and signaling =20
> applications such
> as signaling gateways (SGW) and softswitch signaling interface cards.
>
> The board has altera maxii CPLD, that is used to obtain and manage =20
> board
> configuration. Also there are two SCC UART serial consoles and FCC =20
> ethernet,
> that is routed to the front panel, while other ethernet controlers =20
> (TSEC's) are
> routed to the backplane.
>
> Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
>
> arch/powerpc/platforms/85xx/Kconfig | 7
> arch/powerpc/platforms/85xx/Makefile | 1
> arch/powerpc/platforms/85xx/ksi8560.c | 257 ++++++++++++++++++++++++=20=
> ++++++++++
> 3 files changed, 265 insertions(+)
applied to powerpc-next.
- k
^ permalink raw reply
* Re: [PATCH 2/4] Emerson KSI8560 bootwrapper
From: Kumar Gala @ 2008-03-07 15:09 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080304163426.GC19634@ru.mvista.com>
On Mar 4, 2008, at 10:34 AM, Alexandr Smirnov wrote:
> Add boot wrapper for Emerson KSI8560 board.
>
> Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
>
> arch/powerpc/boot/Makefile | 1 +
> arch/powerpc/boot/wrapper | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
applied to powerpc-next.
- k
^ permalink raw reply
* Re: [PATCH 4/4] Emerson KSI8560 default config
From: Kumar Gala @ 2008-03-07 15:09 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080304163652.GE19634@ru.mvista.com>
On Mar 4, 2008, at 10:36 AM, Alexandr Smirnov wrote:
> Add default config for Emerson KSI8560 board.
>
> Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
>
> arch/powerpc/configs/ksi8560_defconfig | 899 +++++++++++++++++++++++
> ++++++++++
> 1 file changed, 899 insertions(+)
applied to powerpc-next.
- k
^ permalink raw reply
* Re: [PATCH 3/4] Emerson KSI8560 device tree
From: Kumar Gala @ 2008-03-07 15:10 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080306151451.GA25251@ru.mvista.com>
On Mar 6, 2008, at 9:14 AM, Alexandr Smirnov wrote:
> Add device tree file for Emerson KSI8560 board.
>
> Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
>
> b/arch/powerpc/boot/dts/ksi8560.dts | 264 ++++++++++++++++++++++++++
> ++++++++++
> 1 file changed, 264 insertions(+)
Fixed up i2c to add #address-cells, #size-cells and cell-idnex
applied to powerpc-next.
- k
^ permalink raw reply
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Laurent Pinchart @ 2008-03-07 15:23 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <1203089936.20350.7.camel@p60365-ste>
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
Hi Sergej,
On Friday 15 February 2008 16:38, Sergej Stepanov wrote:
> Am Freitag, den 15.02.2008, 13:50 +0100 schrieb Laurent Pinchart:
> > We're loosing the possibility of having MDC and MDIO on different ports.
> > This is quite easy to fix for the non-CONFIG_PPC_CPM_NEW_BINDING case but
> > I'm not familiar with OF bindings (yet) to fix the
> > CONFIG_PPC_CPM_NEW_BINDING case.
>
> for OF issue i had this for a paar month:
> http://www.spinics.net/lists/netdev/msg45778.html
> http://www.spinics.net/lists/netdev/msg47159.html
> i'll be glad if it helps...
Could these be applied ? Any showstopper ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: Kumar Gala @ 2008-03-07 14:46 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, paulus
In-Reply-To: <1204800155-11613-1-git-send-email-leoli@freescale.com>
On Mar 6, 2008, at 4:42 AM, Li Yang wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8377_mds.dts | 66 ++++++++++++++++++++
> +++++++++
> arch/powerpc/boot/dts/mpc8378_mds.dts | 66 ++++++++++++++++++++
> +++++++++
> arch/powerpc/boot/dts/mpc8379_mds.dts | 66 ++++++++++++++++++++
> +++++++++
> arch/powerpc/platforms/83xx/mpc837x_mds.c | 8 +--
> 4 files changed, 201 insertions(+), 5 deletions(-)
applied.
- k
^ permalink raw reply
* Re: Trouble with SCC UART ports when moving from ppc to powerpc
From: Scott Wood @ 2008-03-07 16:21 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803071521.00383.laurentp@cse-semaphore.com>
On Fri, Mar 07, 2008 at 03:20:55PM +0100, Laurent Pinchart wrote:
> The CPM dual port ram was defined in the device tree as follows (copied from
> the MPC8272ADS board device tree).
>
> muram@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0 10000>;
>
> data@0 {
> compatible = "fsl,cpm-muram-data";
> reg = <0 2000 9800 800>;
> };
> };
>
> Changing the reg property to
>
> reg = <80 1f80 9800 800>;
>
> fixed my problem.
Perhaps there's an SMC1 running with its parameter RAM at offset zero?
> Does anyone have any clue regarding what could write to the dpram ? I thought
> about some CPM peripheral set up by the boot loader, but my board
> initialization code calls cpm2_reset() long before initializing SCC1.
cpm2_reset() doesn't currently actually reset the CPM, for some reason
(unlike cpm1). This should probably be fixed, though then we'd have to
deal with assigning SMC parameter RAM addresses ourselves.
For now, the above fix should be done on any board with an active SMC
device (assuming SMC parameter RAM at zero, as u-boot sets it; other
bootloaders may need to exempt a different region).
-Scott
^ permalink raw reply
* Re: [PATCH 1/5] generic __remove_pages() support
From: Badari Pulavarty @ 2008-03-07 16:36 UTC (permalink / raw)
To: Yasunori Goto; +Cc: linuxppc-dev, Andrew Morton, Dave Hansen, lkml, paulus
In-Reply-To: <20080307102032.A17D.E1E9C6FF@jp.fujitsu.com>
Yasunori Goto wrote:
> Hi Badari-san.
>
>
>> On Thu, 2008-03-06 at 12:54 -0800, Dave Hansen wrote:
>>
>>> On Thu, 2008-03-06 at 10:55 -0800, Badari Pulavarty wrote:
>>>
>>>> + if (memmap)
>>>> + __kfree_section_memmap(memmap, PAGES_PER_SECTION);
>>>> + return;
>>>> + }
>>>> +
>>>> + /*
>>>> + * Allocations came from bootmem - how do I free up ?
>>>> + */
>>>> +
>>>>
>>> Shouldn't we figure this one out before merging?
>>>
>>> I think we at least need a printk() there.
>>>
>> I can add a printk(). I am hoping Yasunori Goto has something to
>> handle this, before we really merge into mainline.
>>
>
> Ah, yes.
> I'm making patches for around here. I'm sorry for your waiting.
>
> BTW, do you hurry for merging your patch?
> To be honest, I would like to solve not only here
> but also some other issues.
> But, if you hurry, I'll concentrate to solve only this.
>
> Bye.
>
>
I am hoping to get all of this merged into 2.6.26. Till then I would
like this to
be tested in -mm. I am not in a hurry, but I would like to make sure
some one is
working on the issue. Please let me know, if you have something to test
- I will
be happy to help out.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Scott Wood @ 2008-03-07 16:37 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <200803071623.42519.laurentp@cse-semaphore.com>
On Fri, Mar 07, 2008 at 04:23:39PM +0100, Laurent Pinchart wrote:
> Hi Sergej,
>
> On Friday 15 February 2008 16:38, Sergej Stepanov wrote:
> > Am Freitag, den 15.02.2008, 13:50 +0100 schrieb Laurent Pinchart:
> > > We're loosing the possibility of having MDC and MDIO on different ports.
> > > This is quite easy to fix for the non-CONFIG_PPC_CPM_NEW_BINDING case but
> > > I'm not familiar with OF bindings (yet) to fix the
> > > CONFIG_PPC_CPM_NEW_BINDING case.
> >
> > for OF issue i had this for a paar month:
> > http://www.spinics.net/lists/netdev/msg45778.html
> > http://www.spinics.net/lists/netdev/msg47159.html
> > i'll be glad if it helps...
>
> Could these be applied ? Any showstopper ?
Acked-by: Scott Wood <scottwood@freescale.com>, if I haven't already.
-Scott
^ permalink raw reply
* Re: [PATCH 1/5] generic __remove_pages() support
From: Badari Pulavarty @ 2008-03-07 16:44 UTC (permalink / raw)
To: Yasunori Goto; +Cc: linuxppc-dev, Andrew Morton, Dave Hansen, lkml, paulus
In-Reply-To: <20080307102032.A17D.E1E9C6FF@jp.fujitsu.com>
Yasunori Goto wrote:
> Hi Badari-san.
>
>
>> On Thu, 2008-03-06 at 12:54 -0800, Dave Hansen wrote:
>>
>>> On Thu, 2008-03-06 at 10:55 -0800, Badari Pulavarty wrote:
>>>
>>>> + if (memmap)
>>>> + __kfree_section_memmap(memmap, PAGES_PER_SECTION);
>>>> + return;
>>>> + }
>>>> +
>>>> + /*
>>>> + * Allocations came from bootmem - how do I free up ?
>>>> + */
>>>> +
>>>>
>>> Shouldn't we figure this one out before merging?
>>>
>>> I think we at least need a printk() there.
>>>
>> I can add a printk(). I am hoping Yasunori Goto has something to
>> handle this, before we really merge into mainline.
>>
>
> Ah, yes.
> I'm making patches for around here. I'm sorry for your waiting.
>
> BTW, do you hurry for merging your patch?
> To be honest, I would like to solve not only here
> but also some other issues.
> But, if you hurry, I'll concentrate to solve only this.
>
> Bye.
>
I am hoping to merge this into 2.6.26. I am not in a hurry, but would like
to make sure some one is working on the issue. If you have something
to test, feel free to pass it to me - I will be happy to test.
Thanks,
Badari
^ permalink raw reply
* [PATCH] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Kumar Gala @ 2008-03-07 16:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Normally we assume kernel images will be loaded at offset 0. However
there are situations, like when the kernel itself is running at a non-zero
physical address, that we don't want to load it at 0.
Allow the wrapper to take an offset. We use this when building u-boot images.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/Makefile | 7 +++++++
arch/powerpc/boot/wrapper | 12 ++++++++++--
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index f43dd6e..1b4bfc6 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -35,6 +35,12 @@ endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj) -I$(srctree)/$(src)/libfdt
+ifdef CONFIG_MEMORY_START
+MEMBASE=$(CONFIG_MEMORY_START)
+else
+MEMBASE=0x00000000
+endif
+
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
@@ -181,6 +187,7 @@ endif
# args (to if_changed): 1 = (this rule), 2 = platform, 3 = dts 4=dtb 5=initrd
quiet_cmd_wrap = WRAP $@
cmd_wrap =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
+ -m $(MEMBASE) \
$(if $3, -s $3)$(if $4, -d $4)$(if $5, -i $5) vmlinux
image-$(CONFIG_PPC_PSERIES) += zImage.pseries
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 6655a90..4f2b2d0 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -50,8 +50,11 @@ objbin=$object
# directory for working files
tmpdir=.
+# physical offset of kernel image
+membase=0x00000000
+
usage() {
- echo 'Usage: wrapper [-o output] [-p platform] [-i initrd]' >&2
+ echo 'Usage: wrapper [-o output] [-p platform] [-i initrd] [-m membase]' >&2
echo ' [-d devtree] [-s tree.dts] [-c] [-C cross-prefix]' >&2
echo ' [-D datadir] [-W workingdir] [--no-gzip] [vmlinux]' >&2
exit 1
@@ -84,6 +87,11 @@ while [ "$#" -gt 0 ]; do
[ "$#" -gt 0 ] || usage
dts="$1"
;;
+ -m)
+ shift
+ [ "$#" -gt 0 ] || usage
+ membase="$1"
+ ;;
-c)
cacheit=y
;;
@@ -225,7 +233,7 @@ fi
case "$platform" in
uboot)
rm -f "$ofile"
- mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
+ mkimage -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
$uboot_version -d "$vmz" "$ofile"
if [ -z "$cacheit" ]; then
rm -f "$vmz"
--
1.5.4.1
^ permalink raw reply related
* [PATCH] Make qe_get_firmware_info reentrant
From: Ionut Nicu @ 2008-03-07 17:27 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Ionut Nicu
The function was returning NULL the second time it was
called if the firmware was uploaded from the boot loader
or the first time it was called if the firmware was
uploaded from the kernel.
Signed-off-by: Ionut Nicu <ionut.nicu@freescale.com>
Acked-By: Timur Tabi <timur@freescale.com>
---
arch/powerpc/sysdev/qe_lib/qe.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 6efbd5e..53d61a0 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -609,7 +609,10 @@ struct qe_firmware_info *qe_get_firmware_info(void)
* If we haven't checked yet, and a driver hasn't uploaded a firmware
* yet, then check the device tree for information.
*/
- if (initialized || qe_firmware_uploaded)
+ if (qe_firmware_uploaded)
+ return &qe_firmware_info;
+
+ if (initialized)
return NULL;
initialized = 1;
--
1.5.4.2
^ permalink raw reply related
* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: Segher Boessenkool @ 2008-03-07 18:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Li Yang, paulus, David Gibson
In-Reply-To: <A984ECC2-9094-4045-B49E-95D924E6AAD2@kernel.crashing.org>
>> I've seen several variants for board control devices (cpld, bcsr,
>> fpga, etc.) I suggest we standardise on "board-control"
>
> I don't see any reason for this. If I have a cpld or fpga why not
> just call it that. I don't see what calling it 'board-control' gets
> us. There may be non-board control functionality in an fpga than what
> do we call it?
Good point. Also, it is important to keep in mind that the "name" is
meant for human consumption only, so while it is important to use some
consistent naming (to not confuse the user), there should be quite some
leeway here.
Segher
^ permalink raw reply
* [PATCH] Xilinx: LL TEMAC: removed __res for powerpc arch
From: John Linn @ 2008-03-07 20:50 UTC (permalink / raw)
To: git, grant.likely, linuxppc-dev; +Cc: John Linn
The copy of the mac address from the board data to the platform
data was moved from the LL TEMAC driver to a virtex_device_fixup
function so the driver works for powerpc arch also.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
arch/ppc/platforms/4xx/Kconfig | 22 +++++++++++----
arch/ppc/platforms/4xx/Makefile | 2 +
arch/ppc/platforms/4xx/xilinx_generic_mlxxx.c | 37 +++++++++++++++++++++++++
drivers/net/xilinx_lltemac/xlltemac_main.c | 6 +---
4 files changed, 57 insertions(+), 10 deletions(-)
create mode 100644 arch/ppc/platforms/4xx/xilinx_generic_mlxxx.c
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
index 8b8ce8e..0f38dec 100644
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -58,6 +58,7 @@ config XILINX_ML300
select XILINX_VIRTEX_II_PRO
select EMBEDDEDBOOT
select XILINX_EMBED_CONFIG
+ select XILINX_MLxxx
help
This option enables support for the Xilinx ML300 evaluation board.
@@ -74,22 +75,25 @@ config XILINX_ML403
select XILINX_VIRTEX_4_FX
select EMBEDDEDBOOT
select XILINX_EMBED_CONFIG
+ select XILINX_MLxxx
help
This option enables support for the Xilinx ML403 evaluation board.
config XILINX_ML405
- bool "Xilinx-ML405"
- select XILINX_VIRTEX_4_FX
- select EMBEDDEDBOOT
- select XILINX_EMBED_CONFIG
- help
- This option enables support for the Xilinx ML405 evaluation board.
+ bool "Xilinx-ML405"
+ select XILINX_VIRTEX_4_FX
+ select EMBEDDEDBOOT
+ select XILINX_EMBED_CONFIG
+ select XILINX_MLxxx
+ help
+ This option enables support for the Xilinx ML405 evaluation board.
config XILINX_ML41x
bool "Xilinx-ML41x"
select XILINX_VIRTEX_4_FX
select EMBEDDEDBOOT
select XILINX_EMBED_CONFIG
+ select XILINX_MLxxx
help
This option enables support for the Xilinx ML410/411 evaluation boards.
@@ -245,6 +249,12 @@ config 405GPR
depends on SYCAMORE
default y
+config XILINX_MLxxx
+ bool
+ help
+ Include platform support for many Xilinx development boards
+ with configuration data stored in IIC eeprom.
+
config XILINX_VIRTEX_II_PRO
bool
select XILINX_VIRTEX
diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
index ee4c987..3c42f85 100644
--- a/arch/ppc/platforms/4xx/Makefile
+++ b/arch/ppc/platforms/4xx/Makefile
@@ -19,6 +19,8 @@ obj-$(CONFIG_XILINX_XUPV2P) += xilinx_generic_ppc.o xilinx_xupv2p.o
obj-$(CONFIG_XILINX_ML403) += xilinx_generic_ppc.o
obj-$(CONFIG_XILINX_ML405) += xilinx_generic_ppc.o
obj-$(CONFIG_XILINX_ML41x) += xilinx_generic_ppc.o
+obj-$(CONFIG_XILINX_MLxxx) += xilinx_generic_mlxxx.o
+obj-$(CONFIG_XILINX_ML507) += xilinx_generic_mlxxx.o
obj-$(CONFIG_405GP) += ibm405gp.o
obj-$(CONFIG_REDWOOD_5) += ibmstb4.o
diff --git a/arch/ppc/platforms/4xx/xilinx_generic_mlxxx.c b/arch/ppc/platforms/4xx/xilinx_generic_mlxxx.c
new file mode 100644
index 0000000..0fb5878
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xilinx_generic_mlxxx.c
@@ -0,0 +1,37 @@
+/*
+ * Xilinx MLxxx board initialization
+ *
+ * 2007 (c) Xilinx, Inc. This file is licensed under the
+ * terms of the GNU General Public License version 2. This program is licensed
+ * "as is" without any warranty of any kind, whether express or implied.
+ */
+
+#include <linux/io.h>
+#include <linux/xilinx_devices.h>
+#include <linux/platform_device.h>
+
+extern bd_t __res;
+
+int virtex_device_fixup(struct platform_device *dev)
+{
+ static int temac_count = 0;
+ struct xlltemac_platform_data *pdata = dev->dev.platform_data;
+
+#if defined(CONFIG_XILINX_MLxxx)
+
+ if (strcmp(dev->name, "xilinx_lltemac") == 0) {
+
+ /* only copy the mac address into the 1st lltemac if
+ there are multiple */
+
+ if (temac_count++ == 0) {
+ printk(KERN_INFO "Fixup MAC address for %s:%d\n",
+ dev->name, dev->id);
+ /* Set the MAC address from the iic eeprom info in the board data */
+ memcpy(pdata->mac_addr, ((bd_t *) &__res)->bi_enetaddr, 6);
+ }
+ }
+#endif
+
+ return 0;
+}
diff --git a/drivers/net/xilinx_lltemac/xlltemac_main.c b/drivers/net/xilinx_lltemac/xlltemac_main.c
index f393c5a..01c9943 100644
--- a/drivers/net/xilinx_lltemac/xlltemac_main.c
+++ b/drivers/net/xilinx_lltemac/xlltemac_main.c
@@ -2980,7 +2980,6 @@ static int detect_phy(struct net_local *lp, char *dev_name)
printk(KERN_WARNING "XTemac: No PHY detected. Assuming a PHY at address 0\n");
return 0; /* default to zero */
}
-extern bd_t __res;
/** Shared device initialization code */
static int xtenet_setup(
@@ -3048,9 +3047,8 @@ static int xtenet_setup(
goto error;
}
- /* Set the MAC address from the iic eeprom info in the board data */
- memcpy(ndev->dev_addr, ((bd_t *) &__res)->bi_enetaddr, 6);
- memcpy(pdata->mac_addr, ((bd_t *) &__res)->bi_enetaddr, 6);
+ /* Set the MAC address from platform data */
+ memcpy(ndev->dev_addr, pdata->mac_addr, 6);
if (_XLlTemac_SetMacAddress(&lp->Emac, ndev->dev_addr) != XST_SUCCESS) {
/* should not fail right after an initialize */
--
1.5.2.1
^ 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