On 12.02.2013 10:36, Conor O'Gorman wrote:
On Tue, 2013-02-12 at 10:51 +0200, malaakso at elisanet.fi wrote:
> On 11.02.2013 20:19, Conor O'Gorman wrote:
> >On Mon, 2013-02-11 at 17:50 +0100, Matti Laakso wrote:
> >> This patch disables the execute-in-place (XIP) support for flash on
> >> lantiq. This has to be disabled since the bus which flash is connected
> >> to does not support unaligned accesses. Resolves data bus errors on
> >> Lantiq routers with Intel command set flash.
> >
> > Interesting, but does lead to a couple of questions.
> >
> > I would have expected instruction fetches to be well aligned?
> >
> > And secondly what sort of code are you running directly from flash?
> >
> > Thanks,
> > Conor
>
> The problem is that XIP is (ab)used by jffs2, among others, to do reads with plain memcpy directly from flash. As far as I understand, memcpy on MIPS is allowed to do unaligned accesses but the underlying bus doesn't support it, so problems occur. "Proper" XIP should work, isn't that how U-Boot stored in flash, for example, works?
>
> Best regards,
> Matti
Yes, I later thought of two scenarios myself, uboot, but you were
talking kernel, and pieces of static data in code space. The flashes are
usually 8 or 16 bit, so the bus restricting things to 32 bit alignment
is still peculiar. The EBU does have byte control/select lines.
Conor
Actually, now that you mentioned it, I realize that the problem is more
peculiar than just that of absolute alignment. From some old sources:
if ( (((unsigned long)to) & 3) == (from & 3) ) {
memcpy_fromio(to, (void *)from, len);
}else {
p = (u8 *) (from);
to_8 = (u8 *) (to);
while(len--){
*to_8++ = *p++;
}
}
So the source and destination must have the _same_ alignment, be it to 1, 2,
3(?) or 4 byte boundary. Anyway, the plain memcpy courtesy of XIP obviously
doesn't satisfy this requirement.
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
