* Re: Kernel 2.6 on MPC8xx performance trouble...
From: David Jander @ 2005-10-31 13:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <003501c5de1a$be79b390$0301a8c0@chuck2>
On Monday 31 October 2005 13:58, Mark Chambers wrote:
>[...]
> > No, sir, no cache detected !
> >
> > Where do I have to look now?
>
> Could the cache be in writethrough mode? (Instead of writeback)
Good point. I just checked the same test, but reading instead of writing. Same
result, no cache detected.
I know how to change cache policy in u-boot, but does the kernel change that?
If so, where?
Greetings,
--
David Jander
^ permalink raw reply
* audit_sysctl_exit can only be used with CONF_AUDIT_SYSCTL
From: Horms @ 2005-10-31 13:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andrew Morton, david
This section of code calls .audit_syscal_exit,
but is inside CONFIG_AUDIT, so it will fail to build
if CONFIG_AUDITSYSCALL is not defined.
After discussion with David Woodhouse, change the
ifdef to CONFIG_AUDITSYSCALL
Signed-off-by: Horms <horms@verge.net.au>
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 984a106..2d22bf0 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -279,7 +279,7 @@ _GLOBAL(ppc32_rt_sigsuspend)
bne syscall_exit
/* If sigsuspend() returns zero, we are going into a signal handler. We
may need to call audit_syscall_exit() to mark the exit from sigsuspend() */
-#ifdef CONFIG_AUDIT
+#ifdef CONFIG_AUDITSYSCALL
ld r3,PACACURRENT(r13)
ld r4,AUDITCONTEXT(r3)
cmpdi 0,r4,0
^ permalink raw reply related
* Re: NFS can not mount (linuxppc2.2.4 mpc5200 lxt971)
From: Tore Martin Hagen @ 2005-10-31 14:13 UTC (permalink / raw)
To: xiay; +Cc: linuxppc-embedded
In-Reply-To: <200510281054.AA34079032@NARI-RELAYS.COM>
ÏÄÓê wrote:
>eth0: config: auto-negotiation on, 100HDX, 10HDX.
>IP-Config: Complete:
> device=eth0, addr=198.87.102.211, mask=255.255.255.0, gw=198.87.102.140,
> host=oops, domain=, nis-domain=(none),
> bootserver=198.87.102.140, rootserver=198.98.102.140, rootpath=
>
>
Hi
Check out your DHCP server. You don't get the rootpath from it.
/etc/dhcpd.conf should contain
option root-path "/local/Mpc8266ads/Box0/root";
or something similar.
also take a look in /var/log/messages to pinpoint the problem.
/Tore Hagen
^ permalink raw reply
* Re: [PATCH] ppc32: Add missing initrd header on ppc440
From: Matt Porter @ 2005-10-31 14:41 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200510311029.13432.sr@denx.de>
On Mon, Oct 31, 2005 at 11:29:13AM +0200, Stefan Roese wrote:
> By the way: What is the current status of the pending 4xx patches. Are they
> going in in this 2-week merge window?
The PPC44x U-Boot cleanup was queued and merged. The rest of PPC4xx
cleanup patches are now pending with akpm and will probably be queued
for Linus shortly. There will be no problem with them being merged.
-Matt
^ permalink raw reply
* Re: Kernel 2.6 on MPC8xx performance trouble...
From: David Jander @ 2005-10-31 15:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200510311408.41691.david.jander@protonic.nl>
On Monday 31 October 2005 14:08, David Jander wrote:
> On Monday 31 October 2005 13:58, Mark Chambers wrote:
> >[...]
> >
> > > No, sir, no cache detected !
> > >
> > > Where do I have to look now?
> >
> > Could the cache be in writethrough mode? (Instead of writeback)
>
> Good point. I just checked the same test, but reading instead of writing.
> Same result, no cache detected.
>
> I know how to change cache policy in u-boot, but does the kernel change
> that? If so, where?
Sorry for the stupid question. I did not remember it was there right before my
eyes. It seems I just got lost in the new menu structure of the Kconfig.
And yes, cache was in writethrough mode!!
It seems as though this option disables cache entirely, because after turning
it on, I suddenly get 2.4-type speed measurements.
With CONFIG_8xx_COPYBACK undefined, both reading and writing gives results as
if there was simply no cache. Shouldn't it at least speed up memory-read
access?
Sorry to everone for wasting their time with this stupid mistake of mine.
Thanks for all the help anyway.
Greetings,
--
David Jander
^ permalink raw reply
* Re: [PATCH] PPC: Basic enablement for new 15" PowerBook
From: Segher Boessenkool @ 2005-10-31 16:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20051030044256.GA10863@pb15.lixom.net>
> It's a qualified guess that the new 17" is PowerBook5,9, but until it's
> confirmed there's not much use in adding it to the pmac_feature table.
It is. See
http://developer.apple.com/documentation/Hardware/Developer_Notes/
Macintosh_CPUs-G4/17inchPowerBookG4/1Overview/
chapter_2_section_6.html#//apple_ref/doc/uid/TP40003166-CH205-TPXREF108
Segher
^ permalink raw reply
* Re: use of phy_connect() in drivers/net/gianfar.c ?
From: Andy Fleming @ 2005-10-31 16:56 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Linux/PPC Development
In-Reply-To: <20051030151847.C4383353416@atlas.denx.de>
On Oct 30, 2005, at 09:18, Wolfgang Denk wrote:
> Dear Matthew,
>
> in message <1130632707.7470.16.camel@localhost.localdomain> you wrote:
> >
> > As far as I understand there are patches in the -mm tree with =20
> contain
> > the updates for the Gianfar driver. The issue is due to a
>
> Do you happen to know of a specific (set of) patch(es)? URL?
>
> > synchronization issue with the new PHY abstraction layer that was =20=
> added.
>
> Yes, obviously. But I am still so na=EFve to expect that such =
changes
> would not make it untested (the code is not even compile clean) to an
> official kernel release like 2.6.14 ?
Sorry about that. The problem was that the offending changes needed =20
to be broken into two patches. The PHY Layer (a separate patch) =20
required changes to the driver, which required concurrent changes in =20
the platform init code (the MDIO bus was set up as its own device). =20
Unfortunately, the driver changes needed to be handled through =20
netdev, while the platform changes were through -mm. We tried to =20
sync it up so that the changes got into Linus' tree at the same time, =20=
but that did not happen. If you pull the tree today, you will find =20
that patch is now in the main tree.
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Mark A. Greer @ 2005-10-31 19:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, Sven Luther
In-Reply-To: <17251.265.196352.234376@cargo.ozlabs.ibm.com>
On Sat, Oct 29, 2005 at 02:56:41PM +1000, Paul Mackerras wrote:
> Sven Luther writes:
>
> > +static struct pci_device_id pci_marvell_mv64360[] = {
> > + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64360) },
>
> Are there other devices in this northbridge whose drivers might also
> want to bind to this PCI id?
>
> What other devices does this northbridge contain?
It does have a PIC, DMA engine, and SRAM that Sven mentioned but there
are also a serial controller (MPSC), an i2c controller, and a watchdog
timer. I would guess that the MPSC and i2c drivers, at least, should
use MODULE_DEVICE_TABLE. If you agree, I'll add it to the list.
Mark
^ permalink raw reply
* enabling/disabling CPUs Kconfig bug
From: Giuliano Pochini @ 2005-10-31 21:11 UTC (permalink / raw)
To: LinuxPPC-dev
The option Processor-->Support for enabling/disabling CPUs should require
Platform options-->Power Management support to be enabled, otherwise compile
fails. I'm not sure if this patch is right or if the problem is somewhere else.
Signed-off-by Giuliano Pochini <pochini@shiny.it>
--- arch/ppc/Kconfig__orig 2005-10-30 17:19:17.000000000 +0000
+++ arch/ppc/Kconfig 2005-10-30 17:19:59.000000000 +0000
@@ -263,7 +263,7 @@
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
- depends on SMP && HOTPLUG && EXPERIMENTAL && PPC_PMAC
+ depends on SMP && HOTPLUG && EXPERIMENTAL && PPC_PMAC && PM
---help---
Say Y here to be able to disable and re-enable individual
CPUs at runtime on SMP machines.
--
Giuliano.
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Sven Luther @ 2005-10-31 21:21 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Andrew Morton, Sven Luther, linuxppc-dev
In-Reply-To: <20051031190524.GE5055@mag.az.mvista.com>
On Mon, Oct 31, 2005 at 12:05:24PM -0700, Mark A. Greer wrote:
> On Sat, Oct 29, 2005 at 02:56:41PM +1000, Paul Mackerras wrote:
> > Sven Luther writes:
> >
> > > +static struct pci_device_id pci_marvell_mv64360[] = {
> > > + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64360) },
> >
> > Are there other devices in this northbridge whose drivers might also
> > want to bind to this PCI id?
> >
> > What other devices does this northbridge contain?
>
> It does have a PIC, DMA engine, and SRAM that Sven mentioned but there
> are also a serial controller (MPSC), an i2c controller, and a watchdog
> timer. I would guess that the MPSC and i2c drivers, at least, should
> use MODULE_DEVICE_TABLE. If you agree, I'll add it to the list.
Yeah, forgot those, we don't use them on the pegasos though.
Friendly,
Sven Luther
^ permalink raw reply
* Export assembly symbol
From: Duong Nguyen @ 2005-10-31 23:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
Hello Garcia,
My name is Duong Nguyen. I am also working on a project that is needing
to export symbols from an assembly file for a loadable module. I am
having the exact problem that you were looking for help in August.
Have you gotten a solution for it yet ?
Would you please share your finding with me ?
Thanks
Duong
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
[-- Attachment #2: Type: text/html, Size: 3983 bytes --]
^ permalink raw reply
* Re: exception vectors
From: Olof Johansson @ 2005-11-01 1:46 UTC (permalink / raw)
To: Ingmar; +Cc: linuxppc-dev list
In-Reply-To: <20051031093907.M8073@gmx.net>
On Mon, Oct 31, 2005 at 10:58:53AM +0100, Ingmar wrote:
> On Sun, 30 Oct 2005 20:28:49 -0600, Hollis Blanchard wrote
> > On Oct 30, 2005, at 6:35 PM, Ingmar wrote:
> > >
> > > I am trying to overwrite the exception vector space of an ibook G4 :).
> >
> > Why?
> >
>
> For my thesis project I am porting the Minix (v3) OS.
Sounds like using qemu or some other emulator to do the PPC port first
might be an easier choice, and make debugging easier for you during
early bringup.
-Olof
^ permalink raw reply
* Re: Patches for 2.6.15
From: Paul Mackerras @ 2005-11-01 5:53 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <20051028103041.B15268@cox.net>
Matt Porter writes:
> Ok, we have a set of 4xx patches that I plan to send to Andrew.
> They are some existing 4xx SoC/board updates as well as a new
> SoC/board. They are obviously mostly confined to the 4xx code paths
> but there's likely conflicts in changes to Makefiles, etc.
>
> Would you prefer these going upstream before or after the
> powerpc-merge pull?
Did you send them yet? Linus has pulled the powerpc-merge tree, as
I'm sure you've noticed.
Paul.
^ permalink raw reply
* Re: Patches for 2.6.15
From: Paul Mackerras @ 2005-11-01 5:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <D45D980C-C3F8-4418-A159-6F10708C914A@freescale.com>
Kumar Gala writes:
> Can you merge this in:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=2931
Having the same extern declaration in several C files raises a red
flag. Could we have that in a suitable header file instead please?
Paul.
^ permalink raw reply
* Re: [PATCH] ppc32: Fix SCC Uart write problem after 2. open()
From: Heiko Schocher @ 2005-11-01 7:17 UTC (permalink / raw)
To: linuxppc-dev
Hello,
Sorry, here comes the resubmit of the Patch because
corruption of whitespaces.
on a MPC8260 based Board, i succesfully wrote chars
over a SCC in UART Mode, but after i closed the port
and opened it again, the write() call failed!
(cpm_uart_tx_empty()returns continually 0).
The following Patch will fix this problem.
thanks
Heiko Schocher
[PATCH] ppc32: Fix SCC Uart write problem after 2. open().
Signed-off-by: Heiko Schocher <hs@denx.de>
---
commit f27d5789521e3f70a293075a63d195b22f8156ed
tree 1b459d4a9a2795e39e1d415ff21f2a25a0d0fbe5
parent d2fcbaa6d5fcb3c1f80c98997dbcf6f6ee075f1b
author Heiko Schocher <hs@pollux.(none)> Mon, 31 Oct 2005 15:46:50 +0100
committer Heiko Schocher <hs@pollux.(none)> Mon, 31 Oct 2005 15:46:50 +0100
drivers/serial/cpm_uart/cpm_uart_core.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index a452c38..ac05ee9 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -445,6 +445,10 @@ static void cpm_uart_shutdown(struct uar
/* Shut them really down and reinit buffer descriptors */
cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
cpm_uart_initbd(pinfo);
+ if (IS_SMC(pinfo))
+ cpm_uart_init_smc(pinfo);
+ else
+ cpm_uart_init_scc(pinfo);
}
}
^ permalink raw reply related
* [PATCH] ppc32: fix: swallowed chars when booting.
From: Heiko Schocher @ 2005-11-01 7:22 UTC (permalink / raw)
To: linuxppc-dev
Hello,
Sorry, here comes the resubmit of the Patch because
corruption of whitespaces.
on a MPC8260 based Board, i lost some chars on the SMC2
Console, when booting the kernel. The following Patch
will fix this.
thanks
Heiko Schocher
[PATCH] ppc32: fix: swallowed chars when booting.
In cpm_uart_set_termios(): wait until all chars are transmitted,
before writing the SMC Mode Register.
Signed-off-by: Heiko Schocher <hs@denx.de>
---
commit d2fcbaa6d5fcb3c1f80c98997dbcf6f6ee075f1b
tree d602dae10d2010ca1506c6a02e6a6db36ac86aca
parent ed28f96ac1960f30f818374d65be71d2fdf811b0
author Heiko Schocher <hs@pollux.(none)> Mon, 31 Oct 2005 12:11:55 +0100
committer Heiko Schocher <hs@pollux.(none)> Mon, 31 Oct 2005 12:11:55 +0100
drivers/serial/cpm_uart/cpm_uart_core.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index 25825f2..a452c38 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -553,6 +553,11 @@ static void cpm_uart_set_termios(struct
* present.
*/
prev_mode = smcp->smc_smcmr;
+ /* Wait for all the BDs marked sent */
+ while(!cpm_uart_tx_empty(port)) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(4);
+ }
smcp->smc_smcmr = smcr_mk_clen(bits) | cval | SMCMR_SM_UART;
smcp->smc_smcmr |= (prev_mode & (SMCMR_REN | SMCMR_TEN));
} else {
\f
!-------------------------------------------------------------flip-
^ permalink raw reply related
* Re: exception vectors
From: Ingmar @ 2005-11-01 8:28 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20051101014630.GA7938@pb15.lixom.net>
> > > > I am trying to overwrite the exception vector space of an ibook G4 :).
> > >
> > > Why?
> > >
> >
> > For my thesis project I am porting the Minix (v3) OS.
>
> Sounds like using qemu or some other emulator to do the PPC port first
> might be an easier choice, and make debugging easier for you during
> early bringup.
I was going to try that, before I got the ibook. Then I got the ibook and I
wanted to get my hand dirty. Nothing beats the real thing :)
But I have figured it out, I have the code working...
It are more or less (just) two things:
- mmu off,
- make sure u copy through the cache.
And of course make sure your secondary code is working as it should, then a emu
would help :).
Thanks for the reactions.
Ingmar
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Paul Mackerras @ 2005-11-01 9:25 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Andrew Morton, linuxppc-dev, Sven Luther
In-Reply-To: <20051031190524.GE5055@mag.az.mvista.com>
Mark A. Greer writes:
> It does have a PIC, DMA engine, and SRAM that Sven mentioned but there
> are also a serial controller (MPSC), an i2c controller, and a watchdog
> timer. I would guess that the MPSC and i2c drivers, at least, should
> use MODULE_DEVICE_TABLE. If you agree, I'll add it to the list.
But the point is that if one driver has claimed the device (because
its ID is in its module device table), the other drivers won't be able
to. You need something like the macio driver that BenH did, which
claims the macio device and creates a macio bus structure and allows
individual macio device drivers to claim the pieces of it.
Paul.
^ permalink raw reply
* Re: Patches for 2.6.15
From: Matt Porter @ 2005-11-01 13:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17255.737.832440.137041@cargo.ozlabs.ibm.com>
On Tue, Nov 01, 2005 at 04:53:37PM +1100, Paul Mackerras wrote:
> Matt Porter writes:
>
> > Ok, we have a set of 4xx patches that I plan to send to Andrew.
> > They are some existing 4xx SoC/board updates as well as a new
> > SoC/board. They are obviously mostly confined to the 4xx code paths
> > but there's likely conflicts in changes to Makefiles, etc.
> >
> > Would you prefer these going upstream before or after the
> > powerpc-merge pull?
>
> Did you send them yet? Linus has pulled the powerpc-merge tree, as
> I'm sure you've noticed.
Yes I did. I saw the merge go into mainline and rebased what was
necessary off of that. Andrew now has them queued up for Linus so
we are set. BTW, we're starting to look at merging 4xx to arch/powerpc/
now.
-Matt
^ permalink raw reply
* [PATCH] ppc bug.h namespace pollution
From: Al Viro @ 2005-11-01 15:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
DATA_TYPE is really not a good thing to put into header that
gets included all over the tree...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----
diff -urN RC14-base/include/asm-powerpc/bug.h current/include/asm-powerpc/bug.h
--- RC14-base/include/asm-powerpc/bug.h 2005-11-01 02:39:50.000000000 -0500
+++ current/include/asm-powerpc/bug.h 2005-11-01 04:50:01.000000000 -0500
@@ -15,12 +15,12 @@
#define BUG_TABLE_ENTRY(label, line, file, func) \
".llong " #label "\n .long " #line "\n .llong " #file ", " #func "\n"
#define TRAP_OP(ra, rb) "1: tdnei " #ra ", " #rb "\n"
-#define DATA_TYPE long long
+#define BUG_DATA_TYPE long long
#else
#define BUG_TABLE_ENTRY(label, line, file, func) \
".long " #label ", " #line ", " #file ", " #func "\n"
#define TRAP_OP(ra, rb) "1: twnei " #ra ", " #rb "\n"
-#define DATA_TYPE int
+#define BUG_DATA_TYPE int
#endif /* __powerpc64__ */
struct bug_entry {
@@ -55,7 +55,7 @@
".section __bug_table,\"a\"\n\t" \
BUG_TABLE_ENTRY(1b,%1,%2,%3) \
".previous" \
- : : "r" ((DATA_TYPE)(x)), "i" (__LINE__), \
+ : : "r" ((BUG_DATA_TYPE)(x)), "i" (__LINE__), \
"i" (__FILE__), "i" (__FUNCTION__)); \
} while (0)
@@ -65,7 +65,7 @@
".section __bug_table,\"a\"\n\t" \
BUG_TABLE_ENTRY(1b,%1,%2,%3) \
".previous" \
- : : "r" ((DATA_TYPE)(x)), \
+ : : "r" ((BUG_DATA_TYPE)(x)), \
"i" (__LINE__ + BUG_WARNING_TRAP), \
"i" (__FILE__), "i" (__FUNCTION__)); \
} while (0)
^ permalink raw reply
* AMCC440EP Boot Source
From: Dick Hollenbeck @ 2005-11-01 15:31 UTC (permalink / raw)
To: linuxppc-dev
We are looking at the yosemite design but want a CF2 socket for the OS
image. Can U-Boot reside in the EEPROM accessible via I2C?
This would allow us to remove the flash entirely in favor of the CF2
flash. If yes, are there any drawbacks to this vs. keeping a small bit
of flash soldered to the board?
--
Please help fix the U.S. software industry before it is too late.
Contact your U.S. representatives with this information:
http://lpf.ai.mit.edu/Patents/industry-at-risk.html
http://www.groklaw.net/article.php?story=20041003041632172
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: David Woodhouse @ 2005-11-01 15:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17253.39993.502458.390760@cargo.ozlabs.ibm.com>
On Mon, 2005-10-31 at 15:23 +1100, Paul Mackerras wrote:
> It is now possible to build kernels for powermac, pSeries, iSeries and
> maple with ARCH=powerpc, and for powermac, both 32-bit and 64-bit
> build and run.
Hm. Not entirely in line with my experience. Can you share the configs
you used?
Using http://david/woodhou.se/powerpc-merge-32.config it doesn't
actually boot on my powerbook. I'll try it on the Pegasos later or
tomorrow, where I have a serial console; it dies very early.
Aside from disabling CONFIG_NVRAM because call_rtas() isn't implemented
anywhere, I also needed to do this to make that config build:
--- linux-2.6.14/arch/powerpc/kernel/setup-common.c.orig 2005-11-01 10:14:32.000000000 +0000
+++ linux-2.6.14/arch/powerpc/kernel/setup-common.c 2005-11-01 10:15:03.000000000 +0000
@@ -203,11 +203,11 @@ static int show_cpuinfo(struct seq_file
#ifdef CONFIG_TAU_AVERAGE
/* more straightforward, but potentially misleading */
seq_printf(m, "temperature \t: %u C (uncalibrated)\n",
- cpu_temp(i));
+ cpu_temp(cpu_id));
#else
/* show the actual temp sensor range */
u32 temp;
- temp = cpu_temp_both(i);
+ temp = cpu_temp_both(cpu_id);
seq_printf(m, "temperature \t: %u-%u C (uncalibrated)\n",
temp & 0xff, temp >> 16);
#endif
--
dwmw2
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: David Woodhouse @ 2005-11-01 16:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17253.39993.502458.390760@cargo.ozlabs.ibm.com>
On Mon, 2005-10-31 at 15:23 +1100, Paul Mackerras wrote:
> It is now possible to build kernels for powermac, pSeries, iSeries and
> maple with ARCH=powerpc, and for powermac, both 32-bit and 64-bit
> build and run.
The ppc64 build (http://david.woodhou.se/powerpc-merge-64.config) fares
worse than ppc32 for me -- it doesn't even build.
arch/powerpc/platforms/powermac/pic.c:614: error: ‘ppc_cached_irq_mask’ undeclared (first use in this function)
arch/powerpc/platforms/powermac/pic.c:620: error: ‘pmac_irq_hw’ undeclared (first use in this function)
arch/powerpc/platforms/powermac/pic.c:621: error: ‘max_real_irqs’ undeclared (first use in this function)
arch/powerpc/platforms/powermac/pic.c:641: warning: implicit declaration of function ‘pmac_unmask_irq’
If I leave CONFIG_ADB_PMU enabled (as I think I should since some G5s
have it?) I also see this:
drivers/macintosh/via-pmu.c:2410: undefined reference to `.pmac_tweak_clock_spreading'
drivers/macintosh/via-pmu.c:2494: undefined reference to `.set_context'
drivers/macintosh/via-pmu.c:2670: undefined reference to `._nmask_and_or_msr'
drivers/macintosh/via-pmu.c:2592: undefined reference to `.set_context'
If I turn CONFIG_ADB_PMU off, I see this:
arch/powerpc/platforms/powermac/time.c:335: undefined reference to `.pmu_register_sleep_notifier'
I think I'll leave the task of switching the Fedora rawhide kernel to
arch/powerpc to another day :)
--
dwmw2
^ permalink raw reply
* Re: AMCC440EP Boot Source
From: Stefan Roese @ 2005-11-01 16:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dick Hollenbeck
In-Reply-To: <43678A3A.1050803@softplc.com>
Hi Dick,
On Tuesday 01 November 2005 16:31, Dick Hollenbeck wrote:
> We are looking at the yosemite design but want a CF2 socket for the OS
> image. Can U-Boot reside in the EEPROM accessible via I2C?
No. 440EP definitely can't boot from I2C EEPROM! With CF2 you mean
CompactFlash, right?
> This would allow us to remove the flash entirely in favor of the CF2
> flash. If yes, are there any drawbacks to this vs. keeping a small bit
> of flash soldered to the board?
Keep the small NOR FLASH and save yourself a lot of trouble. 256kB is enough
in most cases.
By the way: This is off topic here and should be asked in the U-Boot list.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] ppc32: Fix SCC Uart write problem after 2. open()
From: Dan Malek @ 2005-11-01 16:08 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <AHEILKONAKAEJPHNMOPNMEFBCDAA.hs@denx.de>
On Nov 1, 2005, at 2:17 AM, Heiko Schocher wrote:
> The following Patch will fix this problem.
This is wrong. We should never have to reinitialize the
buffer descriptors (which I see the driver does in some cases)
and we certainly should never have to reinitialize the
SCC or SMC peripherals like this.
Once the driver has initialized the SCC or SMC and set up
the buffer descriptors during kernel start up, it should never
be done again. The only thing we should do is stop/start
the transmitter or receiver, and they should continue operation
with the next buffer descriptor in the ring.
This patch just covers up a driver bug, find and fix the real bug.
Thanks.
-- Dan
^ 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