* Re: compact flash driver
From: Bizhan Gholikhamseh (bgholikh) @ 2005-11-02 11:28 UTC (permalink / raw)
To: mcr; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
>>>>> "Alex" == Alex Zeffertt <ajz@cambridgebroadband.com> writes:
>> Hello All, Are there any compact flash driver supported for Linux
>> 2.6? If there is where can i get the source code. Thanks, Bizhan
>>
Alex> I think that CF cards just get treated the same as any other
Alex> IDE disk by linux. No special driver needed.
>Yes. There are some gotchas with newer pcmcia/cardbus flash cards.
>For instance, Silicon Systems devices claim to support IORDY, but
don't, which results in a system hang. I imagine that the same >kind of
things will show up in newer CF devices, although I think that CF can't
support DMA.
>It also depends upon how you interface CF: via an IDE controller, or
via a cardbus interface.
>I expect to have a git tree with stuff available soon.
Do you have an early release code? I can start to work at.
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 2064 bytes --]
^ permalink raw reply
* Board Bringup problem with 2.6.13.4
From: David H. Lynch Jr @ 2005-11-02 9:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050906130029.74727.qmail@web8405.mail.in.yahoo.com>
I am working through bringing up Linux 2.6.13.4 on a Xilinx V4 based ppc405.
with memory from 0x0 through 0x7fffffff
Right now I get:
>Starting MonitorX.elf: V3.3.2.0.
>
>loaded at: 00400000 0047F13C
>board data at: 0047D128 0047D13C
>relocated to: 00405300 00405314
>zimage at: 00405A95 0047CE71
>avail ram: 00480000 08000000
>
>Linux/PPC load: console=ttyS0,9600 console=tty0 init=/linuxrc
looptype=squashfs cdroot splash=silentttttt
>Uncompressing Linux......done.
>Now booting the kernel
I have been able to trace execution into head_4xx.S to immediately
before turn_on_mmu:
But immediately after this I lose the ability to trace.
I have been tracing things with a status port at 0x70000000 I can write
to and read from the host side with code like
lis r14,0x7000 /* debugging port */
li r15,0x2305 /* value to output */
stw r15,4(r14)
eieio
after turn_on_mmu executes this does not seem to work.
looking at other code it appeared that I needed to add
tophy(r14,r14) prior to the stw
but that does not seem to help.
What do I need to do to be able to continue to use my debug port ?
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: David Woodhouse @ 2005-11-02 9:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17256.4190.184855.821331@cargo.ozlabs.ibm.com>
On Wed, 2005-11-02 at 12:03 +1100, Paul Mackerras wrote:
> That's probably either the pci quirk that got added to do USB host
> controller handoff unconditionally on all platforms, and which touches
> the device without doing pci_enable_device or checking whether MMIO is
> enabled. A fix has gone into Linus' tree for that.
>
> There was also a bug added to the adbhid.c driver which would cause an
> oops when you pressed a key if you had an ADB keyboard (which
> powerbooks do). That's also fixed in Linus' tree.
It was neither of those -- after a few warnings about sleeping in
inappropriate contexts it just seems to stop. The Pegasos is a little
more informative -- lots of 'hda: lost interrupt' on that. Keyboard
seems to work though, and Bogomips calculation -- so maybe it's just PCI
interrupts which are missing. I'll poke at it further.
I'll also try again on the powerbook today and see if I can get anything
more useful out of it.
--
dwmw2
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: David Woodhouse @ 2005-11-02 7:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17256.17408.247708.622755@cargo.ozlabs.ibm.com>
On Wed, 2005-11-02 at 15:43 +1100, Paul Mackerras wrote:
> I also pulled in Linus' tree, and now drivers/char/tlclk.c fails to
> build for some reason. I claim that's not my fault, however. :)
It just needs <linux/platform_device.h> included. That reminds me -- I
needed that in platforms/chrp/pegasos_eth.c too.
diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c
--- a/arch/powerpc/platforms/chrp/pegasos_eth.c
+++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
@@ -15,6 +15,7 @@
#include <linux/ioport.h>
#include <linux/device.h>
#include <linux/mv643xx.h>
+#include <linux/platform_device.h>
#include <linux/pci.h>
#define PEGASOS2_MARVELL_REGBASE (0xf1000000)
diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c
--- a/drivers/char/tlclk.c
+++ b/drivers/char/tlclk.c
@@ -43,6 +43,7 @@
#include <linux/sysfs.h>
#include <linux/device.h>
#include <linux/miscdevice.h>
+#include <linux/platform_device.h>
#include <asm/io.h> /* inb/outb */
#include <asm/uaccess.h>
--
dwmw2
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: Paul Mackerras @ 2005-11-02 4:43 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1130861207.21212.66.camel@hades.cambridge.redhat.com>
David Woodhouse writes:
> The ppc64 build (http://david.woodhou.se/powerpc-merge-64.config) fares
> worse than ppc32 for me -- it doesn't even build.
Those errors were all due to getting powerbook sleep code included
because you have CONFIG_PM=y. I have changed things so that that code
doesn't get included on a 64-bit build (at least until BenH gets sleep
going on the G5 :).
I also pulled in Linus' tree, and now drivers/char/tlclk.c fails to
build for some reason. I claim that's not my fault, however. :)
Paul.
^ permalink raw reply
* Re: [PATCH] ppc bug.h namespace pollution
From: Paul Mackerras @ 2005-11-02 3:29 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <20051102031043.GB7992@ftp.linux.org.uk>
Al Viro writes:
> Should be OK...
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
OK, I'll put that in my powerpc-merge tree and ask Linus to pull it.
I want to do a few more cleanups on that file now that I look at it.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] ppc bug.h namespace pollution
From: Al Viro @ 2005-11-02 3:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <17256.10342.228209.745529@cargo.ozlabs.ibm.com>
On Wed, Nov 02, 2005 at 01:45:58PM +1100, Paul Mackerras wrote:
> Al Viro writes:
>
> > DATA_TYPE is really not a good thing to put into header that
> > gets included all over the tree...
>
> Very true. However, I don't see any reason why the cast shouldn't
> just be (long) on both 32-bit and 64-bit, so we can get rid of that
> define altogether.
Should be OK...
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 22:08:35.000000000 -0500
+++ current/include/asm-powerpc/bug.h 2005-11-01 22:09:28.000000000 -0500
@@ -15,12 +15,10 @@
#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
#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
#endif /* __powerpc64__ */
struct bug_entry {
@@ -55,7 +53,7 @@
".section __bug_table,\"a\"\n\t" \
BUG_TABLE_ENTRY(1b,%1,%2,%3) \
".previous" \
- : : "r" ((DATA_TYPE)(x)), "i" (__LINE__), \
+ : : "r" ((long)(x)), "i" (__LINE__), \
"i" (__FILE__), "i" (__FUNCTION__)); \
} while (0)
@@ -65,7 +63,7 @@
".section __bug_table,\"a\"\n\t" \
BUG_TABLE_ENTRY(1b,%1,%2,%3) \
".previous" \
- : : "r" ((DATA_TYPE)(x)), \
+ : : "r" ((long)(x)), \
"i" (__LINE__ + BUG_WARNING_TRAP), \
"i" (__FILE__), "i" (__FUNCTION__)); \
} while (0)
^ permalink raw reply
* Re: [PATCH] ppc bug.h namespace pollution
From: Paul Mackerras @ 2005-11-02 2:45 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <20051101151716.GY7992@ftp.linux.org.uk>
Al Viro writes:
> DATA_TYPE is really not a good thing to put into header that
> gets included all over the tree...
Very true. However, I don't see any reason why the cast shouldn't
just be (long) on both 32-bit and 64-bit, so we can get rid of that
define altogether.
Paul.
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: Paul Mackerras @ 2005-11-02 1:04 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1130860444.21212.52.camel@hades.cambridge.redhat.com>
[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 170 bytes --]
David Woodhouse writes:
> Hm. Not entirely in line with my experience. Can you share the configs
> you used?
Forgot to attach the configs on my previous reply.
Paul.
[-- Attachment #2: config tarball --]
[-- Type: application/octet-stream, Size: 19644 bytes --]
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: Paul Mackerras @ 2005-11-02 1:03 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1130860444.21212.52.camel@hades.cambridge.redhat.com>
David Woodhouse writes:
> Hm. Not entirely in line with my experience. Can you share the configs
> you used?
Sure, attached (as a .tar.gz). For 32-bit pmac, you currently have to
disable CONFIG_PREP and (I believe) the TAU options. For the 64-bit
configs I basically just used the defconfigs in arch/ppc64/configs.
> 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.
That's probably either the pci quirk that got added to do USB host
controller handoff unconditionally on all platforms, and which touches
the device without doing pci_enable_device or checking whether MMIO is
enabled. A fix has gone into Linus' tree for that.
There was also a bug added to the adbhid.c driver which would cause an
oops when you pressed a key if you had an ADB keyboard (which
powerbooks do). That's also fixed in Linus' tree.
> 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
Thanks, I'll put that in.
Paul.
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: David Gibson @ 2005-11-02 0:06 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1130860444.21212.52.camel@hades.cambridge.redhat.com>
On Tue, Nov 01, 2005 at 03:54:04PM +0000, David Woodhouse wrote:
> 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?
I gather paulus doesn't believe in CONFIG_TAU.
> 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
>
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Re: [PATCH 2/2] MTD: Add initial support for DAVE "PPChameleon" board.
From: Matt Porter @ 2005-11-01 23:30 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: llandre, linuxppc-embedded
In-Reply-To: <20051012154431.C4C53353A4F@atlas.denx.de>
On Wed, Oct 12, 2005 at 05:44:31PM +0200, Wolfgang Denk wrote:
> Hello,
>
> the following patch (against current kernel.org tree) adds MTD
> support for the NOR and NAND flashes on the "PPChameleon" modules /
> eval boards manufactured by DAVE s.r.l.
This should be submitted to the MTD maintainer(s).
-Matt
^ permalink raw reply
* Re: [PATCH 1/2] ppc32: Add initial support for DAVE "PPChameleon" board.
From: Matt Porter @ 2005-11-01 23:29 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: llandre, linuxppc-embedded
In-Reply-To: <20051012153817.D370D353A4F@atlas.denx.de>
On Wed, Oct 12, 2005 at 05:38:17PM +0200, Wolfgang Denk wrote:
> the following patch (against current kernel.org tree) adds suport for
> the "PPChameleon" modules / eval boards manufactured by DAVE s.r.l.
See comments below.
> +config PPChameleonEVB
> + bool "PPChameleonEVB"
> + help
> + This option enables support for the DAVE 405EP evaluation board.
> +
It's unusual to have a mixed case config option. Is there a better
option that makes sense? PP_CHAM_EVB?
> /* DCR defines */
> -#define DCRN_CPMSR_BASE 0x0BA
> -#define DCRN_CPMFR_BASE 0x0B9
> +#define DCRN_CPMSR_BASE 0x0BA
> +#define DCRN_CPMFR_BASE 0x0B9
Please drop these whitespace changes.
> -#define IBM_CPM_GPT 0x80000000 /* GPT interface */
> -#define IBM_CPM_PCI 0x40000000 /* PCI bridge */
> -#define IBM_CPM_UIC 0x00010000 /* Universal Int Controller */
> -#define IBM_CPM_CPU 0x00008000 /* processor core */
> -#define IBM_CPM_EBC 0x00002000 /* EBC controller */
> -#define IBM_CPM_SDRAM0 0x00004000 /* SDRAM memory controller */
> -#define IBM_CPM_GPIO0 0x00001000 /* General Purpose IO */
> -#define IBM_CPM_TMRCLK 0x00000400 /* CPU timers */
> -#define IBM_CPM_PLB 0x00000100 /* PLB bus arbiter */
> -#define IBM_CPM_OPB 0x00000080 /* PLB to OPB bridge */
> -#define IBM_CPM_DMA 0x00000040 /* DMA controller */
> -#define IBM_CPM_IIC0 0x00000010 /* IIC interface */
> -#define IBM_CPM_UART1 0x00000002 /* serial port 0 */
> -#define IBM_CPM_UART0 0x00000001 /* serial port 1 */
> +#define IBM_CPM_GPT 0x80000000 /* GPT interface */
> +#define IBM_CPM_PCI 0x40000000 /* PCI bridge */
> +#define IBM_CPM_UIC 0x00010000 /* Universal Int Controller */
> +#define IBM_CPM_CPU 0x00008000 /* processor core */
> +#define IBM_CPM_EBC 0x00002000 /* EBC controller */
> +#define IBM_CPM_SDRAM0 0x00004000 /* SDRAM memory controller */
> +#define IBM_CPM_GPIO0 0x00001000 /* General Purpose IO */
> +#define IBM_CPM_TMRCLK 0x00000400 /* CPU timers */
> +#define IBM_CPM_PLB 0x00000100 /* PLB bus arbiter */
> +#define IBM_CPM_OPB 0x00000080 /* PLB to OPB bridge */
> +#define IBM_CPM_DMA 0x00000040 /* DMA controller */
> +#define IBM_CPM_IIC0 0x00000010 /* IIC interface */
> +#define IBM_CPM_UART1 0x00000002 /* serial port 0 */
> +#define IBM_CPM_UART0 0x00000001 /* serial port 1 */
Same here, if whitespace chanes are important submit them separately.
> diff --git a/arch/ppc/platforms/4xx/ppchameleon.c b/arch/ppc/platforms/4xx/ppchameleon.c
> new file mode 100644
> --- /dev/null
<snip>
> +#if defined(CONFIG_BIOS_FIXUP)
> +void __init bios_fixup (struct pci_controller *hose, struct pcil0_regs *pcip)
<snip>
You don't use this bios_fixup garbage in this port (at least according
to your defconfig) so just drop it.
As an aside, this stuff is pretty awful and has been since 405 first
came into the tree. If the basic functionality were required, a new
port should simply reprogram the pci host bridge and let the pci
subsystem place the BARs.
-Matt
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Pantelis Antoniou @ 2005-11-01 22:55 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <20051101172524.GA5623@logos.cnet>
On Tuesday 01 November 2005 19:25, Marcelo Tosatti wrote:
> On Sun, Oct 30, 2005 at 11:03:24PM +0300, Pantelis Antoniou wrote:
> > Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
> > address fixes the problem.
>
> Hi Panto,
>
> Its working fine around here. How much of a vanilla 2.6.14 your is?
>
> [root@CAS root]# cat /proc/cpuinfo
> processor : 0
> cpu : 8xx
> clock : 48MHz
> bus clock : 48MHz
> revision : 0.0 (pvr 0050 0000)
> bogomips : 47.82
> [root@CAS root]# uname -a
> Linux CAS 2.6.14 #2 Tue Nov 1 16:20:28 CST 2005 ppc unknown
>
>
Vanila 2.6.14 worked fine too.
It's the mm patches that started coming in later.
Unfortunately the version did not change, so I can't provide it.
Did you used a current git tree?
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-01 17:25 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <200510302203.25390.pantelis.antoniou@gmail.com>
On Sun, Oct 30, 2005 at 11:03:24PM +0300, Pantelis Antoniou wrote:
> Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
> address fixes the problem.
Hi Panto,
Its working fine around here. How much of a vanilla 2.6.14 your is?
[root@CAS root]# cat /proc/cpuinfo
processor : 0
cpu : 8xx
clock : 48MHz
bus clock : 48MHz
revision : 0.0 (pvr 0050 0000)
bogomips : 47.82
[root@CAS root]# uname -a
Linux CAS 2.6.14 #2 Tue Nov 1 16:20:28 CST 2005 ppc unknown
^ permalink raw reply
* Re: Makefile check for older binutils broken?
From: Marcelo Tosatti @ 2005-11-01 16:33 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20051028161054.GB22245@smtp.west.cox.net>
> > Yep, that does the trick. Is it good now?
>
> Er, that's odd. I was using writing parens, not shell parens :) Can
> you test the failure case here by changing dssall to garbage? Also,
> that's not a clean patch, but vs your last one that wasn't valid.
Problem is specific to invocation of "make" inside a (particular) Makefile.
Again, sorry for you wasting your time.
^ permalink raw reply
* RE: AMCC440EP Boot Source
From: Steven Blakeslee @ 2005-11-01 16:43 UTC (permalink / raw)
To: Dick Hollenbeck, linuxppc-dev
> We are looking at the yosemite design but want a CF2 socket=20
> for the OS=20
> image. Can U-Boot reside in the EEPROM accessible via I2C? =20
Are you sure that the 440EP can run code from the EEPROM on the I2C?
The 440EP loads configuration information from the EEPROM on the I2C but
I don't know it can run code.=20
>=20
> This would allow us to remove the flash entirely in favor of=20
> the CF2 flash. If yes, are there any drawbacks to this vs.=20
> keeping a small bit of flash soldered to the board?
I'm pretty sure you need to have flash. If you don't want the onboard
flash you can connect some through the PCI.
^ 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-11-01 16:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, Sven Luther
In-Reply-To: <17255.13444.672360.996441@cargo.ozlabs.ibm.com>
On Tue, Nov 01, 2005 at 08:25:24PM +1100, Paul Mackerras wrote:
> 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.
Okay. TBH, I still have to look at what the MODULE_DEVICE_TABLE does so
it was ignorance + laziness on my part.
> 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.
I'll take a look.
Mark
^ 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
* 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: 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: 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
* 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
* [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
* 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
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