* Re: board with no RTC
From: Matt Porter @ 2005-01-12 23:48 UTC (permalink / raw)
To: Goforth, Edward; +Cc: linuxppc-embedded
In-Reply-To: <9A48EF7239039B48834A3F6B644B0C71EF8679@vaff06-mail01.ad.gd-ais.com>
On Wed, Jan 12, 2005 at 06:25:45PM -0500, Goforth, Edward wrote:
> We have a 440gx based custom board. I have learned that it does not
> have a RTC. Has anyone had any success with a board without a RTC, or is
> it even possible? How much of a problem will this cause?
>
> Should we get the board respun with a RTC? We would prefer using a 2.4
> kernel, but would certainly go to a 2.6 kernel if that made things
> easier.
>
> Thanks in advance for any advice.
No problems. Just set your time from another source. Many PPC boards
do this that don't need local time retention across power cycles.
I've got a 440gx board sitting here running happily this way.
-Matt
^ permalink raw reply
* Re: RFC: [PATCH] platform device driver model support
From: Mark A. Greer @ 2005-01-12 23:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0501120133080.21665@blarg.somerset.sps.mot.com>
Kumar Gala wrote:
>All,
>
>Please take a look at the following patch. It adds driver model support
>via platform devices to 85xx. This is originally based on patches from
>Jason M.
>
>The idea behind the code is that for a give family: 4xx, 8xx, 82xx, 83xx,
>85xx, 86xx we will have structure defns for the following:
>
>enum ppc_soc_devices
>in asm-ppc/<family.h>:
> list of all unique devices in the family
>
>struct platform_device soc_platform_devices[]
>in arch/ppc/platforms/<family>/<family>_devices.c:
> describes all platform devices that exist in the family
>
>struct soc_spec soc_specs[]
>in arch/ppc/platforms/<family>/<family>_soc.c:
> describes each unique chip in the family and what devices it has
>
>Plus the following functions:
>
>identify_soc_by_id() -- determine soc by an int id
>identify_soc_by_name() -- determin soc by name (useful in some 82xx cases)
>ppc_soc_get_pdata() -- get platform_data pointer so board code can modify
>ppc_soc_update_paddr() -- update iomem resources with a given paddr
>
>Please provide feedback, I want to get this into 2.6.11 for 85xx.
>
>
My $0.02.
I didn't go thru in complete detail but I like the idea. I have a
couple minor comments, though.
1) Can we pick something other than 'soc' since the Marvell bridges
really aren't SOCs? I don't really know what is better but just to
throw something out, how about haing them all look like ppc_pd_xxx()?
2) In 8540_ads.c you're digging out platform_device entries and
modifying them in your mpc8540ads_setup_arch() routine. I think the
platform_device "way" of doing that would be to make your mods via the
platform_notify() hook (eventually called by device_add() which was
ultimately called from platform_add_devices()).
Mark
^ permalink raw reply
* Re: status of the G4 l2 cache flush and MSR errate patch
From: Benjamin Herrenschmidt @ 2005-01-13 0:33 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev list
In-Reply-To: <20050109123515.GC17561@pegasos>
> Mmm, well, i am not really the author of this one. Jacob Pan from freescale is
> the author, so we should change this, will do. So this should show :
>
> ## DP: Patch author: Pan Jacob-r7aahq <Jacob.Pan@freescale.com>
> > ## DP: Upstream status: under review by benh.
>
> The patch does two things. Use hardware assist for cache flush, which seems to
> be ok on 744x processors, but broken on earlier G4s and G3s. And add a printk
> in case of some exception, so the user knows about it instead of it being
> silently discarded.
The HW assist isn't completely ok neither... it should be enough for
enabling the cache at boot though. I've been banging my head lately
trying to get a properly working & reliable cache flush mecanism for use
on the Mac laptops since we need that for cpufreq and sleep on various
models, but what I have right now is just a "works most of the time"
kind of implementation.
> I was under the impression that benh said that the patch was ok, but not
> really relevant, since it applies to code travel cases which either are not
> really used in the common case, or result in a dying of the kernel anyway.
> Don't remember all the details though. They do respond to some G4 processor
> errata's though.
I'll have a look again. Just back from vacation, leave me a coupe of
days to catch up with everything and I'll take care of those.
Ben.
^ permalink raw reply
* RE: Kernel boot hangs by parallel flood pings
From: Ho Lee @ 2005-01-13 0:14 UTC (permalink / raw)
To: 'linuxppc'; +Cc: 'Steffen Rumler'
In-Reply-To: <F9865C8B04ED3A4D8D793FCE19368854F2FBDF@EXCHANGE01.corp.skystream.com>
I met the same problem in CPM driver, and there could be many
solutions. I think the right place to fix is the fec driver.
The fec driver registers interrupt handler during the
initialization not when the device is opened, so it may
receive packets even the device is not up and running (also
before the network subsystem is initialized) My fix was to
ignore the received packets if the driver is not opened.
--- linux-2.4.26.orig/arch/ppc/8xx_io/fec.c
+++ linux-2.4.26/arch/ppc/8xx_io/fec.c
@@ -587,6 +587,9 @@
goto rx_processing_done;
}
+ if (!netif_running(dev))
+ goto rx_processing_done;
+
/* Process the incoming frame.
*/
fep->stats.rx_packets++;
Regards,
Ho
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Rune Torgersen
Sent: Wednesday, January 12, 2005 7:32 AM
To: Steffen Rumler; linuxppc
Subject: RE: Kernel boot hangs by parallel flood pings
--- Kernel.old/net/ipv4/ip_output.c Thu Jun 5 09:00:39 2003
+++ Kernel/net/ipv4/ip_output.c Thu Jun 5 09:00:28 2003
@@ -1087,11 +1087,11 @@
void __init ip_init(void)
{
- dev_add_pack(&ip_packet_type);
-
ip_rt_init();
inet_initpeers();
+ dev_add_pack(&ip_packet_type);
+
#ifdef CONFIG_IP_MULTICAST
proc_net_create("igmp", 0, ip_mc_procinfo);
#endif
>>
^ permalink raw reply
* Re: RFC: [PATCH] platform device driver model support
From: Kumar Gala @ 2005-01-13 4:19 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded, Kumar Gala
In-Reply-To: <41E5B318.3060304@mvista.com>
> My $0.02.
>
> I didn't go thru in complete detail but I like the idea.=A0 I have a
> couple minor comments, though.
>
> 1) Can we pick something other than 'soc' since the Marvell bridges
> really aren't SOCs?=A0 I don't really know what is better but just to
> throw something out, how about haing them all look like ppc_pd_xxx()?
What about ppc_plat_xxx() or ppc_sys_xxx() [for system]? 'sys' maybe=20
more consistent with our naming conventions in that arch/ppc/platforms=20=
is more board focused, and arch/ppc/syslib is bridge and non-core chip=20=
functionality.
> 2) In 8540_ads.c you're digging out platform_device entries and
> modifying them in your mpc8540ads_setup_arch() routine.=A0 I think the
> platform_device "way" of doing that would be to make your mods via the
> platform_notify() hook (eventually called by device_add() which was
> ultimately called from platform_add_devices()).
This is problematic for some things like the updating of the IOMEM=20
resources since that needs to occur before platform_device_register is=20=
called. However, the updates in mpc8540_ads.c could possibly handled=20
by platform_notify(), will look into that.
- kumar=
^ permalink raw reply
* About Zebra Error
From: Aubrey Lee @ 2005-01-13 8:50 UTC (permalink / raw)
To: linuxppc-embedded
hi, In the PC(i686) system, I build and run zebra successfully. And now
I'm porting it to the powerpc system. Cross-compiling finished without error.
But when I run the zebra from my target board, it gives me a big headache:
--------------------------------------------------------------------------
bash-2.05b# /opt/zebra/sbin/zebra
sock: Address family not supported by protocol
----------------------------------------------------------------------------
And Up to now I cann't find the message in the souce
code files.
The two ethx and their driver of my board is OK.
What shall I do?
Any comment and suggestion will be welcome!
Thank you very much!
Best regards!
Aubrey.Lee
^ permalink raw reply
* Re: About Zebra Error
From: Eugene Surovegin @ 2005-01-13 9:12 UTC (permalink / raw)
To: Aubrey Lee; +Cc: linuxppc-embedded
In-Reply-To: <7f834d4e0501130050666b757a@mail.gmail.com>
On Thu, Jan 13, 2005 at 04:50:27PM +0800, Aubrey Lee wrote:
> hi, In the PC(i686) system, I build and run zebra successfully. And now
> I'm porting it to the powerpc system. Cross-compiling finished without error.
> But when I run the zebra from my target board, it gives me a big headache:
> --------------------------------------------------------------------------
> bash-2.05b# /opt/zebra/sbin/zebra
> sock: Address family not supported by protocol
> ----------------------------------------------------------------------------
> And Up to now I cann't find the message in the souce
> code files.
> The two ethx and their driver of my board is OK.
> What shall I do?
Most probably zebra needs some some socket family (e.g. PF_PACKET)
which wasn't enabled in your PPC kernel.
Compare .config files for x86 and PPC kernels, especially networking
configuration parts.
The reason you cannot find "Address family not supported by protocol"
message in the zebra sources is because this message comes from libc,
e.g. by using perror(3) or sys_errlist directly.
--
Eugene
^ permalink raw reply
* Re: About Zebra Error
From: Mark Powell @ 2005-01-13 9:18 UTC (permalink / raw)
To: Aubrey Lee; +Cc: linuxppc-embedded
In-Reply-To: <7f834d4e0501130050666b757a@mail.gmail.com>
Aubrey Lee wrote:
> hi, In the PC(i686) system, I build and run zebra successfully. And now
>I'm porting it to the powerpc system. Cross-compiling finished without error.
>But when I run the zebra from my target board, it gives me a big headache:
>--------------------------------------------------------------------------
>bash-2.05b# /opt/zebra/sbin/zebra
> sock: Address family not supported by protocol
>----------------------------------------------------------------------------
>And Up to now I cann't find the message in the souce
>code files.
> The two ethx and their driver of my board is OK.
> What shall I do?
>
>
I had a similar message when running udhcpd. The problem was that some
network drivers were built as modules. Adding the following to
modules.conf cured my problem:
# PF_PACKET support needed by udhcpc
alias net-pf-17 af_packet
--
Mark Powell, Senior Software Engineer
Curtiss-Wright Controls Embedded Computing
Tel: +44 (0) 1763 852222
Email: medp@primagraphics.com
^ permalink raw reply
* USB host on MPC 8272ADS
From: Vitaly Bordug @ 2005-01-13 9:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am currently trying to support USB host controller on MPC8272ADS board.
Does anyone proceed with this more or less? In my case, CPM does not
transmit packet
(READY flag is not cleared as it should when CPM handles transaction).
What can be possible reasons of such behavior?
--
Sincerely, Vitaly
^ permalink raw reply
* About zebra Error
From: Aubrey Lee @ 2005-01-13 10:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi, now I know what the problem is.
For my case, the ppc-linux kernel should be configured as the following:
The Item [Unix domain Socket] should be selected [Y]
Just so so.
^ permalink raw reply
* TQM860L hangs after soft reboot
From: Jens-Peter.Oswald @ 2005-01-13 12:37 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 576 bytes --]
Hi all,
We've designed a custom board for an TQM860L module from TQ-Components.
Now the following behaviour occurs:
After a soft reset (from linux or bootloader u-boot) the board hangs.
Only a hard reset (power cycle or RESIN# pin low of TQ-Modul) wakes it
up.
In the evaluation board STK8xxL from TQ the modul boots normally after a
soft reset.
I assume it might be a forgotten pullup- or pull down in our custom
board.
Any hints which pins I must check?
By the way, how does linux handle a soft reset?
--
Dipl.-Ing. Jens-Peter Oswald
[-- Attachment #1.2: Type: text/html, Size: 1404 bytes --]
^ permalink raw reply
* [PATCH] 8272ADS FCC clock setting
From: Li Yang-r58472 @ 2005-01-13 9:49 UTC (permalink / raw)
To: linuxppc-dev
The patches fix Clock pin Configuration of MPC8272ADS board FCC support, and clear up comment on it.
Signed-off-by: Li Yang <LeoLi@freescale.com>
Patch for 2.4.28:
--- linux-2.4.28/arch/ppc/cpm2_io/fcc_enet.c 2004-08-08 07:26:04.000000000 +0800
+++ linux-patched/arch/ppc/cpm2_io/fcc_enet.c 2004-12-23 14:02:04.980850470 +0800
@@ -158,14 +158,16 @@
#define PA1_DIRA0 (PA1_RXDAT | PA1_CRS | PA1_COL | PA1_RXER | PA1_RXDV)
#define PA1_DIRA1 (PA1_TXDAT | PA1_TXEN | PA1_TXER)
-/* CLK12 is receive, CLK11 is transmit. These are board specific. -*/
+/* FCC1 Clock configuration. These are board specific.
+ */
#ifdef CONFIG_ADS8272
+/* CLK11 is receive, CLK10 is transmit. */
#define PC_F1RXCLK ((uint)0x00000400)
#define PC_F1TXCLK ((uint)0x00000200)
-#define CMX1_CLK_ROUTE ((uint)0x36000000)
+#define CMX1_CLK_ROUTE ((uint)0x35000000)
#define CMX1_CLK_MASK ((uint)0xff000000)
#else
+/* CLK12 is receive, CLK11 is transmit. */
#define PC_F1RXCLK ((uint)0x00000800)
#define PC_F1TXCLK ((uint)0x00000400)
#define CMX1_CLK_ROUTE ((uint)0x3e000000)
@@ -189,14 +191,16 @@
#define PB2_DIRB0 (PB2_RXDAT | PB2_CRS | PB2_COL | PB2_RXER | PB2_RXDV)
#define PB2_DIRB1 (PB2_TXDAT | PB2_TXEN | PB2_TXER)
-/* CLK13 is receive, CLK14 is transmit. These are board dependent. -*/
+/* FCC2 Clock configuration. These are board specific.
+ */
#ifdef CONFIG_ADS8272
+/* CLK15 is receive, CLK16 is transmit. */
#define PC_F2RXCLK ((uint)0x00004000)
#define PC_F2TXCLK ((uint)0x00008000)
#define CMX2_CLK_ROUTE ((uint)0x00370000)
#define CMX2_CLK_MASK ((uint)0x00ff0000)
#else
+/* CLK13 is receive, CLK14 is transmit. */
#define PC_F2RXCLK ((uint)0x00001000)
#define PC_F2TXCLK ((uint)0x00002000)
#define CMX2_CLK_ROUTE ((uint)0x00250000)
@@ -220,8 +224,9 @@
#define PB3_DIRB0 (PB3_RXDAT | PB3_CRS | PB3_COL | PB3_RXER | PB3_RXDV)
#define PB3_DIRB1 (PB3_TXDAT | PB3_TXEN | PB3_TXER)
-/* CLK15 is receive, CLK16 is transmit. These are board dependent. -*/
+/* FCC3 Clock configuration. These are board specific.
+ * CLK15 is receive, CLK16 is transmit.
+ */
#define PC_F3RXCLK ((uint)0x00004000)
#define PC_F3TXCLK ((uint)0x00008000)
#define CMX3_CLK_ROUTE ((uint)0x00003700)
Patch for 2.6.9:
--- linux-2.6.9/arch/ppc/8260_io/fcc_enet.c 2004-10-19 05:54:07.000000000 +0800
+++ linux-patched/arch/ppc/8260_io/fcc_enet.c 2004-12-23 13:58:50.698840185 +0800
@@ -158,19 +158,22 @@
#define PA1_DIRA0 (PA1_RXDAT | PA1_CRS | PA1_COL | PA1_RXER | PA1_RXDV)
#define PA1_DIRA1 (PA1_TXDAT | PA1_TXEN | PA1_TXER)
+/* FCC1 Clock configuration. These are board specific.
+ */
#ifdef CONFIG_SBC82xx
-/* rx is clk9, tx is clk10 */
+/* CLK9 is receive, CLK10 is transmit. */
#define PC_F1RXCLK ((uint)0x00000100)
#define PC_F1TXCLK ((uint)0x00000200)
#define CMX1_CLK_ROUTE ((uint)0x25000000)
#define CMX1_CLK_MASK ((uint)0xff000000)
#elif defined(CONFIG_ADS8272)
+/* CLK11 is receive, CLK10 is transmit. */
#define PC_F1RXCLK ((uint)0x00000400)
#define PC_F1TXCLK ((uint)0x00000200)
-#define CMX1_CLK_ROUTE ((uint)0x36000000)
+#define CMX1_CLK_ROUTE ((uint)0x35000000)
#define CMX1_CLK_MASK ((uint)0xff000000)
#else /* other boards */
-/* CLK12 is receive, CLK11 is transmit. These are board specific. */
+/* CLK12 is receive, CLK11 is transmit. */
#define PC_F1RXCLK ((uint)0x00000800)
#define PC_F1TXCLK ((uint)0x00000400)
#define CMX1_CLK_ROUTE ((uint)0x3e000000)
@@ -194,14 +197,16 @@
#define PB2_DIRB0 (PB2_RXDAT | PB2_CRS | PB2_COL | PB2_RXER | PB2_RXDV)
#define PB2_DIRB1 (PB2_TXDAT | PB2_TXEN | PB2_TXER)
-/* CLK13 is receive, CLK14 is transmit. These are board dependent. -*/
+/* FCC2 Clock configuration. These are board specific.
+ */
#ifdef CONFIG_ADS8272
+/* CLK15 is receive, CLK16 is transmit. */
#define PC_F2RXCLK ((uint)0x00004000)
#define PC_F2TXCLK ((uint)0x00008000)
#define CMX2_CLK_ROUTE ((uint)0x00370000)
#define CMX2_CLK_MASK ((uint)0x00ff0000)
#else
+/* CLK13 is receive, CLK14 is transmit. */
#define PC_F2RXCLK ((uint)0x00001000)
#define PC_F2TXCLK ((uint)0x00002000)
#define CMX2_CLK_ROUTE ((uint)0x00250000)
@@ -225,8 +230,9 @@
#define PB3_DIRB0 (PB3_RXDAT | PB3_CRS | PB3_COL | PB3_RXER | PB3_RXDV)
#define PB3_DIRB1 (PB3_TXDAT | PB3_TXEN | PB3_TXER)
-/* CLK15 is receive, CLK16 is transmit. These are board dependent. -*/
+/* FCC3 Clock configuration. These are board specific.
+ * CLK15 is receive, CLK16 is transmit.
+ */
#define PC_F3RXCLK ((uint)0x00004000)
#define PC_F3TXCLK ((uint)0x00008000)
#define CMX3_CLK_ROUTE ((uint)0x00003700)
--
Leo Li
Software Engineer
Metrowerks -- Freescale Semiconductor
Office: +8610-65642272
LeoLi@freescale.com
^ permalink raw reply
* Re: [PATCH] cpm2_io/fcc_enet: make clock setting more straightforward
From: Tom Rini @ 2005-01-13 14:30 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730813D3@zch01exm40.ap.freescale.net>
On Thu, Jan 13, 2005 at 06:07:49PM +0800, Li Yang-r58472 wrote:
> This patch refined the clock setting part of FCC Ethernet driver, making it easier for further porting. It also fixed MPC8272ADS setting. If apply this patch, the previous patch is not needed.
This looks like what I thought I pushed to linuxppc-2.4 already. Once
linux-2.4.29 comes out I'll work with Kumar and Marcelo to see what we
can get merged back into the main linux-2.4 tree again.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: TQM860L hangs after soft reboot
From: Wolfgang Denk @ 2005-01-13 14:46 UTC (permalink / raw)
To: Jens-Peter.Oswald; +Cc: linuxppc-embedded
In-Reply-To: <1D40077EC04042479FDA552D718E051B010D7528@ktms3.net.local>
In message <1D40077EC04042479FDA552D718E051B010D7528@ktms3.net.local> you wrote:
>
> After a soft reset (from linux or bootloader u-boot) the board hangs.
I don't know which Linux kernel you're running, but U-Boot triggers a
checkstop reset of the CPU to reboot the system. If this does not
restart the board, then there is a hardware problem.
> I assume it might be a forgotten pullup- or pull down in our custom
> board.
>
> Any hints which pins I must check?
You should probably contact TQ Support with such a question. I doubt
that this is a topic for this mailing list. Try asking Andreas Widder,
08153-9308-235, <Andreas.Widder@tqc.de>
> By the way, how does linux handle a soft reset?
See function m8xx_restart() in "arch/ppc/kernel/m8xx_setup.c"; in our
linuxppc_2_4_devel tree the same mechanism as in U-Boot (i. e.
checkstop reset) is used.
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
The best things in life are for a fee.
^ permalink raw reply
* AW: TQM860L hangs after soft reboot
From: Martin Krause @ 2005-01-13 14:46 UTC (permalink / raw)
To: Jens-Peter.Oswald; +Cc: linuxppc-embedded
Hi Jens-Peter,
linuxppc-embedded-bounces@ozlabs.org wrote on Donnerstag, 13. Januar
2005 13:37:=20
> Hi all,
> We've designed a custom board for an TQM860L module from
> TQ-Components.=20
> Now the following behaviour occurs:
> After a soft reset (from linux or bootloader u-boot) the board hangs.
> Only a hard reset (power cycle or RESIN# pin low of TQ-Modul) wakes
> it up.
RESIN# is routed to pin PORESET# of the CPU (with some reset logic in =
between).
> In the evaluation board STK8xxL from TQ the modul boots normally
> after a soft reset. I assume it might be a forgotten pullup- or pull
> down in our custom board.
Try a look at the user manual: MPC860UM 3/2003, REV 2, Table 11-1.MPC860 =
Reset Responses and the following chapter.
> By the way, how does linux handle a soft reset?
U-Boot uses the checkstop reset (caused by a machine check after=20
trying to execute an instruciton at a non-existing address).
Hope this was somewhat of a help.
Regards,
Martin
^ permalink raw reply
* Re: [PATCH] 8272ADS FCC clock setting
From: Tom Rini @ 2005-01-13 14:57 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730813D2@zch01exm40.ap.freescale.net>
On Thu, Jan 13, 2005 at 05:49:25PM +0800, Li Yang-r58472 wrote:
> The patches fix Clock pin Configuration of MPC8272ADS board FCC support, and clear up comment on it.
This shouldn't be required in linuxppc-2.4, as I pushed your patch to
cleanup the pin selection earlier, and I'll see about getting it into
2.4.30 (too late for 2.4.29). For 2.6, I've pushed these changes (along
with some others for PQ2FADS) into linuxppc-2.5, as the fcc_enet driver
in stock 2.6 needs massive updates (I'm hoping it can be obsoleted by a
new one from Andy Flemming).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH] cpm2_io/fcc_enet: make clock setting more straightforward
From: Li Yang-r58472 @ 2005-01-13 10:07 UTC (permalink / raw)
To: linuxppc-dev
This patch refined the clock setting part of FCC Ethernet driver, making it easier for further porting. It also fixed MPC8272ADS setting. If apply this patch, the previous patch is not needed.
I don't know if the style of this enhancement is good or bad, please comment.
Signed-off-by: Li Yang <LeoLi@freescale.com>
--- linux-2.4.28/arch/ppc/cpm2_io/fcc_enet.c 2004-08-08 07:26:04.000000000 +0800
+++ linux-patched/arch/ppc/cpm2_io/fcc_enet.c 2004-12-29 16:52:47.911064570 +0800
@@ -16,6 +16,9 @@
* small packets. Since this is a cache coherent processor and CPM,
* I could also preallocate SKB's and use them directly on the interface.
*
+ * 2004-12 Leo Li (leoli@freescale.com)
+ * - Rework the FCC clock configuration part, make it easier to configure.
+ *
*/
#include <linux/config.h>
@@ -141,6 +144,62 @@
* help show what pins are used for each device.
*/
+/* Since the CLK setting changes greatly from board to board, I changed
+ * it to a easy way. You just need to specify which CLK number to use.
+ * Note that only limited choices can be make on each port.
+ */
+
+/* FCC1 Clock Source Configuration. There are board specific.
+ Can only choose from CLK9-12 */
+#ifdef CONFIG_ADS8272
+#define F1_RXCLK 11
+#define F1_TXCLK 10
+#else
+#define F1_RXCLK 12
+#define F1_TXCLK 11
+#endif
+
+/* FCC2 Clock Source Configuration. There are board specific.
+ Can only choose from CLK13-16 */
+#ifdef CONFIG_ADS8272
+#define F2_RXCLK 15
+#define F2_TXCLK 16
+#else
+#define F2_RXCLK 13
+#define F2_TXCLK 14
+#endif
+
+/* FCC3 Clock Source Configuration. There are board specific.
+ Can only choose from CLK13-16 */
+#define F3_RXCLK 15
+#define F3_TXCLK 16
+
+/* Automatically generates register configurations */
+#define PC_CLK(x) ((uint)(1<<(x-1))) /* FCC CLK I/O ports */
+
+#define CMXFCR_RF1CS(x) ((uint)((x-5)<<27)) /* FCC1 Receive Clock Source */
+#define CMXFCR_TF1CS(x) ((uint)((x-5)<<24)) /* FCC1 Transmit Clock Source */
+#define CMXFCR_RF2CS(x) ((uint)((x-9)<<19)) /* FCC2 Receive Clock Source */
+#define CMXFCR_TF2CS(x) ((uint)((x-9)<<16)) /* FCC2 Transmit Clock Source */
+#define CMXFCR_RF3CS(x) ((uint)((x-9)<<11)) /* FCC3 Receive Clock Source */
+#define CMXFCR_TF3CS(x) ((uint)((x-9)<<8)) /* FCC3 Transmit Clock Source */
+
+#define PC_F1RXCLK PC_CLK(F1_RXCLK)
+#define PC_F1TXCLK PC_CLK(F1_TXCLK)
+#define CMX1_CLK_ROUTE (CMXFCR_RF1CS(F1_RXCLK) | CMXFCR_TF1CS(F1_TXCLK))
+#define CMX1_CLK_MASK ((uint)0xff000000)
+
+#define PC_F2RXCLK PC_CLK(F2_RXCLK)
+#define PC_F2TXCLK PC_CLK(F2_TXCLK)
+#define CMX2_CLK_ROUTE (CMXFCR_RF2CS(F2_RXCLK) | CMXFCR_TF2CS(F2_TXCLK))
+#define CMX2_CLK_MASK ((uint)0x00ff0000)
+
+#define PC_F3RXCLK PC_CLK(F3_RXCLK)
+#define PC_F3TXCLK PC_CLK(F3_TXCLK)
+#define CMX3_CLK_ROUTE (CMXFCR_RF3CS(F3_RXCLK) | CMXFCR_TF3CS(F3_TXCLK))
+#define CMX3_CLK_MASK ((uint)0x0000ff00)
+
+
/* I/O Pin assignment for FCC1. I don't yet know the best way to do this,
* but there is little variation among the choices.
*/
@@ -158,19 +217,6 @@
#define PA1_DIRA0 (PA1_RXDAT | PA1_CRS | PA1_COL | PA1_RXER | PA1_RXDV)
#define PA1_DIRA1 (PA1_TXDAT | PA1_TXEN | PA1_TXER)
-/* CLK12 is receive, CLK11 is transmit. These are board specific.
-*/
-#ifdef CONFIG_ADS8272
-#define PC_F1RXCLK ((uint)0x00000400)
-#define PC_F1TXCLK ((uint)0x00000200)
-#define CMX1_CLK_ROUTE ((uint)0x36000000)
-#define CMX1_CLK_MASK ((uint)0xff000000)
-#else
-#define PC_F1RXCLK ((uint)0x00000800)
-#define PC_F1TXCLK ((uint)0x00000400)
-#define CMX1_CLK_ROUTE ((uint)0x3e000000)
-#define CMX1_CLK_MASK ((uint)0xff000000)
-#endif
/* I/O Pin assignment for FCC2. I don't yet know the best way to do this,
* but there is little variation among the choices.
@@ -189,19 +235,6 @@
#define PB2_DIRB0 (PB2_RXDAT | PB2_CRS | PB2_COL | PB2_RXER | PB2_RXDV)
#define PB2_DIRB1 (PB2_TXDAT | PB2_TXEN | PB2_TXER)
-/* CLK13 is receive, CLK14 is transmit. These are board dependent.
-*/
-#ifdef CONFIG_ADS8272
-#define PC_F2RXCLK ((uint)0x00004000)
-#define PC_F2TXCLK ((uint)0x00008000)
-#define CMX2_CLK_ROUTE ((uint)0x00370000)
-#define CMX2_CLK_MASK ((uint)0x00ff0000)
-#else
-#define PC_F2RXCLK ((uint)0x00001000)
-#define PC_F2TXCLK ((uint)0x00002000)
-#define CMX2_CLK_ROUTE ((uint)0x00250000)
-#define CMX2_CLK_MASK ((uint)0x00ff0000)
-#endif
/* I/O Pin assignment for FCC3. I don't yet know the best way to do this,
* but there is little variation among the choices.
@@ -220,12 +253,6 @@
#define PB3_DIRB0 (PB3_RXDAT | PB3_CRS | PB3_COL | PB3_RXER | PB3_RXDV)
#define PB3_DIRB1 (PB3_TXDAT | PB3_TXEN | PB3_TXER)
-/* CLK15 is receive, CLK16 is transmit. These are board dependent.
-*/
-#define PC_F3RXCLK ((uint)0x00004000)
-#define PC_F3TXCLK ((uint)0x00008000)
-#define CMX3_CLK_ROUTE ((uint)0x00003700)
-#define CMX3_CLK_MASK ((uint)0x0000ff00)
/* MII status/control serial interface.
*/
--
Leo Li
Software Engineer
Metrowerks -- Freescale Semiconductor
Office: +8610-65642272
LeoLi@freescale.com
^ permalink raw reply
* RE: board with no RTC
From: Goforth, Edward @ 2005-01-13 15:14 UTC (permalink / raw)
To: linuxppc-embedded
Thanks to everyone who responded. Now that a RTC is not a requirement,
can anyone offer advice on what I will need to do to get the kernel
(2.4.18) to play nice?
Thanks,
Ed
> -----Original Message-----
> From: Ed.Goforth@gd-ais.com [mailto:Ed.Goforth@gd-ais.com]=20
> Sent: Wednesday, January 12, 2005 6:26 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: board with no RTC
>=20
>=20
> We have a 440gx based custom board. I have learned that it does not
> have a RTC. Has anyone had any success with a board without a=20
> RTC, or is
> it even possible? How much of a problem will this cause? =20
>=20
> Should we get the board respun with a RTC? We would prefer=20
> using a 2.4
> kernel, but would certainly go to a 2.6 kernel if that made things
> easier.
>=20
> Thanks in advance for any advice.
>=20
> Ed Goforth
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Tom Rini @ 2005-01-13 15:16 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <20050112151508.GS3391@smtp.west.cox.net>
On Wed, Jan 12, 2005 at 08:15:08AM -0700, Tom Rini wrote:
> On Wed, Jan 12, 2005 at 03:17:11PM +0100, Joakim Tjernlund wrote:
> > > On Wed, Jan 12, 2005 at 08:53:17AM +0100, Joakim Tjernlund wrote:
[snip]
> > > > Patch looks good to me, but I want to ask when this error
> > > > can be triggered in practice?
> > >
> > > It is possible to see this in the real world, as we (<hat=mvista>) found
> > > this with a customers app.
> >
> > hmm, this app must have been doing something pretty special. Any idea what
> > caused it?
>
> Only vaugely. I'll poke the folks who did the investigation to see if
> they recall (the app is quite large) and follow up with details, I hope.
First, we couldn't get this issue to happen w/ anything but the custom
app. It would generate a lot of I-TLB Error exceptions, with bit 1 of
SRR1 set, and these went fine, the I-TLB got updated, and execution
continued. But then at some point, and we aren't sure why exactly, an
0x1100 is generated, and we crash. We don't know what went and caused
an 0x1100 to be generated instead of an 0x1300 (my wild-ass-guess is the
code jumped very very far ahead).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: board with no RTC
From: Matt Porter @ 2005-01-13 16:26 UTC (permalink / raw)
To: Goforth, Edward; +Cc: linuxppc-embedded
In-Reply-To: <9A48EF7239039B48834A3F6B644B0C71EF8750@vaff06-mail01.ad.gd-ais.com>
On Thu, Jan 13, 2005 at 10:14:20AM -0500, Goforth, Edward wrote:
> Thanks to everyone who responded. Now that a RTC is not a requirement,
> can anyone offer advice on what I will need to do to get the kernel
> (2.4.18) to play nice?
Are you using the linuxppc-2.4 tree? If you want up to date 2.4 4xx
support you should be using that tree as a starting point. Support
is better yet in 2.6 where most developers are spending their time.
-Matt
^ permalink raw reply
* Re: RFC: [PATCH] platform device driver model support
From: Mark A. Greer @ 2005-01-13 17:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded, Kumar Gala
In-Reply-To: <579DFDF6-651A-11D9-92A0-000393DBC2E8@freescale.com>
Kumar Gala wrote:
>> My $0.02.
>>
>> I didn't go thru in complete detail but I like the idea. I have a
>> couple minor comments, though.
>>
>> 1) Can we pick something other than 'soc' since the Marvell bridges
>> really aren't SOCs? I don't really know what is better but just to
>> throw something out, how about haing them all look like ppc_pd_xxx()?
>
>
> What about ppc_plat_xxx() or ppc_sys_xxx() [for system]? 'sys' maybe
> more consistent with our naming conventions in that arch/ppc/platforms
> is more board focused, and arch/ppc/syslib is bridge and non-core chip
> functionality.
ppc_sys_xxx() sounds good to me.
>
>
>> 2) In 8540_ads.c you're digging out platform_device entries and
>> modifying them in your mpc8540ads_setup_arch() routine. I think the
>> platform_device "way" of doing that would be to make your mods via the
>> platform_notify() hook (eventually called by device_add() which was
>> ultimately called from platform_add_devices()).
>
>
> This is problematic for some things like the updating of the IOMEM
> resources since that needs to occur before platform_device_register is
> called.
I don't think so. In fact, the platform_notify() will be called from
[platform_add_devices()]/platform_device_register()/device_register()/device_add()/platform_notify().
There is an example in the bk://source.mvista.com/linux-2.5-marvell tree
inside arch/ppc/platforms/katana.c. It was only a suggestion anyway, so
its not a big deal.
Mark
^ permalink raw reply
* Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model)
From: Andy Fleming @ 2005-01-13 19:50 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <20050106070245.GA6539@gate.ebshome.net>
On Jan 6, 2005, at 01:02, Eugene Surovegin wrote:
> On Thu, Dec 23, 2004 at 03:00:13PM -0600, Andy Fleming wrote:
>>
>>> Adds a Phy Abstraction Layer which allows ethernet controllers to
>>> manage their PHYs without knowing the details of how the particular
>>> PHY device operates. This code steals heavily from BenH's sungem
>>> driver, and got some stuff out of Jason McMullan's patch.
>
> Some random notes from quick look at the code:
>
> 1) IMO if we can extract some info from the PHY using _standard_
> registers we should use them, even if the PHY provides some custom
> ones.
>
> I suspect that _all_ XXX_read_status functions for different PHYs in
> your patch can be easily handled by generic IEEE 802.3 compliant code
> (you need to update genphy_read_status to properly handle GigE of
> course).
Ok, I understand this, but a part of me rebels. The "standard"
procedure is to read the Link Partner Advertisement, AND it with the
Advertisement, and then find the highest setting that works. It seems
to me that this is replicating work that is already done by the PHY,
and I hate to do work that's already been done.
I also have one worry about this technique (though I'm still reading
the 802.3 spec to see if my worry is valid). Is it possible that the
PHY would choose a setting which is lower than the highest possible,
and therefore render the method above inaccurate?
>
> 2) genphy can be changed to handle GigE speeds as well.
Yeah, that's not a problem. I just wasn't sure if the bits were
properly defined on non-gigabit PHYs. I will change this, as long as
the relevant bits are always correct on 10/100 PHYs
>
> 3) I think it's better for the genphy case to _detect_ PHY features
> instead of hard coding PHY_BASIC_FEATURES. In this case you can easily
> handle 10/100 and 10/100/1000 PHYs by genphy code.
Ok, that's easy enough
>
> 4) Pause negotiation/advertising is completely missing.
Sigh... I knew someone would ask for that. I will get right on this.
^ permalink raw reply
* Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model)
From: Eugene Surovegin @ 2005-01-13 21:21 UTC (permalink / raw)
To: Andy Fleming; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <61A37C72-659C-11D9-8D70-000393C30512@freescale.com>
On Thu, Jan 13, 2005 at 01:50:31PM -0600, Andy Fleming wrote:
> >I suspect that _all_ XXX_read_status functions for different PHYs in
> >your patch can be easily handled by generic IEEE 802.3 compliant code
> >(you need to update genphy_read_status to properly handle GigE of
> >course).
>
> Ok, I understand this, but a part of me rebels. The "standard"
> procedure is to read the Link Partner Advertisement, AND it with the
> Advertisement, and then find the highest setting that works. It seems
> to me that this is replicating work that is already done by the PHY,
> and I hate to do work that's already been done.
Well, some PHYs have a non-standard way to get this info, some PHYs
don't. I don't understand why do you want to bloat kernel with
knowledge of this PHY-specific registers when there is a standard way
to get this info? In fact I use IBM EMAC with a lot of different PHYs
and never needed this special code, except only PHY initialization
maybe.
> I also have one worry about this technique (though I'm still reading
> the 802.3 spec to see if my worry is valid). Is it possible that the
> PHY would choose a setting which is lower than the highest possible,
> and therefore render the method above inaccurate?
It's a standard, period. If there is a PHY which isn't compliant I
guess it will not work anyway, but in this case, yes, we can use
PHY-specific link detection, but only in this case. I suspect you'll
have a hard time finding such PHY :)
> Yeah, that's not a problem. I just wasn't sure if the bits were
> properly defined on non-gigabit PHYs. I will change this, as long as
> the relevant bits are always correct on 10/100 PHYs
I use ES bit in MII_BMSR register to detect availability of MII_ESR
register. So far it worked OK with number of 10/100 PHYs.
> >4) Pause negotiation/advertising is completely missing.
>
> Sigh... I knew someone would ask for that. I will get right on this.
This is not that difficult, I have example code in NAPI IBM EMAC
driver (http://kernel.ebshome.net).
--
Eugene
^ permalink raw reply
* mpc-i2c.c in 2.6
From: Kumar Gala @ 2005-01-13 21:24 UTC (permalink / raw)
To: Adrian Cox; +Cc: Scott Hall, Embedded PPC Linux list
Adrian,
I was wondering if you had any opinions on the timeout between
transactions in drivers/i2c/busses/mpc-i2c. Looking at it, we
currently set the timeout between transactions to 1 second (HZ). Any
reason its this high?
on 85xx, I'm able to set it to HZ/100 w/o any really issue.
thanks
- kumar
^ permalink raw reply
* Re: mpc-i2c.c in 2.6
From: Mark A. Greer @ 2005-01-13 21:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Hall, Embedded PPC Linux list
In-Reply-To: <8A6296CC-65A9-11D9-B612-000393DBC2E8@freescale.com>
Kumar Gala wrote:
> Adrian,
>
> I was wondering if you had any opinions on the timeout between
> transactions in drivers/i2c/busses/mpc-i2c. Looking at it, we
> currently set the timeout between transactions to 1 second (HZ). Any
> reason its this high?
>
> on 85xx, I'm able to set it to HZ/100 w/o any really issue.
This is just an FYI since I've been in this code recently. You can
change the timeout from userspace with an ioctl. Something like this
should do it:
static char *usage_msg = "Usage: set_timeout <timeout value>\n";
int main(int argc, char **argv)
{
uint timeout;
int file;
if (argc != 2) {
fprintf(stderr, usage_msg);
return 1;
}
timeout = strtoul(argv[1], NULL, 0);
if ((file = open("/dev/i2c/0", O_RDWR)) < 0) {
printf("Can't open device, errno: %d (%s)\n",
errno, strerror(errno));
return 1;
}
if (ioctl(file, I2C_TIMEOUT, &timeout) < 0) {
printf("Can't do TIMEOUT: %s\n", strerror(errno));
return 1;
}
return 0;
}
^ permalink raw reply
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