[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150818120618.GA4294@afzalpc>
Date: Tue, 18 Aug 2015 17:36:18 +0530
From: Afzal Mohammed <afzal.mohd.ma@...il.com>
To: Lucas Stach <l.stach@...gutronix.de>
Cc: Russell King - ARM Linux <linux@....linux.org.uk>,
"santosh.shilimkar@...cle.com" <santosh.shilimkar@...cle.com>,
Murali Karicheri <m-karicheri2@...com>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
ssantosh@...nel.org
Subject: Re: [PATCH] ARM: keystone: add a work around to handle asynchronous
external abort
Hi Murali,
On Tue, Aug 18, 2015 at 10:28:20AM +0200, Lucas Stach wrote:
> Am Dienstag, den 18.08.2015, 09:13 +0100 schrieb Russell King - ARM
> Linux:
> > It seems to be pointing towards something in the boot loader...
> >
> > Normally, uboot will hook itself into the vectors to report errors, but
> > I wonder whether uboot enables asynchronous aborts while it's running.
> > Don't forget to make sure that the aborts are disabled again prior to
> > calling the kernel.
> >
> At least one of the Marvell platforms has the same issue with the
> bootloader (I think it is some downstream U-Boot) leaving an imprecise
> abort hanging around as a nice present for Linux to crash on.
If you have a JTAG, maybe you can manually set CPSR.A bit (equivalent
of Lucas's patch) at bootloader/kernel entry and conclude who is the
culprit or maybe even localize it better.
This method did help in rootcausing issue in one of the SoC that showed
the same behaviour.
Regards
Afzal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists