* Kernel 2.6 support for MVME5500?
From: Henry A. Leinhos @ 2005-11-29 20:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
Hi,
Does anyone have any information regarding support for the Motorola
MVME5500 SBC under kernel 2.6.x? Motorola has 2.4.x patches on their
website, but I can't seem to find anything for 2.6.x.
Thanks,
Henry
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2562 bytes --]
^ permalink raw reply
* MPC85xx i2c interface bug
From: dwilson @ 2005-11-29 20:42 UTC (permalink / raw)
To: linuxppc-embedded
We have found a problem in the i2c-mpc.c file (linux 2.4 kernel). The
logic for the i2c transfer termination seems to have been inverted.
The original function is:
/* Perform one i2c_msg transfer. It could be a read, or a write.
* This function assumes that the address byte has been sent
* already, and only handles the message contents */
static int mpc_i2c_xfer_bytes(struct mpc_i2c_private* priv, struct
i2c_msg* pm)
{
volatile struct mpc_i2c *regs = priv->regs;
char *buf = pm->buf;
int len = pm->len;
int i;
int ret = 0;
if(pm->flags & I2C_M_RD) {
/* Change to read mode */
priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
/* If there is only one byte, we need to TXAK now */
if(len == 1)
priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
/* Do a dummy read, to initiate the first read */
priv->read(®s->i2cdr);
}
for(i = 0; i < len; ++i) {
/* If this is a read, read a byte, otherwise, write a byte */
if(pm->flags & I2C_M_RD) {
/* Wait for the previous read to finish */
ret = wait_for_txcomplete(priv);
if (ret)
return ret;
/* If this is the 2nd to last byte, send
* the TXAK signal */
if(i == len - 2) {
priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
}
/* If this is the last byte, send STOP */
if (i == len - 1)
mpc_i2c_stop(priv);
buf[i] = priv->read(®s->i2cdr);
} else {
/* Otherwise, it's a write */
priv->write(®s->i2cdr, buf[i], MPC_I2C_FULLREG);
/* Wait for the transaction to complete */
ret = wait_for_txcomplete(priv);
if(ret)
return ret;
/* Return error if we didn't get the ack */
if((priv->read(®s->i2csr) & MPC_I2CSR_RXAK)) {
printk(KERN_DEBUG "NO ACK!\n");
ret = -EREMOTEIO;
}
}
/* If there was an error, abort */
if(ret)
return ret;
}
return ret;
}
The problem is that the TXAK bit is set incorrectly: it should be set to a
zero when acks are to be sent and then set to a 1 just before reading the
next-to-last byte in the transfer (8555 Processor Reference Manual
(MPC8555ERM rev1), section 11.3.1.3 and also Figure 11-8).
Changes to the above code are thus:
302c302
< priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
---
> priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX | MPC_I2CCR_TXAK);
306c306
< priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
---
> priv->write(®s->i2ccr, MPC_I2CCR_TXAK,
MPC_I2CCR_TXAK);
324c324
< priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
---
> priv->write(®s->i2ccr, MPC_I2CCR_TXAK,
MPC_I2CCR_TXAK);
Thanks,
Dan.
^ permalink raw reply
* [PATCH] powerpc ppc32 clean up available memory models
From: Andy Whitcroft @ 2005-11-29 19:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Andy Whitcroft
In-Reply-To: <438B5523.40903@shadowen.org>
Ok, attempt #2 at cleaning up the memory models for powerpc/ppc32.
Made it very explicit which combinations require FLATMEM and left
the defaults alone for SPARSEMEM. Seems to do what I expect.
Comments.
-apw
=== 8< ===
powerpc: ppc32 clean up available memory models
Clean up the currently available memory models for ppc32 under
the powerpc architecture. We need FLATMEM for ppc32 enable it.
SPARSEMEM is not parameterised for ppc32 so disable that. Take this
opportunity to clean up white space for FLATMEM_ENABLE.
Against 2.6.15-rc3 with Anton's flatmem disable patch.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff -upN reference/arch/powerpc/Kconfig current/arch/powerpc/Kconfig
--- reference/arch/powerpc/Kconfig
+++ current/arch/powerpc/Kconfig
@@ -578,11 +578,12 @@ config ARCH_SELECT_MEMORY_MODEL
depends on PPC64
config ARCH_FLATMEM_ENABLE
- def_bool y
- depends on PPC64 && !NUMA
+ def_bool y
+ depends on (PPC64 && !NUMA) || PPC32
config ARCH_SPARSEMEM_ENABLE
def_bool y
+ depends on PPC64
config ARCH_SPARSEMEM_DEFAULT
def_bool y
^ permalink raw reply
* [PATCH] powerpc ppc32 fix definition of distribute_irqs
From: Andy Whitcroft @ 2005-11-29 19:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Andy Whitcroft
Now that I can attempt to compile powerpc/ppc32 it appears there is
a problem with the definition of distribute_irqs, this patch
seems to fix it for me.
-apw
=== 8< ===
powerpc: ppc32 fix definition of distribute_irqs
When we select ppc32 under the powerpc architecture we get the
error below. This relates to defining distribute_irqs when this
configuratiom option is undefined.
CC arch/powerpc/sysdev/mpic.o
.../arch/powerpc/sysdev/mpic.c: In function `mpic_setup_this_cpu':
.../arch/powerpc/sysdev/mpic.c:788: error: `CONFIG_IRQ_ALL_CPUS'
undeclared (first use in this function)
Against 2.6.15-rc3.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff -upN reference/arch/powerpc/sysdev/mpic.c current/arch/powerpc/sysdev/mpic.c
--- reference/arch/powerpc/sysdev/mpic.c
+++ current/arch/powerpc/sysdev/mpic.c
@@ -45,7 +45,11 @@ static struct mpic *mpic_primary;
static DEFINE_SPINLOCK(mpic_lock);
#ifdef CONFIG_PPC32 /* XXX for now */
-#define distribute_irqs CONFIG_IRQ_ALL_CPUS
+#ifdef CONFIG_IRQ_ALL_CPUS
+#define distribute_irqs (1)
+#else
+#define distribute_irqs (0)
+#endif
#endif
/*
^ permalink raw reply
* [PATCH] Export __flush_icache_range since flush_icache_range is defined as inline
From: Otavio Salvador @ 2005-11-29 17:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc
[-- Attachment #1.1: Type: text/plain, Size: 1718 bytes --]
This change makes MOL work again since it need to use that specific symbol.
Signed-off-by: Otavio Salvador <otavio@debian.org>
---
arch/powerpc/kernel/ppc_ksyms.c | 2 +-
arch/ppc/kernel/ppc_ksyms.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
applies-to: 9253bd3b562d6c59044b6175883724f591697da4
b634f3ccf73ca6502b1dd42f372a6ec6bea15ffb
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index af4d1bc..2647933 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -167,7 +167,7 @@ EXPORT_SYMBOL(giveup_spe);
EXPORT_SYMBOL(__flush_icache_range);
#else
EXPORT_SYMBOL(flush_instruction_cache);
-EXPORT_SYMBOL(flush_icache_range);
+EXPORT_SYMBOL(__flush_icache_range);
EXPORT_SYMBOL(flush_tlb_kernel_range);
EXPORT_SYMBOL(flush_tlb_page);
EXPORT_SYMBOL(_tlbie);
diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c
index 66073f7..bb6a5c6 100644
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -184,7 +184,7 @@ EXPORT_SYMBOL(kernel_thread);
EXPORT_SYMBOL(flush_instruction_cache);
EXPORT_SYMBOL(giveup_fpu);
-EXPORT_SYMBOL(flush_icache_range);
+EXPORT_SYMBOL(__flush_icache_range);
EXPORT_SYMBOL(flush_dcache_range);
EXPORT_SYMBOL(flush_icache_user_range);
EXPORT_SYMBOL(flush_dcache_page);
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
you the whole house."
[-- Attachment #2: Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply related
* Re: immap with 8xx.
From: Dan Malek @ 2005-11-29 18:13 UTC (permalink / raw)
To: ihornberger; +Cc: linuxppc-devel list
In-Reply-To: <1133275187.2664.32.camel@iho.sysgo.com>
On Nov 29, 2005, at 9:39 AM, Ingo Hornberger wrote:
> But it seems that there was some generalization work done, which didn't
> reach the 8xx part. Particularly this means that some parts of
> 'asm/commproc.h' as well as (at least) 'asm/immap_8260.h' built up a
> new
> header 'asm/immap_cpm2.h'.
That's because the cpm2 is used in more parts than just the 82xx,
so we carved up the files to make it more useful.
> Actally I miss a file like 'asm/immap_cpm1.h'.
The 8xx is the only processor to use the CPM1, so just update
the immap or 8xx files to accommodate the differences you may
need. There isn't a similar requirement to create a immap_cpm1.h
file like there was for the CPM2. What kind of updates do you need?
Thanks.
-- Dan
^ permalink raw reply
* USB on MPC8272
From: Nathael PAJANI @ 2005-11-29 17:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi all!
I have to support USB hcd for an Actis board based on a MPC8248
processor. I already have a 2.6.9 linux kernel running fine on it, and
actualy have to use it rather than a newer one.
I'm actualy looking for existing or ongoing jobs.
Mike Rapoport:
When you say "I'm running linux 2.6.12.3 with "custom" USB host driver."
Are you speaking of this one: "http://cpm2usb.sourceforge.net./" or another?
Kumar Gala:
On the thread "MPC8555 USB host support" you're asking:
"Also, are you aware of Freescale's driver for this?"
Where is this support located? (which files or directories)
Thanks.
PS: Thanks a lot for people who helped me when porting linux 2.6.13 to
the Actis board VSBX6560 whith MPC8560 processor. It's finished. (Or at
least, no bug reports yet :)
How to commit a patch to the main kernel tree?
^ permalink raw reply
* Re: [PATCH] 3/3 Generic sys_rt_sigsuspend
From: Daniel Jacobowitz @ 2005-11-29 15:53 UTC (permalink / raw)
To: David Woodhouse
Cc: drepper, linuxppc-dev, Mika Penttilä, akpm, linux-kernel
In-Reply-To: <1133260923.31573.131.camel@baythorne.infradead.org>
On Tue, Nov 29, 2005 at 10:42:03AM +0000, David Woodhouse wrote:
> I believe not. The previous versions would loop until do_signal()
> returned non-zero; i.e. until a signal was actually delivered.
> By returning -ERESTARTNOHAND we achieve the same effect. If there's a
> signal delivered, that gets magically converted to -EINTR, but if
> there's no signal delivered, the syscall gets restarted.
And, crazy coincidence, I think this will fix the recently reported
ptrace attach bug. Right now if you ptrace a process stuck in
sigsuspend, you can't easily force it to return to userspace.
I'll test that if these patches are merged.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Parag Warudkar @ 2005-11-29 16:11 UTC (permalink / raw)
To: Michael Hanselmann; +Cc: linuxppc-dev, debian-powerpc, linux-kernel
In-Reply-To: <20051129075047.GA26460@hansmi.ch>
On Nov 29, 2005, at 2:50 AM, Michael Hanselmann wrote:
> The mouse moves, but slowly. Maybe something isn't correct yet, but it
> works basically.
Yeah, mine works like that too - but sometimes it will go left->right
when you moved the finger
right->left and vice versa.
> I get 256 bytes in each transfer as well, but didn't look at the bytes
> behind 40. Maybe that'll help to make it more responsive.
Nope, if yours works with 80 bytes, it only sends 80. It will still
work with anything > 80 but that's superfluous data.
(E,g, Mine works even with 1024 - anything above 256 seems junk, but
with < 256 it dies with EOVERFLOW )
Right now I have detected that byte # 13 increases when moving finger
along the bottom from left corner to right,
and byte #11 changes when moved from bottom left corner to top left.
Gotta figure out the rest of the movement patterns
along with how many total sensors X and Y are there and how to relate
the data to something to report to the input device!
Hopefully Johannes will have a PowerBook with either of the 0x0214 or
0x0215 touchpads
and we will make some headway!
Parag
^ permalink raw reply
* Re: [PATCH] 3/3 Generic sys_rt_sigsuspend
From: David Woodhouse @ 2005-11-29 16:09 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: drepper, linuxppc-dev, Mika Penttilä, akpm, linux-kernel
In-Reply-To: <20051129155346.GA25431@nevyn.them.org>
On Tue, 2005-11-29 at 10:53 -0500, Daniel Jacobowitz wrote:
> And, crazy coincidence, I think this will fix the recently reported
> ptrace attach bug. Right now if you ptrace a process stuck in
> sigsuspend, you can't easily force it to return to userspace.
> I'll test that if these patches are merged.
That seems to be true. What I get with my patches is...
# strace -p `pidof sigsusptest`
Process 1954 attached - interrupt to quit
rt_sigsuspend([]) = ? ERESTARTNOHAND (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [])
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(4, 64), ...}) = 0
ioctl(1, TCGETS, {B115200 opost isig icanon echo ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3001f000
write(1, "r is -1\n", 8) = 8
munmap(0x3001f000, 4096) = 0
exit_group(8) = ?
Process 1954 detached
... whereas without them I get not only a failure to attach, until
there's a signal, but an unexplained SIGSEGV too...
# strace -p `pidof sigsusptest`
Process 3105 attached - interrupt to quit
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigsuspend([]) = 14
rt_sigsuspend([] <unfinished ...>
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 3105 detached
--
dwmw2
^ permalink raw reply
* RE: Which way to store log in flash on mpc8xx?
From: Fillod Stephane @ 2005-11-29 15:37 UTC (permalink / raw)
To: David Jander; +Cc: linux-mtd, linuxppc-embedded
David Jander wrote:
[..]
>After getting some advice from peoble at mtd-list, I switched to 2.6.14
for=20
>our new developments, and jffs2 seems a lot more stable now. I can only
>recommend you to consider switching. Besides consuming a little more
RAM and=20
>Flash, 2.6.14 is miles ahead in terms of almost anything else, plus
it's a=20
>bit faster on 8xx than 2.4.25!!
Strange. I heard a different song here[1], but haven't checked the fact=20
myself. From what I've seen, mtd/jffs2 is faster on 2.6.x than 2.4.x.
[1] http://www.denx.de/wiki/Know/Linux24vs26
>I have to warn you though, that it still seems not to be as rock-solid
as one=20
>might want for an embedded system: We have a stress test running for a
few=20
>weeks now simulating power-failures during writes to files on jffs2,
and mtd=20
>has some occasional hick-ups. Those hick-ups seem to be far less
serious than=20
>gc.c crashing, but we will have to take them into account in our
application.
>This is the situation: Sometimes the test application crashes giving a=20
>write-error on the mtd device, preceded by an error message from the=20
>mtd-driver (and jffs2, but the problem seems to come from mtd). The
error=20
>message is like "MTD do_write_buffer(): software timeout", which
normally=20
See the patch past my sig. It changes the timeout from couple ms to 1
second.
RTAI & Xenomai users should need it. IMHO, the WANT_SHORT_WTIMEOUT
embraced code should simply go away, or get a decent explanation.
>means a flash programming error, most probably due to sector beeing
worn out,=20
>but I don't think that is the case, since those problems began
appearing=20
>quite early and went away all by them selves. Flash doesn't magically
"fix"=20
itself over time, does it?
>Maybe it's a problem in the AMD flash driver (our device is a Spansion=20
Mirror-bit S29GL256M11)
Regards,
--=20
Stephane
--- drivers/mtd/chips/cfi_cmdset_0002.c 12 Sep 2005 09:27:29 -0000
+++ drivers/mtd/chips/cfi_cmdset_0002.c 29 Nov 2005 15:30:30 -0000
@@ -935,6 +935,12 @@
struct cfi_private *cfi =3D map->fldrv_priv;
unsigned long timeo =3D jiffies + HZ;
/*
+ * Hardware errors should be infrequent,
+ * so a short timeout is of no benefit.
+ * And it just hurts with RTAI.
+ */
+#ifdef WANT_SHORT_WTIMEOUT
+ /*
* We use a 1ms + 1 jiffies generic timeout for writes (most
devices
* have a max write time of a few hundreds usec). However, we
should
* use the maximum timeout value given by the chip at probe time
@@ -944,6 +950,7 @@
* timeout of 0 jiffies if HZ is smaller than 1000.
*/
unsigned long uWriteTimeout =3D ( HZ / 1000 ) + 1;
+#endif
int ret =3D 0;
map_word oldd;
int retry_cnt =3D 0;
@@ -987,8 +994,10 @@
adr, map_bankwidth(map),
chip->word_write_time);
=20
+#ifdef WANT_SHORT_WTIMEOUT
/* See comment above for timeout value. */
timeo =3D jiffies + uWriteTimeout;=20
+#endif
for (;;) {
if (chip->state !=3D FL_WRITING) {
/* Someone's suspended the write. Sleep */
@@ -1189,8 +1198,15 @@
{
struct cfi_private *cfi =3D map->fldrv_priv;
unsigned long timeo =3D jiffies + HZ;
+ /*
+ * Hardware errors should be infrequent,
+ * so a short timeout is of no benefit.
+ * And it just hurts with RTAI.
+ */
+#ifdef WANT_SHORT_WTIMEOUT
/* see comments in do_write_oneword() regarding uWriteTimeo. */
unsigned long uWriteTimeout =3D ( HZ / 1000 ) + 1;
+#endif
int ret =3D -EIO;
unsigned long cmd_adr;
int z, words;
@@ -1248,7 +1264,9 @@
adr, map_bankwidth(map),
chip->word_write_time);
=20
+#ifdef WANT_SHORT_WTIMEOUT
timeo =3D jiffies + uWriteTimeout;=20
+#endif
=09
for (;;) {
if (chip->state !=3D FL_WRITING) {
^ permalink raw reply
* immap with 8xx.
From: Ingo Hornberger @ 2005-11-29 14:39 UTC (permalink / raw)
To: linuxppc-devel list
Hi,
I'm currently porting an old 2.4 kernel driver to 2.6.14. I got some
problems with the immap and idma stuff. The driver is very special and
uses it's own dma handling, because it's too different from the default.
So it strongly depends on the underlying hardware. (In this case 8xx)
With kernel 2.4 it used the headers:
- asm/commproc.h
- asm/8xx_immap.h
But it seems that there was some generalization work done, which didn't
reach the 8xx part. Particularly this means that some parts of
'asm/commproc.h' as well as (at least) 'asm/immap_8260.h' built up a new
header 'asm/immap_cpm2.h'.
Actally I miss a file like 'asm/immap_cpm1.h'.
If it would be the right solution to create a file like this, that's no
problem. I only wanted to make sure that I don't do duplicated work this
time.
regards,
Ingo
^ permalink raw reply
* Re: Which way to store log in flash on mpc8xx?
From: David Jander @ 2005-11-29 14:17 UTC (permalink / raw)
To: David Ho; +Cc: linuxppc-embedded
In-Reply-To: <4dd15d180511281706q388def30r42d3452c392bc92@mail.gmail.com>
Hi,
On Tuesday 29 November 2005 02:06, David Ho wrote:
> Hi, just catching up on this problem as I have another unit that
> showed the same symptom.
> My system looks like this
>
> MPC852T
> 128Mbytes SDRAM
> 64Mbytes Flash
>
> Flash partitions
> 2*1.25Mbytes partitions for Kernel
> 61.5Mbytes for rootfs and applications.
> Remaining 1Mbyte for U-boot, u-boot env and spare.
>
> I get that same problem as well. kernel BUG at gc.c: 139
>
> I have compiled Perl, Openssl, Openssh, etc running NFS so SDRAM is
> definitely not the issue.
I have done almost the same (compiling Perl didn't succeed because of an
out-of memory condition), and never had any other reason to suspect hardware
problems.
After getting some advice from peoble at mtd-list, I switched to 2.6.14 for
our new developments, and jffs2 seems a lot more stable now. I can only
recommend you to consider switching. Besides consuming a little more RAM and
Flash, 2.6.14 is miles ahead in terms of almost anything else, plus it's a
bit faster on 8xx than 2.4.25!!
I have to warn you though, that it still seems not to be as rock-solid as one
might want for an embedded system: We have a stress test running for a few
weeks now simulating power-failures during writes to files on jffs2, and mtd
has some occasional hick-ups. Those hick-ups seem to be far less serious than
gc.c crashing, but we will have to take them into account in our application.
This is the situation: Sometimes the test application crashes giving a
write-error on the mtd device, preceded by an error message from the
mtd-driver (and jffs2, but the problem seems to come from mtd). The error
message is like "MTD do_write_buffer(): software timeout", which normally
means a flash programming error, most probably due to sector beeing worn out,
but I don't think that is the case, since those problems began appearing
quite early and went away all by them selves. Flash doesn't magically "fix"
itself over time, does it?
Maybe it's a problem in the AMD flash driver (our device is a Spansion
Mirror-bit S29GL256M11)
> David: have you gotten any new insights since?
Yes, see above.
Please keep me informed if you get to know something more about the
problem ;-)
If you want more detail about what tests we are doing, and the problems we had
so far, feel free to ask, or read my posts to the MTD list. Right now its
46268 power-cycles and counting.
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* [PATCH] prevent stack corruption in call_prom_ret
From: Olaf Hering @ 2005-11-29 13:04 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Use the correct pointer to clear the memory of the return values,
to prevent stack corruption in the callers stackframe.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/prom_init.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.15-rc3-olh/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.15-rc3-olh.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6.15-rc3-olh/arch/powerpc/kernel/prom_init.c
@@ -265,7 +265,7 @@ static int __init call_prom_ret(const ch
va_end(list);
for (i = 0; i < nret; i++)
- rets[nargs+i] = 0;
+ args.args[nargs+i] = 0;
if (enter_prom(&args, RELOC(prom_entry)) < 0)
return PROM_ERROR;
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* error when compiling glibc on cygwin
From: Gao Bismar @ 2005-11-29 11:31 UTC (permalink / raw)
To: linuxppc-embedded
I wanna complier a MPC860 crosstool on cygwin, and I use crosstool-0.38,but
hit on error :
powerpc-860-linux-gnu-gcc -nostdlib -nostartfiles -o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog
-Wl,-dynamic-linker=/lib/ld.so.1
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/csu/crt1.o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/csu/crti.o
`powerpc-860-linux-gnu-gcc --print-file-name=crtbegin.o`
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog.o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_charmap.o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap.o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap-dir.o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/linereader.o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/dummy-repertoire.o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/simple-hash.o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/xstrdup.o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/xmalloc.o
-Wl,-rpath-link=/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc:/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/math:/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/elf:/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/dlfcn:/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/nss:/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/nis:/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/rt:/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/resolv:/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/crypt:/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/linuxthreads
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc_nonshared.a
-lgcc `powerpc-860-linux-gnu-gcc --print-file-name=crtend.o`
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/csu/crtn.o
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog.o(.text+0x424):
In function `main':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog.o(.text+0x498):
In function `main':: undefined reference to `open'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog.o(.text+0x4f8):
In function `main':: undefined reference to `__fxstat'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog.o(.text+0x530):
In function `main':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog.o(.text+0x5bc):
In function `main':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog.o(.text+0xb08):
In function `process_fd':: undefined reference to `read'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog.o(.text+0xbbc):
In function `process_fd':: undefined reference to `read'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog.o(.text+0x1044):
In function `print_known_names':: undefined reference to `isatty'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_charmap.o(.text+0x108):
In function `charmap_conversion':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_charmap.o(.text+0x170):
In function `charmap_conversion':: undefined reference to `open'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_charmap.o(.text+0x1c8):
In function `charmap_conversion':: undefined reference to `__fxstat'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_charmap.o(.text+0x200):
In function `charmap_conversion':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_charmap.o(.text+0x288):
In function `charmap_conversion':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_charmap.o(.text+0xa78):
In function `process_fd':: undefined reference to `read'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_charmap.o(.text+0xb2c):
In function `process_fd':: undefined reference to `read'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap-dir.o(.text+0x254):
In function `charmap_readdir':: undefined reference to `__xstat'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap-dir.o(.text+0x388):
In function `fopen_uncompressed':: undefined reference to `open'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap-dir.o(.text+0x3a0):
In function `fopen_uncompressed':: undefined reference to `__fxstat'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap-dir.o(.text+0x3c8):
In function `fopen_uncompressed':: undefined reference to `pipe'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap-dir.o(.text+0x4b0):
In function `fopen_uncompressed':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap-dir.o(.text+0x4b8):
In function `fopen_uncompressed':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap-dir.o(.text+0x4dc):
In function `fopen_uncompressed':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap-dir.o(.text+0x4e4):
In function `fopen_uncompressed':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/charmap-dir.o(.text+0x4ec):
In function `fopen_uncompressed':: undefined reference to `close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__dup'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `utime'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__libc_fcntl'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__write'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__getcwd'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__dup2'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__read'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__unlink'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__open'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__libc_read'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__xstat64'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__lxstat'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__chmod'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__isatty'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__statfs'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__chdir'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__readlink'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__mkdir'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__poll'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__statvfs64'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__pipe'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__libc_open'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__chown'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__xmknod'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__lseek'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `dup'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `atexit'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__lxstat64'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__ttyname_r'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__libc_lseek'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__rmdir'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__fstatfs'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__close'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__fxstat64'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__libc_write'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__fcntl'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__access'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__open64'
/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/libc.so.6:
undefined reference to `__fstatvfs64'
collect2: ld returned 1 exit status
make[2]: ***
[/home/crosstool-0.38/build/powerpc-860-linux-gnu/gcc-2.95.3-glibc-2.2.3/build-glibc/iconv/iconv_prog]
Error 1
make[2]: Leaving directory `/home/src/glibc-2.2.3/iconv'
make[1]: *** [iconv/others] Error 2
make[1]: Leaving directory `/home/src/glibc-2.2.3'
make: *** [all] Error 2
I use google to search the solution but faild. Many people hit on this
error, but none solution was found.
Any help would be very much appreciated.
Thaks
abutter
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* spi on mpc82xx
From: Thomas Arvanitis @ 2005-11-29 11:14 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I was wondering what is the status for supporting spi devices with 2.6
on an mpc82xx device (I use an mpc8275). I checked and the kernel from
kernel.org does not include anything. Is there an spi bus
infrastructure (like i2c) coming any time soon, where one can add
support for specific chips, and then write a driver on top of that?
Or a plan for these things?
I found a patch for something like that, by Grant Likely, but I don't
know whether I should go that way.
I want to write a driver for controlling the micrel ks8995 ethernet
switch through spi. Should I just go for a self contained driver?
Thanks for you help,
-Thomas.
^ permalink raw reply
* Re: [PATCH] 3/3 Generic sys_rt_sigsuspend
From: David Woodhouse @ 2005-11-29 10:42 UTC (permalink / raw)
To: Mika Penttilä; +Cc: akpm, linuxppc-dev, linux-kernel, drepper
In-Reply-To: <438BE48B.9060908@kolumbus.fi>
On Tue, 2005-11-29 at 07:18 +0200, Mika Penttilä wrote:
> You are not setting saved_sigmask here.
Oops; well spotted. Thanks.
> And shouldn't it return -EINTR?
I believe not. The previous versions would loop until do_signal()
returned non-zero; i.e. until a signal was actually delivered.
By returning -ERESTARTNOHAND we achieve the same effect. If there's a
signal delivered, that gets magically converted to -EINTR, but if
there's no signal delivered, the syscall gets restarted.
diff -u b/kernel/compat.c b/kernel/compat.c
--- b/kernel/compat.c
+++ b/kernel/compat.c
@@ -859,7 +859,7 @@
#ifdef __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND
long compat_sys_rt_sigsuspend(compat_sigset_t __user *unewset, compat_size_t sigsetsize)
{
- sigset_t saveset, newset;
+ sigset_t newset;
compat_sigset_t newset32;
/* XXX: Don't preclude handling different sized sigset_t's. */
@@ -872,7 +872,7 @@
sigdelsetmask(&newset, sigmask(SIGKILL)|sigmask(SIGSTOP));
spin_lock_irq(¤t->sighand->siglock);
- saveset = current->blocked;
+ current->saved_sigmask = current->blocked;
current->blocked = newset;
recalc_sigpending();
spin_unlock_irq(¤t->sighand->siglock);
diff -u b/kernel/signal.c b/kernel/signal.c
--- b/kernel/signal.c
+++ b/kernel/signal.c
@@ -2626,7 +2626,7 @@
#ifdef __ARCH_WANT_SYS_RT_SIGSUSPEND
long sys_rt_sigsuspend(sigset_t __user *unewset, size_t sigsetsize)
{
- sigset_t saveset, newset;
+ sigset_t newset;
/* XXX: Don't preclude handling different sized sigset_t's. */
if (sigsetsize != sizeof(sigset_t))
@@ -2637,7 +2637,7 @@
sigdelsetmask(&newset, sigmask(SIGKILL)|sigmask(SIGSTOP));
spin_lock_irq(¤t->sighand->siglock);
- saveset = current->blocked;
+ current->saved_sigmask = current->blocked;
current->blocked = newset;
recalc_sigpending();
spin_unlock_irq(¤t->sighand->siglock);
--
dwmw2
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Johannes Berg @ 2005-11-29 10:38 UTC (permalink / raw)
To: Michael Hanselmann
Cc: linuxppc-dev, debian-powerpc, linux-kernel, Parag Warudkar
In-Reply-To: <20051129075047.GA26460@hansmi.ch>
Michael Hanselmann wrote:
>> I haven't looked at your changes completely yet but are you saying it
>> works? Meaning mouse moves properly?
>
> The mouse moves, but slowly. Maybe something isn't correct yet, but it
> works basically.
All this sounds almost like your touchpad is much more similar to the old
one. I'll most likely have access to a new powerbook within the next two
weeks, so I'll be able to take a look.
johannes
^ permalink raw reply
* Re: [PATCH] ppc32: Adds MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet
From: Vitaly Bordug @ 2005-11-29 10:25 UTC (permalink / raw)
To: ihornberger; +Cc: linuxppc-embedded
In-Reply-To: <1133258862.2664.13.camel@iho.sysgo.com>
Ingo Hornberger wrote:
> Hi Vitaly,
>
> OK, I don't really see the advantage of removing the identification
> stuff, but perhaps I'm missing something. Was there any discussion in
> the past that I've skipped while reading through the archive?
>
> Because I found the identifcation code really nice. The only problem was
> that my 8xx didn't support the SVR register.
>
There was a number of discussions in this regard, which result finally that there no method to identify 8xx board
uniquely just using board registers. Hence, we are making identification by board name; the names are presented in syslib/mpc8xx_sys.c.
You can see example in this patch.
> regards,
> Ingo
>
> On Mon, 2005-11-28 at 20:00 +0300, Vitaly Bordug wrote:
>> Added proper ppc_sys identification and fs_platform_info's for MPC 885ADS, 866ADS and
>> 8272ADS. Assuming setbitsXX/clrbitsXX patch is applied.
>>
>>
>> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
>>
>> ---
>> Sincerely,
>> Vitaly
>>
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] ppc32: Adds MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet
From: Ingo Hornberger @ 2005-11-29 10:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <438B379B.6090904@ru.mvista.com>
Hi Vitaly,
OK, I don't really see the advantage of removing the identification
stuff, but perhaps I'm missing something. Was there any discussion in
the past that I've skipped while reading through the archive?
Because I found the identifcation code really nice. The only problem was
that my 8xx didn't support the SVR register.
regards,
Ingo
On Mon, 2005-11-28 at 20:00 +0300, Vitaly Bordug wrote:
> Added proper ppc_sys identification and fs_platform_info's for MPC 885ADS, 866ADS and
> 8272ADS. Assuming setbitsXX/clrbitsXX patch is applied.
>
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
>
> ---
> Sincerely,
> Vitaly
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: Problem running kernel 2.6.14 (DENX) on MPC866
From: Gil Madar @ 2005-11-29 8:41 UTC (permalink / raw)
To: 'Wolfgang Denk', gil-ad; +Cc: linuxppc-embedded
Thanks for your reply Wolfgang!
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Tuesday, November 29, 2005 10:09 AM
>
> I load linux from u-boot, and manage to go all the way until the
call to cpu_idle() from rest_init().
> The system claims mounts a root file system over NFS. Sniffer logs
and host logs support this claim.
> If I do a while ( 1 ) printk( whatever ), just before cpu_idle(),
the system continues to run.
> If I let it call cpu_idle(), the system hangs.
For 8xx you could / should use the kernel.org tree. We don't use
2.6
on 8xx yet.
I will try that.
> U-Boot 1.1.3 (Nov 22 2005 - 00:26:43)
>
> CPU: unknown MPC86x (0x08010004) at 133 MHz: 16 kB I-Cache 8 kB
D-Cache FEC present
> *** Warning: CPU Core has Silicon Bugs -- Check the
Errata ***
You should fix this.
OK.
> Monitor Command Prompt:>setenv gatewayip 10.0.0.138;setenv ethaddr
00:01:02:03:04:05; setenv console ttyCPM0,38400n8; setenv
You use an illegal MAC address; please read the FAQ, especially
http://www.denx.de/wiki/view/DULG/EthernetDoesNotWork and
http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress
The ethernet address is ok. not mine, but legal ;-) I checked at
standards.ieee.org:
00-01-02 (hex) 3COM CORPORATION
000102 (base 16) 3COM CORPORATION
5400 Bayfront Plaza - MS: 4220
Santa Clara CA 95052
UNITED STATES
Thanks for your time,
Gil
^ permalink raw reply
* Re: SPI and USB on MPC8272
From: Mike Rapoport @ 2005-11-29 8:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded list
In-Reply-To: <20051129081052.77DA1353F54@atlas.denx.de>
Wolfgang Denk wrote:
>In message <438BF854.1040408@compulab.co.il> you wrote:
>
>
>>I'm running linux 2.6.12.3 with "custom" USB host driver. I tried to add
>>
>>
>...
>
>
>><http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=summary>
>>
>>
>
>What has our 2.4.25 source tree to do with your 2.6.12.3 kernel?
>
>
Dear Wolfgang,
I've used the cpm_spi.[ch] from your 2.4.25 tree with my 2.6.12.3
kernel. As for the URL it sneaked it by mistake.
>Best regards,
>
>Wolfgang Denk
>
>
>
--
Sincerely yours,
Mike Rapoport
-----------------------------------------------------------------
CompuLab Ltd.
MALAT Bldg., Technion, Haifa, ISRAEL
Mailing address: P.O. Box 66, Nesher 36770, ISRAEL
Tel: 972-4-8290146
Fax: 972-4-8325251
Web: http://www.compulab.co.il
^ permalink raw reply
* Re: SPI and USB on MPC8272
From: Wolfgang Denk @ 2005-11-29 8:10 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded list
In-Reply-To: <438BF854.1040408@compulab.co.il>
In message <438BF854.1040408@compulab.co.il> you wrote:
>
> I'm running linux 2.6.12.3 with "custom" USB host driver. I tried to add
...
> <http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=summary>
What has our 2.4.25 source tree to do with your 2.6.12.3 kernel?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Lispers are among the best grads of the Sweep-It-Under-Someone-
Else's-Carpet School of Simulated Simplicity. [Was that sufficiently
incendiary? :-)] - Larry Wall in <1992Jan10.201804.11926@netlabs.com
^ permalink raw reply
* Re: Problem running kernel 2.6.14 (DENX) on MPC866
From: Wolfgang Denk @ 2005-11-29 8:08 UTC (permalink / raw)
To: gil-ad; +Cc: linuxppc-embedded
In-Reply-To: <200511290147.05220.gil-ad@myrealbox.com>
In message <200511290147.05220.gil-ad@myrealbox.com> you wrote:
>
> I load linux from u-boot, and manage to go all the way until the call to cpu_idle() from rest_init().
> The system claims mounts a root file system over NFS. Sniffer logs and host logs support this claim.
> If I do a while ( 1 ) printk( whatever ), just before cpu_idle(), the system continues to run.
> If I let it call cpu_idle(), the system hangs.
For 8xx you could / should use the kernel.org tree. We don't use 2.6
on 8xx yet.
> U-Boot 1.1.3 (Nov 22 2005 - 00:26:43)
>
> CPU: unknown MPC86x (0x08010004) at 133 MHz: 16 kB I-Cache 8 kB D-Cache FEC present
> *** Warning: CPU Core has Silicon Bugs -- Check the Errata ***
You should fix this.
> Monitor Command Prompt:>setenv gatewayip 10.0.0.138;setenv ethaddr 00:01:02:03:04:05; setenv console ttyCPM0,38400n8; setenv
You use an illegal MAC address; please read the FAQ, especially
http://www.denx.de/wiki/view/DULG/EthernetDoesNotWork and
http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
How many seconds are there in a year? If I tell you there are 3.155 x
10^7, you won't even try to remember it. On the other hand, who could
forget that, to within half a percent, pi seconds is a nanocentury.
-- Tom Duff, Bell Labs
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Michael Hanselmann @ 2005-11-29 7:50 UTC (permalink / raw)
To: Parag Warudkar; +Cc: linuxppc-dev, debian-powerpc, linux-kernel
In-Reply-To: <68465DDA-053F-4A85-9204-549E830B2269@comcast.net>
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
Hello Parag
On Tue, Nov 29, 2005 at 01:11:00AM -0500, Parag Warudkar wrote:
> Is yours the 15" model or the 17"? Mine is 15" and the product id is
> 0x0214.
It's the 15" one.
> I haven't looked at your changes completely yet but are you saying it
> works? Meaning mouse moves properly?
The mouse moves, but slowly. Maybe something isn't correct yet, but it
works basically.
> Also I find it strange that your model requires 80 bytes ATP_DATASIZE
> - mine isn't happy at all with anything less than 256. The less number
> of sensors you defined is again a puzzle.
That are points I need to investigate further.
> If the format of the data is same (which looks like it is with your
> model) then yes, but in my case the data arrives is 64 byte blocks -
> there are 4 of them in one transfer, each a reading on it's own.
I get 256 bytes in each transfer as well, but didn't look at the bytes
behind 40. Maybe that'll help to make it more responsive.
> Hmm. More confusion.
Oh yes. Why does Apple ship the basically same PowerBook with different
Touchpads?
Greets,
Michael
--
Gentoo Linux Developer using m0n0wall | http://hansmi.ch/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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