On 11/3/21 12:10 AM, Mathias Kresin wrote:
11/2/21 11:52 PM, Hauke Mehrtens:
On 11/2/21 11:35 PM, Mathias Kresin wrote:
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
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
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
11/2/21 11:52 PM, Hauke Mehrtens:
On 11/2/21 11:35 PM, Mathias Kresin wrote:
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 wh
On 11/2/21 11:35 PM, Mathias Kresin wrote:
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 fla
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 t
