From owner-freebsd-arm@freebsd.org  Sat Jun  6 19:55:39 2020
Return-Path: <owner-freebsd-arm@freebsd.org>
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 4509133CBDC
 for <freebsd-arm@mailman.nyi.freebsd.org>;
 Sat,  6 Jun 2020 19:55:39 +0000 (UTC)
 (envelope-from kevans@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org
 [IPv6:2610:1c1:1:606c::24b:4])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
 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 49fVcW1CS9z3V1J
 for <freebsd-arm@freebsd.org>; Sat,  6 Jun 2020 19:55:39 +0000 (UTC)
 (envelope-from kevans@freebsd.org)
Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com
 [209.85.222.181])
 (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 1B206293CB
 for <freebsd-arm@freebsd.org>; Sat,  6 Jun 2020 19:55:39 +0000 (UTC)
 (envelope-from kevans@freebsd.org)
Received: by mail-qk1-f181.google.com with SMTP id w1so13405689qkw.5
 for <freebsd-arm@freebsd.org>; Sat, 06 Jun 2020 12:55:39 -0700 (PDT)
X-Gm-Message-State: AOAM531ANeUSdKG+3kaUhDKRKy1CWNZ4Wet3b+L3YNH858EtXqsXN31G
 3Lks4+90wJ+GSvC6nGIAb+RZTsnEvFkDjtY4U8g=
X-Google-Smtp-Source: ABdhPJzKdNRPjxLiK5PY7270c/Q1bPdDcXv/vd3guR1W/DPcbn8KPuMB6DBcnJu0TOXmOwso2bgH1DJ6qbbNYcOMmns=
X-Received: by 2002:a37:a3ce:: with SMTP id
 m197mr15843834qke.493.1591473338771; 
 Sat, 06 Jun 2020 12:55:38 -0700 (PDT)
MIME-Version: 1.0
References: <kb9ZDoXeXjZQGaI_pHItcwGDLz9nl5FzAe-_mxkI1N9MAFSkDpvFbwt-JUy-YmoOg-3C9bFyiNYgUoGvAnJZvsxbbGVHP4ZlUC84EgCd6A0=@protonmail.com>
 <F6CF4F00-44EA-4980-9B45-F7EE92738351@googlemail.com>
 <CACNAnaGwsrgQsSGxxOTr4n6cxP_ts3Z07pmTwb8inGzNXR2B3w@mail.gmail.com>
 <D14EC630-3BE9-4E19-B76A-B721C2BBBF75@googlemail.com>
 <TOfPYaU1tsGAVzQ8BHRMQKLpEJ3n-kGyxXrTnkciwTs5iQQlrRsN-ZfV_Dp2hbhfJR8mJHIaaPm6CTCW-Ga2kyA0cwG_IVWfq6wQZBWgiLA=@protonmail.com>
In-Reply-To: <TOfPYaU1tsGAVzQ8BHRMQKLpEJ3n-kGyxXrTnkciwTs5iQQlrRsN-ZfV_Dp2hbhfJR8mJHIaaPm6CTCW-Ga2kyA0cwG_IVWfq6wQZBWgiLA=@protonmail.com>
From: Kyle Evans <kevans@freebsd.org>
Date: Sat, 6 Jun 2020 14:55:27 -0500
X-Gmail-Original-Message-ID: <CACNAnaE8hvyRWZQQ6fXcy2HtEn6uDC5t_uR36zh1ba25=GT9ng@mail.gmail.com>
Message-ID: <CACNAnaE8hvyRWZQQ6fXcy2HtEn6uDC5t_uR36zh1ba25=GT9ng@mail.gmail.com>
Subject: Re: Report: FreeBSD on Rpi4 8 GB model
To: Robert Crowston <crowston@protonmail.com>
Cc: =?UTF-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com>, 
 "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.33
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2020 19:55:39 -0000

On Sat, Jun 6, 2020 at 2:45 PM Robert Crowston <crowston@protonmail.com> wrote:
>
> > No, SPIN_PAGES=2 is fine
>
> I confirm that CONFIG_RPI_EFI_NR_SPIN_PAGES 2 is sufficient.
>

Thanks for confirming. :-)

> > Even without this setting, it should still largely boot;
> > you'll just only have half the memory you wanted.
>
> Without raising the spin pages limit, the kernel panics while trying to start the secondary CPUs. I don't have a working JTAG so I can't diagnose exactly why, but the spin table thing seemed like an obvious thing to check.
>

Sorry, that was specifically referring to raising CONFIG_NR_DRAM_BANKS
-- an unmodified sysutils/u-boot-rpi4 (which uses
CONFIG_RPI_EFI_NR_SPIN_PAGES=2) should boot with half the RAM
recognized, and bumping CONFIG_NR_DRAM_BANKS in our fragment should
correct that.