ARM: dts: rockchip: Reserve unusable memory region on rk3066
Subsystems (2)
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
For some reason accessing memory region above 0xfe000000 freezes system on rk3066. There is similiar bug on later rockchip soc (rk3288) solved same way.
--- arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++ 1 file changed, 13 insertions(+)
arch/arm/boot/dts/rk3066a.dtsi +13 -0
@@ -93,6 +93,19 @@ }; }; + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + /* + * The rk3066 cannot use the memory area above 0x9F000000 + * for some unknown reason. + */ + unusable at 9F000000 { + reg = <0x9F000000 0x1000000>; + }; + }; + i2s0: i2s at 10118000 { compatible = "rockchip,rk3066-i2s"; reg = <0x10118000 0x2000>;
Signature · 1 line
2.7.4
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Hi,
Quoted 18 lines · On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
For some reason accessing memory region above
0xfe000000freezes system on rk3066. There is similiar bug on later rockchip soc (rk3288) solved same way.Signed-off-by Pawe? Jarosz <[email protected]>--- arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++ 1 file changed, 13 insertions(+)arch/arm/boot/dts/rk3066a.dtsi +1
-0@@ -93,6 +93,19 @@ }; }; + reserved-memory {
arch/arm/boot/dts/rk3066a.dtsi line 106
Quoted 10 lines
arch/arm/boot/dts/rk3066a.dtsi +10
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges; + /* + * The rk3066 cannot use the memory area above 0x9F000000 + * for some unknown reason. + */ + unusable at 9F000000 { + reg = <0x9F000000 0x1000000>; + };
I don't think this is a sane workaround, but it is at best difficult to tell, given there's no reason given for why this memory is unusable.
For instance, if bus accesses to this address hang, then this patch only makes the hand less likely, since the kernel will still map the region (and therefore the CPU can perform speculative accesses).
Are issues with this memory consistently seen in practice?
Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to determine if the memory is returning erroneous values?
Thanks,
Mark.
Heiko Stuebner
maintainerPATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
Quoted 3 lines
Hi,
On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?=
Quoted 35 lines · wrote:
Quoted 21 lines
For some reason accessing memory region above
0xfe000000freezes system on rk3066. There is similiar bug on later rockchip soc (rk3288) solved same way.Signed-off-by Pawe? Jarosz <[email protected]>---
arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++ 1 file changed, 13 insertions(+)(quoted diff) +0
-0
b/arch/arm/boot/dts/rk3066a.dtsiindex 0d0dae3..44c8956 100644arch/arm/boot/dts/rk3066a.dtsi +1
-0@@ -93,6 +93,19 @@ }; }; + reserved-memory {arch/arm/boot/dts/rk3066a.dtsi line 108
Quoted 10 lines
arch/arm/boot/dts/rk3066a.dtsi +10
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges; + /* + * The rk3066 cannot use the memory area above 0x9F000000 + * for some unknown reason. + */ + unusable at 9F000000 { + reg = <0x9F000000 0x1000000>; + };I don't think this is a sane workaround, but it is at best difficult to tell, given there's no reason given for why this memory is unusable.
Quoted 8 lines
For instance, if bus accesses to this address hang, then this patch only makes the hand less likely, since the kernel will still map the region (and therefore the CPU can perform speculative accesses).
Are issues with this memory consistently seen in practice?
Can you enable
CONFIG_MEMTESTand pass 'memtest' to the kernel, to determine if the memory is returning erroneous values?
just for the sake of completeness, on the rk3288 the issue was the dma not being able to access the specific memory region (interestingly also the last 16MB but of the 4GB area supported on the rk3288). So memory itself was ok, just dma access to it failed.
We didn't find any other sane solution to limit the dma access in a general way at the time, so opted for just blocking the memory region (as it was similarly only
In the patch above, the newly blocked area is in the middle of the two 1gb memory areas (0x60000000-0xa0000000-1, 0xa0000000-0xe0000000-1).
Pavel, apart from Mark's CONFIG_MEMTEST request above could you also specifiy what type of error you see please?
Thanks
Heiko
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Hi,
main symptom is complete system freeze.
With CONFIG_MEMTEST enabled and with passed "memtest" to the kernel all tests run ok.
But when i run command for example "memtester 800M" or simple "apt update" freeze happening.
And when i reserve this region in dts, board is stable again.
Thanks,
Pawel
W dniu 01.10.2016 o 21:18, Heiko Stuebner pisze:
Quoted 65 lines
Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
Quoted 3 lines
Hi,
On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?=
Quoted 34 lines · wrote:
Quoted 21 lines
For some reason accessing memory region above
0xfe000000freezes system on rk3066. There is similiar bug on later rockchip soc (rk3288) solved same way.Signed-off-by Pawe? Jarosz <[email protected]>---
arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++ 1 file changed, 13 insertions(+)(quoted diff) +0
-0
b/arch/arm/boot/dts/rk3066a.dtsiindex 0d0dae3..44c8956 100644arch/arm/boot/dts/rk3066a.dtsi +1
-0@@ -93,6 +93,19 @@ }; }; + reserved-memory {arch/arm/boot/dts/rk3066a.dtsi line 108
Quoted 10 lines
arch/arm/boot/dts/rk3066a.dtsi +10
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges; + /* + * The rk3066 cannot use the memory area above 0x9F000000 + * for some unknown reason. + */ + unusable at 9F000000 { + reg = <0x9F000000 0x1000000>; + };I don't think this is a sane workaround, but it is at best difficult to tell, given there's no reason given for why this memory is unusable.
Quoted 8 lines
For instance, if bus accesses to this address hang, then this patch only makes the hand less likely, since the kernel will still map the region (and therefore the CPU can perform speculative accesses).
Are issues with this memory consistently seen in practice?
Can you enable
CONFIG_MEMTESTand pass 'memtest' to the kernel, to determine if the memory is returning erroneous values?just for the sake of completeness, on the rk3288 the issue was the dma not being able to access the specific memory region (interestingly also the last 16MB but of the 4GB area supported on the rk3288). So memory itself was ok, just dma access to it failed.
We didn't find any other sane solution to limit the dma access in a general way at the time, so opted for just blocking the memory region (as it was similarly only
In the patch above, the newly blocked area is in the middle of the two 1gb memory areas (0x60000000-0xa0000000-1, 0xa0000000-0xe0000000-1).
Pavel, apart from Mark's
CONFIG_MEMTESTrequest above could you also specifiy what type of error you see please?Thanks
Heiko
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
In reply to Heiko StuebnerQuoted 6 lines · Heiko Stuebner
Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
Quoted 1 line
On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?=
Quoted 3 lines · wrote:
Quoted 3 lines
For some reason accessing memory region above
0xfe000000freezes system on rk3066. There is similiar bug on later rockchip soc (rk3288) solved same way.
[...]
Quoted 21 lines
Quoted 21 lines
arch/arm/boot/dts/rk3066a.dtsi line 106
Quoted 11 lines
arch/arm/boot/dts/rk3066a.dtsi +11
-0+ reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + /* + * The rk3066 cannot use the memory area above 0x9F000000 + * for some unknown reason. + */ + unusable at 9F000000 { + reg = <0x9F000000 0x1000000>; + };I don't think this is a sane workaround, but it is at best difficult to tell, given there's no reason given for why this memory is unusable.
For instance, if bus accesses to this address hang, then this patch only makes the hand less likely, since the kernel will still map the region (and therefore the CPU can perform speculative accesses).
Are issues with this memory consistently seen in practice?
Quoted 7 lines
Quoted 2 lines
Can you enable
CONFIG_MEMTESTand pass 'memtest' to the kernel, to determine if the memory is returning erroneous values?just for the sake of completeness, on the rk3288 the issue was the dma not being able to access the specific memory region (interestingly also the last 16MB but of the 4GB area supported on the rk3288). So memory itself was ok, just dma access to it failed.
How odd.
Quoted 3 lines
We didn't find any other sane solution to limit the dma access in a general way at the time, so opted for just blocking the memory region (as it was similarly only
I was under the impression that dma-ranges could describe this kind of DMA addressing limitation. Was there some problem with that? Perhaps the driver is not acquiring/configuring its mask correctly?
Thanks,
Mark.
Heiko Stuebner
maintainerPATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Am Montag, 3. Oktober 2016, 11:20:54 CEST schrieb Mark Rutland:
Quoted 44 lines · Heiko Stuebner
Quoted 8 lines
Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
Quoted 2 lines
On Sat, Oct 01, 2016 at 04:09:39PM +0200,
=?UTF-8?q?Pawe=C5=82=20Jarosz?=Quoted 3 lines · wrote:
Quoted 3 lines
For some reason accessing memory region above
0xfe000000freezes system on rk3066. There is similiar bug on later rockchip soc (rk3288) solved same way.[...]
Quoted 22 lines
Quoted 22 lines
arch/arm/boot/dts/rk3066a.dtsi line 106
Quoted 11 lines
arch/arm/boot/dts/rk3066a.dtsi +11
-0+ reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + /* + * The rk3066 cannot use the memory area above 0x9F000000 + * for some unknown reason. + */ + unusable at 9F000000 { + reg = <0x9F000000 0x1000000>; + };I don't think this is a sane workaround, but it is at best difficult to tell, given there's no reason given for why this memory is unusable.
For instance, if bus accesses to this address hang, then this patch only makes the hand less likely, since the kernel will still map the region (and
therefore the CPU can perform speculative accesses).Are issues with this memory consistently seen in practice?
Quoted 7 lines
Quoted 2 lines
Can you enable
CONFIG_MEMTESTand pass 'memtest' to the kernel, to determine if the memory is returning erroneous values?just for the sake of completeness, on the rk3288 the issue was the dma not being able to access the specific memory region (interestingly also the last 16MB but of the 4GB area supported on the rk3288). So memory itself was ok, just dma access to it failed.
How odd.
Quoted 7 lines
Quoted 3 lines
We didn't find any other sane solution to limit the dma access in a general way at the time, so opted for just blocking the memory region (as it was similarly only
I was under the impression that dma-ranges could describe this kind of DMA addressing limitation. Was there some problem with that? Perhaps the driver is not acquiring/configuring its mask correctly?
I remember looking at (and trying) different options back then.
dma-mask wanted power-of-2 values (so it's either 4GB or 2GB (or lower)), zone-dma was a 32bit (and non-dt) thing and dma-ranges seem to simply also calculate a dma-mask from the value, so you're down to 2GB again.
So just blocking of those 16MB at the end for 4GB devices somehow sounded nicer than limiting dma access to only half the memory.
I may be overlooking something but that was what I came up with last year.
Heiko
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Quoted 31 lines
Quoted 17 lines
Quoted 9 lines
Quoted 9 lines
I don't think this is a sane workaround, but it is at best difficult to tell, given there's no reason given for why this memory is unusable.
For instance, if bus accesses to this address hang, then this patch only makes the hand less likely, since the kernel will still map the region (and
therefore the CPU can perform speculative accesses).Quoted 8 lines
Quoted 4 lines
Are issues with this memory consistently seen in practice?
Can you enable
CONFIG_MEMTESTand pass 'memtest' to the kernel, to determine if the memory is returning erroneous values?just for the sake of completeness, on the rk3288 the issue was the dma not being able to access the specific memory region (interestingly also the last 16MB but of the 4GB area supported on the rk3288). So memory itself was ok, just dma access to it failed.
Quoted 8 lines
How odd.
Quoted 3 lines
We didn't find any other sane solution to limit the dma access in a general way at the time, so opted for just blocking the memory region (as it was similarly only
I was under the impression that dma-ranges could describe this kind of DMA addressing limitation. Was there some problem with that? Perhaps the driver is not acquiring/configuring its mask correctly?
I remember looking at (and trying) different options back then.
dma-mask wanted power-of-2 values (so it's either 4GB or 2GB (or lower)), zone-dma was a 32bit (and non-dt) thing and dma-ranges seem to simply also calculate a dma-mask from the value, so you're down to 2GB again.
Quoted 7 lines
So just blocking of those 16MB at the end for 4GB devices somehow sounded nicer than limiting dma access to only half the memory.
I may be overlooking something but that was what I came up with last year.
Heiko
Is there a chance to accept this patch?
I know it's not the best solution to this problem, but i don't know a better one.
Heiko Stübner
maintainerPATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Hi Pawe?,
Am Dienstag, 4. Oktober 2016, 13:56:07 schrieb Pawe? Jarosz:
Quoted 43 lines
Quoted 43 lines
Quoted 22 lines
Quoted 11 lines
Quoted 11 lines
I don't think this is a sane workaround, but it is at best difficult to tell, given there's no reason given for why this memory is unusable.
For instance, if bus accesses to this address hang, then this patch only
makes the hand less likely, since the kernel will still map the region (and
therefore the CPU can perform speculative accesses).Are issues with this memory consistently seen in practice?
Quoted 8 lines
Quoted 2 lines
Can you enable
CONFIG_MEMTESTand pass 'memtest' to the kernel, to determine if the memory is returning erroneous values?just for the sake of completeness, on the rk3288 the issue was the dma not
being able to access the specific memory region (interestingly also the last 16MB but of the 4GB area supported on the rk3288). So memory itself was ok, just dma access to it failed.How odd.
Quoted 8 lines
Quoted 4 lines
We didn't find any other sane solution to limit the dma access in a general way at the time, so opted for just blocking the memory region (as
it was similarly onlyI was under the impression that dma-ranges could describe this kind of DMA addressing limitation. Was there some problem with that? Perhaps the driver is not acquiring/configuring its mask correctly?
I remember looking at (and trying) different options back then.
dma-mask wanted power-of-2 values (so it's either 4GB or 2GB (or lower)), zone-dma was a 32bit (and non-dt) thing and dma-ranges seem to simply also calculate a dma-mask from the value, so you're down to 2GB again.
So just blocking of those 16MB at the end for 4GB devices somehow sounded nicer than limiting dma access to only half the memory.
I may be overlooking something but that was what I came up with last year.
Quoted 6 lines
Quoted 1 line
Heiko
Is there a chance to accept this patch?
I know it's not the best solution to this problem, but i don't know a better one.
there is always a "chance". But with changes like these, we always try to find a real cause first, before resorting to solutions like this. So it's definitly not off the table, but I'd like to investigate further first, so that we don't accumulate unnecessary hacks over time.
Especially that your region seems to be in the middle of the designated ram area is strange.
Could you please tell which board you're using (and how much memory it has)
Thanks
Heiko
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
In reply to =?UTF-8?q?Pawe=C5=82=20Jarosz?=Hi, Pawe?:
Quoted 2 lines · On 2016?10?01? 22:09, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
For some reason accessing memory region above
0xfe000000freezes system on rk3066. There is similiar bug on later rockchip soc (rk3288)
RK3066 only support 2GB memory from 0x60000000 to 0xE0000000, can not access above 0xfe000000. I think you mean 0x9F000000?
Quoted 13 lines
solved same way.
Signed-off-by Pawe? Jarosz <[email protected]>--- arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++ 1 file changed, 13 insertions(+)arch/arm/boot/dts/rk3066a.dtsi +0
-0@@ -93,6 +93,19 @@ };
arch/arm/boot/dts/rk3066a.dtsi line 103
Quoted 10 lines
arch/arm/boot/dts/rk3066a.dtsi +8
-0}; + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + /* + * The rk3066 cannot use the memory area above 0x9F000000 + * for some unknown reason. + */
I don't remember RK3066 has such limit. I will double check with our IC design team.
Do you know which master can not access this memory area [0x9F000000~0xA0000000)?
Quoted 8 lines
arch/arm/boot/dts/rk3066a.dtsi +5
-0+ unusable at 9F000000 { + reg = <0x9F000000 0x1000000>; + }; + }; + i2s0: i2s at 10118000 { compatible = "rockchip,rk3066-i2s"; reg = <0x10118000 0x2000>;
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Hi
W dniu 05.10.2016 o 04:27, Huang, Tao pisze:
Quoted 6 lines
Hi, Pawe?:
Quoted 2 lines · On 2016?10?01? 22:09, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
For some reason accessing memory region above
0xfe000000freezes system on rk3066. There is similiar bug on later rockchip soc (rk3288)RK3066 only support 2GB memory from
0x60000000to0xE0000000, can not access above0xfe000000. I think you mean0x9F000000?
Yes i meant 0x9F00000. Sorry for that.
Quoted 4 lines
I don't remember RK3066 has such limit. I will double check with our IC design team.
Do you know which master can not access this memory area [0x9F000000~0xA0000000)?
I don't.
Quoted 1 line
Could you please tell which board you're using (and how much memory it has)
Rikomagic MK808 1GB RAM
Thanks
Pawel
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Hi Pawe?:
Quoted 9 lines · Pawe? Jarosz
W dniu 05.10.2016 o 04:27, Huang, Tao pisze:
Quoted 4 lines
I don't remember RK3066 has such limit. I will double check with our IC design team.
Do you know which master can not access this memory area [0x9F000000~0xA0000000)?I don't.
Quoted 1 line
Could you please tell which board you're using (and how much memory it has)
Rikomagic MK808 1GB RAM
Our IC guy need us tell them which master can not access such area, DMA or EMMC Controller or GPU, etc? Could you tell me how to reproduce such issue?
And we can confirm CPU core can access this memory through /dev/mem and the test board is 1GB too. Personally, I don't think RK3066 has such limit because when we verify this chip, we don't found such limit at all.
Thanks,
Huang, Tao
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Hi
W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
Quoted 9 lines
Our IC guy need us tell them which master can not access such area, DMA or EMMC Controller or GPU, etc? Could you tell me how to reproduce such issue?
And we can confirm CPU core can access this memory through/dev/memand the test board is 1GB too. Personally, I don't think RK3066 has such limit because when we verify this chip, we don't found such limit at all.Thanks,
Huang, Tao
I'm getting this on Ubuntu 16.04 with mainline kernel. My board always freezes when i type: "memtester 800M"
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Hi, Pawe?:
Quoted 8 lines · Pawe? Jarosz
W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
Quoted 7 lines
Our IC guy need us tell them which master can not access such area, DMA or EMMC Controller or GPU, etc? Could you tell me how to reproduce such issue?
And we can confirm CPU core can access this memory through/dev/memand the test board is 1GB too. Personally, I don't think RK3066 has such limit because when we verify this chip, we don't found such limit at all.
Quoted 5 lines
Quoted 2 lines
Thanks,
Huang, TaoI'm getting this on Ubuntu 16.04 with mainline kernel. My board always freezes when i type: "memtester 800M"
We try run memtest 800M with Linux kernel 4.8, which killed by OOM. But if we run:
# memtester -p 0x9F000000 16K 1 memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only).
pagesize is 4096
pagesizemask is 0xfffff000
want 0MB (16384 bytes)
Loop 1/1:
Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok 8-bit Writes : ok 16-bit Writes : ok
So these memory should be fine to CPU core. Maybe your system just freeze because out of memory.
PATCH 1/1 ARM: dts: rockchip: Reserve unusable memory region on rk3066
Hi
W dniu 13.10.2016 o 09:12, Huang, Tao pisze:
Quoted 45 lines
Hi, Pawe?:
Quoted 8 lines · Pawe? Jarosz
W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
Quoted 7 lines
Our IC guy need us tell them which master can not access such area, DMA or EMMC Controller or GPU, etc? Could you tell me how to reproduce such issue?
And we can confirm CPU core can access this memory through/dev/memand the test board is 1GB too. Personally, I don't think RK3066 has such limit because when we verify this chip, we don't found such limit at all.Quoted 5 lines
Quoted 2 lines
Thanks,
Huang, TaoI'm getting this on Ubuntu 16.04 with mainline kernel. My board always freezes when i type: "memtester 800M"
We try run memtest 800M with Linux kernel 4.8, which killed by OOM. But if we run:
# memtester -p 0x9F000000 16K 1 memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only).pagesize is 4096
pagesizemask is0xfffff000
want 0MB (16384 bytes)
Loop 1/1:Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : okSequential Increment: ok
Solid Bits : ok
Block Sequential : ok
Checkerboard : ok
Bit Spread : ok
Bit Flip : ok
Walking Ones : ok
Walking Zeroes : ok
8-bit Writes : ok
16-bit Writes : ok
Quoted 3 lines
So these memory should be fine to CPU core. Maybe your system just freeze because out of memory.
weird ... memtester -p 0x9F000000 16K 1 gave me the same result.
Could you try one last command:
memtester 400M
Values > 200M causing freeze.
If this won't do it, than maybe there is something wrong with my board.
Thanks for your time.