Re: Random reboots on ODROID-N2+

From: Stefan Agner <stefan@agner.ch>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Byron Stanoszek <gandalf@winds.org>,
	linux-amlogic@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	Neil Armstrong <narmstrong@baylibre.com>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Mike Rapoport <rppt@kernel.org>
Subject: Re: Random reboots on ODROID-N2+
Date: Fri, 23 Jul 2021 21:48:47 +0200	[thread overview]
Message-ID: <50c6925775c207d0751e20fa9d45611a@agner.ch> (raw)
In-Reply-To: <0067ee4c-b9d2-1c92-2444-759ac9a56de0@arm.com>

On 2021-07-23 19:47, Robin Murphy wrote:
> On 2021-07-23 17:14, Robin Murphy wrote:
>> On 2021-07-23 16:56, Stefan Agner wrote:
<snip>
>>>>
>>>> Booting with "efi=debug" should (among other things) print the memory
>>>> map at boot if you want to double-check that that is the source of the
>>>> mismatch. Our EFI code should be perfectly capable of setting the
>>>> memblock flag if the region *is* described appropriately, see
>>>> reserve_regions() in drivers/firmware/efi/efi-init.c.
>>>
>>> Booting 5.12.10 with "efi=debug" on U-Boot 2021.04 gave this:
>>> [    0.000000] Machine model: Hardkernel ODROID-N2Plus
>>> [    0.000000] efi: Getting UEFI parameters from /chosen in DT:
>>> [    0.000000] efi: UEFI not found.
>>> [    0.000000] OF: fdt: Reserved memory: failed to reserve memory for
>>> node 'secmon@5000000': base 0x0000000005000000, size 3 MiB
>>>
>>> So it seems UEFI is not in the play here?
>>
>> Ah, OK, in that case I guess the question remains why does early_init_dt_reserve_memory_arch() think the region is already reserved? My instinctive assumption was an EFI memory map being present; seeing that U-Boot does indeed reflect DT reservations there *and* has had a likely-looking bug recently was then just overwhelmingly suggestive :)
> 
> Actually, poking at U-Boot a bit more I find
> meson_board_add_reserved_memory() - can you check /sys/firmware/fdt
> and see if the region ends up being passed as a /memreserve/ as well
> as a proper reserved-memory node?
> 
> IIRC the semantics of /memreserve/ aren't really well-defined enough
> to be suitable for the kind of things which require no-map, and my new
> guess is that that's what ends up conflicting here.

Seems to be present in booth:

On v5.12.10
# fdtdump /sys/firmware/fdt
...
/memreserve/ 0x5000000 0x300000;
...
    reserved-memory {
        #address-cells = <0x00000002>;
        #size-cells = <0x00000002>;
        ranges;
        secmon@5000000 {
            reg = <0x00000000 0x05000000 0x00000000 0x00300000>;
            no-map;
            phandle = <0x00000068>;
        };
        linux,cma {
            compatible = "shared-dma-pool";
            reusable;
            size = <0x00000000 0x10000000>;
            alignment = <0x00000000 0x00400000>;
            linux,cma-default;
        };
    };

--
Stefan

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