On Fri, Dec 18, 2020 at 09:59:26PM +0000, Guillaume Tucker wrote:
> On 13/12/2020 08:23, Mike Rapoport wrote:
> > Hi Guillaume,
> >
> > On Fri, Dec 11, 2020 at 09:53:46PM +0000, Guillaume Tucker wrote:
> >> Hi Mike,
> >>
>
> OK, sorry for the delay. I've built a kernel and booted it as
> you requested, and also found that the issue was due to this
> memory area defined in arch/arm/boot/dts/rk3288.dtsi:
>
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> /*
> * The rk3288 cannot use the memory area above 0xfe000000
> * for dma operations for some reason. While there is
> * probably a better solution available somewhere, we
> * haven't found it yet and while devices with 2GB of ram
> * are not affected, this issue prevents 4GB from booting.
> * So to make these devices at least bootable, block
> * this area for the time being until the real solution
> * is found.
> */
> dma-unusable@fe000000 {
> reg = <0x0 0xfe000000 0x0 0x1000000>;
> };
> };
>
> So I've put a hack[1] on top of 950c37691925 to skip adding a
> node in memblock_enforce_memory_reserved_overlap() if the base
> address is 0xfe000000, which got the kernel booting. Here's the
> console log:
>
> https://people.collabora.com/~gtucker/tmp/2966825.txt
>
> and the full test job details, if this helps:
>
> https://lava.collabora.co.uk/scheduler/job/2966825
>
>
> I haven't really looked much further than that, but I'll be
> available on Monday to help run other tests if needed.
Sorry for the delay, I was mostly offline for the last three weeks.
Thanks for the logs, it seems that implicitly adding reserved regions to
memblock.memory wasn't that bright idea :)
> Thanks,
> Guillaume
>
> [1] https://people.collabora.com/~gtucker/tmp/2966825.patch
--
Sincerely yours,
Mike.
