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.
