linux-mips
[Top] [All Lists]

Re: Broadcom Swarm support

To: Kaz Kylheku <KKylheku@zeugmasystems.com>
Subject: Re: Broadcom Swarm support
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 27 Jun 2009 00:24:32 +0100
Cc: Aurelien Jarno <aurelien@aurel32.net>, linux-mips@linux-mips.org
In-reply-to: <DDFD17CC94A9BD49A82147DDF7D545C501C3539B@exchange.ZeugmaSystems.local>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20090624063453.GA16846@volta.aurel32.net> <DDFD17CC94A9BD49A82147DDF7D545C501C3539B@exchange.ZeugmaSystems.local>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
On Wed, Jun 24, 2009 at 03:18:24PM -0700, Kaz Kylheku wrote:
> From: Kaz Kylheku <KKylheku@zeugmasystems.com>
> Date: Wed, 24 Jun 2009 15:18:24 -0700
> To: Aurelien Jarno <aurelien@aurel32.net>, linux-mips@linux-mips.org
> Subject: RE: Broadcom Swarm support
> Content-Type: text/plain;
>       charset="us-ascii"
> 
> Aurelien Jarno wrote:
> > Hi all,
> > 
> > I am still trying to get a Broadcom Swarm boot on a recent kernel. I
> > have made some progress, but I am now stuck on another problem.
> > 
> > I am using a lmo 2.6.30 kernel, using the defconfig 
> 
> [ snip ]
> 
> > | Kernel panic - not syncing: Attempted to kill init!
> > | Rebooting in 5 seconds..Passing control back to CFE...
> 
> What kernel were you running prior to trying 30?
> 
> When I migrated from 2.6.17 to 2.6.26, on a Broadcom
> 1480 based board, I discovered that there is some kind
> of instruction cache problem, which causes userland to
> fetch garbage instead of code from its mmap-ped executables.
> I could not get init to execute successfully.
> 
> Sorry, I can no longer remember whether this problem was
> SMP specific or not (like what you're experiencing);
> it might have been.
> 
> At some point in the kernel history, Ralfie decided that
> the flush_icache_page function is unnecessary and
> turned it into a MIPS-wide noop. But the SB1 core, which has
> a VIVT instruction cache, it appears that there
> is some kind of issue whereby when it
> is handling a fault for a not-present virtual page,
> it somehow ends up with bad data in the instruction
> cache---perhaps an inconsistent state due to not having
> been able to complete the fetch, but having initiated
> a cache update on the expectation that the fetch
> will complete. It seems that the the fault handler
> is expected to do a flush.
> 
> Anyway, see if you can work this patch (based on 2.6.26)
> into your kernel, and report whether it makes any difference.

The functionality of flush_icache_page() is being handled update_mmu_cache.

The SB1 isn't the only MIPS CPU featuring VIVT caches - there are also
the MIPS 20K and 25K CPUs and the virtually identical SB1A core.  I've
tested Linux on 20K and 25K just days ago and I get months of uptime on my
BCM1480 box.

What type of boot devices are you using, is it the onboard IDE controller
by any chance?

  Ralf

<Prev in Thread] Current Thread [Next in Thread>