Am Dienstag, dem 02.11.2021 um 23:35 +0100 schrieb Mathias Kresin: > At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the > assembly of LzmaProps_Decode. The instructions are using unaligned > access, which locks up danube boards using memory mapped NOR flash. > > It isn't clear whether it is a limitation of the flash chip or a > limitation of the EBU. > > Moving the pointer to the next int position and accessing accessing > just > the first byte, let gcc use sll instead of lwr/lwl and prevents the > unaligned access. > > Signed-off-by: Mathias Kresin <d...@kresin.me> > --- > .../0030-lzma-fix-unaligned-access.patch | 32 > +++++++++++++++++++ > 1 file changed, 32 insertions(+) > create mode 100644 package/boot/uboot-lantiq/patches/0030-lzma-fix- > unaligned-access.patch > > diff --git a/package/boot/uboot-lantiq/patches/0030-lzma-fix- > unaligned-access.patch b/package/boot/uboot-lantiq/patches/0030-lzma- > fix-unaligned-access.patch > new file mode 100644 > index 0000000000..de9afe0bf5 > --- /dev/null > +++ b/package/boot/uboot-lantiq/patches/0030-lzma-fix-unaligned- > access.patch > @@ -0,0 +1,32 @@ > +From a335c4c0532cf0d09b31e73f8461d3b4d0ce6f9a Mon Sep 17 00:00:00 > 2001 > +From: Mathias Kresin <d...@kresin.me> > +Date: Sun, 31 Oct 2021 23:04:54 +0100 > +Subject: [PATCH] lzma: fix unaligned access > + > +At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the > +assembly of LzmaProps_Decode. The instructions are using unaligned > +access, which locks up danube boards using memory mapped NOR flash. > + > +It isn't clear whether it is a limitation of the flash chip or a > +limitation of the EBU.
I think the problem is not the unaligned access but the 32bit read operation. The internal EBU data bus has a 16 bit width and can access 8bit or 16bit flash devices. So 8bit read operations at odd addresses shouldn't be a problem. I'm not sure what happens exactly at 32bit reads but this maybe involves multiple reads from flash and also some internal endianess swapping. Maybe a more robust solution would be to use readb(data[n] to always force 8bit reads. > + > +Moving the pointer to the next int position and accessing accessing > just > +the first byte, let gcc use sll instead of lwr/lwl and prevents the > +unaligned access. > + > +Signed-off-by: Mathias Kresin <d...@kresin.me> > +--- > + lib/lzma/LzmaDec.c | 2 +- > + 1 file changed, 1 insertion(+), 1 deletion(-) > + > +--- a/lib/lzma/LzmaDec.c > ++++ b/lib/lzma/LzmaDec.c > +@@ -929,7 +929,7 @@ SRes LzmaProps_Decode(CLzmaProps *p, con > + if (size < LZMA_PROPS_SIZE) > + return SZ_ERROR_UNSUPPORTED; > + else > +- dicSize = data[1] | ((UInt32)data[2] << 8) | ((UInt32)data[3] > << 16) | ((UInt32)data[4] << 24); > ++ dicSize = data[1] | ((UInt32)data[2] << 8) | ((UInt32)data[3] > << 16) | ((UInt32)(data+1)[0] << 24); > + > + if (dicSize < LZMA_DIC_MIN) > + dicSize = LZMA_DIC_MIN; -- - Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
