From owner-freebsd-arm@freebsd.org Mon Mar 16 14:17:27 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 A18A626781E for ; Mon, 16 Mar 2020 14:17:27 +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) 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 48gz072y2qz4cGY for ; Mon, 16 Mar 2020 14:17:27 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (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 40B8F13CE6 for ; Mon, 16 Mar 2020 14:17:27 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f175.google.com with SMTP id d8so26398984qka.2 for ; Mon, 16 Mar 2020 07:17:27 -0700 (PDT) X-Gm-Message-State: ANhLgQ05KNSuGbD3/QBgGK1G2iyBqUeSc2K6sjDRuJtaqvbM2PortKRm Ffybrq/9x9lLLfH6suMqw6LotNAcdE3FotUiMPU= X-Google-Smtp-Source: ADFU+vswnYbQlxrMZ1wzqN8dvA33QItuwUtdtqgXwheze1pedG+67fvuE3USfeAwiCQUjGgzF0+jsUzmWqj2ClGyGus= X-Received: by 2002:a37:cc1:: with SMTP id 184mr12116091qkm.430.1584368246757; Mon, 16 Mar 2020 07:17:26 -0700 (PDT) MIME-Version: 1.0 References: <20200315041203.GA55605@www.zefox.net> <90DE70B3-F3A5-4EFE-832C-7C412744D974@yahoo.com> <5A11699F-7EDD-4541-82C0-62993C95EE72@yahoo.com> In-Reply-To: <5A11699F-7EDD-4541-82C0-62993C95EE72@yahoo.com> From: Kyle Evans Date: Mon, 16 Mar 2020 09:17:14 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Panic on Rpi3 at r358976 To: Mark Millard Cc: bob prohaska , "freebsd-arm@freebsd.org" 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, 16 Mar 2020 14:17:27 -0000 On Sun, Mar 15, 2020 at 11:11 PM Mark Millard wrote: > > > > On 2020-Mar-15, at 19:03, Kyle Evans wrote: > > > On Sun, Mar 15, 2020 at 8:54 PM Mark Millard wrote: > >>> On 2020-Mar-15, at 17:33, Kyle Evans wrote: > >> > >>> On Sat, Mar 14, 2020 at 11:12 PM bob prohaska wrote: > >>>> > >>>> Tried to boot a kernel built from r358976 on a Pi3 and got a panic: > >>>> > >>>> [... snip ...] > >>> > >>> Hi, > >>> > >>> I've got a patch against sysutils/u-boot-rpi{3,4} based on what I've > >>> submitted upstream that I'm test-building again and will soon be > >>> submitting to Phabricator; please give it a shot and confirm if it > >>> makes life happier or not: > >>> https://people.freebsd.org/~kevans/rpi-psci.diff > >> > >> I grep'd in the area that holds where I did the > >> investigative patch that enabled the RPi4 to boot > >> and such without the armstub8-gic.bin memory being > >> slamed. (I've not done any clean-out of the materials > >> in that area.) > >> > >> The result is not suggestive of CONFIG_RPI_EFI_NR_SPIN_PAGES > >> making a difference: > >> > >> [... snip ...] > > > > Indeed; note these lines in my patch: > > > > PATCHFILES+= 1245351/raw 1245352/raw > > > > These pull in the patches I submitted upstream that introduces > > CONFIG_RPI_EFI_NR_SPIN_PAGES so that they don't have to accept an > > arbitrary bump of the reserved page count, since it's just our PSCI > > stub that's larger. > > Sorry. The day has gone as one where I need to > separately validate that I've not omitted something > for pretty much whatever I was trying to do. > > I applied the patch and rebuilt and substituted > the new u-boot.bin for my hacked one. The context > is head -r358510 that was booting with my hack > okay. (I'll soon be updating to -r358966 .) > > The result did not go well. Using boot -v > indicates that the 2nd page is not protected on > the RPi4: > > [... snip ...] Indeed- my apologies. In the config fragment, it should read CONFIG_RPI_EFI_NR_SPIN_PAGES=2 rather than CONFIG_RPI_EFI_NR_SPIN_PAGES="2" (note the lack of quotes in the correct version) -- apparently I hadn't transcribed that properly when I was porting it from my initially tested patch to u-boot. Thanks, Kyle Evans