From owner-freebsd-arm@freebsd.org Sat Jun 6 19:45:05 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 B392233C867 for ; Sat, 6 Jun 2020 19:45:05 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49fVNK06LWz3T32 for ; Sat, 6 Jun 2020 19:45:04 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sat, 06 Jun 2020 19:44:58 +0000 To: =?UTF-8?Q?Klaus_K=C3=BCchemann?= From: Robert Crowston Cc: Kyle Evans , "freebsd-arm@freebsd.org" Reply-To: Robert Crowston Subject: Re: Report: FreeBSD on Rpi4 8 GB model Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49fVNK06LWz3T32 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.06 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24:c]; FREEMAIL_FROM(0.00)[protonmail.com]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.131:from]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-0.95)[-0.955]; FREEMAIL_TO(0.00)[googlemail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.131:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.04)[-1.035]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 19:45:05 -0000 > No, SPIN_PAGES=3D2 is fine I confirm that CONFIG_RPI_EFI_NR_SPIN_PAGES 2 is sufficient. > 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 sta= rt the secondary CPUs. I don't have a working JTAG so I can't diagnose exac= tly why, but the spin table thing seemed like an obvious thing to check. Starting CPU 1 (1) panic: Failed to start CPU 1 (1), error 16 cpuid =3D 0 time =3D 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff00000075cd0c lr =3D 0xffff00000010a0ac sp =3D 0xffff000000010590 fp =3D 0xffff000000010790 db_trace_self_wrapper() at vpanic+0x194 pc =3D 0xffff00000010a0ac lr =3D 0xffff0000004185c0 sp =3D 0xffff0000000107a0 fp =3D 0xffff0000000107f0 vpanic() at panic+0x44 pc =3D 0xffff0000004185c0 lr =3D 0xffff000000418368 sp =3D 0xffff000000010800 fp =3D 0xffff0000000108b0 panic() at start_cpu+0x224 pc =3D 0xffff000000418368 lr =3D 0xffff00000076bd94 sp =3D 0xffff0000000108c0 fp =3D 0xffff0000000108c0 start_cpu() at cpu_init_fdt+0x34 pc =3D 0xffff00000076bd94 lr =3D 0xffff00000076b094 sp =3D 0xffff0000000108d0 fp =3D 0xffff000000010930 cpu_init_fdt() at ofw_cpu_early_foreach+0x180 pc =3D 0xffff00000076b094 lr =3D 0xffff00000020e0cc sp =3D 0xffff000000010940 fp =3D 0xffff000000010990 ofw_cpu_early_foreach() at mp_start+0x8c pc =3D 0xffff00000020e0cc lr =3D 0xffff000000472e98 sp =3D 0xffff0000000109a0 fp =3D 0xffff0000000109f0 mp_start() at mi_startup+0x12c pc =3D 0xffff000000472e98 lr =3D 0xffff0000003abfcc sp =3D 0xffff000000010a00 fp =3D 0xffff000000010a20 mi_startup() at virtdone+0x5c pc =3D 0xffff0000003abfcc lr =3D 0xffff00000000108c sp =3D 0xffff000000010a30 fp =3D 0x0000000000000000 KDB: enter: panic =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Saturday, 6 June 2020 20:29, Klaus K=C3=BCchemann via freebsd-arm wrote: > > > > Am 06.06.2020 um 21:19 schrieb Kyle Evans kevans@freebsd.org: > > On Sat, Jun 6, 2020 at 2:13 PM Klaus K=C3=BCchemann via freebsd-arm > > freebsd-arm@freebsd.org wrote: > > > > > > Am 06.06.2020 um 20:15 schrieb Robert Crowston via freebsd-arm free= bsd-arm@freebsd.org: > > > > =E2=80=A6... > > > > Edit board/raspberrypi/rpi/Kconfig, set RPI_EFI_NR_SPIN_PAGES to a = larger number (I picked 10, probably too big, but it was easier than doing = the arithmetic). > > > > =E2=80=A6=E2=80=A6 > > > > > > You mean that https://reviews.freebsd.org/D24085 rpi4_fragment has to= set SPIN_PAGES from 2 to 10 ? > > > This could be done in sysutils/u-boot-rpi4 , perhaps with something l= ike an #ifdef RPI4/8GB=E2=80=9C for the first try . > > > > No, SPIN_PAGES=3D2 is fine; the default in upstream is 1 because they > > don't need any more, so he would've needed to manually bump it to 2. > > You should be able to just add CONFIG_NR_DRAM_BANKS=3D8 to > > sysutils/u-boot-rpi4's rpi4_fragment and it 'just work' -- this was > > tested on IRC a couple days ago, and should be safe for all variants > > as far as I'm aware (but needed to test on my 4GB variant). Even > > without this setting, it should still largely boot; you'll just only > > have half the memory you wanted. > > Thanks, > > Kyle Evans > > Ah, thanks a lot ! > So it was too hasty from me to post to https://reviews.freebsd.org/D24085= :-) > Regards > Klaus > > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"