* Re: [RFC] Add __initbss section
From: Franck Bui-Huu @ 2007-11-04 8:29 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, Geert Uytterhoeven, linux-mips
In-Reply-To: <Pine.LNX.4.64N.0710191239490.13279@blysk.ds.pg.gda.pl>
Maciej W. Rozycki wrote:
> On Thu, 18 Oct 2007, Franck Bui-Huu wrote:
>> After spending some fun time trying several different configurations
>> with gcc and ld, I noticed that gcc makes a section with @nobits
>> attribute if the section name starts with .bss.*
>
> Exactly how GCC sets section flags is mostly determined by
> default_section_type_flags() in gcc/varasm.c; some flags are set elsewhere
> too. This is with HEAD of GCC.
>
It seems that we can rely on this behaviour. I looked at gcc 4.1.2/3.2
sources and they made a section part of .bss if the section name starts
with ".bss.".
>> Another test I did is to put .init.bss (not .bss.init) section right
>> before .bss section in order to have only one segment to load. And it
>> makes magically ld do the right thing. I must admit that I don't
>> understand why, and the lack of documentation doesn't help...
>
> Hmm, isn't what `info ld' says enough?
Hmm, I'm must be blind but I missed that each time I read it. Could
you point out the section number please ?
OK, I think the best thing to do now is to respin the patchset and
submit it linux arch mailing list.
thanks,
Franck
^ permalink raw reply
* "Bad eraseblock"-problem with au1550nd-NAND-driver after kernel update to 2.6.23.1
From: Thorsten Schulz @ 2007-11-04 9:10 UTC (permalink / raw)
To: linux-mips
Hi,
I am fiddeling around with an Au1550-System (Lippert CoolMoteMaster).
After I updated the Kernel from 2.6.17.7 to 2.6.23.1 the flash driver complaints about Bad eraseblocks at kernel start:
[17179570.224000] NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit)
[17179570.232000] Scanning device for bad blocks
[17179570.236000] Bad eraseblock 0 at 0x00000000
[17179570.240000] Bad eraseblock 1 at 0x00020000
[17179570.248000] Bad eraseblock 2 at 0x00040000
[..]
[17179579.748000] Bad eraseblock 2046 at 0x0ffc0000
[17179579.752000] Bad eraseblock 2047 at 0x0ffe0000
[17179579.756000] Creating 1 MTD partitions on "NAND 256MiB 3,3V 8-bit":
[17179579.760000] 0x00000000-0x10000000 : "NAND FS 0"
[17179579.772000] au1xxx-ohci au1xxx-ohci.0: Au1xxx OHCI
[..]
I get the same output from the .17.7. kernel apart from the 'Bad'-messages. The size seems correct, as I should get one 256MB-flash-device. I did use the patch from Lippert to set their platform data, which was intended for 2.6.17.7. With small changes it also succeeds on 2.6.23.1 but this doesn't mean that it's correct ;)
The 2.6.17.7 kernel still runs fine with that flash.
I am quite new to kernel hacking and after some cause searching I'm still lost. Were there any changes in the necessary configuration / platform setup that I am missing? Any ideas / hints what I can look for? Any common mistakes?
ciao,
Thorsten
^ permalink raw reply
* Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent
From: Thomas Bogendoerfer @ 2007-11-04 10:05 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071104003338.GB28717@linux-mips.org>
On Sun, Nov 04, 2007 at 12:33:38AM +0000, Ralf Baechle wrote:
> On Fri, Nov 02, 2007 at 11:08:19PM +0100, Thomas Bogendoerfer wrote:
>
> > On Fri, Nov 02, 2007 at 12:20:01PM +0000, Ralf Baechle wrote:
> > > One thing I'm still wondering about, does the kernel actually go tickless
> > > for you?
> >
> > a kernel with CONFIG_NO_HZ boots and acts normal. But it looks like
> > the PIT is still ticking at the selected 100HZ...
>
> I think this happens because the R4030 clockevent device has a rather
r4030 is of course disabled in my test.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Get stuck in wake_up_process(rq->migration_thread);
From: KokHow.Teh @ 2007-11-04 11:26 UTC (permalink / raw)
To: linux-mips
Hi;
I have a linux-2.6.20 kernel configured with CONFIG_MIPS_MT_SMP
(SMVPE) running on a MIPS34KC processor emulation platform. Everything
goes fine until the scheduler gets stuck in trying to wake up the
migration thread. I configured the kernel with max_cache_size=2097152,
having no idea of what the variable is all about. Putting debug messages
in kernel/sched.c tells me that the the migration_thread() routine has
gone to sleep calling schedul() function and set_cpus_allowed() function
gets stuck in wake_up_process(rq->migration_thread);
Any insight is appreciated.
Regards.
KH
^ permalink raw reply
* Get stuck in wake_up_process(rq->migration_thread);
From: KokHow.Teh @ 2007-11-04 11:26 UTC (permalink / raw)
To: linux-mips
Hi;
I have a linux-2.6.20 kernel configured with CONFIG_MIPS_MT_SMP
(SMVPE) running on a MIPS34KC processor emulation platform. Everything
goes fine until the scheduler gets stuck in trying to wake up the
migration thread. I configured the kernel with max_cache_size=2097152,
having no idea of what the variable is all about. Putting debug messages
in kernel/sched.c tells me that the the migration_thread() routine has
gone to sleep calling schedul() function and set_cpus_allowed() function
gets stuck in wake_up_process(rq->migration_thread);
Any insight is appreciated.
Regards.
KH
^ permalink raw reply
* [PATCH] iounmap if in vr41xx_pciu_init() pci clock is over 33MHz
From: Roel Kluin @ 2007-11-04 12:00 UTC (permalink / raw)
To: linux-mips
iounmap if pci clock is over 33MHz
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/mips/pci/pci-vr41xx.c b/arch/mips/pci/pci-vr41xx.c
index 240df9e..33c4f68 100644
--- a/arch/mips/pci/pci-vr41xx.c
+++ b/arch/mips/pci/pci-vr41xx.c
@@ -154,6 +154,7 @@ static int __init vr41xx_pciu_init(void)
pciu_write(PCICLKSELREG, QUARTER_VTCLOCK);
else {
printk(KERN_ERR "PCI Clock is over 33MHz.\n");
+ iounmap(pciu_base);
return -EINVAL;
}
^ permalink raw reply related
* Re: [PATCH] Kill __bzero()
From: Atsushi Nemoto @ 2007-11-04 15:42 UTC (permalink / raw)
To: fbuihuu; +Cc: ralf, linux-mips
In-Reply-To: <472D8058.5080209@gmail.com>
On Sun, 04 Nov 2007 09:18:32 +0100, Franck Bui-Huu <fbuihuu@gmail.com> wrote:
> 2/ For the caller, it makes no difference to call memset instead
> since it has to setup the second parameter of __bzero to 0.
__bzero() does not clobber v0 but memset() does. I don't know if gcc
does some magical thing to protect v0, but it would be safer to add v0
explicitly to clobber-list of __clear_user().
---
Atsushi Nemoto
^ permalink raw reply
* Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Thiemo Seufer @ 2007-11-04 17:47 UTC (permalink / raw)
To: Franck Bui-Huu
Cc: Nigel Stephens, Maciej W. Rozycki, Ralf Baechle, linux-mips
In-Reply-To: <472D8110.2080506@gmail.com>
Franck Bui-Huu wrote:
> Nigel Stephens wrote:
> > Aha, that probably explains it. Franck is using the "SDE for Linux
> > v6.05" toolchain, and in that version of GCC -march=mips32r2 implies a
>
> [snip]
>
> BTW, are there any other toolchains out there that support smartmips ASE ?
Latest GCC upstream supports it (in SVN since 2007-07-05).
Thiemo
^ permalink raw reply
* Re: Get stuck in wake_up_process(rq->migration_thread);
From: Kevin D. Kissell @ 2007-11-04 18:59 UTC (permalink / raw)
To: KokHow.Teh, linux-mips
In-Reply-To: <31E09F73562D7A4D82119D7F6C17298602B11510@sinse303.ap.infineon.com>
Your description isn't much to go on, but the first thing I'd look at
in such a situation would be the state of the Cause and Status registers
on the two VPEs. Cross-VPE scheduling interrupts on the standard
emulation platform, which lacks hardware support for cross-VPE
interrupts, sends IPIs by reaching across using MTTR instructions
and setting a software interrupt bit on the other VPE. Other uses
of the same software interrupt (SW1 by default), or manipulations
in other kernel code that might clear its IM bit in the Status register,
could cause that mechanism to break down and cease processing
interprocessor interrupts. It's a common failure mode if one botches
a mod to SMTC, and I've seen it on an SMVP port as well.
Kevin K.
----- Original Message -----
From: <KokHow.Teh@infineon.com>
To: <linux-mips@linux-mips.org>
Sent: Sunday, November 04, 2007 3:26 AM
Subject: Get stuck in wake_up_process(rq->migration_thread);
> Hi;
> I have a linux-2.6.20 kernel configured with CONFIG_MIPS_MT_SMP
> (SMVPE) running on a MIPS34KC processor emulation platform. Everything
> goes fine until the scheduler gets stuck in trying to wake up the
> migration thread. I configured the kernel with max_cache_size=2097152,
> having no idea of what the variable is all about. Putting debug messages
> in kernel/sched.c tells me that the the migration_thread() routine has
> gone to sleep calling schedul() function and set_cpus_allowed() function
> gets stuck in wake_up_process(rq->migration_thread);
> Any insight is appreciated.
>
> Regards.
> KH
>
>
^ permalink raw reply
* Re: Get stuck in wake_up_process(rq->migration_thread);
From: Kevin D. Kissell @ 2007-11-04 18:59 UTC (permalink / raw)
To: KokHow.Teh, linux-mips
In-Reply-To: <31E09F73562D7A4D82119D7F6C17298602B11510@sinse303.ap.infineon.com>
Your description isn't much to go on, but the first thing I'd look at
in such a situation would be the state of the Cause and Status registers
on the two VPEs. Cross-VPE scheduling interrupts on the standard
emulation platform, which lacks hardware support for cross-VPE
interrupts, sends IPIs by reaching across using MTTR instructions
and setting a software interrupt bit on the other VPE. Other uses
of the same software interrupt (SW1 by default), or manipulations
in other kernel code that might clear its IM bit in the Status register,
could cause that mechanism to break down and cease processing
interprocessor interrupts. It's a common failure mode if one botches
a mod to SMTC, and I've seen it on an SMVP port as well.
Kevin K.
----- Original Message -----
From: <KokHow.Teh@infineon.com>
To: <linux-mips@linux-mips.org>
Sent: Sunday, November 04, 2007 3:26 AM
Subject: Get stuck in wake_up_process(rq->migration_thread);
> Hi;
> I have a linux-2.6.20 kernel configured with CONFIG_MIPS_MT_SMP
> (SMVPE) running on a MIPS34KC processor emulation platform. Everything
> goes fine until the scheduler gets stuck in trying to wake up the
> migration thread. I configured the kernel with max_cache_size=2097152,
> having no idea of what the variable is all about. Putting debug messages
> in kernel/sched.c tells me that the the migration_thread() routine has
> gone to sleep calling schedul() function and set_cpus_allowed() function
> gets stuck in wake_up_process(rq->migration_thread);
> Any insight is appreciated.
>
> Regards.
> KH
>
>
^ permalink raw reply
* Re: [PATCH] Kill __bzero()
From: Franck Bui-Huu @ 2007-11-04 20:02 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: ralf, linux-mips
In-Reply-To: <20071105.004208.74752504.anemo@mba.ocn.ne.jp>
Atsushi Nemoto wrote:
> On Sun, 04 Nov 2007 09:18:32 +0100, Franck Bui-Huu <fbuihuu@gmail.com> wrote:
>> 2/ For the caller, it makes no difference to call memset instead
>> since it has to setup the second parameter of __bzero to 0.
>
> __bzero() does not clobber v0 but memset() does. I don't know if gcc
> does some magical thing to protect v0, but it would be safer to add v0
> explicitly to clobber-list of __clear_user().
>
good catch ! I'll do it.
thanks
Franck
^ permalink raw reply
* [PATCH] Kill __bzero() [take #2]
From: Franck Bui-Huu @ 2007-11-04 20:13 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Atsushi Nemoto, linux-mips
This patch removes this function because:
1/ Its unconventional prototype is error prone: its prototype is
the same as memset one but was documented by mips_ksym.c like the
following:
extern void *__bzero(void *__s, size_t __count);
2/ For the caller, it makes no difference to call memset instead
since it has to setup the second parameter of __bzero to 0.
3/ It's not part of the Linux user access API, so no module can use
it.
4/ It needs to be exported with EXPORT_SYMBOL and therefore consumes
some extra bytes.
5/ It has only one user.
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
---
This take includes Atsushi's comment.
Franck
arch/mips/kernel/mips_ksyms.c | 2 --
arch/mips/lib/csum_partial.S | 2 +-
arch/mips/lib/memcpy.S | 2 +-
arch/mips/lib/memset.S | 4 +---
include/asm-mips/uaccess.h | 4 ++--
5 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c
index 225755d..6da9fa8 100644
--- a/arch/mips/kernel/mips_ksyms.c
+++ b/arch/mips/kernel/mips_ksyms.c
@@ -14,7 +14,6 @@
#include <asm/pgtable.h>
#include <asm/uaccess.h>
-extern void *__bzero(void *__s, size_t __count);
extern long __strncpy_from_user_nocheck_asm(char *__to,
const char *__from, long __len);
extern long __strncpy_from_user_asm(char *__to, const char *__from,
@@ -38,7 +37,6 @@ EXPORT_SYMBOL(kernel_thread);
*/
EXPORT_SYMBOL(__copy_user);
EXPORT_SYMBOL(__copy_user_inatomic);
-EXPORT_SYMBOL(__bzero);
EXPORT_SYMBOL(__strncpy_from_user_nocheck_asm);
EXPORT_SYMBOL(__strncpy_from_user_asm);
EXPORT_SYMBOL(__strlen_user_nocheck_asm);
diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S
index c0a77fe..8d3fa1e 100644
--- a/arch/mips/lib/csum_partial.S
+++ b/arch/mips/lib/csum_partial.S
@@ -694,7 +694,7 @@ l_exc:
ADD dst, t0 # compute start address in a1
SUB dst, src
/*
- * Clear len bytes starting at dst. Can't call __bzero because it
+ * Clear len bytes starting at dst. Can't call memset because it
* might modify len. An inefficient loop for these rare times...
*/
beqz len, done
diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S
index a526c62..425f2c3 100644
--- a/arch/mips/lib/memcpy.S
+++ b/arch/mips/lib/memcpy.S
@@ -443,7 +443,7 @@ l_exc:
ADD dst, t0 # compute start address in a1
SUB dst, src
/*
- * Clear len bytes starting at dst. Can't call __bzero because it
+ * Clear len bytes starting at dst. Can't call memset because it
* might modify len. An inefficient loop for these rare times...
*/
beqz len, done
diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S
index 3f8b8b3..a13248b 100644
--- a/arch/mips/lib/memset.S
+++ b/arch/mips/lib/memset.S
@@ -46,7 +46,7 @@
.endm
/*
- * memset(void *s, int c, size_t n)
+ * void *memset(void *s, int c, size_t n)
*
* a0: start of area to clear
* a1: char to fill with
@@ -68,8 +68,6 @@ LEAF(memset)
#endif
or a1, t1
1:
-
-FEXPORT(__bzero)
sltiu t0, a2, LONGSIZE /* very small region? */
bnez t0, small_memset
andi t0, a0, LONGMASK /* aligned? */
diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h
index c30c718..35c5fad 100644
--- a/include/asm-mips/uaccess.h
+++ b/include/asm-mips/uaccess.h
@@ -643,11 +643,11 @@ __clear_user(void __user *addr, __kernel_size_t size)
"move\t$4, %1\n\t"
"move\t$5, $0\n\t"
"move\t$6, %2\n\t"
- __MODULE_JAL(__bzero)
+ __MODULE_JAL(memset)
"move\t%0, $6"
: "=r" (res)
: "r" (addr), "r" (size)
- : "$4", "$5", "$6", __UA_t0, __UA_t1, "$31");
+ : "$2", "$4", "$5", "$6", __UA_t0, __UA_t1, "$31");
return res;
}
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Franck Bui-Huu @ 2007-11-04 20:19 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: Nigel Stephens, Maciej W. Rozycki, Ralf Baechle, linux-mips
In-Reply-To: <20071104174710.GA9363@networkno.de>
Thiemo Seufer wrote:
>
> Latest GCC upstream supports it (in SVN since 2007-07-05).
>
Good news although gcc 4.3 release is planed for end of January.
Is SDE gcc going to be obsolete after this release ?
Franck
^ permalink raw reply
* Re: [PATCH] iounmap if in vr41xx_pciu_init() pci clock is over 33MHz
From: Yoichi Yuasa @ 2007-11-04 22:27 UTC (permalink / raw)
To: Roel Kluin; +Cc: yoichi_yuasa, linux-mips
In-Reply-To: <472DB446.3020804@tiscali.nl>
On Sun, 04 Nov 2007 13:00:06 +0100
Roel Kluin <12o3l@tiscali.nl> wrote:
> iounmap if pci clock is over 33MHz
>
> Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Acked-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
> ---
> diff --git a/arch/mips/pci/pci-vr41xx.c b/arch/mips/pci/pci-vr41xx.c
> index 240df9e..33c4f68 100644
> --- a/arch/mips/pci/pci-vr41xx.c
> +++ b/arch/mips/pci/pci-vr41xx.c
> @@ -154,6 +154,7 @@ static int __init vr41xx_pciu_init(void)
> pciu_write(PCICLKSELREG, QUARTER_VTCLOCK);
> else {
> printk(KERN_ERR "PCI Clock is over 33MHz.\n");
> + iounmap(pciu_base);
> return -EINVAL;
> }
>
>
>
^ permalink raw reply
* Re: NPTL support
From: veerasena reddy @ 2007-11-05 10:01 UTC (permalink / raw)
To: Markus Gothe; +Cc: uclibc, linux-mips, linux-kernel.org, buildroot
Hi Markus,
thanks for the information.
i checked out uclibc-nptl (version 0.9.29). is it a stable release?
If i want to build toolchain using buildroot with nptl support for linux kernel 2.6.18.8, could you please guide us the right version of buildroot, binutils, and gcc to be used.
Thanks & Regards,
Veerasena.
----- Original Message ----
From: Markus Gothe <markus.gothe@27m.se>
To: veerasena reddy <veerasena_b@yahoo..co.in>
Cc: uclibc@uclibc.org; linux-mips <linux-mips@linux-mips.org>; linux-kernel.org <linux-kernel@vger.kernel.org>; buildroot@uclibc.org
Sent: Friday, 2 November, 2007 6:01:41 PM
Subject: Re: NPTL support
You'll have to use the uClibc-nptl branch on their svn. In 0.9.28, no.
//Markus
On 2 Nov 2007, at 06:03, veerasena reddy wrote:
> Hi,
>
> I am trying to build the toolchain for MIPS processor using buildroot.
> I am using gcc version of 3.4.3, binutils-2.15, uclibc-0.9.28 and
> linux-2.6.18.8 kernel.
>
> Basically i need to enable NPTL feature support in my toolchain.
> does uclibc-0.9.28 has the support for NPTL?
> If not, how can i get it enabled for my above build configuration?
>
> I see there is separate branch "uclibc-nptl" in uclibc.
> Do i need to use this (uclibc-nptl) to meet my requirement?
>
> Could you please suggest me right approach to succssfully enable NPTL?
>
> Thanks in advance.
>
> Regards,
> Veerasena.
>
>
> Why delete messages? Unlimited storage is just a click away.
> Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/
> tools-08.html
>
>
_______________________________________
Mr Markus Gothe
Software Engineer
Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)73 718 72 80
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com
Did you know? You can CHAT without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php/
^ permalink raw reply
* Re: [PATCH] Kill __bzero()
From: Ralf Baechle @ 2007-11-05 11:24 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: linux-mips
In-Reply-To: <472D8058.5080209@gmail.com>
On Sun, Nov 04, 2007 at 09:18:32AM +0100, Franck Bui-Huu wrote:
> 1/ Its unconventional prototype is error prone: its prototype is
> the same as memset one but was documented by mips_ksym.c like the
> following:
>
> extern void *__bzero(void *__s, size_t __count);
>
> 2/ For the caller, it makes no difference to call memset instead
> since it has to setup the second parameter of __bzero to 0.
>
> 3/ It's not part of the Linux user access API, so no module can use
> it.
>
> 4/ It needs to be exported with EXPORT_SYMBOL and therefore consumes
> some extra bytes.
>
> 5/ It has only one user.
>
> Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
> ---
>
> I'm wondering if I'm missing something, because this function seems
> so ugly and useless in the first place, that I can't refrain to
> submit a patch to get rid of it.
Memset is almost always only ever invoked with a zero argument. So the
idea was to have something like this:
extern void *__memset(void *__s, int __c, size_t __count);
extern void *bzero(void *__s, size_t __count);
static inline void *memset(void *s, int c, size_t count)
{
if (__builtin_constant_p(c) && c == 0) {
bzero(s, count);
return s;
} else
return __memset(s, __c, count);
}
But that was never quite implemented like this as you noticed.
As for the differences in the return value, they're because of of
clear_user and __clear_user which return the number of bytes that could
_not_ be cleared in $a2. Memset being invoked through the normal C calling
conventions ignores this value while it's the actual result of interest for
__clear_user.
I hope that explains things a little.
Ralf
^ permalink raw reply
* Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Ralf Baechle @ 2007-11-05 11:36 UTC (permalink / raw)
To: Franck Bui-Huu
Cc: Thiemo Seufer, Nigel Stephens, Maciej W. Rozycki, linux-mips
In-Reply-To: <472E2955.3000803@gmail.com>
On Sun, Nov 04, 2007 at 09:19:33PM +0100, Franck Bui-Huu wrote:
> > Latest GCC upstream supports it (in SVN since 2007-07-05).
> >
>
> Good news although gcc 4.3 release is planed for end of January.
>
> Is SDE gcc going to be obsolete after this release ?
As for the kernel I don't really care. The policy is that a working kernel
must be buildable with a stock gcc. Which at times is painful, search for
all the great use of .word in include/asm-mips/ ... This doesn't say
anything against taking advantage of other toolchains such SDE; it's just
the functionality must be there with a vanilla GNU toolchain of the miminum
supported version which currently still is 3.2.
Ralf
^ permalink raw reply
* Re: [PATCH] iounmap if in vr41xx_pciu_init() pci clock is over 33MHz
From: Ralf Baechle @ 2007-11-05 11:43 UTC (permalink / raw)
To: Roel Kluin; +Cc: linux-mips
In-Reply-To: <472DB446.3020804@tiscali.nl>
On Sun, Nov 04, 2007 at 01:00:06PM +0100, Roel Kluin wrote:
> iounmap if pci clock is over 33MHz
Applied. Note that this is purely cosmetic; for 64-bit kernels or
anything in the low 512MB of physcial address space ioremap on a 32-bit
kernel ioremap can never fail on MIPS and iounmap is a nop in this case.
Ralf
^ permalink raw reply
* Re: [PATCH] Use strchr instead of strstr in mips/fw/arc/cmdline.c
From: Ralf Baechle @ 2007-11-05 11:46 UTC (permalink / raw)
To: Roel Kluin; +Cc: linux-mips
In-Reply-To: <472B7379.4030003@tiscali.nl>
On Fri, Nov 02, 2007 at 07:59:05PM +0100, Roel Kluin wrote:
> Use strchr instead of strstr when searching for a single character
>
> Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Thanks, queued for 2.6.25.
Ralf
^ permalink raw reply
* Re: NPTL support
From: Markus Gothe @ 2007-11-05 12:24 UTC (permalink / raw)
To: veerasena reddy; +Cc: uclibc, linux-mips, linux-kernel.org, buildroot
In-Reply-To: <279675.30374.qm@web8411.mail.in.yahoo.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I don't use neither buildroot nor uClibc-nptl, due to uClibc-nptl is a
(dev-)branch and not a release. It differs quite a lot from the 0.9.29
release.
//Markus
veerasena reddy wrote:
> Hi Markus,
>
> thanks for the information.
>
> i checked out uclibc-nptl (version 0.9.29). is it a stable release?
> If i want to build toolchain using buildroot with nptl support for
> linux kernel 2.6.18.8, could you please guide us the right version
> of buildroot, binutils, and gcc to be used.
>
> Thanks & Regards, Veerasena.
>
> ----- Original Message ---- From: Markus Gothe
> <markus.gothe@27m.se> To: veerasena reddy
> <veerasena_b@yahoo..co.in> Cc: uclibc@uclibc.org; linux-mips
> <linux-mips@linux-mips.org>; linux-kernel.org
> <linux-kernel@vger.kernel.org>; buildroot@uclibc.org Sent: Friday,
> 2 November, 2007 6:01:41 PM Subject: Re: NPTL support
>
> You'll have to use the uClibc-nptl branch on their svn. In 0.9.28,
> no.
>
> //Markus
>
> On 2 Nov 2007, at 06:03, veerasena reddy wrote:
>
>> Hi,
>>
>> I am trying to build the toolchain for MIPS processor using
>> buildroot. I am using gcc version of 3.4.3, binutils-2.15,
>> uclibc-0.9.28 and linux-2.6.18.8 kernel.
>>
>> Basically i need to enable NPTL feature support in my toolchain.
>> does uclibc-0.9.28 has the support for NPTL? If not, how can i
>> get it enabled for my above build configuration?
>>
>> I see there is separate branch "uclibc-nptl" in uclibc. Do i need
>> to use this (uclibc-nptl) to meet my requirement?
>>
>> Could you please suggest me right approach to succssfully enable
>> NPTL?
>>
>> Thanks in advance.
>>
>> Regards, Veerasena.
>>
>>
>> Why delete messages? Unlimited storage is just a click away. Go
>> to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/
>> tools-08.html
>>
>>
>
> _______________________________________
>
> Mr Markus Gothe Software Engineer
>
> Phone: +46 (0)13 21 81 20 (ext. 1046) Fax: +46 (0)13 21 21 15
> Mobile: +46 (0)73 718 72 80 Diskettgatan 11, SE-583 35 Linköping,
> Sweden www.27m.com
>
>
> Did you know? You can CHAT without downloading messenger. Go to
> http://in.messenger.yahoo.com/webmessengerpromo.php/
>
>
- --
_______________________________________
Mr Markus Gothe
Software Engineer
Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)73 718 72 80
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHLwuS6I0XmJx2NrwRCLRDAJ9O5mtOAtncebZ9yTZoZpWQLD7hKwCghfdz
IlaSKs6XX+dD6dqC5YFYbRY=
=/Kz+
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC] Add __initbss section
From: Maciej W. Rozycki @ 2007-11-05 12:38 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Ralf Baechle, Geert Uytterhoeven, linux-mips
In-Reply-To: <472D82D1.1050401@gmail.com>
On Sun, 4 Nov 2007, Franck Bui-Huu wrote:
> > Hmm, isn't what `info ld' says enough?
>
> Hmm, I'm must be blind but I missed that each time I read it. Could
> you point out the section number please ?
That's section 3.8, I would guess, but if what you are looking for is not
there, then perhaps the description could be improved.
Maciej
^ permalink raw reply
* Deleting read-only environment variable on Sibyte board.
From: Ralf Baechle @ 2007-11-05 13:02 UTC (permalink / raw)
To: linux-mips
I've got a read-only environment variable on my Sibyte/Broadcom Bigsur
system. Annoyingly it's the network address. Any help on how to
delete such an undeletable environment variable would be welcome.
Thanks,
Ralf
^ permalink raw reply
* Re: 2.6.24-rc1 does not boot on SGI
From: Giuseppe Sacco @ 2007-11-05 13:15 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20071029150625.GB4165@linux-mips.org>
Hi Ralf,
Il giorno lun, 29/10/2007 alle 15.06 +0000, Ralf Baechle ha scritto:
> On Sun, Oct 28, 2007 at 08:17:11PM +0100, Giuseppe Sacco wrote:
>
> > Nothing changed using this patch: the system does not boot. Currently I
> > suspect the reason is the change the IRQ handling because it is the main
> > change in arch/mips/sg-ip32.
>
> All the patch was meant to is to renumber interrupts so interrupts 0 ... 7
> become available for use with cpu_irq.c. Irq 7 is the cp0 compare interrupt
> which on IP32 is used as the clockevent device that is the source of
> timer interrupts.
The latest git update, gave a bootable 2.6.24-rc1 but now, while
booting, the system start looping and calling function print_irq_desc()
from kernel/irq/internals.h. I can only read "...count:...unhandled:..."
since the text scroll too quickly, but I will try to connect a serial
console in order to send here the complete message.
Bye,
Giuseppe
^ permalink raw reply
* Re: Donation of an Indigo 2 R4K@250
From: Martin Michlmayr @ 2007-11-05 14:12 UTC (permalink / raw)
To: debian-mips; +Cc: debian-boot, hardware-donations, linux-mips
In-Reply-To: <Pine.LNX.4.58.0711051413270.16253@nora.oreilly.de>
If anyone is interested in an Indigo 2 located in Cologne, Germany,
please let me know.
> I would like to donate the MIPS porters an SGI Indigo 2 R4K@250Mhz.
> Fully working, keyboard/mouse/monitor included, but no IRIX.
>
> The machine is located in Cologne/Germany - pickup preferred...
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Nigel Stephens @ 2007-11-05 15:58 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Thiemo Seufer, Maciej W. Rozycki, Ralf Baechle, linux-mips
In-Reply-To: <472E2955.3000803@gmail.com>
Franck Bui-Huu wrote:
> Thiemo Seufer wrote:
>
>> Latest GCC upstream supports it (in SVN since 2007-07-05).
>>
>>
>
> Good news although gcc 4.3 release is planed for end of January.
>
Franck
A supported toolchain which now includes SmartMIPS support is the
CodeSourcery MIPS Linux toolchain, based on gcc-4.2, see
http://www.codesourcery.com/store/catalogue/c3/p17
> Is SDE gcc going to be obsolete after this release ?
>
A pre-built "bare-iron" SDE configuration of GCC will probably continue
to exist as part of the MIPS cross-development tools, but we are working
to ensure that as many as possible of the SDE changes are available
upstream for use by other Linux or GNU toolchain vendors, and/or those
who wish to roll their own toolchain.
Nigel
--
Nigel Stephens | 7200 Cambridge Research Park | t:[+44|0]1223 203110
MIPS Technologies | Cambridge, England CB25 9TL | f:[+44|0]1223 203181
^ 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