* Re: [PATCH 3/4] serial_txx9 driver support
From: Frank Rowand @ 2008-01-18 23:44 UTC (permalink / raw)
To: ralf; +Cc: linux-mips
In-Reply-To: <1200436432.4092.38.camel@bx740>
On Tue, 2008-01-15 at 14:33 -0800, Frank Rowand wrote:
> 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(+)
Just for the record... original attribution is very important.
I meant to mention in the original email, but I overlooked it, that
the serial_txx9.c code is mostly from the kgdb patch version 2.4 at
http://kgdb.linsyssoft.com/downloads.htm with a few slight changes. The
code is attributed to Ralf in the comments at the head of that patch
file. I suspect that Ralf recognized his code when I first sent it to
him :-).
-Frank
^ permalink raw reply
* Re: [PATCH] tc35815: Use irq number for tc35815-mac platform device id
From: Ralf Baechle @ 2008-01-18 23:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Atsushi Nemoto, linux-mips
In-Reply-To: <479105DE.4040407@garzik.org>
On Fri, Jan 18, 2008 at 03:02:38PM -0500, Jeff Garzik wrote:
> Atsushi Nemoto wrote:
>> The tc35815-mac platform device used a pci bus number and a devfn to
>> identify its target device, but the pci bus number may vary if some
>> bus-bridges are found. Use irq number which is be unique for embedded
>> controllers.
>>
>> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
>> ---
>> arch/mips/tx4938/toshiba_rbtx4938/setup.c | 4 ++--
>> drivers/net/tc35815.c | 2 +-
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> ACK, Ralf please apply through your tree...
Done. Thanks Atsushi,
Ralf
^ permalink raw reply
* Re: [PATCH] tc35815: Use irq number for tc35815-mac platform device id
From: Jeff Garzik @ 2008-01-18 20:02 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips, ralf
In-Reply-To: <20080119.011552.41196389.anemo@mba.ocn.ne.jp>
Atsushi Nemoto wrote:
> The tc35815-mac platform device used a pci bus number and a devfn to
> identify its target device, but the pci bus number may vary if some
> bus-bridges are found. Use irq number which is be unique for embedded
> controllers.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
> ---
> arch/mips/tx4938/toshiba_rbtx4938/setup.c | 4 ++--
> drivers/net/tc35815.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
ACK, Ralf please apply through your tree...
^ permalink raw reply
* Re: [PATCH] SGISEEQ: fix oops when doing ifconfig down; ifconfig up
From: Jeff Garzik @ 2008-01-18 20:01 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: netdev, linux-mips, ralf, jgarzik
In-Reply-To: <20080112230847.1EB3EC2F35@solo.franken.de>
Thomas Bogendoerfer wrote:
> When doing init_ring checking whether a new skb needs to be allocated
> was wrong.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> ---
>
> This is a bug fix for the 2.6.25 driver.
>
> drivers/net/sgiseeq.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c
> index c69bb8b..78994ed 100644
> --- a/drivers/net/sgiseeq.c
> +++ b/drivers/net/sgiseeq.c
> @@ -193,7 +193,7 @@ static int seeq_init_ring(struct net_device *dev)
>
> /* And now the rx ring. */
> for (i = 0; i < SEEQ_RX_BUFFERS; i++) {
> - if (!sp->rx_desc[i].rdma.pbuf) {
> + if (!sp->rx_desc[i].skb) {
> dma_addr_t dma_addr;
> struct sk_buff *skb = netdev_alloc_skb(dev, PKT_BUF_SZ);
applied
^ permalink raw reply
* Re: [PATCH] tc35815: Use irq number for tc35815-mac platform device id
From: Ralf Baechle @ 2008-01-18 16:59 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips, jeff
In-Reply-To: <20080119.011552.41196389.anemo@mba.ocn.ne.jp>
On Sat, Jan 19, 2008 at 01:15:52AM +0900, Atsushi Nemoto wrote:
> The tc35815-mac platform device used a pci bus number and a devfn to
> identify its target device, but the pci bus number may vary if some
> bus-bridges are found. Use irq number which is be unique for embedded
> controllers.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Looks ok and seems to be 2.6.24 stuff.
Gotta hash out with Jeff who will merge it.
Ralf
^ permalink raw reply
* [PATCH] tc35815: Use irq number for tc35815-mac platform device id
From: Atsushi Nemoto @ 2008-01-18 16:15 UTC (permalink / raw)
To: linux-mips; +Cc: ralf, jeff
The tc35815-mac platform device used a pci bus number and a devfn to
identify its target device, but the pci bus number may vary if some
bus-bridges are found. Use irq number which is be unique for embedded
controllers.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
---
arch/mips/tx4938/toshiba_rbtx4938/setup.c | 4 ++--
drivers/net/tc35815.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mips/tx4938/toshiba_rbtx4938/setup.c b/arch/mips/tx4938/toshiba_rbtx4938/setup.c
index 4a81523..632e5d2 100644
--- a/arch/mips/tx4938/toshiba_rbtx4938/setup.c
+++ b/arch/mips/tx4938/toshiba_rbtx4938/setup.c
@@ -598,8 +598,8 @@ static int __init rbtx4938_ethaddr_init(void)
printk(KERN_WARNING "seeprom: bad checksum.\n");
}
for (i = 0; i < 2; i++) {
- unsigned int slot = TX4938_PCIC_IDSEL_AD_TO_SLOT(31 - i);
- unsigned int id = (1 << 8) | PCI_DEVFN(slot, 0); /* bus 1 */
+ unsigned int id =
+ TXX9_IRQ_BASE + (i ? TX4938_IR_ETH1 : TX4938_IR_ETH0);
struct platform_device *pdev;
if (!(tx4938_ccfgptr->pcfg &
(i ? TX4938_PCFG_ETH1_SEL : TX4938_PCFG_ETH0_SEL)))
diff --git a/drivers/net/tc35815.c b/drivers/net/tc35815.c
index d887c05..370d329 100644
--- a/drivers/net/tc35815.c
+++ b/drivers/net/tc35815.c
@@ -611,7 +611,7 @@ static int __devinit tc35815_mac_match(struct device *dev, void *data)
{
struct platform_device *plat_dev = to_platform_device(dev);
struct pci_dev *pci_dev = data;
- unsigned int id = (pci_dev->bus->number << 8) | pci_dev->devfn;
+ unsigned int id = pci_dev->irq;
return !strcmp(plat_dev->name, "tc35815-mac") && plat_dev->id == id;
}
^ permalink raw reply related
* Re: Toshiba JMR 3927 working setup?
From: Atsushi Nemoto @ 2008-01-18 1:05 UTC (permalink / raw)
To: gregor.waltz; +Cc: linux-mips, ralf
In-Reply-To: <478F8758.1010105@raritan.com>
On Thu, 17 Jan 2008 11:50:32 -0500, Gregor Waltz <gregor.waltz@raritan.com> wrote:
> What ought to be done to fix the init_IRQ()/kmalloc problem?
Oops, that was my mistake. The txx9_irq_init() assumes its baseaddr
can be remapped without TLB. This is true but plat_ioremap for
jmr3927 was wrong.
Could you try this patch? (can be used for 2.6.23 and current git)
Subject: [MIPS] Fix plat_ioremap for JMR3927
TX39XX's "reserved" segment in CKSEG3 area is 0xff000000-0xfffeffff.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
---
diff --git a/include/asm-mips/mach-jmr3927/ioremap.h b/include/asm-mips/mach-jmr3927/ioremap.h
index aa131ad..ac3be35 100644
--- a/include/asm-mips/mach-jmr3927/ioremap.h
+++ b/include/asm-mips/mach-jmr3927/ioremap.h
@@ -25,7 +25,7 @@ static inline void __iomem *plat_ioremap(phys_t offset, unsigned long size,
{
#define TXX9_DIRECTMAP_BASE 0xff000000ul
if (offset >= TXX9_DIRECTMAP_BASE &&
- offset < TXX9_DIRECTMAP_BASE + 0xf0000)
+ offset < TXX9_DIRECTMAP_BASE + 0xff000)
return (void __iomem *)offset;
return NULL;
}
^ permalink raw reply related
* Re: [PATCH 3/4] serial_txx9 driver support
From: Sergei Shtylyov @ 2008-01-17 16:57 UTC (permalink / raw)
To: frank.rowand; +Cc: Atsushi Nemoto, ralf, linux-mips
In-Reply-To: <1200527181.3939.12.camel@bx740>
Hello Frank. :-)
>>>Add polled debug driver support to serial_txx9.c for kgdb, and initialize
>>>the driver for the Toshiba RBTX4927.
>>I think Jason Wessel's kgdb patchset is a way to go.
> Somehow I overlooked Jason's patchset. Yes, I agree that is the way to go,
BTW, that patchset already has TX[34]9xx KGDB serial driver...
> so my four patches should not be applied.
Well, it's not in the mainline yet anyway...
> -Frank
WBR, Sergei
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Gregor Waltz @ 2008-01-17 16:50 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20080117.010459.51867104.anemo@mba.ocn.ne.jp>
Atsushi Nemoto wrote:
> Hmm. The puts() in arch/mips/jmr3927/common/puts.c looks usable even
> on kernel entry. You can verify if it can really be used on
> start_kernel(), then start tracking down the problem.
>
> ---
> Atsushi Nemoto
>
puts() has helped, but I wish that I had something to dump the stack. Is
kgdb easy to set up?
In main.c, init_IRQ() eventually uses kmalloc:
arch_init_irq() -> txx9_irq_init() -> ioremap() -> __get_vm_area_node()
-> kmalloc_node()...
malloc_sizes is not yet initialized, though, which means that cs_cachep
is zero for all entries. My system reboots when it reaches
cpu_cache_get() in mm/slab.c where cachep is zero.
It seems to me that kmem_cache_init() ought to be run before any
kmallocs. kmem_cache_init() seems to require mem_init(). After I moved
mem_init and kmem_cache_init before init_IRQ(), it gets down to
pidhash_init() before rebooting, which I am looking into now.
What ought to be done to fix the init_IRQ()/kmalloc problem?
Thanks
^ permalink raw reply
* Re: Tester with IP27/IP30 needed
From: Ralf Baechle @ 2008-01-17 15:10 UTC (permalink / raw)
To: Florian Lohoff; +Cc: Thomas Bogendoerfer, linux-mips, debian-mips
In-Reply-To: <20080117082741.GA2586@paradigm.rfc822.org>
On Thu, Jan 17, 2008 at 09:27:41AM +0100, Florian Lohoff wrote:
> > this kills my IP28 after a few seconds. If I drop rdhwr or sync the
> > machine hasn't locked up after running for several minutes. Looks
> > like we are hiting a strange condition.
> >
> > This sort of code could be found in glibc 2.7 all over the place...
> >
> > Thomas.
> >
> > PS: Using rdhwr_noopt doesn't make a difference...
>
> Kills my ip28 after 2 seconds ...
Doesn't harm IP27. I even tried running two copies running in parallel.
Ralf
^ permalink raw reply
* Re: Tester with IP27/IP30 needed
From: Ralf Baechle @ 2008-01-17 11:59 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: Florian Lohoff, linux-mips, debian-mips
In-Reply-To: <20080117004054.GA12051@alpha.franken.de>
On Thu, Jan 17, 2008 at 01:40:54AM +0100, Thomas Bogendoerfer wrote:
> ----------------------------------------------------------------------
> void spin(void *a0)
> {
> while (1) {
> asm volatile(
> " .set mips3 \n"
> " sync \n"
> "1: ll $5, 0($4) \n"
> " sc $3, 0($4) \n"
> " beqz $3, 1b \n"
> " .word 0x7c03e83b \n" /* rdhwr */
> " lw $3, 0($4) \n"
> " nop \n"
> );
> }
> }
>
> int main()
> {
> int a;
>
> spin(&a);
> }
> ----------------------------------------------------------------------
>
> this kills my IP28 after a few seconds. If I drop rdhwr or sync the
> machine hasn't locked up after running for several minutes. Looks
> like we are hiting a strange condition.
SYNC on the R10000 will only graduate if the external signal SyncGblPerf
is asserted. A simple system could simply always set it. I wonder if
that has any affect. Logic analyzer time ...
Ralf
^ permalink raw reply
* Re: Tester with IP27/IP30 needed
From: Thomas Bogendoerfer @ 2008-01-17 10:00 UTC (permalink / raw)
To: Florian Lohoff; +Cc: linux-mips, debian-mips
In-Reply-To: <20080117082741.GA2586@paradigm.rfc822.org>
On Thu, Jan 17, 2008 at 09:27:41AM +0100, Florian Lohoff wrote:
> On Thu, Jan 17, 2008 at 01:40:54AM +0100, Thomas Bogendoerfer wrote:
> > On Tue, Jan 15, 2008 at 12:27:19PM +0100, Florian Lohoff wrote:
> > > Simple testcase for me is:
> >
> > this kills my IP28 after a few seconds. If I drop rdhwr or sync the
> > machine hasn't locked up after running for several minutes. Looks
> > like we are hiting a strange condition.
> >
> > This sort of code could be found in glibc 2.7 all over the place...
> >
> > Thomas.
> >
> > PS: Using rdhwr_noopt doesn't make a difference...
>
> Kills my ip28 after 2 seconds ...
I checked the ErrorEPC and it's pointing right after the sc. This
is consistent to the dump Ralf did on his IP27.
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: Tester with IP27/IP30 needed
From: Florian Lohoff @ 2008-01-17 8:27 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips, debian-mips
In-Reply-To: <20080117004054.GA12051@alpha.franken.de>
[-- Attachment #1: Type: text/plain, Size: 753 bytes --]
On Thu, Jan 17, 2008 at 01:40:54AM +0100, Thomas Bogendoerfer wrote:
> On Tue, Jan 15, 2008 at 12:27:19PM +0100, Florian Lohoff wrote:
> > Simple testcase for me is:
>
> this kills my IP28 after a few seconds. If I drop rdhwr or sync the
> machine hasn't locked up after running for several minutes. Looks
> like we are hiting a strange condition.
>
> This sort of code could be found in glibc 2.7 all over the place...
>
> Thomas.
>
> PS: Using rdhwr_noopt doesn't make a difference...
Kills my ip28 after 2 seconds ...
Flo
--
Florian Lohoff flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Tester with IP27/IP30 needed
From: Thomas Bogendoerfer @ 2008-01-17 0:40 UTC (permalink / raw)
To: Florian Lohoff; +Cc: linux-mips, debian-mips
In-Reply-To: <20080115112719.GB7920@paradigm.rfc822.org>
On Tue, Jan 15, 2008 at 12:27:19PM +0100, Florian Lohoff wrote:
> Simple testcase for me is:
now even simpler:
----------------------------------------------------------------------
void spin(void *a0)
{
while (1) {
asm volatile(
" .set mips3 \n"
" sync \n"
"1: ll $5, 0($4) \n"
" sc $3, 0($4) \n"
" beqz $3, 1b \n"
" .word 0x7c03e83b \n" /* rdhwr */
" lw $3, 0($4) \n"
" nop \n"
);
}
}
int main()
{
int a;
spin(&a);
}
----------------------------------------------------------------------
this kills my IP28 after a few seconds. If I drop rdhwr or sync the
machine hasn't locked up after running for several minutes. Looks
like we are hiting a strange condition.
This sort of code could be found in glibc 2.7 all over the place...
Thomas.
PS: Using rdhwr_noopt doesn't make a difference...
--
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 3/4] serial_txx9 driver support
From: Frank Rowand @ 2008-01-16 23:46 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: ralf, linux-mips
In-Reply-To: <20080117.004716.59650985.anemo@mba.ocn.ne.jp>
On Thu, 2008-01-17 at 00:47 +0900, Atsushi Nemoto wrote:
> On Tue, 15 Jan 2008 14:33:52 -0800, Frank Rowand <frank.rowand@am.sony.com> wrote:
> > Add polled debug driver support to serial_txx9.c for kgdb, and initialize
> > the driver for the Toshiba RBTX4927.
>
> I think Jason Wessel's kgdb patchset is a way to go.
Somehow I overlooked Jason's patchset. Yes, I agree that is the way to go,
so my four patches should not be applied. Thanks for bringing that to my
attention.
-Frank
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: peter fuerst @ 2008-01-16 19:32 UTC (permalink / raw)
To: Richard Sandiford; +Cc: Ralf Baechle, Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <871w9d7nsf.fsf@firetop.home>
Hi,
what next step do you suggest ?
kind regards
peter
On Sun, 23 Dec 2007, Richard Sandiford wrote:
> Date: Sun, 23 Dec 2007 09:39:28 +0000
> From: Richard Sandiford <rsandifo@nildram.co.uk>
> To: peter fuerst <post@pfrst.de>
> Cc: Ralf Baechle <ralf@linux-mips.org>,
> Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
> Kumba <kumba@gentoo.org>, linux-mips@linux-mips.org
> Subject: Re: [UPDATED PATCH] IP28 support
>
>
> ...
>
> Thanks, it seems we have a plan ;)
>
> Richard
>
>
>
^ permalink raw reply
* Re: [PATCH] kernel make error - smtc_ipi.h irq flags, 2.6.24-rc7
From: Ralf Baechle @ 2008-01-16 16:23 UTC (permalink / raw)
To: Frank Rowand; +Cc: linux-mips
In-Reply-To: <1200436004.4092.26.camel@bx740>
On Tue, Jan 15, 2008 at 02:26:44PM -0800, Frank Rowand wrote:
> 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.
Thanks, applied.
Ralf
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Atsushi Nemoto @ 2008-01-16 16:04 UTC (permalink / raw)
To: gregor.waltz; +Cc: linux-mips
In-Reply-To: <478E22A4.4070604@raritan.com>
On Wed, 16 Jan 2008 10:28:36 -0500, Gregor Waltz <gregor.waltz@raritan.com> wrote:
> I double checked today and found that even the vmlinux make target
> removes that option from .config.
> Is there another way to set that option?
The CONFIG_BOOT_RAW is not user-selectable. You must add "select
BOOT_RAW" to TOSHIBA_JMR3927 block in arch/mips/Kconfig.
> I saw the option used only in arch/mips/kernel/head.S, so I commented
> out the __INIT. Now, I see kernel_entry at the start of the kernel and
> the kernel does not cause an exception, however, it reboots instead
> saying "Rebooting..."
Hmm. The puts() in arch/mips/jmr3927/common/puts.c looks usable even
on kernel entry. You can verify if it can really be used on
start_kernel(), then start tracking down the problem.
---
Atsushi Nemoto
^ permalink raw reply
* Re: Tester with IP27/IP30 needed
From: Ralf Baechle @ 2008-01-16 16:03 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20080115181812.GA14816@linux-mips.org>
On Tue, Jan 15, 2008 at 06:18:12PM +0000, Ralf Baechle wrote:
So I sent an NMI to the IP27 and used the POD to extract as much information
as I could. Below the disassembly of the code. The addresses are looking
a little odd because I had to disassembly at the XKPHYS address even though
the code was actually executing in userspace.
1B 000: 0xa80000007bd5f008: 8c658b98 lw a1,0x8b98(v1)
1B 000: 0xa80000007bd5f00c: 24060001 li a2,0x1
1B 000: 0xa80000007bd5f010: 34a50001 ori a1,a1,0x1
1B 000: 0xa80000007bd5f014: 00003821 move a3,zero
1B 000: 0xa80000007bd5f018: 2402108e li v0,0x108e
1B 000: 0xa80000007bd5f01c: 0000000c syscall
1B 000: 0xa80000007bd5f020: 1000ffd3 b 0xa80000007bd5ef70
1B 000: 0xa80000007bd5f024: 00000000 nop
1B 000: 0xa80000007bd5f028: 3c1c0010 lui gp,0x10
1B 000: 0xa80000007bd5f02c: 279ce938 addiu gp,gp,0xffffffe938
1B 000: 0xa80000007bd5f030: 0399e021 addu gp,gp,t9
1B 000: 0xa80000007bd5f034: 27bdffd8 addiu sp,sp,0xffffffffd8
1B 000: 0xa80000007bd5f038: afbf0020 sw ra,0x20(sp)
1B 000: 0xa80000007bd5f03c: afb1001c sw s1,0x1c(sp)
1B 000: 0xa80000007bd5f040: afb00018 sw s0,0x18(sp)
1B 000: 0xa80000007bd5f044: afbc0010 sw gp,0x10(sp)
1B 000: 0xa80000007bd5f048: 7c03e83b op1f v1,zero,0xfffffffff
1B 000: fffe83b
1B 000: 0xa80000007bd5f04c: 8f848018 lw a0,0x8018(gp)
EPC is pointing to this lw so the subsequent instruction from the op1f which
is rdhwr $29. ErrorEPC is pointing further down so it seems we must have
returned from the emulation.
1B 000: 0xa80000007bd5f050: 24718b90 addiu s1,v1,0xffffff8b90
1B 000: 0xa80000007bd5f054: 24901710 addiu s0,a0,0x1710
1B 000: 0xa80000007bd5f058: 8e020008 lw v0,0x8(s0)
1B 000: 0xa80000007bd5f05c: 00000000 nop
1B 000: 0xa80000007bd5f060: 1051000d beq v0,s1,0xa8000000f098
1B 000: 0xa80000007bd5f064: 00001821 move v1,zero
1B 000: 0xa80000007bd5f068: 24020001 li v0,0x1
1B 000: 0xa80000007bd5f06c: c0851710 ll a1,0x1710(a0)
1B 000: 0xa80000007bd5f070: 14a30006 bne a1,v1,0xa8000000f08c
1B 000: 0xa80000007bd5f074: 00003021 move a2,zero
1B 000: 0xa80000007bd5f078: 00403021 move a2,v0
1B 000: 0xa80000007bd5f07c: e0861710 sc a2,0x1710(a0)
1B 000: 0xa80000007bd5f080: 10c0fffa beq a2,zero,0xa800d5f06c
And this is where the ErrorEPC is pointing.
1B 000: 0xa80000007bd5f084: 00000000 nop
1B 000: 0xa80000007bd5f088: 0000000f sync
1B 000: 0xa80000007bd5f08c: 10c0000a beq a2,zero,0xa800d5f0b8
1B 000: 0xa80000007bd5f090: 00000000 nop
Ralf
^ permalink raw reply
* Re: [PATCH 3/4] serial_txx9 driver support
From: Atsushi Nemoto @ 2008-01-16 15:47 UTC (permalink / raw)
To: frank.rowand; +Cc: ralf, linux-mips
In-Reply-To: <1200436432.4092.38.camel@bx740>
On Tue, 15 Jan 2008 14:33:52 -0800, Frank Rowand <frank.rowand@am.sony.com> wrote:
> Add polled debug driver support to serial_txx9.c for kgdb, and initialize
> the driver for the Toshiba RBTX4927.
I think Jason Wessel's kgdb patchset is a way to go.
Anyway, some comments below.
> +int kgdb_initialized;
Should be static.
> +void txx9_sio_kgdb_hook(unsigned int port, unsigned int baud_rate)
Should be static. The baud_rate is not used.
> +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;
> +}
Why port_number other than 1 is bad?
The "return" at the end of the function is redundant.
> +u8
> +txx9_sio_kdbg_rd(void)
> +{
> + unsigned int status, ch;
> + struct uart_txx9_port *up = &serial_txx9_ports[1];
Oh this assumes port number 1. The gdb port number should be customizable.
> + sio_out(up, TXX9_SITFIFO, (u32)ch);
The cast is not needed.
---
Atsushi Nemoto
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Gregor Waltz @ 2008-01-16 15:28 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20080115231421.GB9767@networkno.de>
Thiemo Seufer wrote:
> Enabling CONFIG_BOOT_RAW, as Atsushi already suggested, would have
> added a jump to kernel_entry in this place.
>
Yes, I tried that, but it made no difference at the time and Atsushi
also said that it was broken in git as of 01/05/2008 (I have 2.6.23.9).
The kernel config operations (oldconfig, menuconfig, et al) obliterate
CONFIG_BOOT_RAW from the .config.
I double checked today and found that even the vmlinux make target
removes that option from .config.
Is there another way to set that option?
I saw the option used only in arch/mips/kernel/head.S, so I commented
out the __INIT. Now, I see kernel_entry at the start of the kernel and
the kernel does not cause an exception, however, it reboots instead
saying "Rebooting..."
Thanks
^ permalink raw reply
* Re: [PATCH 1/4] early_printk
From: Atsushi Nemoto @ 2008-01-16 15:27 UTC (permalink / raw)
To: frank.rowand; +Cc: ralf, linux-mips
In-Reply-To: <1200436287.4092.33.camel@bx740>
On Tue, 15 Jan 2008 14:31:27 -0800, Frank Rowand <frank.rowand@am.sony.com> wrote:
> 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(+)
Please do not add MIPS local prom_putchar() to the serial_txx9 driver.
This driver is used on some powerpc platform too.
---
Atsushi Nemoto
^ permalink raw reply
* ramdisk /sbin/init not running
From: Gautam Dawar @ 2008-01-16 11:23 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]
Hi all,
I am trying to run Montavista linux (kernel version 2.4) on my development
board which is based on MIPS processor. The ramdisk is compiled into the
kernel image by placing the ramdisk.gz file in the source tree.
The kernel boots up completely and the control is passed over to /sbin/init
binary present in the ramdisk in the init thread. After that no print is
observed on the console, where I should have observed "BusyBox v0.60.5 (
2005.03.06-21:20+0000) Built-in shell (msh)" as the first print from the
ramdisk binary.
I tried to run my own init binary which was nothing but a simple "Hello
world" application, but even with this binary the print wasn't observed.
Finally, On putting prints in the load_elf_binary routing, I found that
load_elf_binary is returning with retval: 0 which means success.
So, I am suspecting that the problem somehow lies with the UART in that no
prints are seen from the newly execed program(/sbin/init).
Could this be the case?
Could there be a problem with the kernel code?
Following are the last few prints observed on the console:
###############################################################
Freeing initrd memory: 1836k freed
VFS: Mounted root (ext2 filesystem).
Mounted devfs on /dev
Freeing prom memory: 0kb freed
Freeing unused kernel memory: 84k freed
Algorithmics/MIPS FPU Emulator v1.5
###############################################################
Any help in this regard would be greatly appreciated.
Regards,
Gautam
[-- Attachment #2: Type: text/html, Size: 1639 bytes --]
^ permalink raw reply
* Re: [PATCH] I8042: SNI RM support
From: Dmitry Torokhov @ 2008-01-16 5:22 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-input, linux-mips
In-Reply-To: <20080112233904.4E149C2F36@solo.franken.de>
Hi Thomas,
On Saturday 12 January 2008 18:39, Thomas Bogendoerfer wrote:
> +
> +/*
> + * IRQs.
> + */
> +static int i8042_kbd_irq = -1;
> +static int i8042_aux_irq = -1;
Why initialize with -1 and not leave at 0? Or even initialize with 1/12
and override with 33/44 in i8042_platform_init()?
--
Dmitry
^ 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