From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Stuebner Subject: Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066 Date: Sat, 01 Oct 2016 21:18:15 +0200 Message-ID: <6962779.A926KxJite@phil> References: <20161001140939.GA31220@vaio-ubuntu> <20161001181711.GB17554@remoulade> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20161001181711.GB17554@remoulade> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+glpar-linux-rockchip=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Mark Rutland Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, =?utf-8?B?UGF3ZcWC?= Jarosz , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: linux-rockchip.vger.kernel.org QW0gU2Ftc3RhZywgMS4gT2t0b2JlciAyMDE2LCAxOToxNzoxMSBDRVNUIHNjaHJpZWIgTWFyayBS dXRsYW5kOgo+IEhpLAo+IAo+IE9uIFNhdCwgT2N0IDAxLCAyMDE2IGF0IDA0OjA5OjM5UE0gKzAy MDAsID0/VVRGLTg/cT9QYXdlPUM1PTgyPTIwSmFyb3N6Pz0gCndyb3RlOgo+ID4gRm9yIHNvbWUg cmVhc29uIGFjY2Vzc2luZyBtZW1vcnkgcmVnaW9uIGFib3ZlIDB4ZmUwMDAwMDAgZnJlZXplcwo+ ID4gc3lzdGVtIG9uIHJrMzA2Ni4gVGhlcmUgaXMgc2ltaWxpYXIgYnVnIG9uIGxhdGVyIHJvY2tj aGlwIHNvYyAocmszMjg4KQo+ID4gc29sdmVkIHNhbWUgd2F5Lgo+ID4gCj4gPiBTaWduZWQtb2Zm LWJ5OiBQYXdlxYIgSmFyb3N6IDxwYXdlbGphcm9zejM2OTFAZ21haWwuY29tPgo+ID4gLS0tCj4g PiAKPiA+ICBhcmNoL2FybS9ib290L2R0cy9yazMwNjZhLmR0c2kgfCAxMyArKysrKysrKysrKysr Cj4gPiAgMSBmaWxlIGNoYW5nZWQsIDEzIGluc2VydGlvbnMoKykKPiA+IAo+ID4gZGlmZiAtLWdp dCBhL2FyY2gvYXJtL2Jvb3QvZHRzL3JrMzA2NmEuZHRzaQo+ID4gYi9hcmNoL2FybS9ib290L2R0 cy9yazMwNjZhLmR0c2kgaW5kZXggMGQwZGFlMy4uNDRjODk1NiAxMDA2NDQKPiA+IC0tLSBhL2Fy Y2gvYXJtL2Jvb3QvZHRzL3JrMzA2NmEuZHRzaQo+ID4gKysrIGIvYXJjaC9hcm0vYm9vdC9kdHMv cmszMDY2YS5kdHNpCj4gPiBAQCAtOTMsNiArOTMsMTkgQEAKPiA+IAo+ID4gIAkJfTsKPiA+ICAJ Cj4gPiAgCX07Cj4gPiAKPiA+ICsJcmVzZXJ2ZWQtbWVtb3J5IHsKPiA+ICsJCSNhZGRyZXNzLWNl bGxzID0gPDE+Owo+ID4gKwkJI3NpemUtY2VsbHMgPSA8MT47Cj4gPiArCQlyYW5nZXM7Cj4gPiAr CQkvKgo+ID4gKwkJICogVGhlIHJrMzA2NiBjYW5ub3QgdXNlIHRoZSBtZW1vcnkgYXJlYSBhYm92 ZSAweDlGMDAwMDAwCj4gPiArCQkgKiBmb3Igc29tZSB1bmtub3duIHJlYXNvbi4KPiA+ICsJCSAq Lwo+ID4gKwkJdW51c2FibGVAOUYwMDAwMDAgewo+ID4gKwkJCXJlZyA9IDwweDlGMDAwMDAwIDB4 MTAwMDAwMD47Cj4gPiArCQl9Owo+IAo+IEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIHNhbmUgd29y a2Fyb3VuZCwgYnV0IGl0IGlzIGF0IGJlc3QgZGlmZmljdWx0IHRvCj4gdGVsbCwgZ2l2ZW4gdGhl cmUncyBubyByZWFzb24gZ2l2ZW4gZm9yIHdoeSB0aGlzIG1lbW9yeSBpcyB1bnVzYWJsZS4KPiAK PiBGb3IgaW5zdGFuY2UsIGlmIGJ1cyBhY2Nlc3NlcyB0byB0aGlzIGFkZHJlc3MgaGFuZywgdGhl biB0aGlzIHBhdGNoIG9ubHkKPiBtYWtlcyB0aGUgaGFuZCBsZXNzIGxpa2VseSwgc2luY2UgdGhl IGtlcm5lbCB3aWxsIHN0aWxsIG1hcCB0aGUgcmVnaW9uIChhbmQKPiB0aGVyZWZvcmUgdGhlIENQ VSBjYW4gcGVyZm9ybSBzcGVjdWxhdGl2ZSBhY2Nlc3NlcykuCj4gCj4gQXJlIGlzc3VlcyB3aXRo IHRoaXMgbWVtb3J5IGNvbnNpc3RlbnRseSBzZWVuIGluIHByYWN0aWNlPwo+IAo+IENhbiB5b3Ug ZW5hYmxlIENPTkZJR19NRU1URVNUIGFuZCBwYXNzICdtZW10ZXN0JyB0byB0aGUga2VybmVsLCB0 byBkZXRlcm1pbmUKPiBpZiB0aGUgbWVtb3J5IGlzIHJldHVybmluZyBlcnJvbmVvdXMgdmFsdWVz PwoKanVzdCBmb3IgdGhlIHNha2Ugb2YgY29tcGxldGVuZXNzLCBvbiB0aGUgcmszMjg4IHRoZSBp c3N1ZSB3YXMgdGhlIGRtYSBub3QgCmJlaW5nIGFibGUgdG8gYWNjZXNzIHRoZSBzcGVjaWZpYyBt ZW1vcnkgcmVnaW9uIChpbnRlcmVzdGluZ2x5IGFsc28gdGhlIGxhc3QgCjE2TUIgYnV0IG9mIHRo ZSA0R0IgYXJlYSBzdXBwb3J0ZWQgb24gdGhlIHJrMzI4OCkuIFNvIG1lbW9yeSBpdHNlbGYgd2Fz IG9rLCAKanVzdCBkbWEgYWNjZXNzIHRvIGl0IGZhaWxlZC4KCldlIGRpZG4ndCBmaW5kIGFueSBv dGhlciBzYW5lIHNvbHV0aW9uIHRvIGxpbWl0IHRoZSBkbWEgYWNjZXNzIGluIGEgZ2VuZXJhbCB3 YXkgCmF0IHRoZSB0aW1lLCBzbyBvcHRlZCBmb3IganVzdCBibG9ja2luZyB0aGUgbWVtb3J5IHJl Z2lvbiAoYXMgaXQgd2FzIHNpbWlsYXJseSAKb25seSAKCkluIHRoZSBwYXRjaCBhYm92ZSwgdGhl IG5ld2x5IGJsb2NrZWQgYXJlYSBpcyBpbiB0aGUgbWlkZGxlIG9mIHRoZSB0d28gMWdiIAptZW1v cnkgYXJlYXMgKDB4NjAwMDAwMDAtMHhhMDAwMDAwMC0xLCAweGEwMDAwMDAwLTB4ZTAwMDAwMDAt MSkuCgpQYXZlbCwgYXBhcnQgZnJvbSBNYXJrJ3MgQ09ORklHX01FTVRFU1QgcmVxdWVzdCBhYm92 ZSBjb3VsZCB5b3UgYWxzbyBzcGVjaWZpeSAKd2hhdCB0eXBlIG9mIGVycm9yIHlvdSBzZWUgcGxl YXNlPwoKClRoYW5rcwpIZWlrbwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KTGludXgtcm9ja2NoaXAgbWFpbGluZyBsaXN0CkxpbnV4LXJvY2tjaGlwQGxp c3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0 aW5mby9saW51eC1yb2NrY2hpcAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: heiko@sntech.de (Heiko Stuebner) Date: Sat, 01 Oct 2016 21:18:15 +0200 Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066 In-Reply-To: <20161001181711.GB17554@remoulade> References: <20161001140939.GA31220@vaio-ubuntu> <20161001181711.GB17554@remoulade> Message-ID: <6962779.A926KxJite@phil> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > > --- > > > > 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