RE: [PATCH] 2.6.14-rc3 ixp4xx_copy_from little endian/alignment

[John Bowler <jbowler@acm.org>]

From: David Vrabel [mailto:dvrabel@cantab.net]
>John Bowler wrote:
>> +/* On a little-endian IXP4XX system (tested on NSLU2) contrary to the
>> + * Intel documentation LDRH/STRH appears to XOR the address with 10b.

This turns out to be a misleading comment, and I have deleted it:

>The Application Note on IXP4xx endianess operation[1] says that (by 
>default) the XScale core operates in address coherency mode (i.e., it 
>flips address bits).  I suspect you need to set BYTE_SWAP_EN in 
>EXP_CNFG1 and use the P bit in the MMU to get data coherency mode for 
>various peripherals (probably all expansion bus periperals and possibly 
>all the APB peripherals).

This is the observed behaviour (address coherency) - the address bits are
flipped on LE - and I hope the rest of the comments in the patch make
this clear because the central problem being fixed is that the command
address seen by the CPU is flipped from 0xAA to 0xA8 on LE systems.

The only problem with the address coherency setting is that the flash
command address bit flipping causes the flash not to work (there's no
way of configuring the MTD code to use a different address for command,
operations which require data coherency, and data operations which require
address coherency, because the command code *does* do data reads to
get the results back.)

*All* the other peripherals on the system work - including the USB which
is on the PCI bus - we do have this patch:

>Also, I've noticed that the PCI_CSR is mis-configured when the XScale 
>core is in little-endian mode.  ABE (AHB is big-endian) /must/ always be 
>set -- remember that the NPEs are always big-endian devices.

This doesn't affect the flash (we've verified that - i.e. *with* the
patch the flash works in LE regardless of the patch for the PCI_CSR
setting).

>Since I'd never run an IXP4xx in little-endian mode I've not looked at 
>this issue in any great depth so I could be wrong here.  Regardless, the 
>proposed hack to the flash map driver is wrong since all expansion bus 
>peripherals are affected not just flash (i.e., the solution needs to be 
>more generic rather than flash driver specific).

No, that's incorrect.  The patch has been demonstrated to be correct with
all devices (along with the PCI_CSR patch, which Deepak has already pushed
upstream).  I.e. *without* the patch everything works (BE and LE) except
the flash is unuseable, *with* the patch the flash works too.

We examined a number of solutions (i.e. I tried them, had systems which
booted with them and looked at the resultant problems).  I haven't tried
setting data coherency, but I'm assuming this would break at least some
of the peripherals.

Of the solutions I tried this is the only solution which allows us to switch
from LE to BE kernel/rootfs and share data which does not change (the NSLU2
configuration partition, the all important NSLU2 ethernet MAC which is
actually inside the boot loader and the RedBoot FIS directory.)

So I'm effectively saying we need data coherency in the flash, but what we
have in everything *else* is working just find with address coherency.

John Bowler <jbowler@acm.org>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/