diff options
| author | Mathias Kresin <dev@kresin.me> | 2021-11-05 10:41:26 +0100 |
|---|---|---|
| committer | Mathias Kresin <dev@kresin.me> | 2021-11-14 20:15:29 +0100 |
| commit | 565b62cca2fc7d27f1f1584c44830a6e5c4f0f61 (patch) | |
| tree | 453d81092d2e83b986e0e232e554e5478a24d3f6 /.gitattributes | |
| parent | 9bd9e04b6fe7e427a5d90ccbb186c2727767a756 (diff) | |
| download | upstream-565b62cca2fc7d27f1f1584c44830a6e5c4f0f61.tar.gz upstream-565b62cca2fc7d27f1f1584c44830a6e5c4f0f61.tar.bz2 upstream-565b62cca2fc7d27f1f1584c44830a6e5c4f0f61.zip | |
uboot-lantiq: danube: fix hanging lzma kernel uncompression
At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the
assembly of LzmaProps_Decode. While the decission made by the compiler
looks perfect fine, it triggers some obscure hang on lantiq danube-s
v1.5 with MX29LV640EB NOR flash chips.
Only if the offset 1 is used, the hang can be observed. Using any other
offset works fine:
lwl s0,0(a1) - s0 == 0x6d000080
lwl s0,1(a1) - hangs
lwl s0,2(a1) - s0 == 0x0080xxxx
lwl s0,3(a1) - s0 == 0x80xxxxxx
It isn't clear whether it is a limitation of the flash chip, the EBU or
something else.
Force 8bit reads to prevent gcc optimizing the read with lwr/lwl
instructions.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Diffstat (limited to '.gitattributes')
0 files changed, 0 insertions, 0 deletions