Skip site navigation (1)Skip section navigation (2) 
Date:      Mon, 10 Feb 2020 12:17:02 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        Kyle Evans <kevans@freebsd.org>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>, Andrew Turner <andrew@freebsd.org>, Emmanuel Vadot <manu@freebsd.org>
Subject:   Re: RPi4's memreserve use in fdt not handled by aarch64 fdt_get_reserved_mem (called via its initarm)
Message-ID:  <7755D1F4-8A9D-4BC9-839B-4F527206910C@yahoo.com>
In-Reply-To: <CACNAnaEOUrmS10aPt09N08K_p4DinGMPupdAKH6djR3KGU67Jw@mail.gmail.com>
References:  <DF1349C0-ACFA-4FA9-9AC2-507BD0DBB0DE@yahoo.com> <6F4936C9-34A1-4490-8F5A-D1C2B2CE6232@yahoo.com> <CACNAnaEOUrmS10aPt09N08K_p4DinGMPupdAKH6djR3KGU67Jw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help 


On 2020-Feb-10, at 11:36, Kyle Evans <kevans at freebsd.org> wrote:

> (Removing Jeff from CC- it's becoming clear that this isn't his =
problem)
>=20
> On Mon, Feb 10, 2020 at 12:00 AM Mark Millard <marklmi@yahoo.com> =
wrote:
>> On 2020-Feb-9, at 21:12, Mark Millard <marklmi at yahoo.com> wrote:
>>=20
>>> aarch64 seems to be ignoring the RPi4B's memreserve use.
>>>=20
>>> My hypothesis is that head -r356776 and later are
>>> allocating RAM areas that overlap with the
>>> memreserve area.
>>>=20
>>> 1st see separate submittals about the live dts text reported
>>> by fdt print in u-boot on the example RPi4B 4 GiByte machine:
>>>=20
>>> =
https://lists.freebsd.org/pipermail/freebsd-arm/2020-February/021207.html
>>> =
https://lists.freebsd.org/pipermail/freebsd-arm/2020-February/021205.html
>>>=20
>>> Then:
>>>=20
>>> aarch64's initarm uses fdt_get_reserved_mem and not
>>> fdt_get_reserved_regions. So, looking at what that
>>> implies:
>>>=20
>>> int
>>> fdt_get_reserved_mem(struct mem_region *reserved, int *mreserved)
>>> {
>>>       pcell_t reg[FDT_REG_CELLS];
>>>       phandle_t child, root;
>>>       int addr_cells, size_cells;
>>>       int i, rv;
>>>=20
>>>       root =3D OF_finddevice("/reserved-memory");
>>>       if (root =3D=3D -1) {
>>>               return (ENXIO);
>>>       }
>>> . . . (I'll not list it all to show the lack of
>>> memreserve handling) . . .
>>>=20
>>> This does not check for and handle memreserve.
>>>=20
>>> By contrast armv7 and armv6 each have an initarm
>>> that uses fdt_get_reserved_regions and that in
>>> turn has:
>>>=20
>>> int
>>> fdt_get_reserved_regions(struct mem_region *mr, int *mrcnt)
>>> {
>>>       pcell_t reserve[FDT_REG_CELLS * FDT_MEM_REGIONS];
>>>       pcell_t *reservep;
>>>       phandle_t memory, root;
>>>       int addr_cells, size_cells;
>>>       int i, res_len, rv, tuple_size, tuples;
>>>=20
>>>       root =3D OF_finddevice("/");
>>>       memory =3D OF_finddevice("/memory");
>>>       if (memory =3D=3D -1) {
>>>               rv =3D ENXIO;
>>>               goto out;
>>>       }
>>>=20
>>>       if ((rv =3D fdt_addrsize_cells(OF_parent(memory), &addr_cells,
>>>           &size_cells)) !=3D 0)
>>>               goto out;
>>>=20
>>>       if (addr_cells > 2) {
>>>               rv =3D ERANGE;
>>>               goto out;
>>>       }
>>>=20
>>>       tuple_size =3D sizeof(pcell_t) * (addr_cells + size_cells);
>>>=20
>>>       res_len =3D OF_getproplen(root, "memreserve");
>>>       if (res_len <=3D 0 || res_len > sizeof(reserve)) {
>>>               rv =3D ERANGE;
>>>               goto out;
>>>       }
>>>=20
>>>       if (OF_getprop(root, "memreserve", reserve, res_len) <=3D 0) {
>>>               rv =3D ENXIO;
>>>               goto out;
>>>       }
>>> . . .
>>>=20
>>> So this handles memreserve but not /reserved-memory .
>>>=20
>>> It appears that for the RPi4B's the 32-bit "normal use"
>>> has lead to aarch64 having memreserve instead of
>>> /reserved-memory .
>>>=20
>>=20
>> I managed to make a quick test patch for head -r356529
>> but it did not make the RPi4B boot attempt behave
>> differently. So, either I messed up or handling memreserve
>> is not sufficient. (Some alternate information might be
>> covering the address range already?)
>>=20
>> I'm not familiar with the subject matter in the code, so
>> I may have messed up the test. I just used:
>>=20
>> # svnlite diff /usr/src/sys/dev/fdt/fdt_common.c
>> Index: /usr/src/sys/dev/fdt/fdt_common.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- /usr/src/sys/dev/fdt/fdt_common.c   (revision 357529)
>> +++ /usr/src/sys/dev/fdt/fdt_common.c   (working copy)
>> @@ -512,6 +512,11 @@
>>=20
>>        root =3D OF_finddevice("/reserved-memory");
>>        if (root =3D=3D -1) {
>> +               // Fail over to checking for and handling memreserve,
>> +               // such as for a RPi4B.
>> +               if (0 =3D=3D =
fdt_get_reserved_regions(reserved,mreserved))
>> +                       return (0);
>> +
>>                return (ENXIO);
>>        }
>>=20
>=20
> This seems reasonable; specifically CC'ing andrew@ and manu@ to get
> their opinion on the patch, as having authored and reviewed the
> relevant section respectively.

I wrote in a later note, not CC'd to anyone specific at
the time:

Example alternate information was:

       memory@0 {
               device_type =3D "memory";
               reg =3D <0x00000000 0x00000000 0x3b400000 0x00000000 =
0x40000000 0xbc000000>;
       };

That looks like it avoids indicating anything from the
memreserve region. (I've no clue if such is a requirement
for memory@0, but it happens to be the case for the test
context.)

I do not know if such is appropriate code or not. For my
specific test context, it makes no difference.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7755D1F4-8A9D-4BC9-839B-4F527206910C>