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.
Thanks,
John