* Re: CONFIG_PIN_TLB experiments
From: Marcelo Tosatti @ 2005-05-04 19:22 UTC (permalink / raw)
To: Conn Clark; +Cc: linuxppc-embedded
In-Reply-To: <4277BF8F.8040206@esteem.com>
Hi,
On Tue, May 03, 2005 at 11:14:39AM -0700, Conn Clark wrote:
> Marcelo Tosatti wrote:
> >Hi 8xx folks,
>
> <SNIP>
>
> >
> >Actually, CONFIG_PIN_TLB slowdowns the system, as expected (there are only
> >28 usable TLB's instead of 32).
> >
> >
> >v2.6 CONFIG_PIN_TLB:
> >I-TLB userspace misses: 162113
> >I-TLB kernel misses: 135911
> >D-TLB userspace misses: 289452
> >D-TLB kernel misses: 257039
> >
> >v2.6 without CONFIG_PIN_TLB:
> >I-TLB userspace misses: 160828
> >I-TLB kernel misses: 134746
> >D-TLB userspace misses: 253557
> >D-TLB kernel misses: 227383
> >
> >
>
> Considering that the TLB kernel misses are higher with tlb pinning it
> appears as though the pinned TLBs are not marked as valid.
Yep
>
> >The following BDI output shows the pinned, 8MByte data page mapping
> >present,
> >at 0xc0000000.
> >
> >BDI>rds 826
> >SPR 826 : 0x00007f00 32512
> >BDI>rms 792 0x0c001C00
> >BDI>rms 824 1
> >BDI>rds 824
> >SPR 824 : 0xc00000f0 -1073741584
> >BDI>rds 825
> >SPR 825 : 0x00000fe0 4064
> >BDI>rds 826
> >SPR 826 : 0x00007fff 32767 <- "0x00007fff" was 0x00007f00"
> >initially. I tried enabling
> > usermode access without
> > success.
> >
> >There are several 4Kb mappings inside the range covered by this 8Mb TLB
> >entry, for example:
> >
> >BDI>rms 792 0x0c000200
> >BDI>rms 824 1
> >BDI>rds 824
> >SPR 824 : 0xc0224f17 -1071493353
> >BDI>rds 825
> >SPR 825 : 0x002241e0 2245088
> >BDI>rds 826
> >SPR 826 : 0x00007f00 32512
> >
> >And more, without so much detail:
> >SPR 824 : 0xc0224f17 -1071493353
> >SPR 824 : 0xc01fbf17 -1071661289
> >SPR 824 : 0xc0246f17 -1071354089
> >SPR 824 : 0xc023ff17 -1071382761
> >SPR 824 : 0xc7e35f17 - 941400297
> >SPR 824 : 0xc0244f17 -1071362281
> >SPR 824 : 0xc023ef17 -1071386857
> >
> >Note that protection (SPR 826) is exactly the same as the 8Mbyte page
> >protection.
> >Why is the translation mechanism rejection the pinned mappings?
> >
> >Dan, have you ever seen this work? Am I misunderstanding how the pinned
> >entries are supposed to work?
>
> When you load the Mx_EPN of the pinned area is the EV bit being set?
Yep.
"MD_RAM1" (SPR 826) is set:
SPR 826 : 0x00007fff 32767 <- "0x00007fff" was 0x00007f00"
Bits 17 and 18 are set. Their meaning is: "Change bit for DTLB entry" and
"Entry valid flag" respectively.
Bits 19...23 are also set, they represent supervisor access. Note that
bit 23 "supervisor access type" is set: 0 is read-only, 1 is read-write.
so everything looks OK here.
"MD_RAM0":
SPR 825 : 0x00000fe0 4064
Bits 20...26 are set.
20-22: 8Mbyte page set.
23-26: APGI (access protection group in 1's complement) set. It is
zero (1111 in 1's complement).
27: guarded memory not set.
"MD_CAM":
SPR 824 : 0xc00000f0 -1073741584
Bits 24-27 are set.
24-26 is "page size" (111 = 8Mb) and 27 indicates "shared page"
(ASID comparisong disabled).
The 8Mbyte page is used at boot, from "start_here" until "MMU_init()"
gets called...
The manual says, section "9.3 Address Translation"
"When TLB logic detects that a new effective page number (EPN) overlaps
one in the TLB (when taking into account page sizes, subpage validity flags,
user/supervisor state, etc. the new EPN is written and the old one is
invalidated."
I'm trying to boot a kernel which does not create kernel pte's
from 0xc000000 till 0xc080000.
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Kumar Gala @ 2005-05-05 15:12 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050505142354.GZ1221@smtp.west.cox.net>
On May 5, 2005, at 9:23 AM, Tom Rini wrote:
> On Thu, May 05, 2005 at 09:00:50AM -0500, Kumar Gala wrote:
> >
> > On May 5, 2005, at 7:24 AM, Dan Malek wrote:
> >
> > >
> > >
> > >On May 5, 2005, at 1:22 AM, Paul Mackerras wrote:
> > > > If you think we should have -mcpu=3Dxxx on the command line for=20=
> 4xx,
> > > > 44x, 8xx, etc., then that's fine, but that is a separate =
problem
> > >from
> > > > what my patch was addressing (one which my patch might make it
> > >easier
> > > > to fix, though).
> > >
> > >I think that is exactly what we want, although I don't know how=20
> that is
> > > separate from the patch you sent.? My original comment was the=20
> patch
> > > fixes the problem for only one of the cpu cores, not all of =
them.?
> > >Which
> > > then led into the subsequent suggestion of making the biarch work
> > > like the past compilers, and we must specific the flags for =
POWER4
> > > instead of the other way around.? Without explicit -mcpu flags,=20=
> the
> > > existing compiler behavior is just fine .....? but, I guess I'd =
be
> > >standing
> > > in the way of progress to want this :-)
> >
> > I agree with Dan here.=A0 I think we should go ahead and extend the=20=
> patch
> > to set -mcpu and -mtune flags for the list of processors we have in
> > "Processor Type".=A0 If I'm building a kernel for e500 or 4xx I =
might=20
> as
> > well get a kernel that is tuned a bit more for the subarch.=A0
>
> This is fine.
>
> > Additionally, there should be some expert override ability, so if I
> > really want to do -mcpu=3D7455 -mtune=3D7455 I can.
>
> Gack, no!=A0 It's quite a pain to go from CONFIG_FOO=3D"string" into=20=
> useable
> Makefile bits that the one we did have back in 2.4 is gone.=A0 That =
also
> implies gcc finally knows something about these cores that might be
> useful, which I don't think is the case, nor is it likely to be.=A0 =
But=20
> if
> we did want it, we'd probably go the route x86 has.
I'm not saying it has to be done via a CONFIG option, all I'm saying is=20=
if I want to explicitly use GCC then I would hope we could somehow=20
disable it being override.
- kumar=
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice
From: Pantelis Antoniou @ 2005-05-05 14:40 UTC (permalink / raw)
To: jmasel; +Cc: linuxppc-embedded
In-Reply-To: <E1DTgrw-0004Lt-00@gold.webfusion.co.uk>
Jonathan Masel wrote:
> Are you interested in looking at our Resource Manager? It works in 2.4 and
> 2.6 kernels for a wide range of PQ's (virtually all of them).
>
> It seems to take some of these ideas, but further. The basic idea is to
> handle at all on-chip resources in an orderly and robust way (not just
> modularly, but that too). We allocate parallel port pins, clocks (BRG or
> CLK), internal DPRAM and communication channels to "consumers". Board
> specific (if/where needed) are all located in a single per-board file.
> Allocation is all dynamic and we can check that we're not conflicting with
> prior requests. There are quite a few other goodies too (display all
> consumers to which certain resources are allocated, etc).
>
> This lets us easily handle dynamic configurations. E.g. configure pins for
> I2C during reset or start-up, modify them later on when you need ATM (they
> are multiplexed on the same pins on several devices). Or, as you mentioned,
> dynamic modules - but even when they have potentially conflicting requests.
>
> And it is one, simple to use mechanism that we use across all devices
> (adapted for PQ1, PQ2 and PQ3).
>
> If you're interested, please let me know. We'd be happy to contribute it if
> it will help.
>
> Jonathan
>
>
Hi Jonathan.
This is a good time for everyone working in freescale platforms to
just put on the table what it uses and see if a common ground can
be found.
So please post the files, and some comments on how they work.
Regards
Pantelis
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2 1/3] FCC Ethernet PlatformDevice support for 82xx
From: Kumar Gala @ 2005-05-05 14:30 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <427A2604.8040808@ru.mvista.com>
Can you send just an updated patch for just the base platform
additions. What I'm looking for is just changes/additions of the
following files:
arch/ppc/syslib/mpc82xx_device.c
arch/ppc/syslib/mpc82xx_sys.c
include/asm-ppc/mpc8260.h
include/asm-ppc/ppc_sys.h
thanks
- kumar
On May 5, 2005, at 8:56 AM, Vitaly Bordug wrote:
> Eugene Surovegin wrote:
> On Wed, May 04, 2005 at 06:35:16PM +0400, Vitaly Bordug wrote:
>
> This patch adds generic PlatformDevice support to the 82xx family.
> Only FCC's exist currently in the structure, as there is the driver
> which will utilize this.
>
>
> [snip]
>
>
> +#ifdef CONFIG_CPM2
> + identify_ppc_sys_by_id(cpm2_immr->im_memctl.memc_immr << 16);
> +
> + /* Set up the MAC addresses for the FECs
> + */
> + fec = ppc_sys_platform_devices[MPC82xx_FCC1].dev.platform_data;
> + memcpy(fec->mac_addr,bi->bi_enetaddr,6);
> +
> + fec = ppc_sys_platform_devices[MPC82xx_FCC2].dev.platform_data;
> +#ifdef CONFIG_ADS8272
> + memcpy(fec->mac_addr,bi->bi_enet1addr,6);
> +#else
> + memcpy(fec->mac_addr,bi->bi_enetaddr,6);
> + fec->macaddr[5] ^= 1;
> +#endif
> +#endif
>
> What is this? Why does common file contain board specific ifdefs????
>
> [snip]
>
>
> +/* FCC1 Clock Source Configuration. There are board specific.
> + Can only choose from CLK9-12 */
> +#if defined(CONFIG_ADS8272)
> +#define F1_RXCLK 11
> +#define F1_TXCLK 10
> +#else
> +#define F1_RXCLK 12
> +#define F1_TXCLK 11
> +#endif
>
> Same thing. Why on earth you continue current 8xxx trend of putting
> board specific crap into common files?
>
>
> +
> +/* 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
>
> Ditto.
>
>
> +#ifdef CONFIG_ADS8272
> +#define PC_MDIO 0x00002000U
> +#define PC_MDCK 0x00001000U
> +#else
> +#define PC_MDIO 0x00000004U
> +#define PC_MDCK 0x00000020U
> +#endif
>
> Ditto.
>
>
> + .name = "phyinterrupt",
> + .start = SIU_INT_IRQ5,
> + .end = SIU_INT_IRQ5,
> + .flags = IORESOURCE_IRQ,
> + },
>
> Why is this here? PHY interrupt routing is _board_ specific.
>
>
> I have fixed these yet, but I think it will be more reasonable to
> update this together with respective driver which I'll work on
> together with Pantelis.
> Thank you for review.
>
>
> --
> Sincerely,
> Vitaly
>
> <ATT400050.txt>
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice
From: Jonathan Masel @ 2005-05-05 14:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.0.1115279646.20825.linuxppc-embedded@ozlabs.org>
Are you interested in looking at our Resource Manager? It works in 2.4 and
2.6 kernels for a wide range of PQ's (virtually all of them).
It seems to take some of these ideas, but further. The basic idea is to
handle at all on-chip resources in an orderly and robust way (not just
modularly, but that too). We allocate parallel port pins, clocks (BRG or
CLK), internal DPRAM and communication channels to "consumers". Board
specific (if/where needed) are all located in a single per-board file.
Allocation is all dynamic and we can check that we're not conflicting with
prior requests. There are quite a few other goodies too (display all
consumers to which certain resources are allocated, etc).
This lets us easily handle dynamic configurations. E.g. configure pins for
I2C during reset or start-up, modify them later on when you need ATM (they
are multiplexed on the same pins on several devices). Or, as you mentioned,
dynamic modules - but even when they have potentially conflicting requests.
And it is one, simple to use mechanism that we use across all devices
(adapted for PQ1, PQ2 and PQ3).
If you're interested, please let me know. We'd be happy to contribute it if
it will help.
Jonathan
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Tom Rini @ 2005-05-05 14:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <49ea49620ccd32ef3032da76db24ad5d@freescale.com>
On Thu, May 05, 2005 at 09:00:50AM -0500, Kumar Gala wrote:
>
> On May 5, 2005, at 7:24 AM, Dan Malek wrote:
>
> >
> >
> >On May 5, 2005, at 1:22 AM, Paul Mackerras wrote:
> > > If you think we should have -mcpu=xxx on the command line for 4xx,
> > > 44x, 8xx, etc., then that's fine, but that is a separate problem
> >from
> > > what my patch was addressing (one which my patch might make it
> >easier
> > > to fix, though).
> >
> >I think that is exactly what we want, although I don't know how that is
> > separate from the patch you sent.? My original comment was the patch
> > fixes the problem for only one of the cpu cores, not all of them.?
> >Which
> > then led into the subsequent suggestion of making the biarch work
> > like the past compilers, and we must specific the flags for POWER4
> > instead of the other way around.? Without explicit -mcpu flags, the
> > existing compiler behavior is just fine .....? but, I guess I'd be
> >standing
> > in the way of progress to want this :-)
>
> I agree with Dan here. I think we should go ahead and extend the patch
> to set -mcpu and -mtune flags for the list of processors we have in
> "Processor Type". If I'm building a kernel for e500 or 4xx I might as
> well get a kernel that is tuned a bit more for the subarch.
This is fine.
> Additionally, there should be some expert override ability, so if I
> really want to do -mcpu=7455 -mtune=7455 I can.
Gack, no! It's quite a pain to go from CONFIG_FOO="string" into useable
Makefile bits that the one we did have back in 2.4 is gone. That also
implies gcc finally knows something about these cores that might be
useful, which I don't think is the case, nor is it likely to be. But if
we did want it, we'd probably go the route x86 has.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: PPC 44x Watchdog timer
From: Kumar Gala @ 2005-05-05 14:02 UTC (permalink / raw)
To: Takeharu KATO; +Cc: Glenn Burkhardt, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <42797FDE.7080909@ybb.ne.jp>
On May 4, 2005, at 9:07 PM, Takeharu KATO wrote:
> Hi
>
> Glenn Burkhardt wrote:
>
> > watchdog exception interrupt isn't used, and it's only configurable
> for
> > PPC405 (although I think that the technique would work for the whole
> 4xx
> > family).
> >
> > Or am I misreading the code?
> >
> No, the kernel which I mentioned before is MontaVistaLinux.
> IIRC, I look the WDT relevant codes in MontaVistaLinux2.X few years
> ago.
> Of course, It was prepared for PowerPC40X...
>
> > It would also be nice if your patch were applied to the 2.6 kernel
> tree.
> >
> Sorry, It's not my jurisdiction.
> Matt(Porter) or Kumar(Gala) may be responsible for this work.
> #Finally, the patch should be approved by akpm and linus, of course...
>
> Matt or Kumar, would you merge BOOKE_WDT patch to 2.6 kernel tree?
> IIRC, This patch has been left under review state about two month.
> Is there something to be needed for the patch?
Sorry, I think Matt and I have been busy with normal "work". I'll take
a look at this in the next week. If you can update the patches to
something current that would help (but is not critical).
thanks
- kumar
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Kumar Gala @ 2005-05-05 14:00 UTC (permalink / raw)
To: Dan Malek; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <7de437cded3ef3b030898889bf65e8c9@embeddededge.com>
On May 5, 2005, at 7:24 AM, Dan Malek wrote:
>
>
> On May 5, 2005, at 1:22 AM, Paul Mackerras wrote:
> > If you think we should have -mcpu=3Dxxx on the command line for =
4xx,
> > 44x, 8xx, etc., then that's fine, but that is a separate problem=20
> from
> > what my patch was addressing (one which my patch might make it=20
> easier
> > to fix, though).
>
> I think that is exactly what we want, although I don't know how that =
is
> separate from the patch you sent.=A0 My original comment was the =
patch
> fixes the problem for only one of the cpu cores, not all of them.=A0=20=
> Which
> then led into the subsequent suggestion of making the biarch work
> like the past compilers, and we must specific the flags for POWER4
> instead of the other way around.=A0 Without explicit -mcpu flags, the
> existing compiler behavior is just fine .....=A0 but, I guess I'd be
> standing
> in the way of progress to want this :-)
I agree with Dan here. I think we should go ahead and extend the patch=20=
to set -mcpu and -mtune flags for the list of processors we have in=20
"Processor Type". If I'm building a kernel for e500 or 4xx I might as=20=
well get a kernel that is tuned a bit more for the subarch. =20
Additionally, there should be some expert override ability, so if I=20
really want to do -mcpu=3D7455 -mtune=3D7455 I can.
- kumar
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2 1/3] FCC Ethernet PlatformDevice support for 82xx
From: Vitaly Bordug @ 2005-05-05 13:56 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded list
In-Reply-To: <20050504164624.GB11439@gate.ebshome.net>
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]
Eugene Surovegin wrote:
>On Wed, May 04, 2005 at 06:35:16PM +0400, Vitaly Bordug wrote:
>
>
>>This patch adds generic PlatformDevice support to the 82xx family.
>>Only FCC's exist currently in the structure, as there is the driver
>>which will utilize this.
>>
>>
>>
>
>[snip]
>
>
>
>>+#ifdef CONFIG_CPM2
>>+ identify_ppc_sys_by_id(cpm2_immr->im_memctl.memc_immr << 16);
>>+
>>+ /* Set up the MAC addresses for the FECs
>>+ */
>>+ fec = ppc_sys_platform_devices[MPC82xx_FCC1].dev.platform_data;
>>+ memcpy(fec->mac_addr,bi->bi_enetaddr,6);
>>+
>>+ fec = ppc_sys_platform_devices[MPC82xx_FCC2].dev.platform_data;
>>+#ifdef CONFIG_ADS8272
>>+ memcpy(fec->mac_addr,bi->bi_enet1addr,6);
>>+#else
>>+ memcpy(fec->mac_addr,bi->bi_enetaddr,6);
>>+ fec->macaddr[5] ^= 1;
>>+#endif
>>+#endif
>>
>>
>
>What is this? Why does common file contain board specific ifdefs????
>
>[snip]
>
>
>
>>+/* FCC1 Clock Source Configuration. There are board specific.
>>+ Can only choose from CLK9-12 */
>>+#if defined(CONFIG_ADS8272)
>>+#define F1_RXCLK 11
>>+#define F1_TXCLK 10
>>+#else
>>+#define F1_RXCLK 12
>>+#define F1_TXCLK 11
>>+#endif
>>
>>
>
>Same thing. Why on earth you continue current 8xxx trend of putting
>board specific crap into common files?
>
>
>
>>+
>>+/* 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
>>
>>
>
>Ditto.
>
>
>
>>+#ifdef CONFIG_ADS8272
>>+#define PC_MDIO 0x00002000U
>>+#define PC_MDCK 0x00001000U
>>+#else
>>+#define PC_MDIO 0x00000004U
>>+#define PC_MDCK 0x00000020U
>>+#endif
>>
>>
>
>Ditto.
>
>
>
>>+ .name = "phyinterrupt",
>>+ .start = SIU_INT_IRQ5,
>>+ .end = SIU_INT_IRQ5,
>>+ .flags = IORESOURCE_IRQ,
>>+ },
>>
>>
>
>Why is this here? PHY interrupt routing is _board_ specific.
>
>
>
I have fixed these yet, but I think it will be more reasonable to update
this together with respective driver which I'll work on together with
Pantelis.
Thank you for review.
--
Sincerely,
Vitaly
[-- Attachment #2: Type: text/html, Size: 2974 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice support for 82xx
From: Pantelis Antoniou @ 2005-05-05 13:27 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded list
In-Reply-To: <fb6d7d007dc9f75553f1390b86c5f72b@embeddededge.com>
Dan Malek wrote:
>
> On May 5, 2005, at 8:36 AM, Pantelis Antoniou wrote:
>
>> In my experience it's much easier to configure these things once.
>> Hunting down where the driver modifies pins & clocks is a nightmare, if
>> you ever use a non standard configuration.
>
>
> That doesn't quite work, as we have discussed before. The problem with
> setting them in the board set up is you can have loadable modules and
> select among several different IO pin configurations depending upon
> what you load. So, the plan is to have the drivers make a generic
> call out request using feature_call() to the supporting functions in the
> board specific directory. This is for more than just IO pin
> configurations,
> since boards may have power management or other external logic that
> has to be routed to the physical interface. For example, the SCC Ethernet
> driver will perform a feature_call() during set up requesting any necessary
> configuration for SCC2. The board specific function can chose to ignore
> this and get the "default" configuration, or to do whatever is necessary
> unique to the board to enable the external data path. All that drivers
> know
> is there are a couple of specific places where they need configuration
> assistance, they don't care what the specific board has to do.
>
Sounds nice. I'm a much simpler guy it seems :)
> It's in the works and nearly done for a few example 85xx and 82xx
> boards and CPM2 drivers. I'll be checking it in shortly. I just haven't
> decided if I want a varargs list or a data structure for passing the
> information and results.
>
Mind sharing?
> Thanks.
>
> -- Dan
>
>
>
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH] 2.6.11.7 MPC8xx Swap Band-Aid
From: Dan Malek @ 2005-05-05 13:31 UTC (permalink / raw)
To: Jason McMullan; +Cc: PPC_LINUX
In-Reply-To: <1115297124.9050.12.camel@jmcmullan.timesys>
On May 5, 2005, at 8:45 AM, Jason McMullan wrote:
> First off, this patch works.
Well ..... if you invalidate TLBs and flush cache often enough,
you can mask lots of problems :-)
> Secondly, I don't know exactly why. I just found all the band-aids I
> could for MPC8xx swap functionality, applied them, and fixed the places
> where it still bled.
We shouldn't have the 8xx as a special case for the swap flags and
information. We need to take a closer look at this. I guess I'll do
that
as part of fixing up the PTEs for the BDI2000 as well.
> It's more of a dancing bear, than a real fix, but I now have working
> swap (using ATA over Ethernet) on my MPC885 ADS.
IIRC, ATA over Ethernet isn't the same as disk doing DMA due to the
data copies involved.
Thanks.
-- Dan
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice support for 82xx
From: Dan Malek @ 2005-05-05 13:19 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded list
In-Reply-To: <427A1361.6060005@intracom.gr>
On May 5, 2005, at 8:36 AM, Pantelis Antoniou wrote:
> In my experience it's much easier to configure these things once.
> Hunting down where the driver modifies pins & clocks is a nightmare, if
> you ever use a non standard configuration.
That doesn't quite work, as we have discussed before. The problem with
setting them in the board set up is you can have loadable modules and
select among several different IO pin configurations depending upon
what you load. So, the plan is to have the drivers make a generic
call out request using feature_call() to the supporting functions in the
board specific directory. This is for more than just IO pin
configurations,
since boards may have power management or other external logic that
has to be routed to the physical interface. For example, the SCC
Ethernet
driver will perform a feature_call() during set up requesting any
necessary
configuration for SCC2. The board specific function can chose to ignore
this and get the "default" configuration, or to do whatever is necessary
unique to the board to enable the external data path. All that drivers
know
is there are a couple of specific places where they need configuration
assistance, they don't care what the specific board has to do.
It's in the works and nearly done for a few example 85xx and 82xx
boards and CPM2 drivers. I'll be checking it in shortly. I just
haven't
decided if I want a varargs list or a data structure for passing the
information and results.
Thanks.
-- Dan
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice support for 82xx
From: Pantelis Antoniou @ 2005-05-05 12:36 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <427A1423.3040509@ru.mvista.com>
Vitaly Bordug wrote:
>
>> Hi Vitaly
>>
>> Since I'm also working on this, lets try to merge our work in
>> one driver.
>>
>> A few points regarding my driver.
>>
>> 1) It currently supports both 8xx FEC, 82xx FCCs.
>> 2) It will also support SCC ENETS on both 8xx & 82xx, and
>> FECs on coldfire's & 52xx's.
>> 3) We should treat the current MII logic as temporary since
>> Andy Flemming has a replacement by a MII bus.
>>
>> Regarding your driver, there are a couple of things it
>> does arguably better than mine.
>>
>> 1) It has more complete platformization.
>> 2) Adjustuble ring sizes.
>>
>> And here are some gripes.
>>
>> 1) I'm not a proponent of having drivers configuring pins,
>> clocks & other things that are properties of each specific board.
>> I'd rather have the bootloader or the platform initialization
>> handle it once, and have the driver just use these settings.
>> Opinions on this matter differ however :).
>> 2) There are a number of platform defines that are not needed.
>>
>> Well, what do you think?
>>
> The idea itself sounds very good.
> So, let's, as a starting point, implement mentioned things
> (platformization and dynamic rings) within your driver (if you don't
> mind of course).
Please go ahead.
> More specifically, I am going to add necessary platform stuff for 82xx
> and 8xx since we have only 8272ads and 885ads to test this on.
>
> Firmware-only board-specific stuff configuration is a good thing, but
> IMHO it's impossible to provide a universal bootloader configuration
> that will meet all possible requirements, and a person should recompile
> or even modify the firmware in such cases. That is why I included clocks
> and etc stuff to the platform_data structure, so that in board-specific
> headers this values could be redefined if necessary. However I'm not
> sure about PIN setup, should it also reside in the platform_data struct,
> or in the driver (as it is in my patch).
Granted, to do that in the bootloader is very hard.
However we can definately do that in the board setup file, like
arch/ppc/platforms/pq2ads_setup.c
In my experience it's much easier to configure these things once.
Hunting down where the driver modifies pins & clocks is a nightmare, if
you ever use a non standard configuration.
The driver however can probe for it's configuration and display it so
that we can tell what is going on.
>
> Another thing we should change in existing code is direct cpm2_immr
> usage - the driver should be as isolated from this as possible. Dan
> mentioned that the stuff that will offer IOport and likewise access
> right way is almost completed so I'm looking forward some details about
> it from him.
>
Yes, that's another thing that must be done; please go ahead.
Regards
Pantelis
^ permalink raw reply
* [PATCH] 2.6.11.7 MPC8xx Swap Band-Aid
From: Jason McMullan @ 2005-05-05 12:45 UTC (permalink / raw)
To: PPC_LINUX
[-- Attachment #1.1: Type: text/plain, Size: 406 bytes --]
First off, this patch works.
Secondly, I don't know exactly why. I just found all the band-aids I
could for MPC8xx swap functionality, applied them, and fixed the places
where it still bled.
It's more of a dancing bear, than a real fix, but I now have working
swap (using ATA over Ethernet) on my MPC885 ADS.
Enjoy!
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #1.2: cpu-ppc-mpc8xx-swap.patch --]
[-- Type: text/x-patch, Size: 3623 bytes --]
Date: Thu, 05 May 2005 08:31:24 -0400
Summary: MPC8xx swap support
Relative-to: linux-2.6.11.7
Description: MPC8xx swap support, band-aided together from patches by:
Satoshi Adachi <adachi@aa.ap.titech.ac.jp>
Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Jason McMullan <jason.mcmullan@timesys.com>
Signed-Off-By: Jason McMullan <jason.mcmullan@timesys.com>
--- linux-orig/arch/ppc/kernel/head_8xx.S
+++ linux/arch/ppc/kernel/head_8xx.S
@@ -359,9 +359,7 @@
. = 0x1200
DataStoreTLBMiss:
-#ifdef CONFIG_8xx_CPU6
stw r3, 8(r0)
-#endif
DO_8xx_CPU6(0x3f80, r3)
mtspr M_TW, r10 /* Save a couple of working registers */
mfcr r10
@@ -390,6 +388,16 @@
mfspr r10, MD_TWC /* ....and get the pte address */
lwz r10, 0(r10) /* Get the pte */
+ li r3, 0
+ cmpw r10, r3 /* does the pte contain a valid address? */
+ bne 4f
+ mfspr r10, M_TW /* Restore registers */
+ lwz r11, 0(r0)
+ mtcr r11
+ lwz r11, 4(r0)
+ lwz r3, 8(r0)
+ b DataAccess
+4:
/* Insert the Guarded flag into the TWC from the Linux PTE.
* It is bit 27 of both the Linux PTE and the TWC (at least
* I got that right :-). It will be better when we can put
@@ -419,9 +427,7 @@
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
-#endif
rfi
/* This is an instruction TLB error on the MPC8xx. This could be due
--- linux-orig/arch/ppc/mm/init.c
+++ linux/arch/ppc/mm/init.c
@@ -585,7 +585,7 @@
void flush_dcache_icache_page(struct page *page)
{
-#ifdef CONFIG_BOOKE
+#if defined(CONFIG_BOOKE) || defined(CONFIG_8xx)
__flush_dcache_icache(kmap(page));
kunmap(page);
#else
@@ -632,9 +632,15 @@
struct page *page = pfn_to_page(pfn);
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
- if (vma->vm_mm == current->active_mm)
+ if (vma->vm_mm == current->active_mm) {
+#ifdef CONFIG_8xx /* Evil masking of larger problems.
+ * We shouldn't have to do this if
+ * we have properly invalidated!
+ */
+ flush_tlb_page(vma,address);
+#endif
__flush_dcache_icache((void *) address);
- else
+ } else
flush_dcache_icache_page(page);
set_bit(PG_arch_1, &page->flags);
}
--- linux-orig/include/asm-ppc/pgtable.h
+++ linux/include/asm-ppc/pgtable.h
@@ -678,7 +678,11 @@
#define __swp_type(entry) ((entry).val & 0x1f)
#define __swp_offset(entry) ((entry).val >> 5)
#define __swp_entry(type, offset) ((swp_entry_t) { (type) | ((offset) << 5) })
+#ifdef CONFIG_8xx
+#define __pte_to_swp_entry(pte) ((swp_entry_t) { (pte_val(pte) & ~_PAGE_ACCESSED) >> 3 })
+#else
#define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) >> 3 })
+#endif
#define __swp_entry_to_pte(x) ((pte_t) { (x).val << 3 })
/* Encode and decode a nonlinear file mapping entry */
--- linux-orig/include/asm-ppc/tlbflush.h
+++ linux/include/asm-ppc/tlbflush.h
@@ -72,7 +72,7 @@
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{ _tlbie(vmaddr); }
-static inline void flush_tlb_range(struct mm_struct *mm,
+static inline void flush_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{ __tlbia(); }
static inline void flush_tlb_kernel_range(unsigned long start,
--- linux-orig/mm/swapfile.c
+++ linux/mm/swapfile.c
@@ -80,7 +80,7 @@
WARN_ON(page_count(page) <= 1);
bdi = bdev->bd_inode->i_mapping->backing_dev_info;
- bdi->unplug_io_fn(bdi, page);
+ blk_run_backing_dev(bdi, page);
}
up_read(&swap_unplug_sem);
}
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice support for 82xx
From: Vitaly Bordug @ 2005-05-05 12:40 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded list
In-Reply-To: <427A01B7.9090200@intracom.gr>
> Hi Vitaly
>
> Since I'm also working on this, lets try to merge our work in
> one driver.
>
> A few points regarding my driver.
>
> 1) It currently supports both 8xx FEC, 82xx FCCs.
> 2) It will also support SCC ENETS on both 8xx & 82xx, and
> FECs on coldfire's & 52xx's.
> 3) We should treat the current MII logic as temporary since
> Andy Flemming has a replacement by a MII bus.
>
> Regarding your driver, there are a couple of things it
> does arguably better than mine.
>
> 1) It has more complete platformization.
> 2) Adjustuble ring sizes.
>
> And here are some gripes.
>
> 1) I'm not a proponent of having drivers configuring pins,
> clocks & other things that are properties of each specific board.
> I'd rather have the bootloader or the platform initialization
> handle it once, and have the driver just use these settings.
> Opinions on this matter differ however :).
> 2) There are a number of platform defines that are not needed.
>
> Well, what do you think?
>
The idea itself sounds very good.
So, let's, as a starting point, implement mentioned things
(platformization and dynamic rings) within your driver (if you don't
mind of course).
More specifically, I am going to add necessary platform stuff for 82xx
and 8xx since we have only 8272ads and 885ads to test this on.
Firmware-only board-specific stuff configuration is a good thing, but
IMHO it's impossible to provide a universal bootloader configuration
that will meet all possible requirements, and a person should recompile
or even modify the firmware in such cases. That is why I included clocks
and etc stuff to the platform_data structure, so that in board-specific
headers this values could be redefined if necessary. However I'm not
sure about PIN setup, should it also reside in the platform_data struct,
or in the driver (as it is in my patch).
Another thing we should change in existing code is direct cpm2_immr
usage - the driver should be as isolated from this as possible. Dan
mentioned that the stuff that will offer IOport and likewise access
right way is almost completed so I'm looking forward some details about
it from him.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Dan Malek @ 2005-05-05 12:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <17017.44421.790813.918463@cargo.ozlabs.ibm.com>
On May 5, 2005, at 1:22 AM, Paul Mackerras wrote:
> If you think we should have -mcpu=xxx on the command line for 4xx,
> 44x, 8xx, etc., then that's fine, but that is a separate problem from
> what my patch was addressing (one which my patch might make it easier
> to fix, though).
I think that is exactly what we want, although I don't know how that is
separate from the patch you sent. My original comment was the patch
fixes the problem for only one of the cpu cores, not all of them. Which
then led into the subsequent suggestion of making the biarch work
like the past compilers, and we must specific the flags for POWER4
instead of the other way around. Without explicit -mcpu flags, the
existing compiler behavior is just fine ..... but, I guess I'd be
standing
in the way of progress to want this :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Dan Malek @ 2005-05-05 12:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <17017.42136.824607.253146@cargo.ozlabs.ibm.com>
On May 5, 2005, at 12:44 AM, Paul Mackerras wrote:
> The problem only comes up if you configure gcc4 as biarch. I can't
> imagine anyone building a biarch compiler for 4xx or 8xx. :)
Why not? I've never built a "special" compiler for any development
work, and am very likely to use the default compiler installed on
my YDL system (which could likely be a G5) for building any
embedded PowerPC software.
> So yes, only CONFIG_6xx is affected by biarch gcc4 assuming POWER4.
> Other families would only be affected if you were using a generic
> gcc4, which won't work at present anyway, since we don't add
> -mcpu=xxx.
What do you mean by "won't work"? The compiler simply refuses
or builds for a POWER4 because we don't have the proper -mcpu
flags?
Thanks.
-- Dan
^ permalink raw reply
* Re: [RFC][PATCH 2.6.12-rc2 3/3] FCC Ethernet PlatformDevice support for 82xx
From: Pantelis Antoniou @ 2005-05-05 11:21 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <4278DDBF.8080705@ru.mvista.com>
Vitaly Bordug wrote:
> This patch contains actual Ethernet driver on platform bus. Currently
> tested on MPC8272ADS (PQII) board.
>
[snip]
>
Hi Vitaly
Since I'm also working on this, lets try to merge our work in
one driver.
A few points regarding my driver.
1) It currently supports both 8xx FEC, 82xx FCCs.
2) It will also support SCC ENETS on both 8xx & 82xx, and
FECs on coldfire's & 52xx's.
3) We should treat the current MII logic as temporary since
Andy Flemming has a replacement by a MII bus.
Regarding your driver, there are a couple of things it
does arguably better than mine.
1) It has more complete platformization.
2) Adjustuble ring sizes.
And here are some gripes.
1) I'm not a proponent of having drivers configuring pins,
clocks & other things that are properties of each specific board.
I'd rather have the bootloader or the platform initialization
handle it once, and have the driver just use these settings.
Opinions on this matter differ however :).
2) There are a number of platform defines that are not needed.
Well, what do you think?
Regards
Pantelis
^ permalink raw reply
* ATM driver for 8260 (linux 2.4.x) working!
From: Theo Gjaltema @ 2005-05-05 9:19 UTC (permalink / raw)
To: linuxppc-embedded
We once did a port of a ATM driver on the 8260 for a linux 2.2.20 kernel.
For this, we patched a pre-release of the driver build by ?
If interested, I could send you our results.
Greetings,
Theo.
^ permalink raw reply
* Network Setup - HOW TO
From: Atit_Shah @ 2005-05-05 6:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have a custom board designed to function as a router. It has 2
Ethernet ports. Eth1 is a WAN port and Eth0 is a LAN port. This is what
I wish to do:
1. connect the board/router to my company network=20
2. connect a normal system running windows or linux to the router
3. I should be able to ping or browse the net using the normal system
via the router through the company network.
I have connect the normal network cable (not a cross wire cable) between
the router and the company network. The router does not seem to get a
dynamic IP. Why and What should I do for it to get one?
I assigned a static IP to eth1 and pinged another system on the company
network and I do get a reply back. So my eth1 is working fine, but I
would still prefer a dynamic IP.
I connect a system to eth0 again with a normal network cable (not a
cross wire cable) but the system does not seem to get an IP assigned
even when I run the dhcp server on my router....used udhcpd command. Why
and how can I get it up?
Appreciate a response on this....
Has any one come across a tutorial which could help me solve this
Regards
Atit
DISCLAIMER:
This email (including any attachments) is intended for the sole use of =
the intended recipient/s and may contain material that is CONFIDENTIAL =
AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or =
copying or distribution or forwarding of any or all of the contents in =
this message is STRICTLY PROHIBITED. If you are not the intended =
recipient, please contact the sender by email and delete all copies; =
your cooperation in this regard is appreciated.
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Paul Mackerras @ 2005-05-05 5:22 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050505044737.GY1221@smtp.west.cox.net>
Tom Rini writes:
> Why won't it work with generic gcc4 ? Will something more than a lot of
> extra nops be added?
Well, say you are compiling for 405. You either need to have a gcc
that was configured with --with-cpu=405, or you need to have hacked
arch/ppc/Makefile to add -mcpu=405. In both cases the problem doesn't
arise. It only arises if you have a biarch gcc4 that was configured
without any --with-cpu=xxx option and is run without any -mcpu=xxx
option.
If you think we should have -mcpu=xxx on the command line for 4xx,
44x, 8xx, etc., then that's fine, but that is a separate problem from
what my patch was addressing (one which my patch might make it easier
to fix, though).
Paul.
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Tom Rini @ 2005-05-05 4:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17017.42136.824607.253146@cargo.ozlabs.ibm.com>
On Thu, May 05, 2005 at 02:44:08PM +1000, Paul Mackerras wrote:
> Tom Rini writes:
>
> > So here's where the confusion comes in. You're saying that even though
> > (except .S files) no ppc32 kernel config was passing in explicit
> > -mcpu=... or similar, only CONFIG_6xx is hurt by the gcc4 biarch thingy?
>
> Indeed, we were never using -mcpu, and maybe we should be.
>
> The problem only comes up if you configure gcc4 as biarch. I can't
> imagine anyone building a biarch compiler for 4xx or 8xx. :)
I can, quite easily. Think someone like Dan doing dev from their nice
shiney G5.
> Alan Modra tells me that gcc4 can support all the ppc families in the
> one binary, and that you can specify what cpu to use as the assumed
> default at configure time. If you specify --with-cpu=xxx at configure
> time you get scheduling for that particular cpu.
>
> So yes, only CONFIG_6xx is affected by biarch gcc4 assuming POWER4.
> Other families would only be affected if you were using a generic
> gcc4, which won't work at present anyway, since we don't add
> -mcpu=xxx.
Why won't it work with generic gcc4 ? Will something more than a lot of
extra nops be added?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Paul Mackerras @ 2005-05-05 4:44 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050505041225.GX1221@smtp.west.cox.net>
Tom Rini writes:
> So here's where the confusion comes in. You're saying that even though
> (except .S files) no ppc32 kernel config was passing in explicit
> -mcpu=... or similar, only CONFIG_6xx is hurt by the gcc4 biarch thingy?
Indeed, we were never using -mcpu, and maybe we should be.
The problem only comes up if you configure gcc4 as biarch. I can't
imagine anyone building a biarch compiler for 4xx or 8xx. :)
Alan Modra tells me that gcc4 can support all the ppc families in the
one binary, and that you can specify what cpu to use as the assumed
default at configure time. If you specify --with-cpu=xxx at configure
time you get scheduling for that particular cpu.
So yes, only CONFIG_6xx is affected by biarch gcc4 assuming POWER4.
Other families would only be affected if you were using a generic
gcc4, which won't work at present anyway, since we don't add
-mcpu=xxx.
Paul.
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Tom Rini @ 2005-05-05 4:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17017.39523.745634.193331@cargo.ozlabs.ibm.com>
On Thu, May 05, 2005 at 02:00:35PM +1000, Paul Mackerras wrote:
> Dan Malek writes:
>
> > The only reason I mentioned it is the "new" default behavior of the
> > compiler is appropriate for only a very small subset of the cores,
>
> Subset of which set of cores? Do you mean "small subset of 6xx cores"
> or "small subset of PPC cores"? I didn't change anything for non-6xx
> cores except to take out -mstring (if you really want that back, say
> so :). If you mean "small subset of 6xx cores" then are you objecting
> to the specific choice of "-mcpu=603 -mtune=7450", or what?
>
> > My concern wasn't specifically for which options I wanted, but
> > rather for the mechanism to set all of them now that it appears
> > we need to do that.
>
> We don't *need* to do it any more than we did before. It's easy to
> set options for 4xx, 8xx, etc. - just say the word.
>
> > OK, but we still need some kind of indication from the configuration
> > process. It seems to me it would be easier (and more logical) to
> > have the default behavior work like it has in the past, and use the
> > special options for the POWER4, which we already know in
> > the configuration.
>
> The problem isn't for POWER4, the problem is biarch gcc4 optimizing
> for POWER4 when we are compiling for 6xx.
So here's where the confusion comes in. You're saying that even though
(except .S files) no ppc32 kernel config was passing in explicit
-mcpu=... or similar, only CONFIG_6xx is hurt by the gcc4 biarch thingy?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Paul Mackerras @ 2005-05-05 4:00 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, trini
In-Reply-To: <45e21c1ae2899849665fb894a2adcc20@embeddededge.com>
Dan Malek writes:
> The only reason I mentioned it is the "new" default behavior of the
> compiler is appropriate for only a very small subset of the cores,
Subset of which set of cores? Do you mean "small subset of 6xx cores"
or "small subset of PPC cores"? I didn't change anything for non-6xx
cores except to take out -mstring (if you really want that back, say
so :). If you mean "small subset of 6xx cores" then are you objecting
to the specific choice of "-mcpu=603 -mtune=7450", or what?
> My concern wasn't specifically for which options I wanted, but
> rather for the mechanism to set all of them now that it appears
> we need to do that.
We don't *need* to do it any more than we did before. It's easy to
set options for 4xx, 8xx, etc. - just say the word.
> OK, but we still need some kind of indication from the configuration
> process. It seems to me it would be easier (and more logical) to
> have the default behavior work like it has in the past, and use the
> special options for the POWER4, which we already know in
> the configuration.
The problem isn't for POWER4, the problem is biarch gcc4 optimizing
for POWER4 when we are compiling for 6xx.
Paul.
^ 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