* [PATCH] ppc annotations: i2c-mpc
From: Al Viro @ 2005-04-26 1:10 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Usual iomem annotations and NULL noise removal.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
----
diff -urN RC12-rc3-mpsc/drivers/i2c/busses/i2c-mpc.c RC12-rc3-i2c-mpc/drivers/i2c/busses/i2c-mpc.c
--- RC12-rc3-mpsc/drivers/i2c/busses/i2c-mpc.c Wed Apr 20 21:25:33 2005
+++ RC12-rc3-i2c-mpc/drivers/i2c/busses/i2c-mpc.c Mon Apr 25 19:53:08 2005
@@ -55,7 +55,7 @@
#define CSR_RXAK 0x01
struct mpc_i2c {
- char *base;
+ void __iomem *base;
u32 interrupt;
wait_queue_head_t queue;
struct i2c_adapter adap;
@@ -444,7 +444,7 @@
fail_add:
if (i2c->irq != 0)
- free_irq(i2c->irq, 0);
+ free_irq(i2c->irq, NULL);
fail_irq:
iounmap(i2c->base);
fail_map:
^ permalink raw reply
* Re: [PATCH] ppc32: Fix a sleep issues on some laptops
From: Eddy Petrisor @ 2005-04-26 0:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <426C17D3.7000807@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=x-user-defined; format=flowed, Size: 688 bytes --]
I had soem mail problems and this mail was not sent
Eddy Petrisor wrote:
> Benjamin Herrenschmidt wrote:
>
>> Hi !
>>
>> Some earlier models of aluminium powerbooks and ibook G4s have a clock
>> chip that requires some tweaking before and after sleep. It seems that
>> without that magic incantation to disable and re-enable clock spreading,
>> RAM isn't properly refreshed during sleep. This fixes it.
>
> over which version of kernel does this apply, or where can we find it,
> already included? I had some problems with sleeping (well, not me, my
> powerbook :o)
>
--
Regards,
EddyP
===========================
I had a favourite quote, but I forgot it. And it was insightful.
^ permalink raw reply
* Re: [PATCH] ppc32: Fix a sleep issues on some laptops
From: Benjamin Herrenschmidt @ 2005-04-26 0:42 UTC (permalink / raw)
To: Eddy Petrisor
Cc: Andrew Morton, linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <426D8A32.8090005@gmail.com>
On Tue, 2005-04-26 at 03:24 +0300, Eddy Petrisor wrote:
> I had soem mail problems and this mail was not sent
>
> Eddy Petrisor wrote:
> > Benjamin Herrenschmidt wrote:
> >
> >> Hi !
> >>
> >> Some earlier models of aluminium powerbooks and ibook G4s have a clock
> >> chip that requires some tweaking before and after sleep. It seems that
> >> without that magic incantation to disable and re-enable clock spreading,
> >> RAM isn't properly refreshed during sleep. This fixes it.
> >
> > over which version of kernel does this apply, or where can we find it,
> > already included? I had some problems with sleeping (well, not me, my
> > powerbook :o)
It should apply on 2.6.12-rc* and maybe 2.6.11
Ben.
^ permalink raw reply
* 2.6.10 unable to mount a root fs on ramdisk
From: Shawn Jin @ 2005-04-25 22:17 UTC (permalink / raw)
To: ppcembed
Hi,
Tried to mount a root fs on ramdisk on an ebony board but the
following error shows up.
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1=
,0)
There may be a simple answer for this common error. But I haven't
found out it after googling for a while. I remember I had a similar
problem when trying to mount a jffs2 as the root fs. The solution is
to add rootfstype=3Djffs2. I downloaded the ramdisk image from DENX's
ftp site. So I'm sure the image itself has no problem.
I already enabled RAMDISK and initrd support in kernel configuration.
=3D> run ramroot
## Booting image at 00400000 ...
Image Name: Linux-2.6.10
Created: 2005-02-23 18:40:02 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 887207 Bytes =3D 866.4 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x07FA9CC0 =3D> set upper limit to 0x00800000
## cmdline at 0x007FFC00 ... 0x007FFC10
bd address =3D 0x07FAAF90
memstart =3D 0x00000000
memsize =3D 0x08000000
flashstart =3D 0xFF800000
flashsize =3D 0x00480000
flashoffset =3D 0x00000000
sramstart =3D 0x00000000
sramsize =3D 0x00000000
bootflags =3D 0x00000005
intfreq =3D 400 MHz
busfreq =3D 133.333 MHz
baudrate =3D 9600 bps
## Loading RAMDisk Image at 00600000 ...
Image Name: Simple Embedded Linux Framework
Created: 2002-10-24 9:30:38 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1476478 Bytes =3D 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## initrd at 0x00600040 ... 0x007687BD (len=3D1476478=3D0x16877E)
Loading Ramdisk to 07e41000, end 07fa977e ... OK
## Transferring control to Linux (at address 00000000) ...
Linux version 2.6.10 (gcc version 3.3.3 (DENX ELDK 3.1 3.3.3-8)) #1 We
d Feb 23 10:34:11 PST 2005
IBM Ebony port (MontaVista Software, Inc. (source@mvista.com))
<SNIPPED>
NET: Registered protocol family 1
NET: Registered protocol family 17
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1=
,0)
Thanks,
-Shawn.
^ permalink raw reply
* RE: New MPC5200 Eratta/ATA Bugs
From: Stephen Warren @ 2005-04-25 22:13 UTC (permalink / raw)
To: Eric N. Johnson (ACD), linuxppc-embedded
From: Eric N. Johnson (ACD) [mailto:ejohnson@acdstar.com]=20
> At 02:35 PM 4/25/2005, Stephen Warren wrote:
> >Freescale have been working with us on a board work-around for the
> >problem. This basically involves deriving a substitute ATA_ISOLATION
> >signal from the regular ATA control signals, in some cases.
>=20
> Are you able to share the circuit they've recommended? Is it as
simple as:
> ISOLATION =3D ((ATA_CS1 or ATA_IOR) and (ATA_CS0 or ATA_IOR))
>=20
> This seems like it would be in violation of the setup and hold time=20
> requirements for the data bus.
This was suggested:
>>> 2. ... beleives that to fix the ATA_ISOLATION with logic would be
>>> something like this:
>>> ATA_ISOLATION_TO_BUFFERS =3D MPC's_ATA_ISOLATION or (GPIO_UDMA and
ATA_DMA_ACK#)=20
The idea is that the errata only causes a problem for UDMA (not MDMA or
PIO). So, the kernel is modified to set a GPIO whenever UDMA is in
progress. This triggers the external logic to use ATA_DMA_ACK# to
trigger the bus drivers. ATA_DMA_ACK# is the signal that means an actual
DMA data transfer is in progress.
That said, various people are in the process of trying the above logic,
and the more explicit:
ATA_ISOLATION_TO_BUFFERS =3D \
(~GPIO_UDMA and MPC's_ATA_ISOLATION) | \
(GPIO_UDMA and ATA_DMA_ACK#)
(possibly with the extra ~'s in there to fix high v.s. low true...)
And neither of these approaches actually works for us.
If I recall correctly, one of the other errata means MDMA can't work
either...
> I've been told there's a new silicon revision of the MPC5200 due
sometime=20
> later in the year, but the date keeps getting pushed back.
We were told this too. Sounds like maybe sometime in the middle of the
year at the earliest.
--=20
Stephen Warren, Software Engineer, NVIDIA, Fort Collins, CO
swarren@nvidia.com http://www.nvidia.com/
swarren@wwwdotorg.org http://www.wwwdotorg.org/pgp.html
^ permalink raw reply
* RE: New MPC5200 Eratta/ATA Bugs
From: Eric N. Johnson (ACD) @ 2005-04-25 22:00 UTC (permalink / raw)
To: Stephen Warren, linuxppc-embedded
In-Reply-To: <DBFABB80F7FD3143A911F9E6CFD477B00688411F@hqemmail02.nvidia .com>
At 02:35 PM 4/25/2005, Stephen Warren wrote:
>Freescale have been working with us on a board work-around for the
>problem. This basically involves deriving a substitute ATA_ISOLATION
>signal from the regular ATA control signals, in some cases.
Are you able to share the circuit they've recommended? Is it as simple as:
ISOLATION = ((ATA_CS1 or ATA_IOR) and (ATA_CS0 or ATA_IOR))
This seems like it would be in violation of the setup and hold time
requirements for the data bus.
I've been told there's a new silicon revision of the MPC5200 due sometime
later in the year, but the date keeps getting pushed back.
Eric
------------------------------------
Eric Johnson, Electrical Engineer
Advanced Communication Design
7901 12th Avenue South
Bloomington, MN 55425
Ph: 952-854-4000 Fax: 952-854-5774
^ permalink raw reply
* PowerPC + SMP
From: Stuart Yoder @ 2005-04-25 21:11 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 421 bytes --]
Hi.
I am trying to figure out where in the PowerPC kernel the HID1 register
is updated to enable bits dealing with cache coherency in an SMP system.
Grepping through the arch/ppc source does not reveal much.
I have two 7447A processors and somewhere the ABE and SYNCBE bits need
to be turned on to enable cache coherency. Is supposed to happen in
the bootloader prior to the kernel running??
Thanks,
Stuart Yoder
[-- Attachment #2: Type: text/html, Size: 1439 bytes --]
^ permalink raw reply
* Re: PowerPC + SMP
From: Kumar Gala @ 2005-04-25 21:39 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-embedded
In-Reply-To: <052201c549db$37e8b430$2f010a0a@foundation.com>
On Apr 25, 2005, at 4:10 PM, Stuart Yoder wrote:
> Hi.
> =A0
> I am trying to figure out where in the PowerPC kernel the HID1=20
> register is updated to enable bits dealing with cache coherency in an=20=
> SMP system.=A0=A0 Grepping through the arch/ppc source does not reveal=20=
> much.
> =A0
> I have=A0two 7447A processors and somewhere the ABE and SYNCBE bits in=20=
> HID1=A0need to be turned on to enable cache coherency.=A0=A0 Is =
supposed to=20
> happen in the bootloader prior to the kernel running??
The expectation is that the bootloader normally handles such things.
- kumar
^ permalink raw reply
* PowerPC + SMP
From: Stuart Yoder @ 2005-04-25 21:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
Hi.
I am trying to figure out where in the PowerPC kernel the HID1 register
is updated to enable bits dealing with cache coherency in an SMP system.
Grepping through the arch/ppc source does not reveal much.
I have two 7447A processors and somewhere the ABE and SYNCBE bits in
HID1 need to be turned on to enable cache coherency. Is supposed to
happen in the bootloader prior to the kernel running??
Thanks,
Stuart Yoder
[-- Attachment #2: Type: text/html, Size: 1408 bytes --]
^ permalink raw reply
* Re: [RFC] attempt to remove misc-embedded.c
From: Tom Rini @ 2005-04-25 20:26 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050425145916.GA25998@logos.cnet>
On Mon, Apr 25, 2005 at 11:59:17AM -0300, Marcelo Tosatti wrote:
> On Mon, Apr 25, 2005 at 12:55:20PM -0700, Eugene Surovegin wrote:
> > On Mon, Apr 25, 2005 at 11:36:19AM -0300, Marcelo Tosatti wrote:
> > > So the plan is to move all cpu specific code in decompress_kernel() to cpu specific code :)
> > >
> > > Including
> > >
> > > #ifdef CONFIG_44x
> > > /* Reset MAL */
> > > mtdcr(DCRN_MALCR(DCRN_MAL_BASE), MALCR_MMSR);
> > > /* Wait for reset */
> > > while (mfdcr(DCRN_MALCR(DCRN_MAL_BASE)) & MALCR_MMSR) {};
> > > /* Reset EMAC */
> > > *(volatile unsigned long *)PPC44x_EMAC0_MR0 = 0x20000000;
> > > __asm__ __volatile__("eieio");
> > > #endif
> >
> > Hmm, strange, 2.4 has this code already moved to misc-44x.c, I wonder
> > why this change never made it to 2.6.
> >
> > Marcelo, I assume you are going to make this look like 2.4, right?
>
> Sure, that looks better.
>
> Ok, so we can just make something minimal as misc-4xx, for 8xx, and
> have everything which can be outside decompress_kernel() there.
Yes, I think we're starting to understand eachother, as that sounds like
what I was talking about.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [RFC] attempt to remove misc-embedded.c
From: Marcelo Tosatti @ 2005-04-25 14:59 UTC (permalink / raw)
To: Tom Rini, linux-ppc-embedded
In-Reply-To: <20050425195519.GA2970@gate.ebshome.net>
On Mon, Apr 25, 2005 at 12:55:20PM -0700, Eugene Surovegin wrote:
> On Mon, Apr 25, 2005 at 11:36:19AM -0300, Marcelo Tosatti wrote:
> > So the plan is to move all cpu specific code in decompress_kernel() to cpu specific code :)
> >
> > Including
> >
> > #ifdef CONFIG_44x
> > /* Reset MAL */
> > mtdcr(DCRN_MALCR(DCRN_MAL_BASE), MALCR_MMSR);
> > /* Wait for reset */
> > while (mfdcr(DCRN_MALCR(DCRN_MAL_BASE)) & MALCR_MMSR) {};
> > /* Reset EMAC */
> > *(volatile unsigned long *)PPC44x_EMAC0_MR0 = 0x20000000;
> > __asm__ __volatile__("eieio");
> > #endif
>
> Hmm, strange, 2.4 has this code already moved to misc-44x.c, I wonder
> why this change never made it to 2.6.
>
> Marcelo, I assume you are going to make this look like 2.4, right?
Sure, that looks better.
Ok, so we can just make something minimal as misc-4xx, for 8xx, and
have everything which can be outside decompress_kernel() there.
One immediate advantage would be the INTERACTIVE_CONSOLE option.
^ permalink raw reply
* Re: [RFC] attempt to remove misc-embedded.c
From: Eugene Surovegin @ 2005-04-25 19:55 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Tom Rini, linux-ppc-embedded
In-Reply-To: <20050425143619.GF25420@logos.cnet>
On Mon, Apr 25, 2005 at 11:36:19AM -0300, Marcelo Tosatti wrote:
> So the plan is to move all cpu specific code in decompress_kernel() to cpu specific code :)
>
> Including
>
> #ifdef CONFIG_44x
> /* Reset MAL */
> mtdcr(DCRN_MALCR(DCRN_MAL_BASE), MALCR_MMSR);
> /* Wait for reset */
> while (mfdcr(DCRN_MALCR(DCRN_MAL_BASE)) & MALCR_MMSR) {};
> /* Reset EMAC */
> *(volatile unsigned long *)PPC44x_EMAC0_MR0 = 0x20000000;
> __asm__ __volatile__("eieio");
> #endif
Hmm, strange, 2.4 has this code already moved to misc-44x.c, I wonder
why this change never made it to 2.6.
Marcelo, I assume you are going to make this look like 2.4, right?
--
Eugene
^ permalink raw reply
* Re: [RFC] attempt to remove misc-embedded.c
From: Marcelo Tosatti @ 2005-04-25 14:36 UTC (permalink / raw)
To: Tom Rini; +Cc: linux-ppc-embedded
In-Reply-To: <20050425145029.GD3112@smtp.west.cox.net>
On Mon, Apr 25, 2005 at 07:50:29AM -0700, Tom Rini wrote:
> On Wed, Apr 13, 2005 at 04:57:13PM -0300, Marcelo Tosatti wrote:
>
> >
> > Hi Tom,
> >
> > This is an attempt to move remove misc-embedded.c by moving its quirks to
> > misc.c.
> >
> > It needs further fixing and cleaning, for sure.
>
> I like the idea of deleting misc-embedded.c, but I don't think we should
> haven't make many changes to misc.c (except perhaps abstracting away a
> few more hunks of it) as I _think_ most of the cpu-specific stuff can be
> moved around now to the misc-board.c files.
So the plan is to move all cpu specific code in decompress_kernel() to cpu specific code :)
Including
#ifdef CONFIG_44x
/* Reset MAL */
mtdcr(DCRN_MALCR(DCRN_MAL_BASE), MALCR_MMSR);
/* Wait for reset */
while (mfdcr(DCRN_MALCR(DCRN_MAL_BASE)) & MALCR_MMSR) {};
/* Reset EMAC */
*(volatile unsigned long *)PPC44x_EMAC0_MR0 = 0x20000000;
__asm__ __volatile__("eieio");
#endif
There are a few changes which are required for embedded targets, for example, passing "bd"
to serial_init as its 2nd argument.
Some misc-embedded.c requirements also need to be there, in decompress_kernel().
For example
+#ifdef CONFIG_EMBEDDEDBOOT
+ /* Set end of memory available to us. It is always the highest
+ * memory address provided by the board information.
+ */
+ end_avail = (char *)(bp->bi_memsize);
+#else
/* assume the chunk below 8M is free */
end_avail = (char *)0x00800000;
+#endif
And later "end_avail" setting need to be abstracted away.
Is that what you mean?
> > Are there any major disagreements about the change?
> > Might need to define a bd_t structure for all ppc's?
>
> That's something to be left for the flat OF tree thread. :)
>
> --
> Tom Rini
> http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: New MPC5200 Eratta/ATA Bugs
From: Stephen Warren @ 2005-04-25 19:35 UTC (permalink / raw)
To: Eric N. Johnson (ACD), linuxppc-embedded
Eric N. Johnson (ACD) wrote:
> Freescale just realeased a new version of the eratta (hardware bugs)=20
> document for the MPC5200. It was posted last week, and adds some
pretty=20
> significant problems to the FEC Ethernet and IDE/ATA sections.
>
> Specifically, I'm wonder if Eratta ID 485 may be the cause of some of
the=20
> IDE issues we've been attributing to Bestcomm:
>=20
> "During the concurrent access of ATA DMA READ and PCI or LPC the
> ATA_ISOLATION signal can be incorrectly driven when ATA is paused."
>=20
> Unfortunately, their proposed workaround isn't appropriate for many=20
> cases. They suggest that you not use "ATA_ISOLATION" and connect the
ATA=20
> device directly to the LP bus without any buffering. This could lead
to=20
> serious bus integrity issues, especially if the ATA device is
connected by=20
> a ribbon cable.=20
Freescale certainly confirmed that was the issue we were up against.
Freescale have been working with us on a board work-around for the
problem. This basically involves deriving a substitute ATA_ISOLATION
signal from the regular ATA control signals, in some cases.
--=20
Stephen Warren, Software Engineer, NVIDIA, Fort Collins, CO
swarren@nvidia.com http://www.nvidia.com/
swarren@wwwdotorg.org http://www.wwwdotorg.org/pgp.html
^ permalink raw reply
* New MPC5200 Eratta/ATA Bugs
From: Eric N. Johnson (ACD) @ 2005-04-25 19:22 UTC (permalink / raw)
To: linuxppc-embedded
Freescale just realeased a new version of the eratta (hardware bugs)
document for the MPC5200. It was posted last week, and adds some pretty
significant problems to the FEC Ethernet and IDE/ATA sections.
Specifically, I'm wonder if Eratta ID 485 may be the cause of some of the
IDE issues we've been attributing to Bestcomm:
"During the concurrent access of ATA DMA READ and PCI or LPC the
ATA_ISOLATION signal can be incorrectly driven when ATA is paused."
Unfortunately, their proposed workaround isn't appropriate for many
cases. They suggest that you not use "ATA_ISOLATION" and connect the ATA
device directly to the LP bus without any buffering. This could lead to
serious bus integrity issues, especially if the ATA device is connected by
a ribbon cable.
Eric
------------------------------------
Eric Johnson, Electrical Engineer
Advanced Communication Design
7901 12th Avenue South
Bloomington, MN 55425
Ph: 952-854-4000 Fax: 952-854-5774
^ permalink raw reply
* Re: [RFC] attempt to remove misc-embedded.c
From: Tom Rini @ 2005-04-25 14:50 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050413195713.GF11131@logos.cnet>
On Wed, Apr 13, 2005 at 04:57:13PM -0300, Marcelo Tosatti wrote:
>
> Hi Tom,
>
> This is an attempt to move remove misc-embedded.c by moving its quirks to
> misc.c.
>
> It needs further fixing and cleaning, for sure.
I like the idea of deleting misc-embedded.c, but I don't think we should
haven't make many changes to misc.c (except perhaps abstracting away a
few more hunks of it) as I _think_ most of the cpu-specific stuff can be
moved around now to the misc-board.c files.
> Are there any major disagreements about the change?
> Might need to define a bd_t structure for all ppc's?
That's something to be left for the flat OF tree thread. :)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Pantelis Antoniou @ 2005-04-25 11:44 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linux-ppc-embedded
In-Reply-To: <20050424225124.E7314C1510@atlas.denx.de>
Wolfgang Denk wrote:
> Dear Marcelo,
>
[depressing data snipped]
>
> Wolfgang Denk
>
Well it's a mess alright.
Unfortunately we cannot declare that we'll stay on 2.4 forever.
Several subsystems *MTD gough* do not support latest hw, or
the developers have moved on to 2.6 full time, refusing to
bother with 2.4 anymore.
Can we make an effort to pinpoint the performance
bottlenecks & re-implement the affected areas sanely?
The -tiny patchset is a start, but frankly I don't think it's
code/data footprint that it's the problem.
IMHO it's not just the small embedded systems that have been
affected; just on them the effects are more obvious.
So what do you all think?
Regards
Pantelis
^ permalink raw reply
* Re: old SNDF presentation
From: Fabio Estevam @ 2005-04-25 11:06 UTC (permalink / raw)
To: Kopac Drago ITWED2, linuxppc-embedded; +Cc: heinz.wrobel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1166 bytes --]
Hi Drago,
You can find this presentation in the following link:
http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=052577pzMPYZjg286165422098
Session ID: H1125
Best regards,
Fabio Estevam
--- Kopac Drago ITWED2 <kopac@iskratel.si> wrote:
>
> Hello Mr. Wrobel,
>
> My name is Drago Kopac (Iskratel, Slovenia,
> freescale customer). We atend SNDF on
> regular base.
>
> I have remembered your interesting session on SNDF
> 2004 (Frankfurt) titled
> Avoiding Classic Pitfalls in Networking and
> Communications Software: Writing Better Code
> Unfortunatelly I could´t find it on Freescale pages.
>
> Since we are checking linux ethernet driver FCC
> regarding caching/decaching (PQII) I would politely
> ask you to check if you have it somewhere in your
> archive in electronic form ?
>
> Best Regards,
> Drago
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
^ permalink raw reply
* RE: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Joakim Tjernlund @ 2005-04-25 9:57 UTC (permalink / raw)
To: Marcelo Tosatti, Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <20050424165520.GA22786@logos.cnet>
>
> Hi Dan, Joakim,
>
> On Sat, Apr 23, 2005 at 08:00:39PM -0400, Dan Malek wrote:
> >
> > On Apr 23, 2005, at 7:51 PM, Joakim Tjernlund wrote:
> >
> > >hmm, I have more than 24MB of memory and I can run CONFIG_PIN_TLB just
> > >fine with modules off in kernel 2.4. Havn't tried 2.6 yet.
> >
> > Doh. Oh, I see. We only do the optimization for the instruction
> > misses.
> > I'll have to take a closer look at Marcelo's 2.6 tests.
>
> The PIN TLB entry option does not make much difference in my tests,
> never did.
Don't your TLB Miss counters look different for kernel space? If they don't there must be something
very wrong with the CONFIG_PIN_TLB code.
>
> Who wrote the code? Are there results which indicate a performance gain
> from TLB pinning on 8xx? If so, where are such results?
I think Dan wrote this code. In 2.4 I improved the ITLB Miss handler a little for
pinned ITLBs
>
> One problem that I've noted is that initial_mmu sets {I,D}TLB index
> to be 27 (11100).
>
> MI_RSV4I protects TLB's 27...31.
>
> Given that both {I,D}TLB INDEX's are _decreased_ on each update, it seems
> to me that initial_mmu should set {I,D}TLB INDEX to 31, which will then
> decrease down to 27 after 4 TLB's are created.
Makes sense but I can't say for sure. I tried the patch below on my 2.4 tree
and it works fine.
>
> Another question that comes to mind is why initial_mmu does create
> additional 8Meg TLB entries for D-cache but not for I-cache:
Because the kernel code will never grow beyond 8MB, but data will due
to kmalloc() etc.
[SNIP]
^ permalink raw reply
* u-boot Memec Evaluation Board
From: andreas_schmidt @ 2005-04-25 9:01 UTC (permalink / raw)
To: linuxppc-embedded
Hi at all
I'm new there and i try to port the u-boot to memec insight Evaluation Board.
My Configurations:
Memec Insight Evaluation Board with Virtex2Pro
P160 Communications Module
I want to imlement in the u-boot at first the Flash and then Ethernet at P160 Module.
And i want to communicate with u-boot at RS232 Interface.
I have placed xparameters.h in config/ml300.
What must i modify at ml300.h and perhaps other files to adjust the u-boot to my board?
Or perhaps have anyone a ready patch for the board?
I now treing to do something but i get allways errors at compile the u-boot.
^ permalink raw reply
* MPC8272 USB host driver
From: Mike Rapoport @ 2005-04-25 9:49 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm trying to enable integrated USB host controller on MPC8272.
I'd like to use transaction level interface with automatic SOF
generation but I do not receive SOF interrupts although I keep them enabled.
What can be the reason of such behavior?
--
Sincerely Yours,
Mike Rapoport
^ permalink raw reply
* old SNDF presentation
From: Kopac Drago ITWED2 @ 2005-04-25 8:14 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: heinz.wrobel
Hello Mr. Wrobel,
My name is Drago Kopac (Iskratel, Slovenia, freescale customer). We =
atend SNDF on=20
regular base.
I have remembered your interesting session on SNDF 2004 (Frankfurt) =
titled
Avoiding Classic Pitfalls in Networking and Communications Software: =
Writing Better Code=20
Unfortunatelly I could=B4t find it on Freescale pages.=20
Since we are checking linux ethernet driver FCC regarding =
caching/decaching (PQII) I would politely
ask you to check if you have it somewhere in your archive in electronic =
form ?=20
Best Regards,
Drago
^ permalink raw reply
* AW: pthread debugging problem
From: Achim Machura @ 2005-04-25 6:51 UTC (permalink / raw)
To: 'Mark Chambers'; +Cc: Linuxppc-Embedded (E-Mail)
In-Reply-To: <002101c54774$83c85590$0301a8c0@chuck2>
Hello Mark,
-----Ursprüngliche Nachricht-----
Von: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org]Im Auftrag von Mark Chambers
Gesendet: Freitag, 22. April 2005 21:50
An: linuxppc-embedded@ozlabs.org
Betreff: pthread debugging problem
<I am debugging a simple program with several threads, using pthreads.
<printf's tell me that the threading is working, but I am unable to debug
<the program with gdb (gdbserver on the target). I get spurious
<'Program received signal SIG32, Real-time even 32' messages.
<I'm using a stock ELDK tree via NFS boot. I couldn't tell you the ELDK
<version but I've listed some of the components below.
Sometimes we have the same problems.
We have solved it by telling gdb the path of the libs using,
set SOLIB_ABSOLUTE_PREFIX.
Also there is a problem if you use different versions of dynamic libraries
for the progamm and the gdb.
achim
^ permalink raw reply
* [PATCH] ppc iomem annotations: mv643xx_eth
From: Al Viro @ 2005-04-25 6:04 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
void * __iomem replaced with intended void __iomem *.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
----
diff -urN RC12-rc3-ppc-signal/drivers/net/mv643xx_eth.c RC12-rc3-mveth/drivers/net/mv643xx_eth.c
--- RC12-rc3-ppc-signal/drivers/net/mv643xx_eth.c Wed Apr 20 21:25:38 2005
+++ RC12-rc3-mveth/drivers/net/mv643xx_eth.c Mon Apr 25 01:36:36 2005
@@ -99,7 +99,7 @@
static inline u32 mv_read(int offset)
{
- void *__iomem reg_base;
+ void __iomem *reg_base;
reg_base = mv643xx_eth_shared_base - MV643XX_ETH_SHARED_REGS;
@@ -108,7 +108,7 @@
static inline void mv_write(int offset, u32 data)
{
- void * __iomem reg_base;
+ void __iomem *reg_base;
reg_base = mv643xx_eth_shared_base - MV643XX_ETH_SHARED_REGS;
writel(data, reg_base + offset);
^ permalink raw reply
* [PATCH] ppc sparse annotations: emulate_string_inst()
From: Al Viro @ 2005-04-25 6:04 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
replaced declaration of EA from u32 to unsigned long - this beast
is used only to cast it to (userland) pointer and proper integer type for
that is unsigned long.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
----
diff -urN RC12-rc3-mveth/arch/ppc/kernel/traps.c RC12-rc3-ppc-traps/arch/ppc/kernel/traps.c
--- RC12-rc3-mveth/arch/ppc/kernel/traps.c Wed Apr 20 21:25:28 2005
+++ RC12-rc3-ppc-traps/arch/ppc/kernel/traps.c Mon Apr 25 01:36:38 2005
@@ -403,7 +403,7 @@
u8 rA = (instword >> 16) & 0x1f;
u8 NB_RB = (instword >> 11) & 0x1f;
u32 num_bytes;
- u32 EA;
+ unsigned long EA;
int pos = 0;
/* Early out if we are an invalid form of lswx */
^ 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