* Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent
From: Ralf Baechle @ 2007-11-01 15:07 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071101125236.GA16577@alpha.franken.de>
On Thu, Nov 01, 2007 at 01:52:36PM +0100, Thomas Bogendoerfer wrote:
> PIT doesn't work, disable it completly
I think this is the explanation:
include/asm-mips/mach-jazz/timex.h:#define CLOCK_TICK_RATE 100
while the PIT code actually expects 1193182.
Turns out that due to a recent Qemu bug which made the probe for the cp0
compare interrupt fail the Malta code did fall back from the compare timer
to the i8253 PIT for the clockevent device. Works perfectly well.
Ralf
^ permalink raw reply
* Re: [PATCH] SNI: register a02r clockevent; don't use PIT timer
From: Ralf Baechle @ 2007-11-01 15:50 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071101103642.GA28146@alpha.franken.de>
On Thu, Nov 01, 2007 at 11:36:42AM +0100, Thomas Bogendoerfer wrote:
> Register A20R clockevent
> Remove PIT timer setup because it doesn't work
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Applied.
Ralf
^ permalink raw reply
* Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent
From: Ralf Baechle @ 2007-11-01 16:02 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071101150741.GA8570@linux-mips.org>
On Thu, Nov 01, 2007 at 03:07:41PM +0000, Ralf Baechle wrote:
> On Thu, Nov 01, 2007 at 01:52:36PM +0100, Thomas Bogendoerfer wrote:
>
> > PIT doesn't work, disable it completly
>
> I think this is the explanation:
>
> include/asm-mips/mach-jazz/timex.h:#define CLOCK_TICK_RATE 100
>
> while the PIT code actually expects 1193182.
>
> Turns out that due to a recent Qemu bug which made the probe for the cp0
> compare interrupt fail the Malta code did fall back from the compare timer
> to the i8253 PIT for the clockevent device. Works perfectly well.
So I just fixed the MIPS part of the CLOCK_TICK_RATE mess which is really
all over the kernel. I hope this should bring the i2853 to life for you.
Could you test this? It's pretty much the only hope for Jazz to go tickless
so we should try to get it to work. Unfortunately there is a locking issue
lurking there as well so I need some feedback if you can get it to work.
Ralf
^ permalink raw reply
* Re: [PATCH] Put cast inside macro instead of all the callers
From: Ulrich Eckhardt @ 2007-11-01 16:04 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20071031141124.185599da@ripper.onstor.net>
I'm by far not a MIPS expert, but I'm puzzled by the code and how it uses
signed integers for addresses. I just added some comments below, but I'm not
sure if they are valid. Thank you for any clarification!
On Wednesday 31 October 2007, Andrew Sharp wrote:
> Since all the callers of the PHYS_TO_XKPHYS macro call with a constant,
> put the cast to LL inside the macro where it really should be rather
> than in all the callers. This makes macros like PHYS_TO_XKSEG_UNCACHED
> work without gcc whining.
I'm not sure if this is always a compile-time constant so that you can adorn
it with a LL. However, note that this is not a cast, a cast is at runtime.
> if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
> usp = CKSEG1ADDR(sp);
> #ifdef CONFIG_64BIT
> - else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0LL, 0) &&
> - (long long)sp < (long long)PHYS_TO_XKPHYS(8LL, 0))
> - usp = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED,
> + else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0, 0) &&
> + (long long)sp < (long long)PHYS_TO_XKPHYS(8, 0))
> + usp = PHYS_TO_XKPHYS(K_CALG_UNCACHED,
> XKPHYS_TO_PHYS((long long)sp));
I'd say this code is broken in way too many aspects:
1. A plethora of casts. PHYS_TO_XKPHYS() should return a physical address
(i.e. 32 or 64 bits unsigned integer) already, so casting its result should
not be necessary.
2. Using a signed integer of undefined size for an address. At least use an
explicit 64 bit unsigned integer (__u64).
3. The use of signed types makes me wonder about intended overflow semantics.
Just for the record, signed overflow in C causes undefined behaviour, no
diagnostic required, and recent GCC even assume that no overflow occurs as an
optimisation!
> #define PHYS_TO_XKSEG_CACHED(p) PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE,(p))
> #define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK)
> #define PHYS_TO_XKPHYS(cm,a) (_CONST64_(0x8000000000000000) | \
> - ((cm)<<59) | (a))
> + (_CONST64_(cm)<<59) | (a))
This macro will always(!!!) generate a negative number, is that intended?
Uli
- slightly puzzled -
--
Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
^ permalink raw reply
* Re: [SPAM] Re: MIPS assembly directives in GCC
From: Markus Gothe @ 2007-11-01 16:45 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: Hyon Lim, linux-mips
In-Reply-To: <20071101142625.GQ7712@networkno.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Thiemo Seufer wrote:
> Hyon Lim wrote:
>> I investigated kernel assembly source code in my kernel (2.6.10).
>> I found that there are a lot of assembly directives (e.g.,
>> .align, .set reorder, .cpload, .frame etc.). Is there any
>> documents which explains those directives? (not only I described
>> above. All of directives)
>
> Short of reading the assembler sourcecode I believe the best
> document is "See MIPS Run Linux".
>
>
> Thiemo
>
Use the source Luke (or Google)... I think if you'vent got a clue
about assembler (or anything else you're doing) you need to do some
research before asking, that's my not so humble opinion.
- --
_______________________________________
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
iD8DBQFHKgKr6I0XmJx2NrwRCNxEAJ9S1pVnCyBRismBGVoD/lBl119l2gCg0uDy
U4la1KpQWb3zAJfR/Y9Ph0U=
=lSeG
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] Put cast inside macro instead of all the callers
From: Ralf Baechle @ 2007-11-01 17:16 UTC (permalink / raw)
To: Andrew Sharp; +Cc: linux-mips
In-Reply-To: <20071031141124.185599da@ripper.onstor.net>
On Wed, Oct 31, 2007 at 02:11:24PM -0700, Andrew Sharp wrote:
> Resend: I tried sending this a couple of days ago but haven't seen it.
> Wondering if it got stuck in a spam filter or our lovely exchange
> server or something.
It seems the list's spam filter has developed some appetite for patches,
I'm afraid. Generally please cc me on patches.
> Since all the callers of the PHYS_TO_XKPHYS macro call with a constant,
> put the cast to LL inside the macro where it really should be rather
> than in all the callers. This makes macros like PHYS_TO_XKSEG_UNCACHED
> work without gcc whining.
>
> Hopefully this will apply ok.
I'm afraid, no, the definition of PHYS_TO_XKPHYS did change 3 weeks ago ...
Anyway, I fixed that up and queued it for 2.6.25.
Thanks,
Ralf
^ permalink raw reply
* Re: [PATCH] Put cast inside macro instead of all the callers
From: Andrew Sharp @ 2007-11-01 17:23 UTC (permalink / raw)
To: Ulrich Eckhardt; +Cc: linux-mips
In-Reply-To: <200711011704.01079.eckhardt@satorlaser.com>
On Thu, 1 Nov 2007 17:04:01 +0100 Ulrich Eckhardt
<eckhardt@satorlaser.com> wrote:
> I'm by far not a MIPS expert, but I'm puzzled by the code and how it
> uses signed integers for addresses. I just added some comments below,
> but I'm not sure if they are valid. Thank you for any clarification!
>
> On Wednesday 31 October 2007, Andrew Sharp wrote:
> > Since all the callers of the PHYS_TO_XKPHYS macro call with a
> > constant, put the cast to LL inside the macro where it really
> > should be rather than in all the callers. This makes macros like
> > PHYS_TO_XKSEG_UNCACHED work without gcc whining.
>
> I'm not sure if this is always a compile-time constant so that you
> can adorn it with a LL. However, note that this is not a cast, a cast
> is at runtime.
It is always a constant.
> > if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
> > usp = CKSEG1ADDR(sp);
> > #ifdef CONFIG_64BIT
> > - else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0LL,
> > 0) &&
> > - (long long)sp < (long long)PHYS_TO_XKPHYS(8LL, 0))
> > - usp = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED,
> > + else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0, 0)
> > &&
> > + (long long)sp < (long long)PHYS_TO_XKPHYS(8, 0))
> > + usp = PHYS_TO_XKPHYS(K_CALG_UNCACHED,
> > XKPHYS_TO_PHYS((long
> > long)sp));
>
> I'd say this code is broken in way too many aspects:
> 1. A plethora of casts. PHYS_TO_XKPHYS() should return a physical
> address (i.e. 32 or 64 bits unsigned integer) already, so casting its
> result should not be necessary.
> 2. Using a signed integer of undefined size for an address. At least
> use an explicit 64 bit unsigned integer (__u64).
> 3. The use of signed types makes me wonder about intended overflow
> semantics. Just for the record, signed overflow in C causes undefined
> behaviour, no diagnostic required, and recent GCC even assume that no
> overflow occurs as an optimisation!
>
> > #define PHYS_TO_XKSEG_CACHED(p)
> > PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE,(p)) #define
> > XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK) #define
> > PHYS_TO_XKPHYS(cm,a) (_CONST64_(0x8000000000000000)
> > | \
> > - ((cm)<<59) | (a))
> > + (_CONST64_(cm)<<59) | (a))
>
> This macro will always(!!!) generate a negative number, is that
> intended?
Well, it's an address, not a number. Does that help? The point of the
macro is to convert physical addresses to a selectable type of virtual
address, of which mips has several.
Cheers,
a
^ permalink raw reply
* Re: [PATCH] Put cast inside macro instead of all the callers
From: Ralf Baechle @ 2007-11-01 17:47 UTC (permalink / raw)
To: Ulrich Eckhardt; +Cc: linux-mips
In-Reply-To: <200711011704.01079.eckhardt@satorlaser.com>
On Thu, Nov 01, 2007 at 05:04:01PM +0100, Ulrich Eckhardt wrote:
> I'm by far not a MIPS expert, but I'm puzzled by the code and how it uses
> signed integers for addresses. I just added some comments below, but I'm not
> sure if they are valid. Thank you for any clarification!
When going from 32-bit to 64-bit MIPS did sign-extend register values and
addresses, that is for example 0x80000000 became 0xffffffff80000000. That
is the code sequence which on 32-bit is used to load the first address
actually happens to load the 2nd value on a 64-bit machine. Which is an
extremly elegant solution on the hardware level but at a few places
software need to know. The code tries to make clever use of sign extension
by the compiler to avoid multiple constants.
> On Wednesday 31 October 2007, Andrew Sharp wrote:
> > Since all the callers of the PHYS_TO_XKPHYS macro call with a constant,
> > put the cast to LL inside the macro where it really should be rather
> > than in all the callers. This makes macros like PHYS_TO_XKSEG_UNCACHED
> > work without gcc whining.
>
> I'm not sure if this is always a compile-time constant so that you can adorn
> it with a LL. However, note that this is not a cast, a cast is at runtime.
No. The compiler can evaluate the cast of a constant value at compile
time and that exactly is what the code is exploiting here.
> > if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
> > usp = CKSEG1ADDR(sp);
> > #ifdef CONFIG_64BIT
> > - else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0LL, 0) &&
> > - (long long)sp < (long long)PHYS_TO_XKPHYS(8LL, 0))
> > - usp = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED,
> > + else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0, 0) &&
> > + (long long)sp < (long long)PHYS_TO_XKPHYS(8, 0))
> > + usp = PHYS_TO_XKPHYS(K_CALG_UNCACHED,
> > XKPHYS_TO_PHYS((long long)sp));
>
> I'd say this code is broken in way too many aspects:
> 1. A plethora of casts. PHYS_TO_XKPHYS() should return a physical address
> (i.e. 32 or 64 bits unsigned integer) already, so casting its result should
> not be necessary.
No argument about the beauty of the whole thing.
> 2. Using a signed integer of undefined size for an address. At least use an
> explicit 64 bit unsigned integer (__u64).
long long is 64-bit on Linux.
> 3. The use of signed types makes me wonder about intended overflow semantics.
> Just for the record, signed overflow in C causes undefined behaviour, no
> diagnostic required, and recent GCC even assume that no overflow occurs as an
> optimisation!
There is no overflow possible here.
> > #define PHYS_TO_XKSEG_CACHED(p) PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE,(p))
> > #define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK)
> > #define PHYS_TO_XKPHYS(cm,a) (_CONST64_(0x8000000000000000) | \
> > - ((cm)<<59) | (a))
> > + (_CONST64_(cm)<<59) | (a))
>
> This macro will always(!!!) generate a negative number, is that intended?
Sort of. Most users don't care, the address is just an address for them.
Note that the Linux idea of "all virtual addresses can be represented in
an unsigned long" and the MIPS concept of sign extending addresses conflict
at times, so sometimes addresses want to be handled with alot of care.
Ralf
^ permalink raw reply
* Re: [IDE] Fix build bug
From: Denys Vlasenko @ 2007-11-01 18:43 UTC (permalink / raw)
To: Ralf Baechle
Cc: Bartlomiej Zolnierkiewicz, Andrew Morton, linux-kernel, linux-ide,
linux-mips, Martijn Uffing
In-Reply-To: <20071030124155.GA7582@linux-mips.org>
On Tuesday 30 October 2007 12:41, Ralf Baechle wrote:
> On Tue, Oct 30, 2007 at 11:34:29AM +0000, Denys Vlasenko wrote:
>
> > On Thursday 25 October 2007 22:41, Bartlomiej Zolnierkiewicz wrote:
> > > > -static const struct ide_port_info generic_chipsets[] __devinitdata = {
> > > > +static struct ide_port_info generic_chipsets[] __devinitdata = {
> > > > /* 0 */ DECLARE_GENERIC_PCI_DEV("Unknown", 0),
> > > >
> > > > { /* 1 */
> > >
> > > I would prefer to not remove const from generic_chipsets[] so:
> > >
> > > [PATCH] drivers/ide/pci/generic: fix build for CONFIG_HOTPLUG=n
> > >
> > > It turns out that const and __{dev}initdata cannot be mixed currently
> > > and that generic IDE PCI host driver is also affected by the same issue:
> > >
> > > On Thursday 25 October 2007, Ralf Baechle wrote:
> > > > CC drivers/ide/pci/generic.o
> > > > drivers/ide/pci/generic.c:52: error: __setup_str_ide_generic_all_on causes a
> > > > +section type conflict
> > >
> > > [ Also reported by Martijn Uffing <mp3project@sarijopen.student.utwente.nl>. ]
> > >
> > > This patch workarounds the problem in a bit hackish way but without
> > > removing const from generic_chipsets[] (it adds const to __setup() so
> > > __setup_str_ide_generic_all becomes const).
> >
> > You wouldn't believe how much const data is not marked as const because
> > we don't have __constinitdata etc. Literally megabytes.
>
> The gain from marking it const is very little and once any non-const
> __initdata object is added to a compilation unit all other const declarations
> will have to be removed. Bad tradeoff.
We can intrduce new, ro sections or teach gcc that combining const objects into
non-ro sections is not a crime. I wonder why it currently disallows that.
(And it does it only _somethimes_, const pointers happily go into rw sections!)
--
vda
^ permalink raw reply
* NPTL support
From: veerasena reddy @ 2007-11-02 5:03 UTC (permalink / raw)
To: uclibc, linux-mips, linux-kernel.org, buildroot
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
^ permalink raw reply
* Oops with kernel 2.6.8
From: kalyan tejaswi @ 2007-11-02 5:45 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1.1: Type: text/plain, Size: 202 bytes --]
Hi all,
I am using Malta-4Kc with kernel 2.6.8(from linux-mips.org) compiled with
gcc 3.4.4.
I can not boot over NFS.
The console log is attached.
Any hints are greatly appreciated.
Regards
Kalyan
[-- Attachment #1.2: Type: text/html, Size: 405 bytes --]
[-- Attachment #2: console-log.txt --]
[-- Type: text/plain, Size: 7689 bytes --]
set
baseboardserial (RO) 0000000554
bootfile (R/W) vmlinux.srec
bootprot (R/W) tftp
bootserport (R/W) tty0
bootserver (R/W) 10.1.1.58
cpuconfig (R/W)
ethaddr (RO) 00.d0.a0.00.03.22
file (USER) vmlinux.srec-WUSAGI-WIPIP-ATM-EV6
gateway (R/W) 10.1.1.58
gdb (USER) gdbwait gdb8250=0 38400
ip (USER) 10.1.1.100:10.1.1.58:10.1.1.58:255.0.0.0:malta:eth0:off
ip_new (USER) 10.1.1.100:10.1.1.57:10.1.1.57:255.0.0.0:malta:eth0:off
ip_new1 (USER) 10.1.1.100:10.1.1.58:10.1.1.58:255.0.0.0:malta:eth0:off
ip_old (USER) 20.1.1.100:20.1.1.58:20.1.1.58:255.0.0.0:malta:eth0:off
ipaddr (R/W) 10.1.1.100
memsize (RO) 0x04000000
modetty0 (R/W) 38400,n,8,1,hw
modetty1 (R/W) 38400,n,8,1,hw
newroot (USER) /root/kishore/lxdb26
newroot-temp (USER) /home/jeetendr/root_filesystem-1.3-4k
newroot1 (USER) /home/jeetendr/root4K
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bnewroot2 (USER) /root/kalyan/root_filesystem
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bnewroot3 (USER) /root/kishore/root_filesystem-4K
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bnewroot4 (USER) /root/kishore/lxdb-1-2-lfs
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bnfsroot (USER) /root/kishore/lxdb-1-2-user-lfs
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bprompt (R/W) YAMON-4K
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\brootpath (USER) /root/kishore/r1-alpha-rootfs
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bserver (USER) 10.1.1.58
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bstart (R/W) load; go . ip=$ip root=/dev/nfs nfsroot=$newroot panic=1
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bstart_old (USER) load; go . ip=$ip root=/dev/nfs nfsroot=$rootpath
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bsubnetmask (R/W) 255.255.255.0
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\byamonrev (RO) 02.02
Press any key (Ctrl-C to break, Enter to singlestep)\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b
YAMON-4K>
YAMON-4K> load; go . ip=$ip root=/dev/nfs nfsroot=$newroot-temp
About to load tftp://10.1.1.58/vmlinux.srec
Press Ctrl-C to break
........................................
........................................
........................................
........................................
........................................
........................................
....................................
Start = 0x8030d018, range = (0x80100000,0x80329085), format = SREC
LINUX started...
Config serial console: console=ttyS0,38400n8r
Linux version 2.6.8 (kalyan@lxdb02) (gcc version 3.4.4 20050119 (MIPS SDE)) #9 Fri Nov 2 09:26:32 IST 2007
CPU revision is: 00018005
Determined physical RAM map:
memory: 00001000 @ 00000000 (reserved)
memory: 000ef000 @ 00001000 (ROM data)
memory: 00251000 @ 000f0000 (reserved)
memory: 03cbf000 @ 00341000 (usable)
Built 1 zonelists
Kernel command line: ip=10.1.1.100:10.1.1.58:10.1.1.58:255.0.0.0:malta:eth0:off root=/dev/nfs nfsroot=/home/jeetendr/root_filesystem-1.3-4k console=ttyS0,38400n8r
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 16kB 4-way, linesize 16 bytes.
PID hash table entries: 512 (order 9: 4096 bytes)
CPU frequency 125.01 MHz
Using 62.506 MHz high precision timer.
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 61488k/62204k available (1619k kernel code, 632k reserved, 476k data, 116k init, 0k highmem)
Calibrating delay loop... 123.39 BogoMIPS
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Checking for 'wait' instruction... available.
CPU 0 Unable to handle kernel paging request at virtual address 00000014, epc == 80172128, ra == 80172130
Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]:
Cpu 0
$ 0 : 00000000 1000fc00 00000000 802c2000
$ 4 : 802c2000 83fc186c 00000000 80163d80
$ 8 : 00000008 801dae28 000008ac 00000000
$12 : 80330000 00000000 8032c257 0000000a
$16 : 00000000 83fc1900 83fc186c ffffffe9
$20 : 00000000 00000000 80330000 00000000
$24 : 00000000 8032c623
$28 : 802be000 802bfe48 8009e370 80172130
Hi : 00000000
Lo : 000008ac
epc : 80172128 do_pipe+0x58/0x320 Not tainted
ra : 80172130 do_pipe+0x60/0x320
Status: 1000fc03 KERNEL EXL IE
Cause : 90800008
BadVA : 83fc1900
PrId : 00018005
Modules linked in:
Process swapper (pid: 0, threadinfo=802be000, task=802c2000)
Stack : 80330000 00000000 8032c257 0000000a 00418937 000026b5 80334254 00418937
00000060 802c0000 8032cb6f 00000060 00000000 8032c623 1000fc03 b22cc700
00000000 8010045c 00800b00 00000000 00000000 00000000 00000000 00000000
8009e370 801072fc 802bfec0 83fff340 802cb3cc 00000501 0000000c 00000008
8010b3e8 802c0000 00800b00 00000000 802bff80 0000001d 802c0000 802c0000
...
Call Trace:
[<8010045c>] init+0x0/0x254
[<801072fc>] sys_pipe+0x24/0x48
[<8010b3e8>] stack_done+0x24/0x40
[<801283c8>] release_console_sem+0x120/0x314
[<801284d0>] release_console_sem+0x228/0x314
[<8010045c>] init+0x0/0x254
[<8010041c>] rest_init+0x1c/0x28
[<8010548c>] kernel_thread+0x38/0x7c
[<8010041c>] rest_init+0x1c/0x28
[<8030d81c>] start_kernel+0x1b0/0x1d8
[<8030d814>] start_kernel+0x1a8/0x1d8
[<8030d24c>] unknown_bootoption+0x0/0x280
[<8030d08c>] nosmp+0x0/0x10
Code: 00409021 3c168033 8ec23050 <0c05ffb0> 8c440014 1040009b 00408021 0c05c801 00402021
Kernel panic: Attempted to kill the idle task!
In idle task - not syncing
^ permalink raw reply
* Re: [PATCH] Put cast inside macro instead of all the callers
From: Ulrich Eckhardt @ 2007-11-02 8:06 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <200711011704.01079.eckhardt@satorlaser.com>
On Thursday 01 November 2007, Ulrich Eckhardt wrote:
[...]
> - slightly puzzled -
Andrew, Ralf, thanks for the clarifications!
Uli
--
Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
^ permalink raw reply
* Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent
From: Thomas Bogendoerfer @ 2007-11-02 10:17 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071101160210.GA20366@linux-mips.org>
On Thu, Nov 01, 2007 at 04:02:10PM +0000, Ralf Baechle wrote:
> all over the kernel. I hope this should bring the i2853 to life for you.
it does now, even pit clockevent works now (if you apply the patch
below).
Thomas.
Fix ISA irq acknowledge
make r4030 clockevent code look like other mips clockevent code
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
diff --git a/arch/mips/jazz/irq.c b/arch/mips/jazz/irq.c
index ae25b48..d7f8a78 100644
--- a/arch/mips/jazz/irq.c
+++ b/arch/mips/jazz/irq.c
@@ -97,9 +97,10 @@ asmlinkage void plat_irq_dispatch(void)
if (pending & IE_IRQ4) {
r4030_read_reg32(JAZZ_TIMER_REGISTER);
do_IRQ(JAZZ_TIMER_IRQ);
- } else if (pending & IE_IRQ2)
- do_IRQ(r4030_read_reg32(JAZZ_EISA_IRQ_ACK));
- else if (pending & IE_IRQ1) {
+ } else if (pending & IE_IRQ2) {
+ irq = *(volatile u8 *)JAZZ_EISA_IRQ_ACK;
+ do_IRQ(irq);
+ } else if (pending & IE_IRQ1) {
irq = *(volatile u8 *)JAZZ_IO_IRQ_SOURCE >> 2;
if (likely(irq > 0))
do_IRQ(irq + JAZZ_IRQ_START - 1);
@@ -117,16 +118,16 @@ static void r4030_set_mode(enum clock_event_mode mode,
struct clock_event_device r4030_clockevent = {
.name = "r4030",
.features = CLOCK_EVT_FEAT_PERIODIC,
- .rating = 100,
+ .rating = 300,
.irq = JAZZ_TIMER_IRQ,
- .cpumask = CPU_MASK_CPU0,
.set_mode = r4030_set_mode,
};
static irqreturn_t r4030_timer_interrupt(int irq, void *dev_id)
{
- r4030_clockevent.event_handler(&r4030_clockevent);
+ struct clock_event_device *cd = dev_id;
+ cd->event_handler(cd);
return IRQ_HANDLED;
}
@@ -134,15 +135,22 @@ static struct irqaction r4030_timer_irqaction = {
.handler = r4030_timer_interrupt,
.flags = IRQF_DISABLED,
.mask = CPU_MASK_CPU0,
- .name = "timer",
+ .name = "R4030 timer",
};
void __init plat_time_init(void)
{
- struct irqaction *irq = &r4030_timer_irqaction;
+ struct clock_event_device *cd = &r4030_clockevent;
+ struct irqaction *action = &r4030_timer_irqaction;
+ unsigned int cpu = smp_processor_id();
BUG_ON(HZ != 100);
+ cd->cpumask = cpumask_of_cpu(cpu);
+ clockevents_register_device(cd);
+ action->dev_id = cd;
+ setup_irq(JAZZ_TIMER_IRQ, action);
+
/*
* Set clock to 100Hz.
*
@@ -150,8 +158,5 @@ void __init plat_time_init(void)
* a programmable 4-bit divider. This makes it fairly inflexible.
*/
r4030_write_reg32(JAZZ_TIMER_INTERVAL, 9);
- setup_irq(JAZZ_TIMER_IRQ, irq);
-
- clockevents_register_device(&r4030_clockevent);
setup_pit_timer();
}
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply related
* Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent
From: Ralf Baechle @ 2007-11-02 12:20 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071102101713.GA9110@alpha.franken.de>
On Fri, Nov 02, 2007 at 11:17:13AM +0100, Thomas Bogendoerfer wrote:
> On Thu, Nov 01, 2007 at 04:02:10PM +0000, Ralf Baechle wrote:
> > all over the kernel. I hope this should bring the i2853 to life for you.
>
> it does now, even pit clockevent works now (if you apply the patch
> below).
Applied, thanks,
One thing I'm still wondering about, does the kernel actually go tickless
for you?
Ralf
^ permalink raw reply
* Re: NPTL support
From: Markus Gothe @ 2007-11-02 12:31 UTC (permalink / raw)
To: veerasena reddy; +Cc: uclibc, linux-mips, linux-kernel.org, buildroot
In-Reply-To: <335463.37228.qm@web8414.mail.in.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [IDE] Fix build bug
From: Ralf Baechle @ 2007-11-02 12:34 UTC (permalink / raw)
To: Denys Vlasenko
Cc: Bartlomiej Zolnierkiewicz, Andrew Morton, linux-kernel, linux-ide,
linux-mips, Martijn Uffing
In-Reply-To: <200711011843.16894.vda.linux@googlemail.com>
On Thu, Nov 01, 2007 at 06:43:16PM +0000, Denys Vlasenko wrote:
> We can intrduce new, ro sections or teach gcc that combining const objects into
> non-ro sections is not a crime. I wonder why it currently disallows that.
> (And it does it only _somethimes_, const pointers happily go into rw sections!)
The pattern seems to be that const-ness of the first object placed into
a particular section determines the writability of that section. If that
conflicts with the requirements for a later object such as a non-const
object into a section r/o gcc doesn't consider making the section r/w
but throws an error instead.
Ralf
^ permalink raw reply
* Re: Oops with kernel 2.6.8
From: Ralf Baechle @ 2007-11-02 12:57 UTC (permalink / raw)
To: kalyan tejaswi; +Cc: linux-mips
In-Reply-To: <9dd3c65d0711012245r4a1f2061r126d34a907b640cd@mail.gmail.com>
On Fri, Nov 02, 2007 at 11:15:51AM +0530, kalyan tejaswi wrote:
> Hi all,
> I am using Malta-4Kc with kernel 2.6.8(from linux-mips.org) compiled with
> gcc 3.4.4.
>
> I can not boot over NFS.
>
> The console log is attached.
>
> Any hints are greatly appreciated.
2.6.8 is really old, over 3 years now. So forgive if memory of the bugs
in that kernel is fading. I think the one you're seeing was was caused
by memory prefetching beyond the end of memory. The easy fix is to disable
prefetching. See a modern memcpy for how to do that. There are several
other interesting issues hidden in 2.6.8 so I think you really should
upgrade.
Ralf
^ permalink raw reply
* Re: WAIT vs. tickless kernel
From: Atsushi Nemoto @ 2007-11-02 16:46 UTC (permalink / raw)
To: ralf; +Cc: linux-mips
In-Reply-To: <20071031163900.GB22871@linux-mips.org>
On Wed, 31 Oct 2007 16:39:00 +0000, Ralf Baechle <ralf@linux-mips.org> wrote:
> > > The only safe but ugly workaround is to change the return from exception
> > > code to detect if the EPC is in the range startin from the condition
> > > check in the idle loop to including the WAIT instruction and if so to
> > > patch the EPC to resume execution at the condition check or the
> > > instruction following the WAIT.
> >
> > I'm also thinking of this approach. Still wondering if it is worth to
> > implement.
>
> The tickless kernel is very interesting for the low power fraction. And
> it's especially those users who would suffer most the loss of the ability
> to use the WAIT instruction. For a system running from two AAA cells the
> tradeoff is clear ... So I think it's become a must.
Then, something like this? Selecting in build-time is not so good,
but there are some CPUs which do not need this hack at all.
Synthesizing the ret_from_irq() at runtime might satisfy everyone?
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index c8c47a2..621130c 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -51,12 +51,17 @@ static void r39xx_wait(void)
* But it is implementation-dependent wheter the pipelie restarts when
* a non-enabled interrupt is requested.
*/
+#ifdef CONFIG_ROLLBACK_CPU_WAIT
+extern void cpu_wait_rollback(void);
+#define r4k_wait cpu_wait_rollback
+#else
static void r4k_wait(void)
{
__asm__(" .set mips3 \n"
" wait \n"
" .set mips0 \n");
}
+#endif
/*
* This variant is preferable as it allows testing need_resched and going to
diff --git a/arch/mips/kernel/entry.S b/arch/mips/kernel/entry.S
index e29598a..ffa043c 100644
--- a/arch/mips/kernel/entry.S
+++ b/arch/mips/kernel/entry.S
@@ -27,6 +27,20 @@
#endif
.text
+#ifdef CONFIG_ROLLBACK_CPU_WAIT
+ .align 6
+FEXPORT(cpu_wait_rollback)
+ LONG_L t0, TI_FLAGS($28)
+ andi t0, _TIF_NEED_RESCHED
+ bnez t0, 1f
+ .set mips3
+ wait
+ .set mips0
+1:
+ jr ra
+ .align 6
+cpu_wait_rollback_end:
+#endif
.align 5
#ifndef CONFIG_PREEMPT
FEXPORT(ret_from_exception)
@@ -35,6 +49,14 @@ FEXPORT(ret_from_exception)
#endif
FEXPORT(ret_from_irq)
LONG_S s0, TI_REGS($28)
+#ifdef CONFIG_ROLLBACK_CPU_WAIT
+ LONG_L t0, PT_EPC(sp)
+ ori t0, 0x3f
+ xori t0, 0x3f
+ PTR_LA t1, cpu_wait_rollback
+ bne t0, t1, __ret_from_irq
+ LONG_S t0, PT_EPC(sp) # return to cpu_wait_rollback
+#endif
FEXPORT(__ret_from_irq)
LONG_L t0, PT_STATUS(sp) # returning to kernel mode?
andi t0, t0, KU_USER
^ permalink raw reply related
* First implementation is done. (software suspend on MIPS)
From: Hyon Lim @ 2007-11-02 17:26 UTC (permalink / raw)
To: linux-mips
First implementation is done.
My work includes "cpu.c, swsusp.S" which is located on
arch/mips/xxx/power. (xxx is your specific architecture)
But, problem still exist. When system resumed, kernel panic is
occured. (See below)
I think that problem is occured by missing context. (I saved only few register)
Please watch my code and please comment my mistake.
===================================================
swsusp.S
===================================================
.text
/*
* Suspend support for MIPS.
*
* Distribute under GPLv2
*
* Copyright (c) 2007 Hyon Lim <alex@alexlab.net>
*/
#include <linux/linkage.h>
#include <asm/segment.h>
#include <asm/page.h>
#include <asm/asm.h>
#include <asm/offset.h>
#include <asm/regdef.h>
.text
/* this macro generates local word(unsigned long) sized variable */
#define LOCAL_WORD(x) \
.data ;\
.align 2 ;\
.type x, @object;\
.size x, 4 ;\
x:
.space 4
#define WORD_ADDR(x) \
.align 2 ;\
.L##x: ;\
.word x
#define FUNC(x) \
.text ;\
.align 2 ;\
.globl x ;\
.ent x ;\
.type x,@function;\
x:
#define FUNC_END(x) \
.end x
LOCAL_WORD(saved_context_s0);
LOCAL_WORD(saved_context_s1);
LOCAL_WORD(saved_context_s2);
LOCAL_WORD(saved_context_s3);
LOCAL_WORD(saved_context_s4);
LOCAL_WORD(saved_context_s5);
LOCAL_WORD(saved_context_s6);
LOCAL_WORD(saved_context_s7);
LOCAL_WORD(saved_context_ra);
FUNC(swsusp_arch_suspend)
sw s0,saved_context_s0;
sw s1,saved_context_s1;
sw s2,saved_context_s2;
sw s3,saved_context_s3;
sw s4,saved_context_s4;
sw s5,saved_context_s5;
sw s6,saved_context_s6;
sw s7,saved_context_s7;
sw ra,saved_context_ra;
jal swsusp_save;
lw ra,saved_context_ra; // this statement corresponds to RET in x86 asm.
//PRINT("[ASM] RETURN TO C!!");
j ra; //
FUNC_END(swsusp_arch_suspend)
// for using printk
.rdata
.align 2
$LC0:
.ascii "[DEBUG] RETURN TO C!!! from ASM\n\000"
.align 2
$LC1:
.ascii "@@#\000"
.align 2
$LC2:
.ascii "Copy %d!\n\000"
.align 2
$LC3:
.ascii "End loop\n\000"
.align 2
$LC4:
.ascii "[ASM] RESUME SUCCESS!!\n\000"
.align 2
$LC5:
.ascii "[ASM] Start copying pages ... \n\000"
.align 2
$LC6:
.ascii "[ASM] Load nr_copy_pages and pagedir_nosave success!!\n\000"
LOCAL_WORD(tmp_var);
LOCAL_WORD(tmp_var2);
FUNC(swsusp_arch_resume)
/*
* This pseudo code should be implemented.
*
* register u32 *src,*dst;
* for (j=nr_copy_pages; j>0; j--)
* {
* src = pagedir_nosave[j].src;
* dst = pagedir_nosave[j].dst;
* for(i=0;i<1024;i++){
* *dst++ = *src++;
* }
* }
*/
/*
* typedef struct pbe{
* unsigned long address; // address of the copy : base addr;
* unsigned long orig_address; //original address... : base addr + 4;
* ...
*/
// Used register lookup table
// $t0 : orig's contents
// $t1 :
// $t2 : counter, 1024
// $t3 :
// $t4 :
// $t5 :
// $t6 :
// $t7 :
//
// $s0 : pagedir_nosave's address
// $s1 : nr_copy_pages's address
// $s2 : temp_var
// $s3 : src pointer
// $s4 : dst pointer
// $s5 :
// $s6 :
// $s7 :
//
// Get pointer from variables.
lw s0,pagedir_nosave; // load pagedir_nosave's address
lw s1,nr_copy_pages; // $s1=nr_copy_pages;
$copy_loop:
lw s3,0(s0); // $s3 has source destination's address
lw s4,4(s0); // $s4 has orignal address
// Objective : copy orig_address's contents to address
li t2,1024; // $t2 = 1024;, index variable.
$copy_loop_inner:
lw t0,0(s3); // orig's contents into $t0
sw t0,0(s4); // orig's contents to target address's contents
addiu s3,s3,4 // address++
addiu s4,s4,4 // orig_addr++
addiu t2,t2,-1 // decrease counter
blez t2,$end_inner_loop // less than or equal zero
j $copy_loop_inner; // jmp!
$end_inner_loop:
//PRINT("#");
addiu s0,s0,16
addiu s1,s1,-1 // nr_copy_pages = nr_copy_pages - 1;
blez s1,$end_copy
j $copy_loop
$end_copy:
lw s0, saved_context_s0;
lw s1, saved_context_s1;
lw s2, saved_context_s2;
lw s3, saved_context_s3;
lw s4, saved_context_s4;
lw s5, saved_context_s5;
lw s6, saved_context_s6;
lw s7, saved_context_s7;
jal swsusp_restore;
lw ra, saved_context_ra;
j ra;
FUNC_END(swsusp_arch_resume)
===================================================
cpu.c
===================================================
/*
* Suspend support for MIPS.
*
* Distribute under GPLv2
*
* Copyright (c) 2007 Hyon Lim <alex@alexlab.net>
*/
#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <linux/spinlock.h>
#include <linux/poll.h>
#include <linux/delay.h>
#include <linux/sysrq.h>
#include <linux/proc_fs.h>
#include <linux/irq.h>
#include <linux/pm.h>
#include <linux/device.h>
#include <linux/suspend.h>
#include <asm/uaccess.h>
#include <asm/tlbflush.h>
static struct saved_context saved_context;
// This is callee-saved registers
//unsigned long saved_context_s0;
//unsigned long saved_context_s1;
//unsigned long saved_context_s2;
//unsigned long saved_context_s3;
//unsigned long saved_context_s4;
//unsigned long saved_context_s5;
//unsigned long saved_context_s6;
//unsigned long saved_context_s7;
//unsigned long saved_context_ra; // return address
void __save_processor_state(void)
{
preempt_disable();
// kernel_fpu_begin();
// mips uses PF_USEDFPU, but there isn't function of kernel_fpu_begin.
// Think of storing fp related registers.
/* CPU registers */
/*
* save the general registers.
* note that gcc has constructs to specify output of certain registers,
* but they're not used here, because it assumes that you want to modify
* those registers, so it tries to be smart and save them beforehand.
* It's really not necessary, and kinda fishy (check the assembly output),
* so it's avoided.
*/
/*
* can't use output with "m" constraint. because direct addressing is
not permitted
* on MIPS inline assembly. (register relative addressing as I see)
* compiler usually allocates first "r" constraint register with
'v0'. (in my opinion)
* if it doesn't, I'll describe really really massive clobber list
for stability.
*
* "at" register is only used by assembler.
* "zero" register always contains zero.
*/
asm volatile ("subu $29, 4");
asm volatile ("sw $2, ($29)");
asm volatile ("sw $3, (%0)" : : "r" (&saved_context.v[1]));
asm volatile ("sw $4, (%0)" : : "r" (&saved_context.a[0]));
asm volatile ("sw $5, (%0)" : : "r" (&saved_context.a[1]));
asm volatile ("sw $6, (%0)" : : "r" (&saved_context.a[2]));
asm volatile ("sw $7, (%0)" : : "r" (&saved_context.a[3]));
asm volatile ("sw $8, (%0)" : : "r" (&saved_context.t[0]));
asm volatile ("sw $9, (%0)" : : "r" (&saved_context.t[1]));
asm volatile ("sw $10, (%0)" : : "r" (&saved_context.t[2]));
asm volatile ("sw $11, (%0)" : : "r" (&saved_context.t[3]));
asm volatile ("sw $12, (%0)" : : "r" (&saved_context.t[4]));
asm volatile ("sw $13, (%0)" : : "r" (&saved_context.t[5]));
asm volatile ("sw $14, (%0)" : : "r" (&saved_context.t[6]));
asm volatile ("sw $15, (%0)" : : "r" (&saved_context.t[7]));
asm volatile ("sw $16, (%0)" : : "r" (&saved_context.s[0]));
asm volatile ("sw $17, (%0)" : : "r" (&saved_context.s[1]));
asm volatile ("sw $18, (%0)" : : "r" (&saved_context.s[2]));
asm volatile ("sw $19, (%0)" : : "r" (&saved_context.s[3]));
asm volatile ("sw $20, (%0)" : : "r" (&saved_context.s[4]));
asm volatile ("sw $21, (%0)" : : "r" (&saved_context.s[5]));
asm volatile ("sw $22, (%0)" : : "r" (&saved_context.s[6]));
asm volatile ("sw $23, (%0)" : : "r" (&saved_context.s[7]));
asm volatile ("sw $24, (%0)" : : "r" (&saved_context.t[8]));
asm volatile ("sw $25, (%0)" : : "r" (&saved_context.t[9]));
asm volatile ("sw $26, (%0)" : : "r" (&saved_context.k[0]));
asm volatile ("sw $27, (%0)" : : "r" (&saved_context.k[1]));
asm volatile ("sw $28, (%0)" : : "r" (&saved_context.gp));
asm volatile ("sw $30, (%0)" : : "r" (&saved_context.fp));
asm volatile ("sw $31, (%0)" : : "r" (&saved_context.ra));
asm volatile ("lw $2, ($29)");
asm volatile ("addu $29, 4");
asm volatile ("sw $2, (%0)" : : "r" (&saved_context.v[0]) : "$2");
asm volatile ("sw $29, (%0)" : : "r" (&saved_context.sp));
/*
* special registers
*/
asm volatile ("mfhi %0" : "=r" (saved_context.hi));
asm volatile ("mflo %0" : "=r" (saved_context.lo));
// load/link register??
/*
* coprocessor 0 registers (inclde/asm-mips/mipsregs.h)
*/
asm volatile ("mfc0 %0, $0" : "=r" (saved_context.cp0[0]));
asm volatile ("mfc0 %0, $1" : "=r" (saved_context.cp0[1]));
asm volatile ("mfc0 %0, $2" : "=r" (saved_context.cp0[2]));
asm volatile ("mfc0 %0, $3" : "=r" (saved_context.cp0[3]));
asm volatile ("mfc0 %0, $4" : "=r" (saved_context.cp0[4]));
asm volatile ("mfc0 %0, $5" : "=r" (saved_context.cp0[5]));
asm volatile ("mfc0 %0, $6" : "=r" (saved_context.cp0[6]));
asm volatile ("mfc0 %0, $7" : "=r" (saved_context.cp0[7]));
asm volatile ("mfc0 %0, $8" : "=r" (saved_context.cp0[8]));
asm volatile ("mfc0 %0, $9" : "=r" (saved_context.cp0[9]));
asm volatile ("mfc0 %0, $10" : "=r" (saved_context.cp0[10]));
asm volatile ("mfc0 %0, $11" : "=r" (saved_context.cp0[11]));
asm volatile ("mfc0 %0, $12" : "=r" (saved_context.cp0[12]));
asm volatile ("mfc0 %0, $13" : "=r" (saved_context.cp0[13]));
asm volatile ("mfc0 %0, $14" : "=r" (saved_context.cp0[14]));
asm volatile ("mfc0 %0, $15" : "=r" (saved_context.cp0[15]));
asm volatile ("mfc0 %0, $16" : "=r" (saved_context.cp0[16]));
asm volatile ("mfc0 %0, $17" : "=r" (saved_context.cp0[17]));
asm volatile ("mfc0 %0, $18" : "=r" (saved_context.cp0[18]));
asm volatile ("mfc0 %0, $19" : "=r" (saved_context.cp0[19]));
asm volatile ("mfc0 %0, $20" : "=r" (saved_context.cp0[20]));
asm volatile ("mfc0 %0, $21" : "=r" (saved_context.cp0[21]));
asm volatile ("mfc0 %0, $22" : "=r" (saved_context.cp0[22]));
asm volatile ("mfc0 %0, $23" : "=r" (saved_context.cp0[23]));
asm volatile ("mfc0 %0, $24" : "=r" (saved_context.cp0[24]));
asm volatile ("mfc0 %0, $25" : "=r" (saved_context.cp0[25]));
asm volatile ("mfc0 %0, $26" : "=r" (saved_context.cp0[26]));
asm volatile ("mfc0 %0, $27" : "=r" (saved_context.cp0[27]));
asm volatile ("mfc0 %0, $28" : "=r" (saved_context.cp0[28]));
asm volatile ("mfc0 %0, $29" : "=r" (saved_context.cp0[29]));
asm volatile ("mfc0 %0, $30" : "=r" (saved_context.cp0[30]));
asm volatile ("mfc0 %0, $31" : "=r" (saved_context.cp0[31]));
}
void save_processor_state(void)
{
printk("[DEBUG] before __save_processor_state() %s,%d\n",__FILE__,__LINE__);
__save_processor_state();
printk("[DEBUG] after __save_processor_state() %s,%d\n",__FILE__,__LINE__);
}
void __restore_processor_state(void)
{
/*
* first restore %ds, so we can access our data properly
*/
asm volatile (".align 4");
// asm volatile ("movw %0, %%ds" :: "r" ((u16)__KERNEL_DS));
/*
* coprocessor 0 registers (inclde/asm-mips/mipsregs.h)
*/
asm volatile ("mtc0 %0, $0" : : "r" (saved_context.cp0[0]));
asm volatile ("mtc0 %0, $1" : : "r" (saved_context.cp0[1]));
asm volatile ("mtc0 %0, $2" : : "r" (saved_context.cp0[2]));
asm volatile ("mtc0 %0, $3" : : "r" (saved_context.cp0[3]));
asm volatile ("mtc0 %0, $4" : : "r" (saved_context.cp0[4]));
asm volatile ("mtc0 %0, $5" : : "r" (saved_context.cp0[5]));
asm volatile ("mtc0 %0, $6" : : "r" (saved_context.cp0[6]));
asm volatile ("mtc0 %0, $7" : : "r" (saved_context.cp0[7]));
asm volatile ("mtc0 %0, $8" : : "r" (saved_context.cp0[8]));
asm volatile ("mtc0 %0, $9" : : "r" (saved_context.cp0[9]));
asm volatile ("mtc0 %0, $10" : : "r" (saved_context.cp0[10]));
asm volatile ("mtc0 %0, $11" : : "r" (saved_context.cp0[11]));
asm volatile ("mtc0 %0, $12" : : "r" (saved_context.cp0[12]));
asm volatile ("mtc0 %0, $13" : : "r" (saved_context.cp0[13]));
asm volatile ("mtc0 %0, $14" : : "r" (saved_context.cp0[14]));
asm volatile ("mtc0 %0, $15" : : "r" (saved_context.cp0[15]));
asm volatile ("mtc0 %0, $16" : : "r" (saved_context.cp0[16]));
asm volatile ("mtc0 %0, $17" : : "r" (saved_context.cp0[17]));
asm volatile ("mtc0 %0, $18" : : "r" (saved_context.cp0[18]));
asm volatile ("mtc0 %0, $19" : : "r" (saved_context.cp0[19]));
asm volatile ("mtc0 %0, $20" : : "r" (saved_context.cp0[20]));
asm volatile ("mtc0 %0, $21" : : "r" (saved_context.cp0[21]));
asm volatile ("mtc0 %0, $22" : : "r" (saved_context.cp0[22]));
asm volatile ("mtc0 %0, $23" : : "r" (saved_context.cp0[23]));
asm volatile ("mtc0 %0, $24" : : "r" (saved_context.cp0[24]));
asm volatile ("mtc0 %0, $25" : : "r" (saved_context.cp0[25]));
asm volatile ("mtc0 %0, $26" : : "r" (saved_context.cp0[26]));
asm volatile ("mtc0 %0, $27" : : "r" (saved_context.cp0[27]));
asm volatile ("mtc0 %0, $28" : : "r" (saved_context.cp0[28]));
asm volatile ("mtc0 %0, $29" : : "r" (saved_context.cp0[29]));
asm volatile ("mtc0 %0, $30" : : "r" (saved_context.cp0[30]));
asm volatile ("mtc0 %0, $31" : : "r" (saved_context.cp0[31]));
/*
* special registers
*/
asm volatile ("mthi %0" : : "r" (saved_context.hi));
asm volatile ("mtlo %0" : : "r" (saved_context.lo));
/*
* the other general registers
*
* note that even though gcc has constructs to specify memory
* input into certain registers, it will try to be too smart
* and save them at the beginning of the function. This is esp.
* bad since we don't have a stack set up when we enter, and we
* want to preserve the values on exit. So, we set them manually.
*/
asm volatile ("lw $3, (%0)" : : "r" (&saved_context.v[1]));
asm volatile ("lw $4, (%0)" : : "r" (&saved_context.a[0]));
asm volatile ("lw $5, (%0)" : : "r" (&saved_context.a[1]));
asm volatile ("lw $6, (%0)" : : "r" (&saved_context.a[2]));
asm volatile ("lw $7, (%0)" : : "r" (&saved_context.a[3]));
asm volatile ("lw $8, (%0)" : : "r" (&saved_context.t[0]));
asm volatile ("lw $9, (%0)" : : "r" (&saved_context.t[1]));
asm volatile ("lw $10, (%0)" : : "r" (&saved_context.t[2]));
asm volatile ("lw $11, (%0)" : : "r" (&saved_context.t[3]));
asm volatile ("lw $12, (%0)" : : "r" (&saved_context.t[4]));
asm volatile ("lw $13, (%0)" : : "r" (&saved_context.t[5]));
asm volatile ("lw $14, (%0)" : : "r" (&saved_context.t[6]));
asm volatile ("lw $15, (%0)" : : "r" (&saved_context.t[7]));
asm volatile ("lw $16, (%0)" : : "r" (&saved_context.s[0]));
asm volatile ("lw $17, (%0)" : : "r" (&saved_context.s[1]));
asm volatile ("lw $18, (%0)" : : "r" (&saved_context.s[2]));
asm volatile ("lw $19, (%0)" : : "r" (&saved_context.s[3]));
asm volatile ("lw $20, (%0)" : : "r" (&saved_context.s[4]));
asm volatile ("lw $21, (%0)" : : "r" (&saved_context.s[5]));
asm volatile ("lw $22, (%0)" : : "r" (&saved_context.s[6]));
asm volatile ("lw $23, (%0)" : : "r" (&saved_context.s[7]));
asm volatile ("lw $24, (%0)" : : "r" (&saved_context.t[8]));
asm volatile ("lw $25, (%0)" : : "r" (&saved_context.t[9]));
asm volatile ("lw $26, (%0)" : : "r" (&saved_context.k[0]));
asm volatile ("lw $27, (%0)" : : "r" (&saved_context.k[1]));
asm volatile ("lw $28, (%0)" : : "r" (&saved_context.gp));
asm volatile ("lw $29, (%0)" : : "r" (&saved_context.sp));
asm volatile ("lw $30, (%0)" : : "r" (&saved_context.fp));
asm volatile ("lw $31, (%0)" : : "r" (&saved_context.ra));
// Good job 'v0'. It's your turn!
asm volatile ("lw $2, (%0)" : : "r" (&saved_context.v[0]));
preempt_enable();
}
void restore_processor_state(void)
{
printk("[DEBUG] before __restore_processor_state()
%s,%d\n",__FILE__,__LINE__);
__restore_processor_state();
printk("[DEBUG] after __restore_processor_state()
%s,%d\n",__FILE__,__LINE__);
}
/* Needed by apm.c */
EXPORT_SYMBOL(save_processor_state);
EXPORT_SYMBOL(restore_processor_state);
==============================================
Kernel Panic Message
==============================================
kswapd0 left refrigerator, kernel/power/process.c,67
init left refrigerator, kernel/power/process.c,67
CPU 0 Unable to handle kernel paging request at virtual address
fffff689, epc == 801e258c, ra == 801e2c44
Oops in arch/mips/mm/fault.c::do_page_fault, line 204[#1]:
Cpu 0
$ 0 : 00000000 1000f800 fffff689 80364418
$ 4 : 80364018 00000400 fffff689 8038ff34
$ 8 : 00004642 802f3e28 80370000 80370000
$12 : 80370000 fffffffa ffffffff 0000000a
$16 : 80364018 80364417 1000f801 8038ff34
$20 : 00000000 802f0000 80364018 00000400
$24 : 00000001 8038fd22
$28 : 8038e000 8038fe80 8014a438 801e2c44
Hi : 00000083
Lo : e42b2000
epc : 801e258c vsnprintf+0x58/0x6fc Tainted: P
ra : 801e2c44 vscnprintf+0x14/0x30
Status: 1000f802 KERNEL EXL
Cause : 00800008
BadVA : fffff689
PrId : 00018448
Modules linked in: rfs atyx220 atifplib
Process init (pid: 1, threadinfo=8038e000, task=80388b90)
Stack 1: 8031e920 0000305f 000030b0 802f0000 802f0000 802f3e28 80370000 80370000
00000400 802f0000 1000f801 8014a438 00000000 802f0000 802e0000 8014a438
801e2c44 000030b0 80126a24 80126b5c fffff689 8014a438 80360000 80126d00
80364069 802f0000 1000f800 802f3e28 00000051 802f0000 00000001 802f0000
8014a438 8014a438 00000000 80126edc 80126f78 8014a438 00000000 80126edc
802e0000 8014a438 8014a440 8014a438 8014a438 802f0000 00000001 00000000
8014a438 8014a438 8014a438 8014a438 8025305c 00000000 ffffffff 802df120
000000fc 8037a4c8 8014a438 8014a45c 8038ae40 802f0000 00000001 00000000
00000003 0a737974 7fff7c70 00000003 00410000 00000000 7fff7f14 00000001
00000001 00443f10 00000000 00492c80 00000000 00000000 1000e7a0 7fff7ba8
00443fd0 0040baf8 0000f813 00000000 00000000 1000e6f0 10800020 0047038c
55555555 55555555 55555555 55555555 55555555 55555555 55555555 55555555
Stack 2: fffff689 8038ff34 00004642 802f3e28 80370000 80370000 80370000 fffffffa
ffffffff 0000000a 80364018 80364417 1000f801 8038ff34 00000000 802f0000
80364018 00000400 00000001 8038fd22 801063dc 8010d6f4 8038e000 8038fe80
8014a438 801e2c44 1000f802 e42b2000 00000083 fffff689 00800008 801e258c
...
Call Trace:
[<8014a438>] swsusp_suspend+0x78/0xc0
[<8014a438>] swsusp_suspend+0x78/0xc0
[<801e2c44>] vscnprintf+0x14/0x30
[<80126a24>] release_console_sem+0xec/0x364
[<80126b5c>] release_console_sem+0x224/0x364
[<8014a438>] swsusp_suspend+0x78/0xc0
[<80126d00>] vprintk+0x64/0x2c0
[<8014a438>] swsusp_suspend+0x78/0xc0
[<8014a438>] swsusp_suspend+0x78/0xc0
[<80126edc>] vprintk+0x240/0x2c0
[<80126f78>] printk+0x1c/0x28
[<8014a438>] swsusp_suspend+0x78/0xc0
[<80126edc>] vprintk+0x240/0x2c0
[<8014a438>] swsusp_suspend+0x78/0xc0
[<8014a440>] swsusp_suspend+0x80/0xc0
[<8014a438>] swsusp_suspend+0x78/0xc0
[<8014a438>] swsusp_suspend+0x78/0xc0
[<8014a438>] swsusp_suspend+0x78/0xc0
[<8014a438>] swsusp_suspend+0x78/0xc0
[<8014a438>] swsusp_suspend+0x78/0xc0
[<8014a438>] swsusp_suspend+0x78/0xc0
[<8025305c>] restore_processor_state+0x24/0x5c
[<8014a438>] swsusp_suspend+0x78/0xc0
[<8014a45c>] swsusp_suspend+0x9c/0xc0
Code:
18400009 25adffff 24040020 020c102b 01a01821 14400002
25adffff a1840000
1c60fffa 258c0001 01801821 8fb70064 8fb60060 8fb5005c
8fb40058 8fb30054
8fb20050 8fb1004c 8fb00048 00601021 03e00008 27bd0068
04e00041 00111082
30420001 14400033 001110c2 30420001 1040ff90 00119142
25adffff 08078890
24150020 0807892c 00c71025 00071002 00402021 10400004
25ce0001 004f001b
00002012 00001010 00804021 00c03821 00402021 0000b021
0000b821 10000006
24050021 00040840 0004bfc2 00232025 00073840 0016b040
16e00002 008f182b
14600003 24a5ffff 008f2023 26d60001 14a0fff4 00071fc2
00942021 90850000
00081800 00001021 00005821 00564025 006b4825 01003021
01203821 01091025
a3250000 1440ffd9 01ddc821 0807889f 030e102a 25adffff
0807888f 2415002b
020c102b 14400002 24020030 a1820000 080788bd 258c0001
08078898 25adfffe
00063023 00073823 0006102b 00e23823 25adffff 0807888f
2415002d 10400008
24020030 258c0001 020c102b 1440fff0 00000000 92820021
08078937 a1820000
08078944 a1820000 27bdffb8 afb7003c afb60038 afb3002c
afbf0040 afb50034
afb40030 afb20028 afb10024 afb00020 00a0b821 0080b021
afa60050 04a000c7
00e09821 00851821 2471ffff 2482ffff 0222102b 14400023
00808021 00c01021
<90440000> 10800010 00403021 00041e00 00031e03 24020025
1062001d 0230102b
14400004 24c20001 a2040000 8fa60050 24c20001 26100001
afa20050 90440000
1480fff2 00403021 0230102b 1440001e 02161023 a2000000
8fbf0040 8fb7003c
8fb60038 8fb50034 8fb40030 8fb3002c 8fb20028 8fb10024
8fb00020 03e00008
27bd0048 2411ffff 08078962 0004b823 00009021 24c60001
afa60050 80c20000
2442ffe0 2c430011 1060000b 3c03802d 00021080 24638d8c
00431021 8c440000
00800008 00000000 12e0ffe3 00000000 08078979 a2200000
90c50000 3c148032
2682d560 30a300ff 00621821 90640000 00042082 30840001
14800049 2415ffff
00051e00 00031e03 2402002a 1062006c 26620003 80c30000
2402002e 10620048
2408ffff 80c40000 38830068 3882006c 2c630001 2c420001
00621825 14600025
2405ffff 2402004c 10820022 2402005a 10820020 2402007a
1082001e 00000000
80c30000 2463ffdb 2c620054 14400025 2409000a 0230102b
14400003 24020025
a2020000 8fa60050 90c30000 1060003d 26100001 0230102b
1440ffa6 24c20001
a2030000 0807896f 8fa60050 08078988 36520001 08078988
36520010 08078988
36520004 08078988 36520020 08078988 36520008 80c50000
2402006c 24c60001
14a2ffdf afa60050 80c20000 1445ffdc 00000000 24c60001
2405004c 080789bb
Kernel panic - not syncing: Attempted to kill init!
--
Hyon Lim (임현)
Mobile. 010-8212-1240 (Intl' Call : +82-10-8212-1240)
Fax. 032-232-0578 (Intl' Available)
Homepage : http://www.alexlab.net
Blog : http://www.alexlab.net/blog
^ permalink raw reply
* [PATCH] Use strchr instead of strstr in mips/fw/arc/cmdline.c
From: Roel Kluin @ 2007-11-02 18:59 UTC (permalink / raw)
To: linux-mips
Use strchr instead of strstr when searching for a single character
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/mips/fw/arc/cmdline.c b/arch/mips/fw/arc/cmdline.c
index fd604ef..4ca4eef 100644
--- a/arch/mips/fw/arc/cmdline.c
+++ b/arch/mips/fw/arc/cmdline.c
@@ -52,7 +52,7 @@ static char * __init move_firmware_args(char* cp)
strcat(cp, used_arc[i][1]);
cp += strlen(used_arc[i][1]);
/* ... and now the argument */
- s = strstr(prom_argv(actr), "=");
+ s = strchr(prom_argv(actr), '=');
if (s) {
s++;
strcpy(cp, s);
^ permalink raw reply related
* Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent
From: Thomas Bogendoerfer @ 2007-11-02 22:08 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071102122001.GC22829@linux-mips.org>
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...
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent
From: Ralf Baechle @ 2007-11-04 0:33 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071102220819.GA20792@alpha.franken.de>
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
high rating of 300 while the PIT because of an omission or intension
doesn't set it's rating at all so has rating of 0. So Linux prefers the
R4030. You can see which clockevent device is actually getting used
by Linux in /proc/timer_list.
Ralf
^ permalink raw reply
* [PATCH] Kill __bzero()
From: Franck Bui-Huu @ 2007-11-04 8:18 UTC (permalink / raw)
To: Ralf Baechle; +Cc: 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>
---
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.
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 | 2 +-
5 files changed, 4 insertions(+), 8 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..9b8234a 100644
--- a/include/asm-mips/uaccess.h
+++ b/include/asm-mips/uaccess.h
@@ -643,7 +643,7 @@ __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)
--
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 8:21 UTC (permalink / raw)
To: Nigel Stephens; +Cc: Thiemo Seufer, Maciej W. Rozycki, Ralf Baechle, linux-mips
In-Reply-To: <47160D31.5080201@mips.com>
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 ?
thanks,
Franck
^ permalink raw reply
* 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
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