From owner-freebsd-arm@freebsd.org Mon Feb 10 19:36:25 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5ADFA2422F0 for ; Mon, 10 Feb 2020 19:36:25 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48GbkK1c5Cz3xKZ; Mon, 10 Feb 2020 19:36:25 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 2550F414E; Mon, 10 Feb 2020 19:36:25 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f54.google.com with SMTP id dp13so3749032qvb.7; Mon, 10 Feb 2020 11:36:25 -0800 (PST) X-Gm-Message-State: APjAAAWMOBBA8cyzFKyVsMM87YP3xsdfIS4z/ls9llx1b/D1d+RQ+Txo KMrdbGX5adMsn6ZBAbQiNfaiIwfwFclxcZ0Zk34= X-Google-Smtp-Source: APXvYqyky1kPpDHWcgNVsWcCssEe6+5IVaZ1uNhkEMYJhfiZsUMLo/AsEJX6Mm41qQR8RwwYHuOLHrlO5QZ+l7ZhZdo= X-Received: by 2002:a05:6214:118d:: with SMTP id t13mr11199171qvv.5.1581363384474; Mon, 10 Feb 2020 11:36:24 -0800 (PST) MIME-Version: 1.0 References: <6F4936C9-34A1-4490-8F5A-D1C2B2CE6232@yahoo.com> In-Reply-To: <6F4936C9-34A1-4490-8F5A-D1C2B2CE6232@yahoo.com> From: Kyle Evans Date: Mon, 10 Feb 2020 13:36:12 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RPi4's memreserve use in fdt not handled by aarch64 fdt_get_reserved_mem (called via its initarm) To: Mark Millard Cc: freebsd-arm , Andrew Turner , Emmanuel Vadot Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 19:36:25 -0000 (Removing Jeff from CC- it's becoming clear that this isn't his problem) On Mon, Feb 10, 2020 at 12:00 AM Mark Millard wrote: > On 2020-Feb-9, at 21:12, Mark Millard wrote: > > > aarch64 seems to be ignoring the RPi4B's memreserve use. > > > > My hypothesis is that head -r356776 and later are > > allocating RAM areas that overlap with the > > memreserve area. > > > > 1st see separate submittals about the live dts text reported > > by fdt print in u-boot on the example RPi4B 4 GiByte machine: > > > > https://lists.freebsd.org/pipermail/freebsd-arm/2020-February/021207.html > > https://lists.freebsd.org/pipermail/freebsd-arm/2020-February/021205.html > > > > Then: > > > > aarch64's initarm uses fdt_get_reserved_mem and not > > fdt_get_reserved_regions. So, looking at what that > > implies: > > > > 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; > > > > root = OF_finddevice("/reserved-memory"); > > if (root == -1) { > > return (ENXIO); > > } > > . . . (I'll not list it all to show the lack of > > memreserve handling) . . . > > > > This does not check for and handle memreserve. > > > > By contrast armv7 and armv6 each have an initarm > > that uses fdt_get_reserved_regions and that in > > turn has: > > > > 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; > > > > root = OF_finddevice("/"); > > memory = OF_finddevice("/memory"); > > if (memory == -1) { > > rv = ENXIO; > > goto out; > > } > > > > if ((rv = fdt_addrsize_cells(OF_parent(memory), &addr_cells, > > &size_cells)) != 0) > > goto out; > > > > if (addr_cells > 2) { > > rv = ERANGE; > > goto out; > > } > > > > tuple_size = sizeof(pcell_t) * (addr_cells + size_cells); > > > > res_len = OF_getproplen(root, "memreserve"); > > if (res_len <= 0 || res_len > sizeof(reserve)) { > > rv = ERANGE; > > goto out; > > } > > > > if (OF_getprop(root, "memreserve", reserve, res_len) <= 0) { > > rv = ENXIO; > > goto out; > > } > > . . . > > > > So this handles memreserve but not /reserved-memory . > > > > It appears that for the RPi4B's the 32-bit "normal use" > > has lead to aarch64 having memreserve instead of > > /reserved-memory . > > > > 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?) > > I'm not familiar with the subject matter in the code, so > I may have messed up the test. I just used: > > # svnlite diff /usr/src/sys/dev/fdt/fdt_common.c > Index: /usr/src/sys/dev/fdt/fdt_common.c > =================================================================== > --- /usr/src/sys/dev/fdt/fdt_common.c (revision 357529) > +++ /usr/src/sys/dev/fdt/fdt_common.c (working copy) > @@ -512,6 +512,11 @@ > > root = OF_finddevice("/reserved-memory"); > if (root == -1) { > + // Fail over to checking for and handling memreserve, > + // such as for a RPi4B. > + if (0 == fdt_get_reserved_regions(reserved,mreserved)) > + return (0); > + > return (ENXIO); > } > 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.