* Re: Cache aliasing issues using 4K pages.
From: Thiemo Seufer @ 2008-01-15 11:57 UTC (permalink / raw)
To: Luc Perneel; +Cc: linux-mips
In-Reply-To: <1a18fe6d0801142250h7ce58675i2bce7cb2e2db2669@mail.gmail.com>
Luc Perneel wrote:
> On Jan 15, 2008 2:58 AM, Thiemo Seufer <ths@networkno.de> wrote:
>
> > The Engineer wrote:
> > > We are working with a 2.6.12 kernel on a dual-core mips architecture.
> > > In this dual-core system, one core is running the linux kernel and the
> > > other is used for some real-time handling (not directly controlled by
> > > Linux)
> > > We had different stability issues, which could be pinpointed to be
> > > related with cache aliasing problems.
> > > Cache aliasing happens when the same physical memory can be cached
> > > twice as it is accessed by two different virtual addresses.
> > > Indeed, for the index to select the correct cache line the virtual
> > > address is used. If some bits of the virtual page address are used in
> > > the cache index, aliasing can occur.
> > >
> > >
> > > As there is no hardware solution in the mips to recover from this
> > > (which would provide some cache coherency, even for one core), the
> > > only intrinsic safe solution is to enlarge the page size, so that
> > > cache indexing is only done by the offset address in the page (thus
> > > the physical part of the address).
> > > Another solution is to flush the cache if a page is being remapped to
> > > an aliased address (but in our case linux does not has control on the
> > > second core, which can cause issues with shared data between both
> > > cores).
> > > Currently the second solution is used in the kernel, but we found
> > > different issues with it (for instance: we had to merge more recent
> > > mips kernels, to get a reliable copy-on-write behaviour after
> > > forks...).
> > >
> > > Therefore some questions:
> > > - Are there still some known issues with cache aliasing in the MIPS
> > kernel?
> > > - Are there known issues when using 16KB pages (8KB pages seems not be
> > > possible due to tlb issues).
> >
> > With recent kernels and toolchains 16k pages work ok IME. With a 2.6.12
> > kernel however you'll have to backport a serious amount of bugfixes
> > before 16k pages can work. Upgrading the kernel is probably less work.
> >
> > Thiemo
> >
> Thanks for the info, any idea from which kernel this works ok?
I believe the linux-2.6.22-stable branch from www.linux-mips.org is the
best version to use. I don't recall if the earlier branches got all the
necessary fixes.
Thiemo
^ permalink raw reply
* Re: [SPAM] [PATCH][MIPS] Add Atlas to feature-removal-schedule.
From: Maciej W. Rozycki @ 2008-01-15 12:03 UTC (permalink / raw)
To: Dmitri Vorobiev
Cc: Geert Uytterhoeven, Ralf Baechle, linux-mips, Linux-kernel
In-Reply-To: <478BEDD7.6070100@gmail.com>
On Tue, 15 Jan 2008, Dmitri Vorobiev wrote:
> >> +
> >> +What: Support for MIPS Technologies' Altas evaluation board
> > ^^^^^
> > Atlas
>
> This is what happens when doing things in a rush. Thanks, Geert.
Hmm, I wonder why you'd be in such a rush to remove my pet project... ;-)
The last time I tried it worked; unfortunately I have since been taken
away my second serial port that I used as a terminal device for the Atlas
lying next to me and the first port I have in continuous use. I'll see if
I can give it a hit before March though -- any issues with the port should
be minimal.
Maciej
^ permalink raw reply
* Re: Tester with IP27/IP30 needed
From: Ralf Baechle @ 2008-01-15 13:11 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20080115112420.GA7347@alpha.franken.de>
On Tue, Jan 15, 2008 at 12:24:20PM +0100, Thomas Bogendoerfer wrote:
> we are facing a strange problem with lenny/sid chroots on IP28. The
> machine locks up after issuing a few ls/ps commands in a chroot
> bash. This only happens with a lenny/sid chroot, but not with etch.
> The major difference is probably the updare to glibc2.7. Since
> IP28 isn't really a nice R10k machine, it would be good, if someone
> with a working IP27/IP30 could try a lenny/sid chroot and tell us,
> if it's working/not working.
Which CPU revision do you hit these problems on?
Ralf
^ permalink raw reply
* Re: [SPAM] [PATCH][MIPS] Add Atlas to feature-removal-schedule.
From: Dmitri Vorobiev @ 2008-01-15 13:25 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Geert Uytterhoeven, Ralf Baechle, linux-mips, Linux-kernel
In-Reply-To: <Pine.LNX.4.64N.0801151156460.23975@blysk.ds.pg.gda.pl>
Maciej W. Rozycki пишет:
> On Tue, 15 Jan 2008, Dmitri Vorobiev wrote:
>
>>>> +
>>>> +What: Support for MIPS Technologies' Altas evaluation board
>>> ^^^^^
>>> Atlas
>> This is what happens when doing things in a rush. Thanks, Geert.
>
> Hmm, I wonder why you'd be in such a rush to remove my pet project... ;-)
> The last time I tried it worked; unfortunately I have since been taken
This was my way of reasoning here:
1) I would like to make a massive cleanup in the arch/mips/mips-boards
for the reasons explained here:
http://www.linux-mips.org/archives/linux-mips/2008-01/msg00136.html
2) Removing Atlas would reduce the clean-up effort.
3) According to Ralf, the user base for Atlas is zero, the board itself
is buggy.
4) History knows of an attempt to remove Atlas:
http://www.linux-mips.org/archives/linux-mips/2007-06/msg00153.html
5) Nobody is losing, man-hours are saved. No explanation of why not to do that.
Hence, the patch to the feature-removal-schedule.txt.
> away my second serial port that I used as a terminal device for the Atlas
> lying next to me and the first port I have in continuous use. I'll see if
> I can give it a hit before March though -- any issues with the port should
> be minimal.
It would be nice if you could take a look at that (please see the "P.S." part):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=84c21e254205ecac98f75b01589996440c6a6db0
>
> Maciej
>
^ permalink raw reply
* Re: Tester with IP27/IP30 needed
From: Ralf Baechle @ 2008-01-15 13:53 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20080115131145.GA5189@linux-mips.org>
On Tue, Jan 15, 2008 at 01:11:45PM +0000, Ralf Baechle wrote:
> > we are facing a strange problem with lenny/sid chroots on IP28. The
> > machine locks up after issuing a few ls/ps commands in a chroot
> > bash. This only happens with a lenny/sid chroot, but not with etch.
> > The major difference is probably the updare to glibc2.7. Since
> > IP28 isn't really a nice R10k machine, it would be good, if someone
> > with a working IP27/IP30 could try a lenny/sid chroot and tell us,
> > if it's working/not working.
>
> Which CPU revision do you hit these problems on?
On IRC Thomas said it's rev 2.5.
R10000 upto version 2.6 has a broken store conditional so needs
R10000_LLSC_WAR enabled. The sympthom is that SC succeed even though
it should have failed so for example two multiple competing CPUs can
take a spinlock. There is an erratum for this one.
Another bug is when a rdhwr $29 opcode is encountered in a branch delay
slot. This will result in the CPU stopping execution of instructions
but an NMI can recover it. For emulation performance reasons gcc no
longer places rdhwr $29 in delay slots, so this one is no longer
encountered in C code but still could be in assembler code. This one
isn't covered by any errata.
There seem to be more funnies but to the best I can say they were never
officially documented in errata either.
Ralf
^ permalink raw reply
* Re: [SPAM] [PATCH][MIPS] Add Atlas to feature-removal-schedule.
From: Maciej W. Rozycki @ 2008-01-15 13:57 UTC (permalink / raw)
To: Dmitri Vorobiev
Cc: Geert Uytterhoeven, Ralf Baechle, linux-mips, Linux-kernel
In-Reply-To: <478CB437.9080006@gmail.com>
On Tue, 15 Jan 2008, Dmitri Vorobiev wrote:
> 1) I would like to make a massive cleanup in the arch/mips/mips-boards
> for the reasons explained here:
>
> http://www.linux-mips.org/archives/linux-mips/2008-01/msg00136.html
You are certainly welcome to do so!
> 2) Removing Atlas would reduce the clean-up effort.
You can make it a bonus project ;-) -- I would certainly do some testing
with real hardware if pieces of software start flying by.
> 3) According to Ralf, the user base for Atlas is zero, the board itself
> is buggy.
The Ethernet controller embedded in the onboard SAA9730 chip is
questionable, though some of the problems are apparently the result of our
buggy driver. For example the settings of the PHY chip are not
synchronised to what is set in the MAC. I cleaned up a lot of cruft at
one point, but more can apparently be done. Switching to PHYLIB could
help and is on my to-do list. The PHY is a QS6612 and is already
supported by PHYLIB.
Otherwise the board is just fine, though perhaps a little bit strange --
no south bridge for example (i.e. no subtractive ISA/LPC decoding, nor
8259A or 8237A cores within), though the SAA9730 does implicit active
decoding (i.e. not through PCI BARs) of some addresses that used to be
assigned to motherboard devices in the PC/AT architecture (most notably
the keyboard controller). Essentially a PCI-based junk I/O controller of
some sort.
> 4) History knows of an attempt to remove Atlas:
>
> http://www.linux-mips.org/archives/linux-mips/2007-06/msg00153.html
Yes, I know.
> 5) Nobody is losing, man-hours are saved. No explanation of why not to do that.
> Hence, the patch to the feature-removal-schedule.txt.
Well, I am always uneasy about removing stuff that is sufficiently
different from what keeps being supported as quite frequently apparently
oversimplification decisions are made afterwards which make the addition
of support for less usual designs that appear later on unnecessarily
painful.
> It would be nice if you could take a look at that (please see the "P.S." part):
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=84c21e254205ecac98f75b01589996440c6a6db0
I have seen this, thanks. I'll have look, time permitting.
Maciej
^ permalink raw reply
* Re: [SPAM] [PATCH][MIPS] Add Atlas to feature-removal-schedule.
From: Dmitri Vorobiev @ 2008-01-15 14:18 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Geert Uytterhoeven, Ralf Baechle, linux-mips, Linux-kernel
In-Reply-To: <Pine.LNX.4.64N.0801151338150.23975@blysk.ds.pg.gda.pl>
Maciej W. Rozycki пишет:
> On Tue, 15 Jan 2008, Dmitri Vorobiev wrote:
>
>> 1) I would like to make a massive cleanup in the arch/mips/mips-boards
>> for the reasons explained here:
>>
>> http://www.linux-mips.org/archives/linux-mips/2008-01/msg00136.html
>
> You are certainly welcome to do so!
>
>> 2) Removing Atlas would reduce the clean-up effort.
>
> You can make it a bonus project ;-) -- I would certainly do some testing
> with real hardware if pieces of software start flying by.
OK, thanks for your reply. I'll try to proceed with the cleanup without
removing Atlas.
Dmitri
^ permalink raw reply
* Re: memory related kernel bug on cobalt raq2
From: Noah Meyerhans @ 2008-01-15 15:26 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20080115153225.1ee724c8.yoichi_yuasa@tripeaks.co.jp>
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
On Tue, Jan 15, 2008 at 03:32:25PM +0900, Yoichi Yuasa wrote:
> On Mon, 14 Jan 2008 10:31:14 -0500
> Noah Meyerhans <frodo@morgul.net> wrote:
>
> > Hi all. I know this has come up in the past, but in case it's helpful, I
> > figured I'd report that the kernel bug previously reported at (at least)
> > http://www.linux-mips.org/archives/linux-mips/2007-10/msg00093.html is still
> > present in current git kernels (more recently observed in
> > 2.6.24-rc7-raq2-gaeb7040e-dirty). Here's the kernel output:
>
> Do you use swap on your raq2?
>
Yes, I have 256 MB RAM and 500 MB swap.
noah
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Gregor Waltz @ 2008-01-15 15:50 UTC (permalink / raw)
Cc: linux-mips
In-Reply-To: <20080112.211749.25909440.anemo@mba.ocn.ne.jp>
Atsushi Nemoto wrote:
> On Fri, 11 Jan 2008 12:49:49 -0500, Gregor Waltz <gregor.waltz@raritan.com> wrote:
>
>> I built linux-2.6.23.9 with the above, but the results are still the
>> same and the EPC is not in System.map.
>>
>
> Are you searching the exact EPC value in System.map?
> Usually you should find a function symbol which contains the EPC value in it.
>
> Or you can do "mipsel-linux-objdump -d vmlinux" and search the EPC value.
>
The current error is:
Exception! EPC=80026290 CAUSE=00000020(Sys)
80026290 0000000c syscall
80026290 is not in System.map, however, the objdump is much more
informative and does contain that value. That particular syscall is in:
8002628c <kernel_execve>:
8002628c: 24020fab li v0,4011
80026290: 0000000c syscall
80026294: 00401821 move v1,v0
80026298: 14e00003 bnez a3,800262a8 <kernel_execve+0x1c>
8002629c: 00000000 nop
800262a0: 03e00008 jr ra
800262a4: 00601021 move v0,v1
800262a8: 03e00008 jr ra
800262ac: 00031023 negu v0,v1
Does that provide any clues?
I have to go now. I will take another look when I return, but I have
looked at kernel_execve before.
Thanks
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Gregor Waltz @ 2008-01-15 15:50 UTC (permalink / raw)
Cc: linux-mips
In-Reply-To: <20080112.211749.25909440.anemo@mba.ocn.ne.jp>
Atsushi Nemoto wrote:
> On Fri, 11 Jan 2008 12:49:49 -0500, Gregor Waltz <gregor.waltz@raritan.com> wrote:
>
>> I built linux-2.6.23.9 with the above, but the results are still the
>> same and the EPC is not in System.map.
>>
>
> Are you searching the exact EPC value in System.map?
> Usually you should find a function symbol which contains the EPC value in it.
>
> Or you can do "mipsel-linux-objdump -d vmlinux" and search the EPC value.
>
The current error is:
Exception! EPC=80026290 CAUSE=00000020(Sys)
80026290 0000000c syscall
80026290 is not in System.map, however, the objdump is much more
informative and does contain that value. That particular syscall is in:
8002628c <kernel_execve>:
8002628c: 24020fab li v0,4011
80026290: 0000000c syscall
80026294: 00401821 move v1,v0
80026298: 14e00003 bnez a3,800262a8 <kernel_execve+0x1c>
8002629c: 00000000 nop
800262a0: 03e00008 jr ra
800262a4: 00601021 move v0,v1
800262a8: 03e00008 jr ra
800262ac: 00031023 negu v0,v1
Does that provide any clues?
I have to go now. I will take another look when I return, but I have
looked at kernel_execve before.
Thanks
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Thiemo Seufer @ 2008-01-15 16:14 UTC (permalink / raw)
To: Gregor Waltz; +Cc: linux-mips
In-Reply-To: <478CD639.3040307@raritan.com>
Gregor Waltz wrote:
> Atsushi Nemoto wrote:
>> On Fri, 11 Jan 2008 12:49:49 -0500, Gregor Waltz <gregor.waltz@raritan.com> wrote:
>>
>>> I built linux-2.6.23.9 with the above, but the results are still the
>>> same and the EPC is not in System.map.
>>>
>>
>> Are you searching the exact EPC value in System.map?
>> Usually you should find a function symbol which contains the EPC value in it.
>>
>> Or you can do "mipsel-linux-objdump -d vmlinux" and search the EPC value.
>>
>
>
> The current error is:
> Exception! EPC=80026290 CAUSE=00000020(Sys)
> 80026290 0000000c syscall
>
> 80026290 is not in System.map, however, the objdump is much more
> informative and does contain that value. That particular syscall is in:
>
> 8002628c <kernel_execve>:
> 8002628c: 24020fab li v0,4011
> 80026290: 0000000c syscall
> 80026294: 00401821 move v1,v0
> 80026298: 14e00003 bnez a3,800262a8 <kernel_execve+0x1c>
> 8002629c: 00000000 nop
> 800262a0: 03e00008 jr ra
> 800262a4: 00601021 move v0,v1
> 800262a8: 03e00008 jr ra
> 800262ac: 00031023 negu v0,v1
>
> Does that provide any clues?
The kernel failed to set up the general exception handler correctly.
It should have done that before attempting to start the first kernel
thread.
Thiemo
^ permalink raw reply
* pmag-aa-fb
From: Geert Uytterhoeven @ 2008-01-15 17:41 UTC (permalink / raw)
To: Karsten Merker, Thiemo Seufer; +Cc: Linux/MIPS Development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 826 bytes --]
I've just noticed drivers/video/pmag-aa-fb.c is the single remaining frame
buffer device driver that still uses the old 2.4 API (all others have been
converted or removed). So it doesn't work anymore.
Does anyone still care about it?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: pmag-aa-fb
From: Maciej W. Rozycki @ 2008-01-15 17:52 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Karsten Merker, Thiemo Seufer, Linux/MIPS Development
In-Reply-To: <Pine.LNX.4.64.0801151831370.12445@vixen.sonytel.be>
On Tue, 15 Jan 2008, Geert Uytterhoeven wrote:
> I've just noticed drivers/video/pmag-aa-fb.c is the single remaining frame
> buffer device driver that still uses the old 2.4 API (all others have been
> converted or removed). So it doesn't work anymore.
>
> Does anyone still care about it?
Probably. I have the right piece of hardware (thanks, Thiemo), but
little time these days. I mean to have a look at it, but I have no
timeline, sorry. I started converting it at one point, but I recall I
stumbled on porting the hardware cursor support that turned out to be
unsupported with the new API or something.
Maciej
^ permalink raw reply
* Re: Tester with IP27/IP30 needed
From: Ralf Baechle @ 2008-01-15 18:18 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20080115135300.GB5189@linux-mips.org>
On Tue, Jan 15, 2008 at 01:53:00PM +0000, Ralf Baechle wrote:
> > > we are facing a strange problem with lenny/sid chroots on IP28. The
> > > machine locks up after issuing a few ls/ps commands in a chroot
> > > bash. This only happens with a lenny/sid chroot, but not with etch.
> > > The major difference is probably the updare to glibc2.7. Since
> > > IP28 isn't really a nice R10k machine, it would be good, if someone
> > > with a working IP27/IP30 could try a lenny/sid chroot and tell us,
> > > if it's working/not working.
> >
> > Which CPU revision do you hit these problems on?
>
> On IRC Thomas said it's rev 2.5.
>
> R10000 upto version 2.6 has a broken store conditional so needs
> R10000_LLSC_WAR enabled. The sympthom is that SC succeed even though
> it should have failed so for example two multiple competing CPUs can
> take a spinlock. There is an erratum for this one.
>
> Another bug is when a rdhwr $29 opcode is encountered in a branch delay
> slot. This will result in the CPU stopping execution of instructions
> but an NMI can recover it. For emulation performance reasons gcc no
> longer places rdhwr $29 in delay slots, so this one is no longer
> encountered in C code but still could be in assembler code. This one
> isn't covered by any errata.
>
> There seem to be more funnies but to the best I can say they were never
> officially documented in errata either.
So I tested the rootfs provided by Florian and more or less as expected
it immediately took out the 2 CPU R10000 v2.7 Origin I was testing on.
Seems like only one CPU stopped, as the machine was pinging and reacts
to NMIs. So could well be the effect I observed ages ago when trying to
convert to glibc 2.4.
Ralf
^ permalink raw reply
* [PATCH] Cobalt 64-bits kernels can be safely unmarked experimental
From: Florian Fainelli @ 2008-01-15 18:42 UTC (permalink / raw)
To: linux-mips, ralf
This patch removes the condition on
CONFIG_EXPERIMENTAL since 64-bits
cobalt kernels runs fine.
Signed-off-by: Florian Fainelli <florian.fainelli@telecomint.eu>
---
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index b22c043..da5c723 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -82,7 +82,7 @@ config MIPS_COBALT
select SYS_HAS_CPU_NEVADA
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_32BIT_KERNEL
- select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL
+ select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select GENERIC_HARDIRQS_NO__DO_IRQ
^ permalink raw reply related
* Re: [PATCH] Cobalt 64-bits kernels can be safely unmarked experimental
From: Ralf Baechle @ 2008-01-15 19:25 UTC (permalink / raw)
To: Florian Fainelli; +Cc: linux-mips
In-Reply-To: <200801151942.58038.florian.fainelli@telecomint.eu>
On Tue, Jan 15, 2008 at 07:42:57PM +0100, Florian Fainelli wrote:
> This patch removes the condition on
> CONFIG_EXPERIMENTAL since 64-bits
> cobalt kernels runs fine.
Applied, thanks.
Ralf
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Gregor Waltz @ 2008-01-15 20:05 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20080115161457.GB31107@networkno.de>
Thiemo Seufer wrote:
> Gregor Waltz wrote:
>
>> Atsushi Nemoto wrote:
>>
>>> On Fri, 11 Jan 2008 12:49:49 -0500, Gregor Waltz <gregor.waltz@raritan.com> wrote:
>>>
>>>
>>>> I built linux-2.6.23.9 with the above, but the results are still the
>>>> same and the EPC is not in System.map.
>>>>
>>>>
>>> Are you searching the exact EPC value in System.map?
>>> Usually you should find a function symbol which contains the EPC value in it.
>>>
>>> Or you can do "mipsel-linux-objdump -d vmlinux" and search the EPC value.
>>>
>>>
>> The current error is:
>> Exception! EPC=80026290 CAUSE=00000020(Sys)
>> 80026290 0000000c syscall
>>
>> 80026290 is not in System.map, however, the objdump is much more
>> informative and does contain that value. That particular syscall is in:
>>
>> 8002628c <kernel_execve>:
>> 8002628c: 24020fab li v0,4011
>> 80026290: 0000000c syscall
>> 80026294: 00401821 move v1,v0
>> 80026298: 14e00003 bnez a3,800262a8 <kernel_execve+0x1c>
>> 8002629c: 00000000 nop
>> 800262a0: 03e00008 jr ra
>> 800262a4: 00601021 move v0,v1
>> 800262a8: 03e00008 jr ra
>> 800262ac: 00031023 negu v0,v1
>>
>> Does that provide any clues?
>>
>
> The kernel failed to set up the general exception handler correctly.
> It should have done that before attempting to start the first kernel
> thread.
>
>
> Thiemo
>
From where in the kernel image should execution begin?
Presuming that the output of "objdump -d" reflects the disassembled
binary from the beginning in order, it looks like my 2.6 kernel is
running straight into run_init_process as the first real code executed.
From what I have seen in the kernel code, run_init_process should be
jumped to far later in the boot process. If what I am thinking is
correct, then it also explains why the failure happens in kernel_execve.
I have also included the start of my working kernel, which has _ftext
with non-zero data as its first entry. Is the _ftext the ELF header or
some other info for the boot loader?
Thanks
linux-2.6.23.9/vmlinux: file format elf32-tradlittlemips
Disassembly of section .text:
80020000 <run_init_process-0x400>:
...
80020400 <run_init_process>:
80020400: 3c028033 lui v0,0x8033
80020404: 3c068033 lui a2,0x8033
80020408: 244594dc addiu a1,v0,-27428
8002040c: 24c69450 addiu a2,a2,-27568
80020410: 080098a3 j 8002628c <kernel_execve> //
Should this be happening already?
80020414: ac4494dc sw a0,-27428(v0)
80020418 <init_post>:
run_init_process is from linux-2.6.23.9/init/main.c
Our working kernel starts differently:
linux-2.4.12/vmlinux: file format elf32-tradlittlemips
Disassembly of section .text:
80020000 <_ftext>:
80020000: 26 80 01 3c 14 42 3d ac 02 80 08 3c 80 04 08 25
&..<.B=....<...%
80020010: 08 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00
................
...
80020298 <except_vec2_generic>:
80020298: 401a8000 mfc0 k0,$16
8002029c: 241bfff8 li k1,-8
800202a0: 035bd024 and k0,k0,k1
800202a4: 375a0002 ori k0,k0,0x2
800202a8: 409a8000 mtc0 k0,$16
...
800202b8: 0800b248 j 8002c920 <cache_parity_error>
800202bc: 00000000 nop
800202c0 <except_vec4>:
^ permalink raw reply
* [PATCH] kernel make error - smtc_ipi.h irq flags, 2.6.24-rc7
From: Frank Rowand @ 2008-01-15 22:26 UTC (permalink / raw)
To: ralf, linux-mips
From: Frank Rowand <frank.rowand@am.sony.com>
Fix compile warning (which becomes compile error due to -Werror). Type of
argument "flags" for spin_lock_irqsave() was incorrect in some functions.
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
---
include/asm-mips/smtc_ipi.h | 6 3 + 3 - 0 !
1 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.24-rc7/include/asm-mips/smtc_ipi.h
===================================================================
--- linux-2.6.24-rc7.orig/include/asm-mips/smtc_ipi.h
+++ linux-2.6.24-rc7/include/asm-mips/smtc_ipi.h
@@ -49,7 +49,7 @@ struct smtc_ipi_q {
static inline void smtc_ipi_nq(struct smtc_ipi_q *q, struct smtc_ipi *p)
{
- long flags;
+ unsigned long flags;
spin_lock_irqsave(&q->lock, flags);
if (q->head == NULL)
@@ -98,7 +98,7 @@ static inline struct smtc_ipi *smtc_ipi_
static inline void smtc_ipi_req(struct smtc_ipi_q *q, struct smtc_ipi *p)
{
- long flags;
+ unsigned long flags;
spin_lock_irqsave(&q->lock, flags);
if (q->head == NULL) {
@@ -114,7 +114,7 @@ static inline void smtc_ipi_req(struct s
static inline int smtc_ipi_qdepth(struct smtc_ipi_q *q)
{
- long flags;
+ unsigned long flags;
int retval;
spin_lock_irqsave(&q->lock, flags);
^ permalink raw reply
* [PATCH 0/4] implement KGDB on Toshiba RBTX4927, 2.6.24-rc7
From: Frank Rowand @ 2008-01-15 22:28 UTC (permalink / raw)
To: ralf, linux-mips
From: Frank Rowand <frank.rowand@am.sony.com>
This set of patches adds support of KGDB on Toshiba RBTX4927 board.
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
---
^ permalink raw reply
* [PATCH 1/4] early_printk
From: Frank Rowand @ 2008-01-15 22:31 UTC (permalink / raw)
To: ralf, linux-mips
In-Reply-To: <1200436139.4092.30.camel@bx740>
From: Frank Rowand <frank.rowand@am.sony.com>
Implement early printk in the serial_txx9 driver, and enable for the
Toshiba RBTX4927 board. This is needed for the connect to GDB console
message.
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
---
arch/mips/Kconfig | 1 1 + 0 - 0 !
arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c | 6 6 + 0 - 0 !
drivers/serial/serial_txx9.c | 39 39 + 0 - 0 !
3 files changed, 46 insertions(+)
Index: linux-2.6.24-rc7/arch/mips/Kconfig
===================================================================
--- linux-2.6.24-rc7.orig/arch/mips/Kconfig
+++ linux-2.6.24-rc7/arch/mips/Kconfig
@@ -631,6 +631,7 @@ config TOSHIBA_RBTX4927
select I8259 if TOSHIBA_FPCIB0
select SWAP_IO_SPACE
select SYS_HAS_CPU_TX49XX
+ select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
Index: linux-2.6.24-rc7/drivers/serial/serial_txx9.c
===================================================================
--- linux-2.6.24-rc7.orig/drivers/serial/serial_txx9.c
+++ linux-2.6.24-rc7/drivers/serial/serial_txx9.c
@@ -1198,6 +1198,45 @@ MODULE_DEVICE_TABLE(pci, serial_txx9_pci
static struct platform_device *serial_txx9_plat_devs;
+#ifdef CONFIG_EARLY_PRINTK
+
+/*
+ * Do NOT request the console resources, allows normal driver to initialize
+ * console later.
+ */
+
+static int prom_putchar_port = -1;
+
+void early_printk_serial_txx9_console_setup(void)
+{
+ prom_putchar_port = 0;
+}
+
+void prom_putchar(char ch)
+{
+ unsigned int status;
+ struct uart_txx9_port *up;
+
+ if (prom_putchar_port == -1)
+ return;
+
+ up = &serial_txx9_ports[prom_putchar_port];
+
+ if (ch == '\n')
+ prom_putchar('\r');
+
+ while (1) {
+ status = sio_in(up, TXX9_SICISR);
+ if (status & TXX9_SICISR_TRDY) {
+ sio_out(up, TXX9_SITFIFO, (u32)ch);
+ break;
+ }
+ }
+}
+
+#endif
+
+
static int __init serial_txx9_init(void)
{
int ret;
Index: linux-2.6.24-rc7/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
===================================================================
--- linux-2.6.24-rc7.orig/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
+++ linux-2.6.24-rc7/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
@@ -913,6 +913,12 @@ void __init toshiba_rbtx4927_setup(void)
if (strstr(argptr, "console=") == NULL) {
strcat(argptr, " console=ttyS0,38400");
}
+#ifdef CONFIG_EARLY_PRINTK
+ {
+ extern void early_printk_serial_txx9_console_setup(void);
+ early_printk_serial_txx9_console_setup();
+ }
+#endif
#endif
#endif
^ permalink raw reply
* [PATCH 3/4] serial_txx9 driver support
From: Frank Rowand @ 2008-01-15 22:33 UTC (permalink / raw)
To: ralf, linux-mips
In-Reply-To: <1200436139.4092.30.camel@bx740>
From: Frank Rowand <frank.rowand@am.sony.com>
Add polled debug driver support to serial_txx9.c for kgdb, and initialize
the driver for the Toshiba RBTX4927.
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
---
arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c | 6 6 + 0 - 0 !
drivers/serial/serial_txx9.c | 90 90 + 0 - 0 !
2 files changed, 96 insertions(+)
Index: linux-2.6.24-rc7/drivers/serial/serial_txx9.c
===================================================================
--- linux-2.6.24-rc7.orig/drivers/serial/serial_txx9.c
+++ linux-2.6.24-rc7/drivers/serial/serial_txx9.c
@@ -1237,6 +1237,96 @@ void prom_putchar(char ch)
#endif
+/******************************************************************************/
+/* BEG: KDBG Routines */
+/******************************************************************************/
+
+#ifdef CONFIG_KGDB
+int kgdb_initialized;
+
+void txx9_sio_kgdb_hook(unsigned int port, unsigned int baud_rate)
+{
+ static struct resource kgdb_resource;
+ int ret;
+ struct uart_txx9_port *up = &serial_txx9_ports[port];
+
+ /* prevent initialization by driver */
+ kgdb_resource.name = "serial_txx9(debug)";
+ kgdb_resource.start = (resource_size_t)up->port.membase;
+ kgdb_resource.end = (resource_size_t)up->port.membase + 36 - 1;
+ kgdb_resource.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+
+ ret = request_resource(&iomem_resource, &kgdb_resource);
+ if (ret == -EBUSY)
+ printk(KERN_ERR
+ "txx9_sio_kgdb_hook(): request_resource failed\n");
+
+ return;
+}
+void
+txx9_sio_kdbg_init(unsigned int port_number)
+{
+ if (port_number == 1) {
+ txx9_sio_kgdb_hook(port_number, 38400);
+ kgdb_initialized = 1;
+ } else {
+ printk(KERN_ERR
+ "txx9_sio_kdbg_init(): Bad Port Number [%u] != [1]\n",
+ port_number);
+ }
+
+ return;
+}
+
+u8
+txx9_sio_kdbg_rd(void)
+{
+ unsigned int status, ch;
+ struct uart_txx9_port *up = &serial_txx9_ports[1];
+
+ if (!kgdb_initialized)
+ return 0;
+
+ while (1) {
+ status = sio_in(up, TXX9_SIDISR);
+ if (status & 0x1f) {
+ ch = sio_in(up, TXX9_SIRFIFO);
+ break;
+ }
+ }
+
+ return ch;
+}
+
+int
+txx9_sio_kdbg_wr(u8 ch)
+{
+ unsigned int status;
+ struct uart_txx9_port *up = &serial_txx9_ports[1];
+
+ if (!kgdb_initialized)
+ return 0;
+
+ while (1) {
+ status = sio_in(up, TXX9_SICISR);
+ if (status & TXX9_SICISR_TRDY) {
+ if (ch == '\n')
+ txx9_sio_kdbg_wr('\r');
+ sio_out(up, TXX9_SITFIFO, (u32)ch);
+
+ break;
+ }
+ }
+
+ return 1;
+}
+#endif /* CONFIG_KGDB */
+
+
+/******************************************************************************/
+/* END: KDBG Routines */
+/******************************************************************************/
+
static int __init serial_txx9_init(void)
{
int ret;
Index: linux-2.6.24-rc7/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
===================================================================
--- linux-2.6.24-rc7.orig/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
+++ linux-2.6.24-rc7/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
@@ -919,6 +919,12 @@ void __init toshiba_rbtx4927_setup(void)
early_printk_serial_txx9_console_setup();
}
#endif
+#ifdef CONFIG_KGDB
+ {
+ extern void txx9_sio_kdbg_init(unsigned int port_number);
+ txx9_sio_kdbg_init(1);
+ }
+#endif
#endif
#endif
^ permalink raw reply
* [PATCH 2/4] kgdb on not SMP
From: Frank Rowand @ 2008-01-15 22:32 UTC (permalink / raw)
To: ralf, linux-mips
In-Reply-To: <1200436139.4092.30.camel@bx740>
From: Frank Rowand <frank.rowand@am.sony.com>
Fix gdb-stub.c compile warning for non-SMP systems (which becomes compile
error due to -Werror).
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
---
arch/mips/kernel/gdb-stub.c | 2 2 + 0 - 0 !
1 files changed, 2 insertions(+)
Index: linux-2.6.24-rc5/arch/mips/kernel/gdb-stub.c
===================================================================
--- linux-2.6.24-rc5.orig/arch/mips/kernel/gdb-stub.c
+++ linux-2.6.24-rc5/arch/mips/kernel/gdb-stub.c
@@ -656,6 +656,7 @@ void set_async_breakpoint(unsigned long
*epc = (unsigned long)async_breakpoint;
}
+#ifdef CONFIG_SMP
static void kgdb_wait(void *arg)
{
unsigned flags;
@@ -668,6 +669,7 @@ static void kgdb_wait(void *arg)
local_irq_restore(flags);
}
+#endif
/*
* GDB stub needs to call kgdb_wait on all processor with interrupts
^ permalink raw reply
* [PATCH 4/4] invoke kgdb via magic sysrq
From: Frank Rowand @ 2008-01-15 22:34 UTC (permalink / raw)
To: ralf, linux-mips
In-Reply-To: <1200436139.4092.30.camel@bx740>
From: Frank Rowand <frank.rowand@am.sony.com>
Add hooks so that the host can connect to KGDB or asynchronously invoke an
already connected KGDB via a magic sysrq. This should work for most MIPS
targets that support KGDB, though it has only been tested on the Toshiba
RBTX4927. This can be useful to invoke an already connected KGDB for some
types of system hang. It also allows normally booting without connecting
to KGDB, then later connecting to KGDB if kernel debugging is desired.
This functionality exists for PowerPC and sh.
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
---
arch/mips/kernel/gdb-stub.c | 26 26 + 0 - 0 !
1 files changed, 26 insertions(+)
Index: linux-2.6.24-rc7/arch/mips/kernel/gdb-stub.c
===================================================================
--- linux-2.6.24-rc7.orig/arch/mips/kernel/gdb-stub.c
+++ linux-2.6.24-rc7/arch/mips/kernel/gdb-stub.c
@@ -131,6 +131,7 @@
#include <linux/spinlock.h>
#include <linux/slab.h>
#include <linux/reboot.h>
+#include <linux/sysrq.h>
#include <asm/asm.h>
#include <asm/cacheflush.h>
@@ -1154,3 +1155,28 @@ static int __init register_gdb_console(v
console_initcall(register_gdb_console);
#endif
+
+#ifdef CONFIG_MAGIC_SYSRQ
+static void sysrq_handle_gdb(int key, struct tty_struct *tty)
+{
+ if (!initialized) {
+ printk(KERN_ALERT "Wait for gdb client connection ...\n");
+ set_debug_traps();
+ }
+
+ breakpoint();
+}
+static struct sysrq_key_op sysrq_gdb_op = {
+ .handler = sysrq_handle_gdb,
+ .help_msg = "Gdb",
+ .action_msg = "GDB",
+};
+
+static int gdb_register_sysrq(void)
+{
+ printk(KERN_INFO "Registering GDB sysrq handler\n");
+ register_sysrq_key('g', &sysrq_gdb_op);
+ return 0;
+}
+module_init(gdb_register_sysrq);
+#endif
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Thiemo Seufer @ 2008-01-15 23:14 UTC (permalink / raw)
To: Gregor Waltz; +Cc: linux-mips
In-Reply-To: <478D121C.4020701@raritan.com>
Gregor Waltz wrote:
[snip]
> From where in the kernel image should execution begin?
Normally from kernel_entry, but your boot loader appears to start
from the begin of the code segment it loaded.
> Presuming that the output of "objdump -d" reflects the disassembled
> binary from the beginning in order, it looks like my 2.6 kernel is
> running straight into run_init_process as the first real code executed.
> From what I have seen in the kernel code, run_init_process should be
> jumped to far later in the boot process. If what I am thinking is
> correct, then it also explains why the failure happens in kernel_execve.
>
> I have also included the start of my working kernel, which has _ftext
> with non-zero data as its first entry. Is the _ftext the ELF header or
> some other info for the boot loader?
This is likely code which jumps to kernel_entry (but the disassembler
doesn't know since it sees no function symbol, so it defaults to data).
> Thanks
>
>
> linux-2.6.23.9/vmlinux: file format elf32-tradlittlemips
>
> Disassembly of section .text:
>
> 80020000 <run_init_process-0x400>:
> ...
Enabling CONFIG_BOOT_RAW, as Atsushi already suggested, would have
added a jump to kernel_entry in this place.
> 80020400 <run_init_process>:
> 80020400: 3c028033 lui v0,0x8033
> 80020404: 3c068033 lui a2,0x8033
> 80020408: 244594dc addiu a1,v0,-27428
Thiemo
^ permalink raw reply
* does anyone get mpatrol work on linux for mips?
From: zhuzhenhua @ 2008-01-16 2:54 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
hello,all
because valgrind not support mips now, i try to get mpatrol work
on our board(with linux-2.6.14)
i download the src, after compile and run a simple test programme
calling MP_MALLOC
it get a "Segmentation Fault" error.
then i add some print in the mpatrol lib, found that
something seemes wrong at calling "__mp_frameinfo" in
mpatrol/src/stack.c
does anyone run mpatrol success on linux for mips?
thanks for any hints
Best Regards
zzh
[-- Attachment #2: Type: text/html, Size: 893 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox