Re: [PATCH] uboot-lantiq: danube: fix hanging lzma kernel uncompression
11/3/21 2:25 PM, Daniel Schwierzeck: 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 --- .../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 00..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 +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. I've done more testing and the behaviour can be only described as strange. The system only hangs if the offset is 1. lwl s0,0(a1) - 0x6d80 lwl s0,1(a1) - hangs lwl s0,2(a1) - 0x0080 lwl s0,3(a1) - 0x80xx Looks like 32bit reads via the EBU on a flash device are working fine with exception to offset 1. So, it doesn't look like a 32bit read issue and obviously it isn't an issue with unaligned access... Maybe a more robust solution would be to use readb(data[n] to always force 8bit reads. It isn't just more robust, it's the only reliable way. While checking the generated assembler code, I spotted that with my change the read to offset 4 is completely gone. No idea what the compiler is doing here. It only worked by accident. + +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 +--- + 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; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] kernel: add missing UBSAN config symbols
Enabling KERNEL_UBSAN exposes several missing symbols. Add new kernel
build options for UBSAN_BOUNDS and UBSAN_TRAP, disable CONFIG_TEST_UBSAN
in the generic kernel configs and enable CONFIG_UBSAN_MISC in generic
5.10 config. The latter symbol was removed in later kernels, so just set
it to the default value in 5.10 instead of adding a build option for it.
Fixes build failures with KERNEL_UBSAN enabled.
Signed-off-by: Stijn Tintel
---
config/Config-kernel.in | 23 +++
target/linux/generic/config-5.10 | 2 ++
target/linux/generic/config-5.4 | 1 +
3 files changed, 26 insertions(+)
diff --git a/config/Config-kernel.in b/config/Config-kernel.in
index dc249a6031..6758d278e7 100644
--- a/config/Config-kernel.in
+++ b/config/Config-kernel.in
@@ -114,6 +114,16 @@ config KERNEL_UBSAN_ALIGNMENT
Enabling this option on architectures that support unaligned
accesses may produce a lot of false positives.
+config KERNEL_UBSAN_BOUNDS
+ bool "Perform array index bounds checking"
+ depends on KERNEL_UBSAN
+ help
+ This option enables detection of directly indexed out of bounds array
+ accesses, where the array size is known at compile time. Note that
+ this does not protect array overflows via bad calls to the
+ {str,mem}*cpy() family of functions (that is addressed by
+ FORTIFY_SOURCE).
+
config KERNEL_UBSAN_NULL
bool "Enable checking of null pointers"
depends on KERNEL_UBSAN
@@ -121,6 +131,19 @@ config KERNEL_UBSAN_NULL
This option enables detection of memory accesses via a
null pointer.
+config KERNEL_UBSAN_TRAP
+ bool "On Sanitizer warnings, abort the running kernel code"
+ depends on KERNEL_UBSAN
+ help
+ Building kernels with Sanitizer features enabled tends to grow the
+ kernel size by around 5%, due to adding all the debugging text on
+ failure paths. To avoid this, Sanitizer instrumentation can just
+ issue a trap. This reduces the kernel size overhead but turns all
+ warnings (including potentially harmless conditions) into full
+ exceptions that abort the running kernel code (regardless of context,
+ locks held, etc), which may destabilize the system. For some system
+ builders this is an acceptable trade-off.
+
config KERNEL_KASAN
bool "Compile the kernel with KASan: runtime memory debugger"
select KERNEL_SLUB_DEBUG
diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10
index 7b952e8ca8..83004d0879 100644
--- a/target/linux/generic/config-5.10
+++ b/target/linux/generic/config-5.10
@@ -6082,6 +6082,7 @@ CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_STRSCPY is not set
# CONFIG_TEST_SYSCTL is not set
+# CONFIG_TEST_UBSAN is not set
# CONFIG_TEST_UDELAY is not set
# CONFIG_TEST_USER_COPY is not set
# CONFIG_TEST_UUID is not set
@@ -6348,6 +6349,7 @@ CONFIG_UBIFS_FS_ZLIB=y
CONFIG_UBIFS_FS_ZSTD=y
# CONFIG_UBSAN is not set
CONFIG_UBSAN_ALIGNMENT=y
+CONFIG_UBSAN_MISC=y
# CONFIG_UCB1400_CORE is not set
# CONFIG_UCSI is not set
# CONFIG_UDF_FS is not set
diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index c44e9cf40b..bf2b462529 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -5631,6 +5631,7 @@ CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_STRSCPY is not set
# CONFIG_TEST_SYSCTL is not set
+# CONFIG_TEST_UBSAN is not set
# CONFIG_TEST_UDELAY is not set
# CONFIG_TEST_USER_COPY is not set
# CONFIG_TEST_UUID is not set
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] kernel: add missing KASAN config symbols
Enabling KERNEL_KASAN exposes several missing symbols. As KASAN_SW_TAGS is only implemented for arm64 CPUs and requires clang, it doesn't make sense to make this a build option so just default to KASAN_GENERIC and disable KASAN_SW_TAGS. While at it, disable TEST_KASAN_MODULE in the generic 5.10 config. Fixes build failures with KERNEL_KASAN enabled. Signed-off-by: Stijn Tintel --- config/Config-kernel.in | 7 +++ target/linux/generic/config-5.10 | 1 + 2 files changed, 8 insertions(+) diff --git a/config/Config-kernel.in b/config/Config-kernel.in index 6758d278e7..902e211ea1 100644 --- a/config/Config-kernel.in +++ b/config/Config-kernel.in @@ -170,6 +170,13 @@ config KERNEL_KASAN_EXTRA compile time. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 has more +if KERNEL_KASAN + config KERNEL_KASAN_GENERIC + def_bool y + + config KERNEL_KASAN_SW_TAGS + def_bool n +endif choice prompt "Instrumentation type" diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 index 83004d0879..ddcf083a7d 100644 --- a/target/linux/generic/config-5.10 +++ b/target/linux/generic/config-5.10 @@ -6064,6 +6064,7 @@ CONFIG_TCP_CONG_CUBIC=y # CONFIG_TEST_HASH is not set # CONFIG_TEST_HEXDUMP is not set # CONFIG_TEST_IDA is not set +# CONFIG_TEST_KASAN_MODULE is not set # CONFIG_TEST_KMOD is not set # CONFIG_TEST_KSTRTOX is not set # CONFIG_TEST_LIST_SORT is not set -- 2.32.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] bcm4908: start work on images for devices using U-Boot
From: Rafał Miłecki
New BCM4908 family based routers will use U-Boot bootloader. That will
require using a totally different firmware format. Kernel has to be put
in a FIT image.
OpenWrt has some helpers for generating .its files but they don't fit
BCM4908 requirements and there is no simple way of extending any of
them. The best solution seems to be storing an .its template.
BCM4908 bootfs may:
1. contain extra binaries (other than kernel & DTB)
2. include multiple DTB files
3. store device specific U-Boot configurations with custom properties
Such setups are too complex to generate using shell script. Raw .its
file on the other hand seems quire clean & reasonable.
Signed-off-by: Rafał Miłecki
---
target/linux/bcm4908/image/Makefile | 11
target/linux/bcm4908/image/bootfs-generic.its | 25 +++
2 files changed, 36 insertions(+)
create mode 100644 target/linux/bcm4908/image/bootfs-generic.its
diff --git a/target/linux/bcm4908/image/Makefile
b/target/linux/bcm4908/image/Makefile
index 426db4c5a6..929e626e0e 100644
--- a/target/linux/bcm4908/image/Makefile
+++ b/target/linux/bcm4908/image/Makefile
@@ -6,6 +6,17 @@ include $(INCLUDE_DIR)/image.mk
DEVICE_VARS += ASUS_PRODUCTID ASUS_BUILD_NO ASUS_FW_REV ASUS_EXT_NO
DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_REGION
+define Image/Prepare
+ cp bootfs-generic.its $(KDIR)/
+endef
+
+define Build/bootfs
+ cat $@ | $(STAGING_DIR_HOST)/bin/lzma e -eos -si -so > $@.tmp
+ mv $@.tmp $@
+ sed -i "s=\$${kernel}=$@=" $(KDIR)/bootfs-generic.its
+ PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) mkimage -f
$(KDIR)/bootfs-generic.its $(KDIR)/bootfs-generic.itb
+endef
+
define Build/bcm4908asus
$(STAGING_DIR_HOST)/bin/bcm4908asus create -i $@ \
-p $(ASUS_PRODUCTID) -b $(ASUS_BUILD_NO) -f $(ASUS_FW_REV) \
diff --git a/target/linux/bcm4908/image/bootfs-generic.its
b/target/linux/bcm4908/image/bootfs-generic.its
new file mode 100644
index 00..d2f19ed752
--- /dev/null
+++ b/target/linux/bcm4908/image/bootfs-generic.its
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+/dts-v1/;
+
+/ {
+ description = "OpenWrt bootfs image";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ description = "Linux kernel";
+ data = /incbin/("${kernel}");
+ type = "kernel";
+ os = "linux";
+ arch = "arm64";
+ compression = "lzma";
+ load = <0x8>;
+ entry = <0x8>;
+
+ hash-1 {
+ algo = "sha256";
+ };
+ };
+ };
+};
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uboot-lantiq: danube: fix SPL boot
Am Dienstag, dem 02.11.2021 um 23:35 +0100 schrieb Mathias Kresin: > On danube we only have 0x6800 bytes of usable SRAM. Everything behind > can't be written to and a SPL u-boot locks up during boot. > > Since it's a hard to debug issue and took me more than two years to > fix > it, I consider it worth to include fix albeit SPL u-boots are not > build > in OpenWrt. > > I faced the issue while trying to shrink the u-boot to 64K since some > board only have an u-boot partition of that size from the days ifx- > uboot > was used. > > Signed-off-by: Mathias Kresin > --- > ...0032-MIPS-lantiq-danube-fix-SPL-boot.patch | 33 > +++ > 1 file changed, 33 insertions(+) > create mode 100644 package/boot/uboot-lantiq/patches/0032-MIPS- > lantiq-danube-fix-SPL-boot.patch > > diff --git a/package/boot/uboot-lantiq/patches/0032-MIPS-lantiq- > danube-fix-SPL-boot.patch b/package/boot/uboot-lantiq/patches/0032- > MIPS-lantiq-danube-fix-SPL-boot.patch > new file mode 100644 > index 00..794fd8cc2a > --- /dev/null > +++ b/package/boot/uboot-lantiq/patches/0032-MIPS-lantiq-danube-fix- > SPL-boot.patch > @@ -0,0 +1,33 @@ > +From 65f1f160139c2bac83650c9c7c4aee4e5fd74c7c Mon Sep 17 00:00:00 > 2001 > +From: Mathias Kresin > +Date: Sun, 2 May 2021 02:03:05 +0200 > +Subject: [PATCH] MIPS: lantiq: danube: fix SPL boot > + > +On danube we only have 0x6800 bytes of usable SRAM. Everything > behind > +can't be written to and a SPL u-boot locks up during boot. > + > +Signed-off-by: Mathias Kresin > +--- > + arch/mips/include/asm/arch-danube/config.h | 4 ++-- > + 1 file changed, 2 insertions(+), 2 deletions(-) > + > +--- a/arch/mips/include/asm/arch-danube/config.h > b/arch/mips/include/asm/arch-danube/config.h > +@@ -61,7 +61,7 @@ > + > + /* SRAM */ > + #define CONFIG_SYS_SRAM_BASE0xBE1A > +-#define CONFIG_SYS_SRAM_SIZE0x1 > ++#define CONFIG_SYS_SRAM_SIZE0x6800 this is not really documented in the datasheets, but 0x6800 would correspond to the PPE Shared Buffer size and seems to be correct. > + > + /* ASC/UART driver and console */ > + #define CONFIG_LANTIQ_SERIAL > +@@ -117,7 +117,7 @@ > + #define CONFIG_CMD_NET > + #endif > + > +-#define CONFIG_SPL_MAX_SIZE (32 * 1024) > ++#define CONFIG_SPL_MAX_SIZE (18 * 1024) > + #define CONFIG_SPL_BSS_MAX_SIZE (8 * 1024) > + #define CONFIG_SPL_STACK_MAX_SIZE (8 * 1024) > + #define CONFIG_SPL_MALLOC_MAX_SIZE (32 * 1024) Reviewed-by: Daniel Schwierzeck -- - Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uboot-lantiq: fix out of bounds cache invalidate
Am Dienstag, dem 02.11.2021 um 23:35 +0100 schrieb Mathias Kresin:
> If u-boot is compiled with gcc 10+ the relevant part of the memory is
> used as following:
>
> variable BootFile is at address: 0x83ffe4ec
> variable data is at address: 0x83ffdee2
> variable data has len: 0x600
>
> Within invalidate_dcache_range() the cache covering the data variable
> should be invalidated (0x83ffdee2 till 0x83ffdef2).
>
> Due to dcache line size of 32 and some alignment correction, the
> actual
> memory range for which the cache is invalidated is from 0x83ffdee0
> till
> 0x83ffe500, which includes the location of the BootFile variable as
> well.
>
> Afterwards the BootFile variable is 0. The issue can be observed by
> using tftpboot, which always uses the default/generated filename
> instead
> of the specified one.
>
> To fix the issue, align the memory addresses properly before passing
> them to invalidate_dcache_range(). The misalignment can be observed
> with
> older gcc versions as well but the BootFile variable is placed more
> than
> 0x1000 bytes after the data variable and doesn't get null'ed.
>
> Fixes: FS#4113
>
> Signed-off-by: Mathias Kresin
> ---
> ...q-fix-out-of-bounds-cache-invalidate.patch | 48
> +++
> 1 file changed, 48 insertions(+)
> create mode 100644 package/boot/uboot-lantiq/patches/0031-dma-
> lantiq-fix-out-of-bounds-cache-invalidate.patch
>
> diff --git a/package/boot/uboot-lantiq/patches/0031-dma-lantiq-fix-
> out-of-bounds-cache-invalidate.patch b/package/boot/uboot-
> lantiq/patches/0031-dma-lantiq-fix-out-of-bounds-cache-
> invalidate.patch
> new file mode 100644
> index 00..5a2bf39441
> --- /dev/null
> +++ b/package/boot/uboot-lantiq/patches/0031-dma-lantiq-fix-out-of-
> bounds-cache-invalidate.patch
> @@ -0,0 +1,48 @@
> +From f10ffb65865d5bfa5679293b13e027e0474df1fe Mon Sep 17 00:00:00
> 2001
> +From: Mathias Kresin
> +Date: Tue, 2 Nov 2021 21:24:29 +0100
> +Subject: [PATCH] dma: lantiq: fix out of bounds cache invalidate
> +
> +If u-boot is compiled with gcc 10+ the relevant part of the memory
> is
> +used as following:
> +
> +variable BootFile is at address: 0x83ffe4ec
> +variable data is at address: 0x83ffdee2
> +variable data has len: 0x600
> +
> +Within invalidate_dcache_range() the cache covering the data
> variable
> +should be invalidated (0x83ffdee2 till 0x83ffdef2).
> +
> +Due to dcache line size of 32 and some alignment correction, the
> actual
> +memory range for which the cache is invalidated is from 0x83ffdee0
> till
> +0x83ffe500, which includes the location of the BootFile variable as
> +well.
> +
> +Afterwards the BootFile variable is 0. The issue can be observed by
> +using tftpboot, which always uses the default/generated filename
> instead
> +of the specified one.
> +
> +To fix the issue, align the memory addresses properly before passing
> +them to invalidate_dcache_range(). The misalignment can be observed
> with
> +older gcc versions as well but the BootFile variable is placed more
> than
> +0x1000 bytes after the data variable and doesn't get null'ed.
> +
> +Signed-off-by: Mathias Kresin
> +---
> + drivers/dma/lantiq_dma.c | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +--- a/drivers/dma/lantiq_dma.c
> b/drivers/dma/lantiq_dma.c
> +@@ -122,9 +122,9 @@ static inline void ltq_dma_dcache_wb_inv
> +
> + static inline void ltq_dma_dcache_inv(const void *ptr, size_t size)
> + {
> +-unsigned long addr = (unsigned long) ptr;
> ++unsigned long addr = (unsigned long) ptr & ~(ARCH_DMA_MINALIGN
> - 1);
> +
> +-invalidate_dcache_range(addr, addr + size);
> ++invalidate_dcache_range(addr, ALIGN(addr + size,
> ARCH_DMA_MINALIGN));
> + }
actually invalidate_dcache_range() already aligns start and end address
to CONFIG_SYS_CACHELINE_SIZE which is the same as ARCH_DMA_MINALIGN.
In mainline we fixed the cache functions to always issue a sync() after
the cache ops to wait for all HW transactions to be complete. The
Lantiq DMA driver only does this in ltq_dma_dcache_wb_inv() but not
in ltq_dma_dcache_inv(). Maybe adding a ltq_dma_sync() there would also
fix your problem?
> +
> + void ltq_dma_init(void)
--
- Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uboot-lantiq: danube: fix hanging lzma kernel uncompression
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 > --- > .../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 00..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 > +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 > +--- > + 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
