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 NO

[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 def

[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 co

[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

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

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 >

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 wheth