[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[=?UTF-8?q?Pawe=C5=82=20Jarosz?=]

For some reason accessing memory region above 0xfe000000 freezes
system on rk3066. There is similiar bug on later rockchip soc (rk3288)
solved same way.

Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com>
---
 arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 0d0dae3..44c8956 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -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@9F000000 {
+			reg = <0x9F000000 0x1000000>;
+		};
+	};
+
 	i2s0: i2s@10118000 {
 		compatible = "rockchip,rk3066-i2s";
 		reg = <0x10118000 0x2000>;
-- 
2.7.4


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[=?UTF-8?q?Pawe=C5=82=20Jarosz?=]

For some reason accessing memory region above 0xfe000000 freezes
system on rk3066. There is similiar bug on later rockchip soc (rk3288)
solved same way.

Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
---
 arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 0d0dae3..44c8956 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -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>;
-- 
2.7.4

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Mark Rutland]

Hi,

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 0xfe000000 freezes
> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> solved same way.
> 
> Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com>
> ---
>  arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 0d0dae3..44c8956 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -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@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.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Mark Rutland]

Hi,

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 0xfe000000 freezes
> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> solved same way.
> 
> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
> ---
>  arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 0d0dae3..44c8956 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -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>;
> +		};

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.

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Heiko Stuebner]

Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
> Hi,
> 
> 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 0xfe000000 freezes
> > system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> > solved same way.
> > 
> > Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com>
> > ---
> > 
> >  arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/rk3066a.dtsi
> > b/arch/arm/boot/dts/rk3066a.dtsi index 0d0dae3..44c8956 100644
> > --- a/arch/arm/boot/dts/rk3066a.dtsi
> > +++ b/arch/arm/boot/dts/rk3066a.dtsi
> > @@ -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@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?

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

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Heiko Stuebner]

Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
> Hi,
> 
> 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 0xfe000000 freezes
> > system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> > solved same way.
> > 
> > Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
> > ---
> > 
> >  arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/rk3066a.dtsi
> > b/arch/arm/boot/dts/rk3066a.dtsi index 0d0dae3..44c8956 100644
> > --- a/arch/arm/boot/dts/rk3066a.dtsi
> > +++ b/arch/arm/boot/dts/rk3066a.dtsi
> > @@ -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>;
> > +		};
> 
> 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?

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

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Paweł Jarosz]

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:
> Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
>> Hi,
>>
>> 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 0xfe000000 freezes
>>> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
>>> solved same way.
>>>
>>> Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com>
>>> ---
>>>
>>>   arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>>>   1 file changed, 13 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/rk3066a.dtsi
>>> b/arch/arm/boot/dts/rk3066a.dtsi index 0d0dae3..44c8956 100644
>>> --- a/arch/arm/boot/dts/rk3066a.dtsi
>>> +++ b/arch/arm/boot/dts/rk3066a.dtsi
>>> @@ -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@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?
> 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


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Paweł Jarosz]

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:
> Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
>> Hi,
>>
>> 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 0xfe000000 freezes
>>> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
>>> solved same way.
>>>
>>> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
>>> ---
>>>
>>>   arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>>>   1 file changed, 13 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/rk3066a.dtsi
>>> b/arch/arm/boot/dts/rk3066a.dtsi index 0d0dae3..44c8956 100644
>>> --- a/arch/arm/boot/dts/rk3066a.dtsi
>>> +++ b/arch/arm/boot/dts/rk3066a.dtsi
>>> @@ -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>;
>>> +		};
>> 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?
> 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

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Mark Rutland]

On Sat, Oct 01, 2016 at 09:18:15PM +0200, Heiko Stuebner wrote:
> Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
> > 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 0xfe000000 freezes
> > > system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> > > solved same way.

[...]

> > > +	reserved-memory {
> > > +		#address-cells = <1>;
> > > +		#size-cells = <1>;
> > > +		ranges;
> > > +		/*
> > > +		 * The rk3066 cannot use the memory area above 0x9F000000
> > > +		 * for some unknown reason.
> > > +		 */
> > > +		unusable@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?
> 
> 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.

> 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.

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Mark Rutland]

On Sat, Oct 01, 2016 at 09:18:15PM +0200, Heiko Stuebner wrote:
> Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
> > 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 0xfe000000 freezes
> > > system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> > > solved same way.

[...]

> > > +	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?
> > 
> > Can you enable CONFIG_MEMTEST and 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.

> 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.

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Heiko Stuebner]

Am Montag, 3. Oktober 2016, 11:20:54 CEST schrieb Mark Rutland:
> On Sat, Oct 01, 2016 at 09:18:15PM +0200, Heiko Stuebner wrote:
> > Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
> > > 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 0xfe000000 freezes
> > > > system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> > > > solved same way.
> 
> [...]
> 
> > > > +	reserved-memory {
> > > > +		#address-cells = <1>;
> > > > +		#size-cells = <1>;
> > > > +		ranges;
> > > > +		/*
> > > > +		 * The rk3066 cannot use the memory area above 0x9F000000
> > > > +		 * for some unknown reason.
> > > > +		 */
> > > > +		unusable@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?
> > 
> > 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.
> 
> > 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] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Heiko Stuebner]

Am Montag, 3. Oktober 2016, 11:20:54 CEST schrieb Mark Rutland:
> On Sat, Oct 01, 2016 at 09:18:15PM +0200, Heiko Stuebner wrote:
> > Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
> > > 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 0xfe000000 freezes
> > > > system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> > > > solved same way.
> 
> [...]
> 
> > > > +	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?
> > > 
> > > Can you enable CONFIG_MEMTEST and 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.
> 
> > 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

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Paweł Jarosz]

>>>> 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?
>>> 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.
>>
>>> 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
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.

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Paweł Jarosz]

>>>> 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?
>>> 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.
>>
>>> 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
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.

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Heiko Stübner]

Hi Paweł,

Am Dienstag, 4. Oktober 2016, 13:56:07 schrieb Paweł Jarosz:
> >>>> 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?
> >>> 
> >>> 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.
> >> 
> >>> 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
> 
> 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

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Heiko Stübner]

Hi Pawe?,

Am Dienstag, 4. Oktober 2016, 13:56:07 schrieb Pawe? Jarosz:
> >>>> 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?
> >>> 
> >>> 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.
> >> 
> >>> 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
> 
> 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

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Huang, Tao]

Hi, Paweł:
On 2016年10月01日 22:09, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
> For some reason accessing memory region above 0xfe000000 freezes
> 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?
> solved same way.
>
> Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com>
> ---
>  arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 0d0dae3..44c8956 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -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.
> +		 */

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)?

> +		unusable@9F000000 {
> +			reg = <0x9F000000 0x1000000>;
> +		};
> +	};
> +
>  	i2s0: i2s@10118000 {
>  		compatible = "rockchip,rk3066-i2s";
>  		reg = <0x10118000 0x2000>;



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Huang, Tao]

Hi, Pawe?:
On 2016?10?01? 22:09, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
> For some reason accessing memory region above 0xfe000000 freezes
> 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?
> solved same way.
>
> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
> ---
>  arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 0d0dae3..44c8956 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -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.
> +		 */

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)?

> +		unusable at 9F000000 {
> +			reg = <0x9F000000 0x1000000>;
> +		};
> +	};
> +
>  	i2s0: i2s at 10118000 {
>  		compatible = "rockchip,rk3066-i2s";
>  		reg = <0x10118000 0x2000>;

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Paweł Jarosz]

Hi


W dniu 05.10.2016 o 04:27, Huang, Tao pisze:
> Hi, Paweł:
> On 2016年10月01日 22:09, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
>> For some reason accessing memory region above 0xfe000000 freezes
>> 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?
Yes i meant 0x9F00000. Sorry for that.
> 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.
> Could you please tell which board you're using (and how much memory it has)
Rikomagic MK808 1GB RAM

Thanks
Pawel


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Paweł Jarosz]

Hi


W dniu 05.10.2016 o 04:27, Huang, Tao pisze:
> Hi, Pawe?:
> On 2016?10?01? 22:09, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
>> For some reason accessing memory region above 0xfe000000 freezes
>> 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?
Yes i meant 0x9F00000. Sorry for that.
> 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.
> Could you please tell which board you're using (and how much memory it has)
Rikomagic MK808 1GB RAM

Thanks
Pawel

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Huang, Tao]

Hi Paweł:
On 2016年10月05日 14:09, Paweł Jarosz wrote:
> W dniu 05.10.2016 o 04:27, Huang, Tao pisze:
>> 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.
>> 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


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Huang, Tao]

Hi Pawe?:
On 2016?10?05? 14:09, Pawe? Jarosz wrote:
> W dniu 05.10.2016 o 04:27, Huang, Tao pisze:
>> 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.
>> 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

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Paweł Jarosz]

Hi


W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
> 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

I'm getting this on Ubuntu 16.04 with mainline kernel.
My board always freezes when i type: "memtester 800M"

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Paweł Jarosz]

Hi


W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
> 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

I'm getting this on Ubuntu 16.04 with mainline kernel.
My board always freezes when i type: "memtester 800M"

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Huang, Tao]

Hi, Paweł:
On 2016年10月10日 17:11, Paweł Jarosz wrote:
> W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
>> 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
> I'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.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Huang, Tao]

Hi, Pawe?:
On 2016?10?10? 17:11, Pawe? Jarosz wrote:
> W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
>> 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
> I'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.

Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Paweł Jarosz]

Hi


W dniu 13.10.2016 o 09:12, Huang, Tao pisze:
> Hi, Paweł:
> On 2016年10月10日 17:11, Paweł Jarosz wrote:
>> W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
>>> 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
>> I'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.
>

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.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

[Paweł Jarosz]

Hi


W dniu 13.10.2016 o 09:12, Huang, Tao pisze:
> Hi, Pawe?:
> On 2016?10?10? 17:11, Pawe? Jarosz wrote:
>> W dniu 10.10.2016 o 09:18, Huang, Tao pisze:
>>> 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
>> I'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.
>

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.