RE: [microblaze-uclinux] Re: Memory corruption problems with mainline kernel

[Stephen Neuendorffer <stephenn@xxxxxxxxxx>]

> -----Original Message-----
> From: owner-microblaze-uclinux@xxxxxxxxxxxxxxxxxxxx
[mailto:owner-microblaze-
> uclinux@xxxxxxxxxxxxxxxxxxxx] On Behalf Of John Williams
> Sent: Tuesday, November 17, 2009 6:30 PM
> To: microblaze-uclinux@xxxxxxxxxxxxxx
> Subject: Re: [microblaze-uclinux] Re: Memory corruption problems with
mainline kernel
> 
> 
> 
> On Wed, Nov 18, 2009 at 11:58 AM, Graeme Smecher
<graeme.smecher@xxxxxxxxxxxxxx> wrote:
> 
> 
> 	Hi John,
> 
> 
> 	John Williams wrote:
> 
> 
> 		that's a strange one - as you say, it looks like data
corruption, there's funny chars
> sprinkled all through that output.
> 
> 		Confirm you have the following settings on your
MicroBlaze:
> 
> 		 PARAMETER C_USE_MMU = 3
> 		 PARAMETER C_MMU_ZONES = 2
> 		 PARAMETER C_DPLB_BUS_EXCEPTION = 1
> 		 PARAMETER C_IPLB_BUS_EXCEPTION = 1
> 		 PARAMETER C_ILL_OPCODE_EXCEPTION = 1
> 		 PARAMETER C_UNALIGNED_EXCEPTIONS = 1
> 		 PARAMETER C_OPCODE_0x0_ILLEGAL = 1
> 
> 		The last 3 are not critical, but probably a good idea
regardless.
> 
> 
> 
> 	Crucial indeed!
> 
> 	It turns out the problem was in arch/microblaze/lib/fastcopy.S:
a_word_u3(), among others,
> requires C_USE_BARREL=1 to work. Without the barrel shifter, and
without C_ILL_OPCODE_EXCEPTION=1, my
> build was wandering off into the weeds. In my defense, I note that the
reference design on the Xilinx
> wiki
(http://xilinx.wikidot.com/local--files/start/ml507_mb_v1_system.tar.bz)
does not specify
> C_USE_BARREL=1, and it probably should.
> 
> 
> 
> Ah yes, ok.  We've got a ticket to fix that build for the no barrel
shift case.
> 
> 
> 
> 	I see that arch/microblaze/kernel/cpu/cpuinfo-pvr-full.c
includes checks to see if .config's
> settings (e.g. CONFIG_XILINX_MICROBLAZE0_USE_BARREL) agree with the
device tree's list of CPU
> features. Since we're already looking there, perhaps it's worth
producing an angry message if no
> barrel shifter is present.
> 
> 
> 
> This is a tricky one.  We try to defer as much as possible to runtime
binding through the PVR (if
> available) or the device tree (if we have to).
> 
> However, options that influence code generation clearly cannot be
bound so late.  This creates quite
> a complicated situation, and one quite difficult to handle gracefully.
But, we'll keep an eye on it
> and see if can be smoothed.

There seems like a straightforward solution to this:
1) Trap any illegal instruction exception and issue a
slap-across-the-face error message.
2) Provide a default on configuration option that refuses to boot on a
processor without exceptions.

Or another possibility: put the options that kernel was compiled with in
a data section and verify at boot time if it matches the PVR/Device
Tree.  This provides more of a possibility for not catching things if
some code is not compiled with the right flags (such as userspace
binaries).

I'm a firm believer in providing a default-safe environment.  If people
need to go under the hood to optimize things by turning off exceptions,
then that's their purview, but I don't see any reason not
to get them past the obvious mistakes in the beginning.

Steve


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.



___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/