From nobody Sat Aug 12 21:57:59 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RNZKR1qFCz4TrLy for ; Sat, 12 Aug 2023 21:58:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNZKQ5nGcz4T6M for ; Sat, 12 Aug 2023 21:58:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 37CLw0oi019567 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 12 Aug 2023 14:58:00 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 37CLw0Ob019566; Sat, 12 Aug 2023 14:58:00 -0700 (PDT) (envelope-from fbsd) Date: Sat, 12 Aug 2023 14:57:59 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: alpha-1 armv7 git failed: fatal: pack is corrupted (SHA1 mismatch) Message-ID: References: <8DCC324C-966C-45DF-88F6-A442E348D4AA@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8DCC324C-966C-45DF-88F6-A442E348D4AA@yahoo.com> X-Rspamd-Queue-Id: 4RNZKQ5nGcz4T6M X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Sat, Aug 12, 2023 at 02:29:02PM -0700, Mark Millard wrote: [huge snip] > It may be that the problem you had was not local to your machine, > or even to your local network. Some received byte(s) might well > have been bad. > It appears that the exact error varies with time. Perhaps I've simply jumped the gun. The most recent message was ... Receiving objects: 100% (99626/99626), 314.27 MiB | 959.00 KiB/s, done. Resolving deltas: 100% (21416/21416), done. fatal: missing blob object '84f2442457380e747af01d49ad567da70f6cfcbb' fatal: remote did not send all necessary objects Thanks for writing! bob prohaska From nobody Sun Aug 13 00:42:07 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RNdyq1r2mz4m9C9 for ; Sun, 13 Aug 2023 00:42:11 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNdyp2YpBz3H0J for ; Sun, 13 Aug 2023 00:42:10 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=karels.net header.s=mail2 header.b="GNsPMyD/"; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 3.19.118.201 as permitted sender) smtp.mailfrom=mike@karels.net; dmarc=none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 37D0g72C032607 for ; Sat, 12 Aug 2023 19:42:08 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1691887328; bh=DqaXumBRv9YWW9YW79sm+K0Sx+Dx+vm7ZkVipnUi9xA=; h=From:To:Subject:Date; b=GNsPMyD/O37IVh93CQwopMev/zHtMVBDgyLUe3CPqDhXFGF4WrV02mgBdsJm45H2r U9AufUzy64ORlOyaA6nf705GhGUNpx7JCy3rPCOie8fVdqIC9g37oRZ+bkf7YHRWj3 lfvEvtDH2Qlmmfh8Nmcdh4Tawr2U0XoB7A2Z61WPWNSQWk0/mB84Lp453snoqNWF09 6eS+rQiM//yA+QhVJp+kV+S46oI3AEaxFdIUlQwrvSOTYkL0+MhIT3FEwYMaeLg01t ipROuepwYctmFBueLeTU4QxaN6Jh5rbQ9R4wxG1woSZIlupljvEw7hApYKtoh1O/Rp suaMY+QuCtIOA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id zA/nNd8m2GRdfwAAs/W3XQ (envelope-from ) for ; Sat, 12 Aug 2023 19:42:07 -0500 From: Mike Karels To: freebsd-arm Subject: ALPHA1 on Raspberry Pi 3B+ Date: Sat, 12 Aug 2023 19:42:07 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:3.19.118.201]; R_DKIM_ALLOW(-0.20)[karels.net:s=mail2]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; BLOCKLISTDE_FAIL(0.00)[73.62.165.147:server fail,3.19.118.201:server fail]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[karels.net:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[mike]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[karels.net]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RNdyp2YpBz3H0J I booted 14.0-ALPHA1 on a Raspberry Pi 3B+. It boots and runs, but there= are some rough edges that probably indicate things that are broken. Duri= ng the boot, there are 56 occurrences of this sequence: clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 Two other failures: bcm2835_cpufreq0: on cpu0 bcm2835_cpufreq0: Unable to find firmware device device_attach: bcm2835_cpufreq0 attach returned 6 gpioled0: on ofwbus0 gpioled0: failed to map pin The red LED that's on when the system is halted stays on after boot; not sure if that's related to the last item. Looks like the kernel needs adjustments to correspond with the new DTB. I'll append the full dmesg.boot. Mike ---<>--- GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb WARNING: Cannot find freebsd,dts-version property, cannot check DTB compl= iance Copyright (c) 1992-2023 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.= FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 14.0-ALPHA1 aarch64 1400094 #0 main-n264678-136fc495615f: Fri Aug= 11 12:20:43 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENER= IC arm64 FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git ll= vmorg-16.0.6-0-g7cbf1a259152) WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 1824x984 module scmi already present! real memory =3D 994041856 (947 MB) avail memory =3D 942796800 (899 MB) Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 ofw_firmware0: on simplebus0 ofw_clkbus0: on ofw_firmware0 ofw_clkbus1: on ofwbus0 clk_fixed0: on ofw_clkbus1 clk_fixed1: on ofw_clkbus1 regfix0: on ofwbus0 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 regfix1: on ofwbus0 regfix2: on ofwbus0 regfix3: on ofwbus0 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 psci0: on ofwbus0 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 lintc0: mem 0x40000000-0x400000ff on simpl= ebus0 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 intc0: mem 0x7e00b200-0x7e00b3ff irq 39 on= simplebus0 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 gpio0: mem 0x7e200000-0x7e2000b3 irq 7,8 o= n simplebus0 gpiobus0: on gpio0 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 mbox0: mem 0x7e00b880-0x7e00b8bf irq 6 on sim= plebus0 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 generic_timer0: irq 1,2,3,4 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 bcm_dma0: mem 0x7e007000-0x7e007eff irq 23,24,25= ,26,27,28,29,30,31,32,33,34,35,36,37,38 on simplebus0 usb_nop_xceiv0: on ofwbus0 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 bcm2835_clkman0: mem 0x7e101000-0x7e102fff on sim= plebus0 gpioc0: on gpio0 uart0: mem 0x7e201000-0x7e2011ff irq 9 on simple= bus0 uart0: console (115200,n,8,1) spi0: mem 0x7e204000-0x7e2041ff irq 11 on s= implebus0 spibus0: on spi0 spibus0: at cs 0 mode 0 spibus0: at cs 1 mode 0 sdhci_bcm0: mem 0x7e300000-0x7e3000ff ir= q 17 on simplebus0 mmc0: on sdhci_bcm0 iichb0: mem 0x7e804000-0x7e804fff irq 20 on= simplebus0 bcm283x_dwcotg0: mem 0x= 7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 21,22 on simplebus0 usbus1 on bcm283x_dwcotg0 bcmwd0: mem 0x7e100000-0x7e100113,0x7e00a000-0x7e= 00a023 on simplebus0 bcmrng0: mem 0x7e104000-0x7e10400f irq 40 = on simplebus0 fb0: on simplebus0 fb0: keeping existing fb bpp of 32 fbd0 on fb0 WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14= =2E0. VT: Replacing driver "efifb" with new "fb". fb0: 1824x984(1824x984@0,0) 32bpp fb0: fbswap: 1, pitch 7296, base 0x3e513000, screen_size 7237632 pmu0: irq 0 on ofwbus0 cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 bcm2835_cpufreq0: Unable to find firmware device device_attach: bcm2835_cpufreq0 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 clk_fixed2: disabled on ofwbus0 clk_fixed2: Cannot FDT parameters. device_attach: clk_fixed2 attach returned 6 gpioled0: on ofwbus0 gpioled0: failed to map pin armv8crypto0: CPU lacks AES instructions Timecounters tick every 1.000 msec usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0 on usbus1 uhub0: on usbus1 mmcsd0: 64GB at mmc0 50= =2E0MHz/4bit/65535-block iicbus0: on iichb0 iic0: on iicbus0 CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Cache Type =3D <64 byte D-cacheline,64 byte I-cachelin= e,VIPT ICache,64 byte ERG,64 byte CWG> Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <> Instruction Set Attributes 2 =3D <> Processor Features 0 =3D Processor Features 1 =3D <> Memory Model Features 0 =3D Memory Model Features 1 =3D <8bit VMID> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> Debug Features 0 =3D Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> AArch32 Instruction Set Attributes 5 =3D AArch32 Media and VFP Features 0 =3D AArch32 Media and VFP Features 1 =3D CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 Release APs...done TCP_ratelimit: Is now initialized WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufs/rootfs [rw]... uhub0: 1 port with 1 removable, self powered Warning: no time-of-day clock registered, system time will not be set acc= urately Dual Console: Serial Primary, Video Secondary ugen1.2: at usbus1 uhub1 on uhub0 uhub1: o= n usbus1 uhub1: MTT enabled uhub1: 4 ports with 3 removable, self powered ugen1.3: at usbus1 uhub2 on uhub1 uhub2: o= n usbus1 uhub2: MTT enabled uhub2: 3 ports with 2 removable, self powered ugen1.4: at usbus1 muge0 on uhub2 muge0: on usbus1 muge0: Chip ID 0x7800 rev 0002 miibus0: on muge0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,= 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on muge0 ue0: Ethernet address: b8:27:eb:e3:3a:42 ue0: link state changed to UP lo0: link state changed to UP muge0: Chip ID 0x7800 rev 0002 ue0: link state changed to DOWN ue0: link state changed to UP From nobody Sun Aug 13 03:45:54 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RNk373b81z4mNS0 for ; Sun, 13 Aug 2023 03:46:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNk370jSqz3VFT for ; Sun, 13 Aug 2023 03:46:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691898369; bh=I2H2GeI7u6PQulWSm4jw+orpPXaPz7FBLV8of7DYACQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gnasxsBDNZjap56SZpHZRzHvGfz+g/AmwWnBHwKXrHpb1eFaSv4rKjAoKPuFq2Yosuf0LkEyVNYOJbhECzyz+Bfe719FwXHjci8CN3PUP3KXwxg4vE07zsuR6dgw9R0BpS9tDiuR0yS/pwrmDY8+iivw/6i1IKaIV3Rnzk8uTmfiLYYGf5HBycqaMrsyq9yK9p/zZvcEBHKfbD3I3D/GiSVZAfALKnynXImJfcKEQrKm0mUY+OFwPz2ht3U0/rZVXiK6xABxnfCT1nvrcQgE4JkJyFwKpmkShQavzjCkK+cErXfAgpuddMa6mTrw3KBNDrq6Fg6ap0FR4FBF2jj4lQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691898369; bh=UTRDCmrmcXoVyTSlcdtd+/K1fHl77uEmhq4Lx5skoVJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qGkiuO/9IJKWw2NDKyRBtSvSP78pEUtAYrVYVj9GT9V/ne6eT9iS+O6aI2NwUkIQA4jN+uFtQDbemiww7hKRbb72tlDcTFg8hXVnRbN3ctb039/Zh4D6moQ75zc0W9b0iepk7og99NfeAmpTR0WPJW152lUiDnqVUgXaPPUa1Tn2LEVCPhPOZwDMj0JtMtxsKB9vtOE1cTfpiKR1/pOX1b2H6qN57XHbFpIctiK0pKDa3e4ILP0MJ0EFoJRTvjLo+eCRu9VKJHC0LOKoOJEXQ4v8wSDpVxubc0jefVp2oCMfyNpazc/+H7NpKGVk6erQkXQ43VaYgclev5qYwGkV7Q== X-YMail-OSG: 7L.x.6kVM1lpfiAytslaYPem9HQvAwQBDE1Df4mcNACBI0SRgnLum71FeertQtc pLT.UvwwFvhLocigjCmMyCAImVbJYLsC1Xee.cSdrm5iH20lLSVBCbMO4q0QbsxAwN4jBvlqi5IC eagxoQYhz67cufIKh3e0Skn7yqzdJEo70i2e3CNqIVVsqeXj.OcT4hEfyt7YWkdTBJ9paWt4kZIJ AX4uvGCxuTn_i0eMzNAuuCOt2DilUmPS5m3LcvEE.y.PTU9POor1rJASPmvwkaeUTQ4KSwZQQ5VD eEthQKEYP3mNb5MGmF0.DCM8llxc5.6fmS.qZr4qE93JVCO9005NLPqZXI5VRBlrx7r2w4iAkBhS qoL1__hctVpJYSYS_iHZJgpCnN_SPpCnwAXpFa0uefojBa.9bUB7J95QYHKlMFLwzvclBGa8kDds Q.pqI3wP5Xn7KM2__z8nmVSZ7oJpVcwMKSsF_nBVRtv8GpzIfTZYlP69JYHonl.MLwHM2F7OwmO0 5OWl4MXC.lAnppUhu5jUrptdR3o.tzWZm1Hex4YyKKsTKso0TlETEaflrbX14oN6kb9hNdSPreG7 nftlkfzSnQmiqxz2YYr1nEXvTCCreBmzZmyaj_fxpqlO3Rt0R4vzZFW9QfCaVLDGX51pmfuToURl 2WrR3C9fq8cH55QiqUtc7vUCpsegYyLPDW5WwPxJ71PZimcnBKApBNCNjloGIyZnLg0pnXgulJIy _5Gfx34jJl5w4Z996mFf9OLX1TTWkKCpJzNvXKhEx0MfHXDdsJf9DoGkpPTSqI6qReMFIvSnh4XX pndRWJEsSd0qqb3.B8y8cwcBLVVLk0Vk2n5I3pMu5vGYgssxv0CpdmDU5wpqluz2UVb1TrNrr2ce npCn2KPgwzkC900RcQ4YxfYO8D3FSGTDJaNvD_zuDNJXvl52D_yspk2LMv4wY5gxkt2CFl8WCUJW ybaIcc1OY46IpYH0fL9Z8h18wA8tNCMof_PBJ7i22sgSf2kS1tme6eEvOzPt0kR.OXb5PpmnTxJE Bh6jfAceXp2e0_phKVfrlRibRunK._g3yANJfq9UwF88BrTniQfO_Q58JSe78gen0LKMEST9SRmc aPbLfJh4LfUcTky.o_1EuKH4bRftwThLuc.RUJOzM32a2yZAbSolMOv8X4uwM2SlpuDnCSHAzJeX hQFPW097cMysiRy5wbxsnU7VQ8XLmTJqNutzuxWae.36ctrL58W9rr.EEStuoL8_KVMBMvT0BO2a wJrZBaA4zrmVIZsgFsD4RspCZ.cceAnxhkJE2QDTiZ8vbWma_yTy_Eq4PcvrzpEy9_0MbAZZJLuf _lGBJcPRZvnQF8fJtztax45tTxi.Nkkw3mNRxIuR2mlxt_GF4WcLkwP3rDNhpo081K0wnqOYtlwq m.K1dTCgeakIVR._q2Ilx8W_Q3xJUdrdQ0KDz6txWVnB_umP.ialGaGfIejga9zc7Cv1q4VP8LVv ic3yUL20Rzv1y9vaNLl3.3wo7gzq4T2TxDf8kTciSmNKZZH21bjmGauP3QJlM.1zeBsD2ZIF2mcx wGu1teM5dpPr_vg2DkJxY18Q.oagz5kDvEiO2xvIr.tIbI7p9SI7IrpFkXX6OqxaosMesKjCoA_t K_uj.dDEFonhW79b.aulu.XW1Ztrvw2P3o_Ir_TGzDKyVo87MIdRRSPq1XwjnpjVcjRJ3530s3Zp 9HHau0KcF8fKjNkxz6NNzRmiJvu4feCTYUs4qtaa3ZTonuEK0wCydCjNtoQ_YsGr9kCWMnQgyFNv IJSBKKV.0kcgq42sJ73lq82JP7VN5XnWx5xHF80gycEDp1_1ISK4o99gbmqlB005GKYfDWUg1c6C EjtcO2HaAlCgR.HQs12u0Voa_5kMpghB1hEPkP7Diab5dUFbYs6BjZefYhg15TgwOh8cDXvrRKnC Br6MKYZJBY_UJ0pWD6H8JTxZzLRBvxQdXqisIJQskU3CAZdiEVIiOqFUPaJJPKpAWDtDpbJnm2_j ks4ZYxypHr8sV3xjZXOixwOwgIbQyX_QsTvoaRuN_tAZUhviqeseUT8LxuKgKzhG2dAfx5mBKGk3 Jmrn6kzMqxGlDu47ZdDwiJo_VIwwHaqyQzVie9xxGV2qjOAgNyTmF7E1yA._MlwlTAgj_on8v6Hh OPq9jROgso3LxkAMQiR_zcQ4JlVK6mgMIHjMOP7M7hdVdUyZvxyWJnPFAOujW476oWA4WDglj3lJ 3r_iSv4IZZr1v01ASi_.yAP2jfnvoT6JgN.CGmF4yrEXafmNwKM0KBEebyYH9.X8MojKRdzw.AGm hhQ-- X-Sonic-MF: X-Sonic-ID: e251d18e-32da-4506-9d0f-db4f9ebaf850 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Aug 2023 03:46:09 +0000 Received: by hermes--production-ne1-7b767b77cc-ht9fv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a7213aedd7bf30e79997b0bd01e3aac3; Sun, 13 Aug 2023 03:46:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: alpha-1 armv7 git failed: fatal: pack is corrupted (SHA1 mismatch) From: Mark Millard In-Reply-To: Date: Sat, 12 Aug 2023 20:45:54 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <2F080FD7-B63E-4FB6-A165-E24A3DF2730B@yahoo.com> References: <8DCC324C-966C-45DF-88F6-A442E348D4AA@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RNk370jSqz3VFT X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 12, 2023, at 14:57, bob prohaska wrote: > On Sat, Aug 12, 2023 at 02:29:02PM -0700, Mark Millard wrote: > [huge snip] > >> It may be that the problem you had was not local to your machine, >> or even to your local network. Some received byte(s) might well >> have been bad. >> > > It appears that the exact error varies with time. Perhaps I've > simply jumped the gun. The most recent message was > ... > Receiving objects: 100% (99626/99626), 314.27 MiB | 959.00 KiB/s, done. > Resolving deltas: 100% (21416/21416), done. > fatal: missing blob object '84f2442457380e747af01d49ad567da70f6cfcbb' > fatal: remote did not send all necessary objects You might need to use the ssh alternative if your context allows it: ssh://anongit@git.FreeBSD.org/src.git There was a time when git fetch proved unreliable in my context and I got around it via ssh use. It also took less time transferring. === Mark Millard marklmi at yahoo.com From nobody Sun Aug 13 04:25:54 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RNkxH6Pbjz4mRZk for ; Sun, 13 Aug 2023 04:26:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNkxH43P8z3XhG for ; Sun, 13 Aug 2023 04:26:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691900769; bh=KFr+HWcOzgqCFxv/zA6q2xbiVcLwVEgZnOkV5yY18s0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LTk7I+VkQR4CT7d+X6fGslN4nKRsJDprZnAREpBI4UvxZCVebUxd0d5wmCT83/Qk8qZvEea+tjrQiQsIMHY1PlgwxzSU58wA8u+DCt5XYH10vLYslFjEoTh/nb4tmJpSRV+Lq59T32gQEjZLAwc3QlEadCpcVoGkq4ecY8oIzmSvtNzdhkup0eSHxdSeU7mFPZpa+qDkk9gE+6KlBwq502mxiJUtcTi9a9fqswrpK2sp6lInb/5va8DH5eMhbI8dMDzdBNNfzuz3oW+8QbuqUQ36HvX6kUwIlet63LgiGnVw/dICKqr9eB16bzBG6GpmB4MsBrYnlZDJrZbEIIqUgA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691900769; bh=i05mgbBYH2h+tB6gih5LELUHiFCHSmqnrHVWzJhfA1D=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TY3cOd7ac8KfxjAbWASgIeUhOx1HVWM8NfZ044XHuBJVRkPjwYbCfXsBQA8gteT9xF15TTchgZ9DdnUx8rXEQz1AHv4lTH45Jr/beTF0AtZwxLXB6VvcpsBKv/lJzfwoGr0a0qTJ/Ve8VKl/DRhoxFW0WZWzY5wRgcHIXRTwk7QBeNIqRLjEDTFXo6xUQYFfnBQAJbTf8IOwvnMh7Kitlj9HmiExA5mFGTpldnOYxnEgOgnLCVZZO34FVCAUFNx7lXF1K3w6Wwv2azknxsfIExuKaehBKTUlP0sZsWoIyvgsE9RNmDfahYW0+5XPxu3UHgk0M1nuu/MN4x68PM3A3Q== X-YMail-OSG: hJsIbk0VM1nLTBcZdyYDSU9XdzWvgdt1uZXRI7TIdH_9SCf6k1ZU.eRxpWhMJHn n_UkDDjKXCUxR.mLH6HUiQa2f1Q9hzlO9Ebpj20cmTuA1G8FJta0SD0W87AVf.JZO85sPcqde_5q jp7Xgx3hBfz3Lij6NWTRmL._7FlOKb.sD6nPHAPEj6kQ3e0Xtv41PFJvo6GRN1.qYk8F_B6J_.js Zb4abTuQ1cbxBDR4SHo4CQxnn_cZ.DbHKEt3jvgw2zSHna0PGuC3xJm7EQlIUY0hir_Ieg3aFtpC bNEnKkxpN5uQcOWMXY9G2QIzNHd8xsxayhw3t9gliyBBDAvI6UtX8nv47fUpeISqWNQ21cxIks0g eWqK8j4WU03d4GXnkmDVRTEqXvcqYrQNLLQ4.oZQfkhSTtv_r1XLKHnRHwNcDCX6idabgRga69Pw byvPDFiRh4iFp_2dc5SZXcZ_nSjghL2b_rRbWyFLLUh0eAPbCSdjKM7kGwib6LDjgVzGdlE4NG5C hM_viq8uvk_4HRSHz6RXtiVwe73A8aRt9347J3vYvdrvBi9fTo2qJAvkAeYG95AHgLGc0QiRIusb t5j9.DMYd6vcu7dqYu0HN0Hs9fsC4qqSLliPBK9YXQQo2zVIOoGva_txC7BkGbF6S_dUdFCBoyma d52oRplxCHxe6RMr8viBzMv1toqoRJMbwJ.pRelRvMU4GjgWWqL5Qbm3HShWvQYpmn2PQo05.RSa iHUNCggbZI0rqaSlsr6Uw80NMUQ8og0EOomf3Zaok0WRs8hXlhgniSP8N5q1k.zB03v9_wbi6l7E T.0RMEbhgZef8UDhMtx_Su8kCzswB.iisKlIUFLmxj3qJFfJPn1tbb_Tcn3Udq3un6IXt69Wr8ax kpC2gasdgHOHIr4Q_g7pV.HFF.EIn._yR7EjXNNHckaLLj8uq5_kHTcN268E2VI6vfSbf1QGOJOT ctwh8MQn4y8GkofWCyQUkIv8oNbf78pbQhqfqUxIdtMF_NTDWKhJWYeL4bO27F_ukMSO0Fyc7u7b A9MF3BZ1HBm3zrOxT1Ttou2NLTovXnvGbArPnbWaayVoN.Akicdq3LcLZDKhiHvznDrC2aBuFAA9 l.Fv1naJEJYwW7KOjzIPxYT8XLUyydQZXc0KoGi2IurtyA4r2kdGlUeJvMQb95mjyXl_11ZAOhXg s1hF1bQ6h9yfr7K1t4cIec0LuEArGojTF8KvRDUKGpodIJ6Mo4XbX3oueqNl9kGpUNEuX_ocO0V7 YXjMWbPqBI7C38xy_86rKkTY5XDhMd3o6TdrMucJwXvuRpJyF27lZ0PsVFS.UkZ0ByeM81WRLyQX z6S7G006COs_p.qfHzpf_H47DUS4Hq3j5vS1_81alk0ZE8w7aD_KmX_oG0OFw4i3OU5cfxIAqzqG x4s_0UeIKtLxrfHLeIImEWM3hbcKFbXpXvlT9OqezXdzWQ1NEdk6s4CfPf7t_D3YI4LUnao4htzb 7ax6PGsccpUZbQFzMWlRlPsZq2VtnQD_vOMPoK0phFN_QeY2fXbZt96MOtyyNGhADVSpj157oeRc cCjiJzx9_PfEM_NTNMPuhvkXLkkVsdocnmDRkKfqG8Ug9Rv.PZCcA15MV0jF36bSgxYyKp1Dm4OC b2yU6_WtGkVNZ8F6Mtc9SEs15vsV0sROksrjh4SWjB0sOaYr3EolCcPDRaevs_BRFMbhSgj2DDNA AwWcX_zdCM1C75a0Ty9zGl5NC4kkw1bTyaOuerRi_GE650J6r6cGj9jQrli8G3g9GhuOMUfRIOJ2 zUTb_Vj4O3nvpP6a9eTGpSg.Uvzp53W0uMEGiBnbOs39PfwJUo2TLSkW6qdtUBKCmstKj9idRtRb pgwzX4pmT2KcCV7pIbyrT54nZwwurEsCAFblcuoEjIGE4BMpN6GMSUm9rXGrhELhvIQxPbB4aO7I pwbm0O_39btgi835iEhZfPoPo6.fmSt_HFK71n.25ElvLJHrEiOGItiqttTPKbr2SPV00uGxOJNc V9lrjqVBpG6UMNMtlMAUahZN6n_GJILyMd4jmLzYTxr8CXDU8FO9d7T5wOLJnhtV02SAyTY7QREU U_FLi3jo4GbSxyTgj5LE8JIWl1RNp0c.yMNHdghyTer6cuylwe4n6SlFrYDulRNspO_jbr.2Ju_s LvdxdlVRa.qZRdTt4f1WhyfwBy3he4Bz4dzpDMgMtjvI5hkja1zjyxwOIhPRT3KN3ICw4e8.McD3 JgVjZeGT36z8ZifaI92.sLLngobfePXQEglBmLnglWshZvrbV2_4LF7uNnv7t.uy4_yFIi2yYmE7 2 X-Sonic-MF: X-Sonic-ID: 87e4e991-a3db-4ced-8bae-0da39a46a178 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Aug 2023 04:26:09 +0000 Received: by hermes--production-ne1-7b767b77cc-4t526 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ef8e242645228a963a52142df8df9924; Sun, 13 Aug 2023 04:26:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] From: Mark Millard In-Reply-To: Date: Sat, 12 Aug 2023 21:25:54 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: References: To: Mike Karels X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RNkxH43P8z3XhG X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 12, 2023, at 17:42, Mike Karels wrote: > I booted 14.0-ALPHA1 on a Raspberry Pi 3B+. It boots and runs, but there > are some rough edges that probably indicate things that are broken. During > the boot, there are 56 occurrences of this sequence: > > clk_fixed2: disabled on ofwbus0 > clk_fixed2: Cannot FDT parameters. > device_attach: clk_fixed2 attach returned 6 The large count is from a small number of examples. Each internal scan repeats the messages for each example, unless eventually found. I learned this when I had something being looked for too early, before the definition was added to match up with. Everything worked because of the retries eventually finding things after they had been added, but it produced lots of messages first. But, in that case, there was material to find. The RPi4B's get clk_fixed4's instead, with a similar overall count. For the RPi4B the cause is the "fixed-clock" material below (from a diff of .dts files produced from the .dtb files): - cam1_reg { + cam0_clk { + #clock-cells = <0x0>; + compatible = "fixed-clock"; + status = "disabled"; + }; + cam0_regulator { + compatible = "regulator-fixed"; enable-active-high; - gpio = <0xa 0x5 0x0>; - regulator-name = "cam1-reg"; + regulator-name = "cam0-reg"; status = "disabled"; }; + cam1_clk { + + #clock-cells = <0x0>; + compatible = "fixed-clock"; + status = "disabled"; + }; + cam1_regulator { + + compatible = "regulator-fixed"; + enable-active-high; + gpio = <0xb 0x5 0x0>; + regulator-name = "cam1-reg"; + status = "okay"; + }; I doubt that cam0_clk and cam1_clk are ever added to later find, as stands, making every scan report the 2 fixed-clock references each time. This is something that I reported on on the lists back on 2022-Apr-30. But it was mixed with a crash report that turned out to be a separate issue (and was fixed some time ago). It would be possible to decompile the .dtb used for RPi3B+'s to see if cam?_clk fixed-clock's are present. > Two other failures: > > bcm2835_cpufreq0: on cpu0 > bcm2835_cpufreq0: Unable to find firmware device > device_attach: bcm2835_cpufreq0 attach returned 6 > gpioled0: on ofwbus0 > gpioled0: failed to map pin Those are more than noise messages. > The red LED that's on when the system is halted stays on after boot; not > sure if that's related to the last item. > > Looks like the kernel needs adjustments to correspond with the new DTB. > > I'll append the full dmesg.boot. . . . === Mark Millard marklmi at yahoo.com From nobody Sun Aug 13 06:11:59 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RNnHS3w9Pz4q3NT for ; Sun, 13 Aug 2023 06:12:04 +0000 (UTC) (envelope-from titus@edc.ro) Received: from eatlas.ro (eatlas.ro [86.126.82.18]) (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 (2048 bits) client-digest SHA256) (Client CN "eatlas.ro", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNnHR6vx7z4DxP for ; Sun, 13 Aug 2023 06:12:03 +0000 (UTC) (envelope-from titus@edc.ro) Authentication-Results: mx1.freebsd.org; none Received: from mail.edc.ro ([10.1.4.58]) by eatlas.ro (8.16.1/8.16.1) with ESMTPS id 37D6BxDd021712 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 13 Aug 2023 09:12:00 +0300 (EEST) (envelope-from titus@edc.ro) Received: from [192.168.1.9] (86-120-200-242.rdsnet.ro [86.120.200.242] (may be forged)) (authenticated bits=0) by mail.edc.ro (8.16.1/8.16.1) with ESMTPSA id 37D6BwF6092386 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Aug 2023 09:11:58 +0300 (EEST) (envelope-from titus@edc.ro) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=edc.ro; s=mail; t=1691907119; bh=BeKvdduCF+epGP7+W9WM35zDaqyTvfxkfXJQBnXa64Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=graXxoyJdHvPMJeUONPLeA3blEyPQYNA1oD9npOXDFsSos99Arnb+/cDWC18oF6VX K3wS4sQRN/ucfuwXjC+a80wblmsW3mLkWbvhXHQatqfmZPwBkDgUFnHV03L7z6bA9t FQXNTHA232oS7xKqajSlPH4wlohOspfaIggOflIo= Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] From: titus In-Reply-To: Date: Sun, 13 Aug 2023 09:11:59 +0300 Cc: Mike Karels , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> References: To: Mark Millard X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ns.edc.ro X-Rspamd-Queue-Id: 4RNnHR6vx7z4DxP X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8708, ipnet:86.120.0.0/13, country:RO] the failed devices are all linked to raspberrypi,bcm2835-firmware (gpio, cpufreq_dt,=E2=80=A6) which does not see to be probed / attached check fdt ls at the loader prompt and ofwdump -a=20 and boot -v and nm /boot/kernel/kernel|grep bcm2835_firmware_get_revision > On 13 Aug 2023, at 07:25, Mark Millard wrote: >=20 > On Aug 12, 2023, at 17:42, Mike Karels wrote: >=20 >> I booted 14.0-ALPHA1 on a Raspberry Pi 3B+. It boots and runs, but = there >> are some rough edges that probably indicate things that are broken. = During >> the boot, there are 56 occurrences of this sequence: >>=20 >> clk_fixed2: disabled on ofwbus0 >> clk_fixed2: Cannot FDT parameters. >> device_attach: clk_fixed2 attach returned 6 >=20 > The large count is from a small number of examples. Each > internal scan repeats the messages for each example, > unless eventually found. I learned this when I had > something being looked for too early, before the > definition was added to match up with. Everything worked > because of the retries eventually finding things after > they had been added, but it produced lots of messages > first. But, in that case, there was material to find. >=20 > The RPi4B's get clk_fixed4's instead, with a similar > overall count. For the RPi4B the cause is the > "fixed-clock" material below (from a diff of .dts > files produced from the .dtb files): >=20 > - cam1_reg { > + cam0_clk { >=20 > + #clock-cells =3D <0x0>; > + compatible =3D "fixed-clock"; > + status =3D "disabled"; > + }; > + cam0_regulator { > + > compatible =3D "regulator-fixed"; > enable-active-high; > - gpio =3D <0xa 0x5 0x0>; > - regulator-name =3D "cam1-reg"; > + regulator-name =3D "cam0-reg"; > status =3D "disabled"; > }; > + cam1_clk { > + > + #clock-cells =3D <0x0>; > + compatible =3D "fixed-clock"; > + status =3D "disabled"; > + }; > + cam1_regulator { > + > + compatible =3D "regulator-fixed"; > + enable-active-high; > + gpio =3D <0xb 0x5 0x0>; > + regulator-name =3D "cam1-reg"; > + status =3D "okay"; > + }; >=20 > I doubt that cam0_clk and cam1_clk are ever added to later > find, as stands, making every scan report the 2 fixed-clock > references each time. >=20 > This is something that I reported on on the lists back on > 2022-Apr-30. But it was mixed with a crash report that > turned out to be a separate issue (and was fixed some time > ago). >=20 > It would be possible to decompile the .dtb used for RPi3B+'s > to see if cam?_clk fixed-clock's are present. >=20 >> Two other failures: >>=20 >> bcm2835_cpufreq0: on cpu0 >> bcm2835_cpufreq0: Unable to find firmware device >> device_attach: bcm2835_cpufreq0 attach returned 6 >> gpioled0: on ofwbus0 >> gpioled0: failed to map pin >=20 > Those are more than noise messages. >=20 >> The red LED that's on when the system is halted stays on after boot; = not >> sure if that's related to the last item. >>=20 >> Looks like the kernel needs adjustments to correspond with the new = DTB. >>=20 >> I'll append the full dmesg.boot. > . . . >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 >=20 From nobody Sun Aug 13 06:20:18 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RNnTK3YqBz4q3tZ for ; Sun, 13 Aug 2023 06:20:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNnTK0gyrz4FpD for ; Sun, 13 Aug 2023 06:20:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691907635; bh=ZgVllKGPBuew0AqJguCMXpr9ujwfYODs6xUGD14m5g4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=eqYg2tHtcQAHUu88EcKXcHRODIKdXbcKju7CnyVNb0Iz08g5EwcRtqv0pMqdkcvtdJhfsSQmpHmDLPfOjD5+SuVV/keSERxDs1sZzdEWwm5cvRKHJeFwZMlqtI3uczk7rJHiusiSEc5gWhZftqYwEulJnOaU3KR3v+wvN6Lo1CRPosVOX1mfl/JrxnGf34XZmcY0BmyuQooZ1m8P7+Bd8A02NDrBBsHTbvcOZSulnogGd1OasO6VqbkPjWX/ywdzf4uQj9xOSHDWWyW+1Pv32FIHsKiINFy3Zg8I+Xi3gB6+PyESRtoStH0Mm7ZBOS1y0oJRdrm0jsrrwGsgA/XWxw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691907635; bh=+Cp4wLZh2YlnxdPADFpj1etBvlgaVoy40v+4h2VZ+og=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=j35HJxgfSsbkoWl07fOYOjkbwQ5lPggsB/kHWSQu52kDvcOoL8ZQQTKuuwdk1zayB2SE3lLgaJ0vcVTmfSpGDuS+uIAdwSnpZZU4yj5Io/pLDxpPwcI9XEV7G8cN1yDSY5As1Vvvuyq/h7qbCij+G0pXC4wuxpCJmNVszLzwFhD6ci3OfzqdkAyfSfrYbJ6bJOusWGs6S6O19nT4vvqGOHCMzgUSFzGNgL3vaYs8eQ7H/ygnVL4ZoMrfhZSerWZewP0VycPrx7Ti1HuiSiaCjaJ4LZAT3eNk88rYfulgQqOO0Renr2USaL6haPlrd8mQJuA+HM4n4aCeCTBrwGgh/Q== X-YMail-OSG: NzgV.8IVM1lGg.nzXP63RtisgDum9IEdB7_EiZzxVtNSmxrhQhDx0e5K2prUL8j VRQClvDLinZndHNtvvKyGAsTlx8MCuo.j3IqIbIuoGvIbtiqqmzKR4LfI5kb4tBnkXVbfT4093WU RVkMsbeulelt6cNDqV1wIgjcbZ38SdFCObrDwtSgC9X.SQMzTfeY6dORXozYBhKAXUwRzVgo9iJO N9aQoLefigVs4b26aHYfp85r6JGpYAmHhkkNojaViVIHBFfWDmYbo7e4gl8__fS84PkAl7frN7SJ FkVENBmxKilmrQ3msuouDt2ndkITwiCRJEpdOJjhRHz.zFLA9M_B0O4Y9I.bZ_USmk_eEW5On15R h.99CiR9CSgmH7KG0ELpQMzz3D_gShGAFcZGqfpcp0TAV_BKWl64700ueow7QHDDNPmz3vhRgbxa LO_MlH462mJsyCBJXAbKGmoAcQYRfVdLzipWxNLszZ1XvIo1gZKdehnSRNa6CL21ykR6JH3BUwXF H4FohBD3Y5__MlDZafI5RNi8oQHjbYKDarDpAEhr8ysAeVOCsHEcjAXI2e_EIaPkcqWQB8ft6DjH P092ryrAJfKybAwP7TEUwYz7HVcOURub67Y1U4u4JkCNqOGld5EZ8FiCDDf76iTQixpTU.MorkhC bL8wPwb4iPhntl6EiRZ.DbjaqKvfrTJnNs4GIjrsM2AIJmOdsYna5gerxqLaiIAdXPn_M7.D7K6p LpFeECm2iacXt4V_LVBwqBIWlshbUggJnrQG423v2EZdr67Cxw0KeZtaY7934y.SAJjgboFOb6h1 pBYG2fK1y.z3SWh8N8Ab.vd4xajLty_Q6g5rfRF.LDBFeBPZnQMiY6pS6k8qWwYvzemU9kjFDW22 xY0Sge1MUrG8aiz_cLZFb3wfUnARUnoRWkkHJiLgnemyWOGgJNPQjWfBFkNMlNI5vuJt_fDxRX9. ZEGX7Xb7HQMlGSstRDshTnVZm3.mXb8a8AMp9eF6m8JjjvtZ00h78emb5Eq9fC371mJSadgxJPIf t9YWTysFWRT87Ld_HUfQvxHwsvgFd.8oGt9X57nL_4px9jxY8YLPerG2wfs3fK8Nn9wWMPTDUXIO YEs33DwMeqglS8KW1kmd9kE.OswjYAnVVzb8hJuSJojCs83AcrrMLSqJeEUkYicM07Ev_aVYPrXx KVAYVkUztT3_Ru2fWWXxR0_iUax04wFw5_LoUma9a1vKBZAMAbUNaCAMJixtmW91bUDwdbCaZZrw Cu6avJFIMs8ukfYDJ.C5b8LYUmn36eIgenWdi6.dU8PikQYFaOOUgKQiDmyxKgtKCalnbzUvXbn. r4MVFOZtuOnlO3AechIS6.x26K7EEVwvMDmNfpo08dKntXcl2sfXVqwXaV6VfgaJhCmiXs.51qfE XoDUCzoSR8YSxJbFB1ukav1tjVXB5P88hcGWo50BDcolGcBtvjpqDBzuIH02.1jnPbmYOxS.9C7V HJLiayKY8Ed7kxGkmqt78fKb4j.sZBzqDA7fVAvRNS_M_CyNnJHAI.oj6rGxOd6z68g.2V.3uUbk UM67kR0cr3fzo_hXHe6WU5mndIfc0NV.lb_U_Cf1E4M2sVBLuF1vqhe76PPfBPCj6bdMkesUUvbQ 4oXU2zq.rXWrsrO3_WT60fL2tKaEg1BdrybBvO91FsNmazzIUOiC3chl1su8ePcSsvQsDC5GmoTz rOa.d7lQQKiKjIM751x1NjegxWDZX_WiHPRjHhvd9eQc6pIcTEg6tKtLZrebv4GMv150a8mhmsHm TL4VEcIYjlPgvbQtJjhuqcSOKdV_uDLXV4YATzLFxGAa3VmcRhGWy4SqDq1bXEOvgbEiZ0YzSHJ8 lFnre9KwNJqd0_Zl5o7NMTyuAfVedPszV0ae8g3dMGj_w4525.3a1YWOj8Sd9JtGCfjN2Z0R71Ii NUgWP4wC6zHmT4z6oRZ7bO88Hk1sWCl0ib70Fmrt82ThK_nFgqlJCZ5WSeLoONGe5pc0mCWVMYe5 JfxsbbzHEYagRzZq4ucZ.s.3N4zuzkVV66NK2.d8DUP2eezlHCvRUcS7n_9H6d7E7m6mIS8l7oWu KVVnxvghNgvJIKFe_LinZakbs.8_ztPEI9rJNlC6gUSefRs2Gtk2jwsm7hUKB2ITwqbNzYvr5upv N27YwVJpzTXAU.e83KLKoIYyJfFWcA4m6szlQ2wLD7mn8.mZaYHqWyBYd.ryPQ8vlCXDvWS.odx9 3nOFYnBy7IlzLBX3xUxA.tIlWOU84fdycsYkEymOPprrtfyxls3Bmh5XmC1EzRVgi8U6lZ7WVC7p cQ8cl3wlJrg-- X-Sonic-MF: X-Sonic-ID: 419d05b5-3c08-4898-9018-cb9be0cd3f71 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Aug 2023 06:20:35 +0000 Received: by hermes--production-ne1-7b767b77cc-27nt8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4166754b57ba07cfe9b74ad3eccdabc9; Sun, 13 Aug 2023 06:20:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: ALPHA1 on Raspberry Pi 3B+ (& RPi4B) [found where bcm2835_firmware turned into ofw_firmware, making bcm2835_firmware not found] From: Mark Millard In-Reply-To: Date: Sat, 12 Aug 2023 23:20:18 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <8314B51C-5E4D-4F05-8FC8-CFCF3AAD6150@yahoo.com> References: To: Mike Karels , "manu@freebsd.org" X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RNnTK0gyrz4FpD X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 12, 2023, at 17:42, Mike Karels wrote: > . . . >=20 > Two other failures: >=20 > bcm2835_cpufreq0: on cpu0 > bcm2835_cpufreq0: Unable to find firmware device > device_attach: bcm2835_cpufreq0 attach returned 6 > . . . > I'll append the full dmesg.boot. >=20 > Mike >=20 > ---<>--- > . . . > ofwbus0: > simplebus0: on ofwbus0 > ofw_firmware0: on simplebus0 The above line does not match the historical identification: simplebus3: on ofwbus0 simple_mfd0: mem = 0x7d5d2000-0x7d5d2eff on simplebus0 bcm2835_firmware0: on simplebus0 ofw_clkbus1: on bcm2835_firmware0 The modern result outputs no line like: bcm2835_firmware0: on simplebus0 The older result did not output a line like: ofw_firmware0: on simplebus0 In other words the RPi* support was broken by the following change effectively disabling having bcm2835_firmware to be found by bcm2835_cpufreq: author Emmanuel Vadot 2022-12-06 10:57:37 +0000 committer Emmanuel Vadot 2023-08-08 13:13:31 +0000 commit fdfd3a90b6ceba838a40c3c51472883e7de8a440 (patch) . . . ofw: Add a ofw_firmware driver Some SoCs have an external firmware doing power management, clock and = other stuffs. (Xilinx, ARM Juno etc ...) The way it is represent in the = DTB is usually having a 'firmware' node under the root node and have = some nodes under it with the correct compatible strings. The firmware = node itself doesn't have any compatible strings. This driver is simple = subclassed from simplebus and attaches at BUS_PASS_BUS + = BUS_PASS_ORDER_MIDDLE so early drivers (like clock drivers) can still = have a change to attach early. Reviewed by: andrew Sponsored by: Beckhoff Automation GmbH & Co. KG=20 Differential Revision: https://reviews.freebsd.org/D37612 > ofw_clkbus0: on ofw_firmware0 > ofw_clkbus1: on ofwbus0 > clk_fixed0: on ofw_clkbus1 > clk_fixed1: on ofw_clkbus1 . . . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Aug 13 07:35:52 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RNq8D2xp1z4q8Z1 for ; Sun, 13 Aug 2023 07:35:56 +0000 (UTC) (envelope-from ronald@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNq8D2TjTz4Mgj; Sun, 13 Aug 2023 07:35:56 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691912156; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KVblyrEAELYVHihYI+YukkcFuaygo2AYIGJ8CLCQTzM=; b=A8BJPlOwrD6jDHoKMafzwCjZ86qw0SAoZGsuo4fzfbeyphIK4COexEHsKJCwTX97uxVCDf JOtjd9Lwf5wRsjXeek5cyk8JZvDt8LhcX02y6/5u5aRjNU6nPMAc6VzQNsdqsY7OFKdEuO ANjJ7uIsX6+RUYMo0BPM9peXiO9SWA7eARouOINA0rJW0JFsvKnkoX8pztuEUX9JmufQ02 ihKQW6HqG5FcEJTnQmn3SSxu99BrKDzepNWBuDiqx1VHNUVpmU310ZJI/BW4R6rMrIIn3y 69Rjd4GTn3flQURtNv2pVMgswLYlqZzmAPA1L8UiGMTBYQ0ZJhoYz3D1hjtZzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691912156; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KVblyrEAELYVHihYI+YukkcFuaygo2AYIGJ8CLCQTzM=; b=ki+i9tI8AIXlpow3DR4P9VT5+fKIxnVpDCD0bfT2VKcCZOqywZUMWeJS27Z89aasQy2tYS rD1+E2L1fr3QyodZ1sHkVenWyBuCqAlSCi1jIUB30rJD2fhJv7mbdR7acoa9NIwpLB1yLY 0YSb4G8+llPQ8OB6p5gvz7tSYhK1vv9P395R9DRscaOojPtlp5zhavSnSzASlR3pqL/7TD ocDVHW+mEyCJmyyLN5FtYQqW/WVMNDs6vR0sMQvQ/JrWh3CfnQ2/ccDwklMqNBZRkSd26s IuP8U7v6M6zdSl3GMo3OSXkSfIwFrUer0wmUQJpILbFABK6FSAQzHHZgIsC8vg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691912156; a=rsa-sha256; cv=none; b=VtVTpcdC9ForZYt3/0LHtH98+H3Cr/Vwe3xYAN5k7EcvnZvRs0LodbdI0//F6M+a+yJJ+P sp2qmnAynq4VRutl9OCNuJvR7+eIkysXBPzd+3ooHJY9Uv6sHSnfhd0nWxdwMDHSZawFus kfQDdKWPYENgSFJOwar2bHAp/nQNTo5ATb7gVMkacXAthj375mKmrOka9pVWHMpdwEuPSp vkuOiz1T/mAGXsxEcBeKoE6g3KnwTlEPQl8Av+X6/Z62BjQTxW5Fv921WBkHjmBso+GazN ha/4/ER7m0Aa6g1HNqRLknIC6Y/JGWjlcc4u8FtkzjOEi3rNaNUWv1r1BIJcOg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2001:1c00:2709:2010:48cb:205f:a2f7:e96a] (2001-1c00-2709-2010-48cb-205f-a2f7-e96a.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:2709:2010:48cb:205f:a2f7:e96a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RNq8C5CxPzpf1; Sun, 13 Aug 2023 07:35:55 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: Date: Sun, 13 Aug 2023 09:35:52 +0200 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: ARMV7 alpha-1 pkg not installing Content-Language: en-US To: Glen Barber , Mark Millard Cc: bob prohaska , FreeBSD ARM List References: <6A60A119-FA7E-4815-96A2-ACD11CADA348@yahoo.com> From: Ronald Klop In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/12/23 19:18, Glen Barber wrote: > This is semi-expected, but will take a closer look. Thank you for the report. > > Glen > Sent from my phone. > Please excuse my brevity and/or typos. How does a non-existing quarterly generate "No route to host" error? pkg: Error fetching http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly/Latest/pkg.txz: No route to host Are SRV records generated on deploy of the repo? Regards, Ronald. >> On Aug 12, 2023, at 1:00 PM, Mark Millard wrote: >> >> On Aug 12, 2023, at 09:36, bob prohaska wrote: >> >>> A fresh setup of FreeBSD-14.0-ALPHA1-arm-armv7-GENERICSD-20230811-136fc495615f-264678.img >>> boots correctly from a mechanical USB hard disk but can't seem to bootstrap pkg: >>> # pwd >>> /usr >>> # git >>> su: git: not found >>> # git-lite >>> su: git-lite: not found >>> # pkg >>> The package management tool is not yet installed on your system. >>> Do you want to fetch and install it now? [y/N]: y >>> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly, please wait... >>> pkg: Error fetching http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly/Latest/pkg.txz: No route to host >>> A pre-built version of pkg could not be found for your system. >>> Consider changing PACKAGESITE or installing it from ports: 'ports-mgmt/pkg'. >>> # >>> There's nothing obvious wrong with the network connection: >>> # ping 8.8.8.8 >>> PING 8.8.8.8 (8.8.8.8): 56 data bytes >>> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=27.549 ms >>> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=26.108 ms >>> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=26.195 ms >>> ^C >>> >>> # ping www.zefox.org >>> PING www.zefox.org (50.1.20.28): 56 data bytes >>> 64 bytes from 50.1.20.28: icmp_seq=0 ttl=63 time=2.891 ms >>> 64 bytes from 50.1.20.28: icmp_seq=1 ttl=63 time=2.479 ms >>> 64 bytes from 50.1.20.28: icmp_seq=2 ttl=63 time=2.449 ms >>> 64 bytes from 50.1.20.28: icmp_seq=3 ttl=63 time=2.350 ms >>> ^C >>> >>> Did I forget something? >> >> I had to adjust: /etc/pkg/FreeBSD.conf >> >> The issue was the http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly >> reference, instead of using /latest . FreeBSD:14:armv7 does not >> have quarterly yet. See: >> >> https://pkg.freebsd.org/FreeBSD:14:armv7/ >> >> that only lists latest/ not quarterly/ . >> >> Have /etc/pkg/FreeBSD.conf look like: >> >> more /etc/pkg/FreeBSD.conf >> # $FreeBSD$ >> # >> # To disable this repository, instead of modifying or removing this file, >> # create a /usr/local/etc/pkg/repos/FreeBSD.conf file: >> # >> # mkdir -p /usr/local/etc/pkg/repos >> # echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf >> # >> >> FreeBSD: { >> url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest", >> mirror_type: "srv", >> signature_type: "fingerprints", >> fingerprints: "/usr/share/keys/pkg", >> enabled: yes >> } >> >> I did not have to do this for the rock64 or rpi-arm64 snapshots, as >> I remember, just the armv7 snapshot. >> >> >> === >> Mark Millard >> marklmi at yahoo.com >> > > From nobody Sun Aug 13 09:21:09 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RNsTd3qW3z4qHC2 for ; Sun, 13 Aug 2023 09:21:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNsTd2dGMz4XWZ for ; Sun, 13 Aug 2023 09:21:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691918469; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S/Jz742U24cDfvdDn26DAg+gaSgRmeYFuFFoiUjgKCw=; b=wJq34MEOcndYBJRht8BJgOvlbtjf1YyDfTJq/vLdWalSeryp0gIDCSvelAXGkCvb0x1ft2 4mSXIeaEr9tfDnnHETR4wOZHWZgu997ArOoDSqn29qXPR6YKP/AssJphak59f/0ncaZzcL czqPtbbeSgJNTKsUJoWkDm+cZa7SzeLMq7CG28B6rZui61Z2Gmew6kDsFXr+1/QaMYs75v 41TPOtwYqkfjLT6mMLtjhThWIUNI+AZU4eVO2o37TuhXrQFT9N+9tk/8DZ4Lfej5qa1A+b 3CcCdr1vzBd1Y8xc8NbSqRcTNQa8bEkLmleaj6B51iI8KEZd0JwLH2C4x7+o7w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691918469; a=rsa-sha256; cv=none; b=MValQqGjF75QGrY76wcZ9O3qAcIY754rZddTO0iBYXiLpJ6wjO9Xx1CyVeFrrgPwo+djqv EwF5o86HCwcw4Jd/5yR655yRF2Yum2H2L2jVFFZ5lMdTdS7bPVJAP76+P7yE1B2QiUdgJx cN0CKvOjTmh+Wk0Doi7uEjYt/TkWE0ufiLzNbgB57WSZlbS/UGNx84Y32QhdPFl8P+M1j5 0ZBQw1ieLk8SKif8xTTF7L8gHQ53t9hDnndIeABHqV/9kUm9trPpl2byATB9yOPFlKRHZ+ JxSvC+9LjE0K0uLHs5bIe8LZA2PRBFuXWkElFn8PCF1x0n4y9Oy9I16LdnYw/A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4RNsTd1MzvzwXm for ; Sun, 13 Aug 2023 09:21:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 37D9L9KY068763 for ; Sun, 13 Aug 2023 09:21:09 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 37D9L9GH068762 for freebsd-arm@FreeBSD.org; Sun, 13 Aug 2023 09:21:09 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 273087] ALPHA1: rpi4 powerd: no cpufreq(4) support -- aborting: No such file or directory Date: Sun, 13 Aug 2023 09:21:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: manu@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273087 Emmanuel Vadot changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Open |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Aug 13 14:28:35 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RP0JP3B5Wz4Trgh for ; Sun, 13 Aug 2023 14:28:37 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA 2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RP0JP2fHrz3Vbk; Sun, 13 Aug 2023 14:28:37 +0000 (UTC) (envelope-from gjb@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (50.29.233.174.res-cmts.swb2.ptd.net [50.29.233.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 8ADC43673F; Sun, 13 Aug 2023 14:28:36 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us 8ADC43673F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: ARMV7 alpha-1 pkg not installing From: Glen Barber In-Reply-To: Date: Sun, 13 Aug 2023 10:28:35 -0400 Cc: Mark Millard , bob prohaska , FreeBSD ARM List Message-Id: References: To: Ronald Klop X-Mailer: iPhone Mail (20G75) X-Rspamd-Queue-Id: 4RP0JP2fHrz3Vbk X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:208.86.224.0/22, country:US] Hmm, well that is indeed unexpected. Are you accessing it via ipv4 or ipv6? Glen Sent from my phone. Please excuse my brevity and/or typos. > On Aug 13, 2023, at 3:35 AM, Ronald Klop wrote: >=20 > =EF=BB=BFOn 8/12/23 19:18, Glen Barber wrote: >> This is semi-expected, but will take a closer look. Thank you for the re= port. >> Glen >> Sent from my phone. >> Please excuse my brevity and/or typos. >=20 >=20 > How does a non-existing quarterly generate "No route to host" error? >=20 > pkg: Error fetching http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly/Late= st/pkg.txz: No route to host >=20 > Are SRV records generated on deploy of the repo? >=20 > Regards, > Ronald. >=20 >=20 >>>> On Aug 12, 2023, at 1:00 PM, Mark Millard wrote: >>>=20 >>> =EF=BB=BFOn Aug 12, 2023, at 09:36, bob prohaska wr= ote: >>>=20 >>>> A fresh setup of FreeBSD-14.0-ALPHA1-arm-armv7-GENERICSD-20230811-136fc= 495615f-264678.img >>>> boots correctly from a mechanical USB hard disk but can't seem to boots= trap pkg: >>>> # pwd >>>> /usr >>>> # git >>>> su: git: not found >>>> # git-lite >>>> su: git-lite: not found >>>> # pkg >>>> The package management tool is not yet installed on your system. >>>> Do you want to fetch and install it now? [y/N]: y >>>> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:armv7/quar= terly, please wait... >>>> pkg: Error fetching http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly/L= atest/pkg.txz: No route to host >>>> A pre-built version of pkg could not be found for your system. >>>> Consider changing PACKAGESITE or installing it from ports: 'ports-mgmt/= pkg'. >>>> # >>>> There's nothing obvious wrong with the network connection: >>>> # ping 8.8.8.8 >>>> PING 8.8.8.8 (8.8.8.8): 56 data bytes >>>> 64 bytes from 8.8.8.8: icmp_seq=3D0 ttl=3D116 time=3D27.549 ms >>>> 64 bytes from 8.8.8.8: icmp_seq=3D1 ttl=3D116 time=3D26.108 ms >>>> 64 bytes from 8.8.8.8: icmp_seq=3D2 ttl=3D116 time=3D26.195 ms >>>> ^C >>>>=20 >>>> # ping www.zefox.org >>>> PING www.zefox.org (50.1.20.28): 56 data bytes >>>> 64 bytes from 50.1.20.28: icmp_seq=3D0 ttl=3D63 time=3D2.891 ms >>>> 64 bytes from 50.1.20.28: icmp_seq=3D1 ttl=3D63 time=3D2.479 ms >>>> 64 bytes from 50.1.20.28: icmp_seq=3D2 ttl=3D63 time=3D2.449 ms >>>> 64 bytes from 50.1.20.28: icmp_seq=3D3 ttl=3D63 time=3D2.350 ms >>>> ^C >>>>=20 >>>> Did I forget something? >>>=20 >>> I had to adjust: /etc/pkg/FreeBSD.conf >>>=20 >>> The issue was the http://pkg.FreeBSD.org/FreeBSD:14:armv7/quarterly >>> reference, instead of using /latest . FreeBSD:14:armv7 does not >>> have quarterly yet. See: >>>=20 >>> https://pkg.freebsd.org/FreeBSD:14:armv7/ >>>=20 >>> that only lists latest/ not quarterly/ . >>>=20 >>> Have /etc/pkg/FreeBSD.conf look like: >>>=20 >>> more /etc/pkg/FreeBSD.conf >>> # $FreeBSD$ >>> # >>> # To disable this repository, instead of modifying or removing this file= , >>> # create a /usr/local/etc/pkg/repos/FreeBSD.conf file: >>> # >>> # mkdir -p /usr/local/etc/pkg/repos >>> # echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.c= onf >>> # >>>=20 >>> FreeBSD: { >>> url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest", >>> mirror_type: "srv", >>> signature_type: "fingerprints", >>> fingerprints: "/usr/share/keys/pkg", >>> enabled: yes >>> } >>>=20 >>> I did not have to do this for the rock64 or rpi-arm64 snapshots, as >>> I remember, just the armv7 snapshot. >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >>>=20 >=20 From nobody Sun Aug 13 15:17:21 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RP1Nw05VRz4Tvwm for ; Sun, 13 Aug 2023 15:17:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RP1Nv4b48z3fYq for ; Sun, 13 Aug 2023 15:17:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-4fe934c4decso4513254e87.1 for ; Sun, 13 Aug 2023 08:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691939853; x=1692544653; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Z0x1hRHb5KJoy19xmBtTapXWvr029UkYJz51edq8fG0=; b=EhM8cTlCKJ9D0+zPQcfgEPxhbZ8wdeA8qa9Sc9MIV/g8EubPxLE4lgCgyK43u85rK9 4+TVaEHJNn3GWKksSqHvsWYgWPwDXkTZYm6Gr99wb2KbYumvX7X+daE4TfNmMYE1x386 vh5LmOSrB4pWNNdpFXwmDXdoODz1sjUsQd/qNzG3VFfh03Xi5CVt4opKT3WK/DvUMMif hCgnx5/ZrCsHl90FzvG+Fu6SO5tIF1di4bLJP1lBM/Ki20MQTQBbiJ/1fyxYlR0XR2KM H757BvZWiATZDap5jn6/nUXHZeZKtKRn11/xy30NdiaJXyww4RVR9HtbVEmgHSTZ3HI/ MKOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691939853; x=1692544653; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Z0x1hRHb5KJoy19xmBtTapXWvr029UkYJz51edq8fG0=; b=GOw55lfpeCzvyweevO2Of7KVxrKo5fV+KbB8984LKRzQ5ELGb04+uorkw3zPXiblLs UdPhj1HPWcnMbfQRfV5tQWy2W6EOTLGbhSOE/mBfPtH8MeNhgGwg+qMWsqZX0fVhUWBZ +tm1IndwuyuIlecetTFKfKiQ3CRJpdoenhVPVihPUp4ez0kF2ME9Iysb27sWfa2FDL6p nLyz3JMkWb0RtP+jkQ2ipVJkHivVK0BtWXTGFQlZJJEJ+ZeGIN8A+BtgXmhoNsoz5tAV u82NpP8eSZWi/BHaK4roHtROXaJmoDTZ2SgqdmJhwzeePOAkwTbF3awV15CMIcIAehjF pV/A== X-Gm-Message-State: AOJu0YxhjpyXNR+7FWX0ndqTeumx+JYyPTynes3xJHrUvVByilsppjiT TFPBqowArVYIisfkzzgOAe+5COP2SB7vfV4c5XY0qA== X-Google-Smtp-Source: AGHT+IHP7wpfFwlWFRFVuOM1Z/PzId4XcQhkuI4RIzNoFCXgzi8elryrm4IwTL+T0CJdgW+C7NIoVIFL0et6lj2hT6U= X-Received: by 2002:a05:6512:3101:b0:4fd:d078:2e3f with SMTP id n1-20020a056512310100b004fdd0782e3fmr4254385lfb.42.1691939853186; Sun, 13 Aug 2023 08:17:33 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> In-Reply-To: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> From: Warner Losh Date: Sun, 13 Aug 2023 09:17:21 -0600 Message-ID: Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] To: titus Cc: Mark Millard , Mike Karels , freebsd-arm Content-Type: multipart/alternative; boundary="000000000000ee5db50602cf71f1" X-Rspamd-Queue-Id: 4RP1Nv4b48z3fYq X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000ee5db50602cf71f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Manu just updated Linux DTS in the tree. Maybe see if you revert that if the problem persists. Warner On Sun, Aug 13, 2023, 12:12 AM titus wrote: > the failed devices are all linked to raspberrypi,bcm2835-firmware > (gpio, cpufreq_dt,=E2=80=A6) which does not see to be probed / attached > check fdt ls at the loader prompt and ofwdump -a > and boot -v > and nm /boot/kernel/kernel|grep bcm2835_firmware_get_revision > > On 13 Aug 2023, at 07:25, Mark Millard wrote: > > > > On Aug 12, 2023, at 17:42, Mike Karels wrote: > > > >> I booted 14.0-ALPHA1 on a Raspberry Pi 3B+. It boots and runs, but > there > >> are some rough edges that probably indicate things that are broken. > During > >> the boot, there are 56 occurrences of this sequence: > >> > >> clk_fixed2: disabled on ofwbus0 > >> clk_fixed2: Cannot FDT parameters. > >> device_attach: clk_fixed2 attach returned 6 > > > > The large count is from a small number of examples. Each > > internal scan repeats the messages for each example, > > unless eventually found. I learned this when I had > > something being looked for too early, before the > > definition was added to match up with. Everything worked > > because of the retries eventually finding things after > > they had been added, but it produced lots of messages > > first. But, in that case, there was material to find. > > > > The RPi4B's get clk_fixed4's instead, with a similar > > overall count. For the RPi4B the cause is the > > "fixed-clock" material below (from a diff of .dts > > files produced from the .dtb files): > > > > - cam1_reg { > > + cam0_clk { > > > > + #clock-cells =3D <0x0>; > > + compatible =3D "fixed-clock"; > > + status =3D "disabled"; > > + }; > > + cam0_regulator { > > + > > compatible =3D "regulator-fixed"; > > enable-active-high; > > - gpio =3D <0xa 0x5 0x0>; > > - regulator-name =3D "cam1-reg"; > > + regulator-name =3D "cam0-reg"; > > status =3D "disabled"; > > }; > > + cam1_clk { > > + > > + #clock-cells =3D <0x0>; > > + compatible =3D "fixed-clock"; > > + status =3D "disabled"; > > + }; > > + cam1_regulator { > > + > > + compatible =3D "regulator-fixed"; > > + enable-active-high; > > + gpio =3D <0xb 0x5 0x0>; > > + regulator-name =3D "cam1-reg"; > > + status =3D "okay"; > > + }; > > > > I doubt that cam0_clk and cam1_clk are ever added to later > > find, as stands, making every scan report the 2 fixed-clock > > references each time. > > > > This is something that I reported on on the lists back on > > 2022-Apr-30. But it was mixed with a crash report that > > turned out to be a separate issue (and was fixed some time > > ago). > > > > It would be possible to decompile the .dtb used for RPi3B+'s > > to see if cam?_clk fixed-clock's are present. > > > >> Two other failures: > >> > >> bcm2835_cpufreq0: on cpu0 > >> bcm2835_cpufreq0: Unable to find firmware device > >> device_attach: bcm2835_cpufreq0 attach returned 6 > >> gpioled0: on ofwbus0 > >> gpioled0: failed to map pin > > > > Those are more than noise messages. > > > >> The red LED that's on when the system is halted stays on after boot; n= ot > >> sure if that's related to the last item. > >> > >> Looks like the kernel needs adjustments to correspond with the new DTB= . > >> > >> I'll append the full dmesg.boot. > > . . . > > > > =3D=3D=3D > > Mark Millard > > marklmi at yahoo.com > > > > > > > --000000000000ee5db50602cf71f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Manu just updated Linux DTS in the tree. Maybe see if you= revert that if the problem=C2=A0persists.=C2=A0

Warner

On Sun, Aug 13, 2023, 12:12 AM titus <titus@edc.ro> wrote:
the failed devices are all linked to raspberrypi,bcm2= 835-firmware
(gpio, cpufreq_dt,=E2=80=A6) which does not see to be probed / attached
check fdt ls at the loader prompt and ofwdump -a
and boot -v
and nm /boot/kernel/kernel|grep bcm2835_firmware_get_revision
> On 13 Aug 2023, at 07:25, Mark Millard <marklmi@yahoo.com> wr= ote:
>
> On Aug 12, 2023, at 17:42, Mike Karels <mike@karels.net> wrote:=
>
>> I booted 14.0-ALPHA1 on a Raspberry Pi 3B+.=C2=A0 It boots and run= s, but there
>> are some rough edges that probably indicate things that are broken= .=C2=A0 During
>> the boot, there are 56 occurrences of this sequence:
>>
>> clk_fixed2: <Fixed clock> disabled on ofwbus0
>> clk_fixed2: Cannot FDT parameters.
>> device_attach: clk_fixed2 attach returned 6
>
> The large count is from a small number of examples. Each
> internal scan repeats the messages for each example,
> unless eventually found. I learned this when I had
> something being looked for too early, before the
> definition was added to match up with. Everything worked
> because of the retries eventually finding things after
> they had been added, but it produced lots of messages
> first. But, in that case, there was material to find.
>
> The RPi4B's get clk_fixed4's instead, with a similar
> overall count. For the RPi4B the cause is the
> "fixed-clock" material below (from a diff of .dts
> files produced from the .dtb files):
>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0cam1_reg {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0cam0_clk {
>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0#clock-cells = =3D <0x0>;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compatible =3D= "fixed-clock";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0status =3D &qu= ot;disabled";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0};
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0cam0_regulator {
> +
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 compatible =3D = "regulator-fixed";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enable-active-h= igh;
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gpio =3D <0= xa 0x5 0x0>;
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regulator-name= =3D "cam1-reg";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regulator-name= =3D "cam0-reg";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 status =3D &quo= t;disabled";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 };
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0cam1_clk {
> +
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0#clock-cells = =3D <0x0>;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compatible =3D= "fixed-clock";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0status =3D &qu= ot;disabled";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0};
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0cam1_regulator {
> +
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compatible =3D= "regulator-fixed";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enable-active-= high;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gpio =3D <0= xb 0x5 0x0>;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regulator-name= =3D "cam1-reg";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0status =3D &qu= ot;okay";
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0};
>
> I doubt that cam0_clk and cam1_clk are ever added to later
> find, as stands, making every scan report the 2 fixed-clock
> references each time.
>
> This is something that I reported on on the lists back on
> 2022-Apr-30. But it was mixed with a crash report that
> turned out to be a separate issue (and was fixed some time
> ago).
>
> It would be possible to decompile the .dtb used for RPi3B+'s
> to see if cam?_clk fixed-clock's are present.
>
>> Two other failures:
>>
>> bcm2835_cpufreq0: <CPU Frequency Control> on cpu0
>> bcm2835_cpufreq0: Unable to find firmware device
>> device_attach: bcm2835_cpufreq0 attach returned 6
>> gpioled0: <GPIO LEDs> on ofwbus0
>> gpioled0: <PWR> failed to map pin
>
> Those are more than noise messages.
>
>> The red LED that's on when the system is halted stays on after= boot; not
>> sure if that's related to the last item.
>>
>> Looks like the kernel needs adjustments to correspond with the new= DTB.
>>
>> I'll append the full dmesg.boot.
> . . .
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>
>


--000000000000ee5db50602cf71f1-- From nobody Sun Aug 13 16:10:39 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RP2ZV4Zthz4mKQD for ; Sun, 13 Aug 2023 16:10:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RP2ZV1zS2z4LxP for ; Sun, 13 Aug 2023 16:10:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691943055; bh=4FddNg+sAeWmmqNYBSnecRY+gCWmDVpHAXhBDNM5Soo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Zu1Zu0g5cOwQLlyXFUmTuXxpBvMaSEmKGft6n3mXJhEL1oWPuNk/9jPT2JNUAiQwjhnCFHgP1kNUgXYMFP3Ffr2tdbu+iUd4RsvmZLGGdMY85lHwlgT1kdoG6dUk2nqv+U1mMRafCWw/e19wUVrHw/dHvIoGgQmuD5M7WkhVdW56gFBP61raDNni6Gyjq/PRS00we3U+l6sY5RZ/b2HGOYEtvzzDqBTKTC6qZOyqfTqY6zejEtkxB2aOn0fIXiSKsAV0Lf/zPr6VJTWA2W0404oW2HJQMOlHblxrdjfIKJ2pENMSCfpMIkXr5KbwAWZG3j8xVTzwaDhMOyx+IpPYng== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691943055; bh=R4W7CYpZICRE7y0OXy+K0stisG2n98LQ+7CIb08sqP4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DCEf/ucPtSP8dZX4hfryuQSJqqUV3aTpRsK48egN2pfDTtuwVp75eecFzjur7Lsf6uBWVZQIJXsPTHxl2PL7EYagEsSgvdd0znwfwJelwhNs4Czv4Uf7eXAizOKi++/E1VY1BRyjhhu2ybo3qMIKgOnHlu7V03twJiaGKNRnTJKkUYlLYqmKn/KZbnARQFePYiCtma8is8+t+gRsjnOK7rHNWKVJnS9+hMG0CKAYrhwhRB/93Bz6tCIEDCcW8VekJIF8zHK4Drpz9v565DMfl7lP0CYnYbZgu7fM+RG/LPdyIxUILgsd436gAqp/zRXM56JlTSVoP43xfyr4m8f+eQ== X-YMail-OSG: RTey72kVM1ldvNW8x979e4zWw0R6M6nXm17KgZGJMbC6Oi0I7ZLQv2inP59qhzC enUe_JBFoG7znom05sfFZacBlC1bLUANL2kMcflBz415IXu695Y3ZQiBZcfPRoBFhPX2lz7WaMIo q.QsB_rsoX69K2w2ONx_5dVHGL7ZxKn2QWQgW2bpQsPWb6pQvSRTpm6HC1F7R9uOZOY8uiUMD2CV pxrbRctWM6HcJYP.IvnHifoBfB.kZ.P0DwP0ZJGeeCuQ8qmyli3ukzXyMkzAQJ97f7P6NwifAZIS tRbhLB1YxHaOkK.wRIalnZ2juFEBuFmrcTIB.mQCeYEVQGve6O.3skngcQ7TKwYYj7PWSJPPYIm_ KYg4UsyHGP_j3s.56rsIcg9PJPX0t_M76SRnlA1F_s0aubb6TKcQWTRTRFGPV1AyldQu4OV8mrHf LCsd_frUjRzH.d1Jq70w2f4D2m1Cgy4IgY_c3fAb4QrvkZ.a4xHOtLjwm1E7cFBiWRw6UjEHFEgQ kgzt4gRFta7JrdXgel0CJRHkoZjk9fbmI_6yqseuUio_Wyb8NvpbqSUe0RokBFzuhN6mzdxL7CIJ qDiQjjHW9a4dBG21rVdEJ07oRjosKxujcUjbmKq9cVntkm6KaF9edl2czm0CnDsJ2OtN.B5tTdFw bZ.ql7W4T5lM_MLhvZ.agVaFRs4L_Z5B2Hi_1g8kLQL0JzuJ4o_mXcVLoUpjvmPHW27GwocBQAAG TPOKTv1BrNLqJS4mJEWZIZu0Ju5i3Z.kekOPlEN1Y18iMYV.ASkeMOaMSe8NBhVZamVw2M2_iTwt rxaQD0dQrWnlhauVxojNsKN_GyBWp56NBPHi8MpZtAQyZEb0yzId0lXRHEi7gggiwAtZJT2ZOalR 48g0fpLFAibktAPUnkbvO9eVWck1k8il0t3lUBzrJbO_A4.zJp2zDnrcy_0AmvYCfdfd9soyU0t0 RaJwwHnSbLqyptDzlGWbcspVBBXwFEs8I_bbvndpnN7lnDBHPdLProL5TL1EekT0ysqmETT_3smM EF3b9zIBq9qWmsLiM_6kreioEAAES3XRhBcD7VacNfSB3yazVauD5UlvusOMp9h74d30F.lPblP5 7451UszErJZ7QDvgyY263JK3T0aYjrCBB6HlTpmjC0ffIQ_Tio5oDXbqx2Y523sYT4ORsJGfi_d. xNh2tRtRSRs.Xgmnx35RZi81HMguPvCL4RbEC9s3P23nFn0.C1b4Dy3xoVP3ExNKuv9gkUXTJqrx 671XuapBQUcYiinzxR8CFxcDiThHehfHQTdURNv3tjgwi2JuCzz9pBeZEwHGYd4crhUsxJuQTDcS y3jaz0.yJSBiebDSJtrnYBtqjEHUcljigOLyI3_fKbRdnuX5pFfFw.26SjazKa2bnn6pxtN.pg6_ rYm5KKxSwyDdTQJBzZJerzyQKLr2rde3VYp6v2sBd_ieZ4p0SWVGm_jfTHNYJBiY2IbBPnaDInqh hm0EJFsEhL7Nb7J4ils95Yi9PtItQfAeesocp8as5aJzH.pLy7vK7zWYdxpQORWegZ3dSajjasuK dbiq92MC487tQ2oHjTmPvAJ3ES.AEYd0CtWrXhlvNSUnKot2lNVFC1FI8GlSxXJ_E_ZzPxbwSnK0 DcrHm3NyN4gO2eaKmssbudNNb1gC4eh7BN8KADo4b9BbS58XN9dMRzsjH5EeopxtyA3oc0O0FF.5 BlM__KkPlJt0K_jRZoxV1yoVMaFj6rkwy2lUvWgjlBV8D5GIPHXHFG5bG5ch5nkjlkWKJxbi4YwJ w66zf2hRVOz1iBZgu5vf6esN6upbvuxYs2TbRE40z3HY5nh_I282znPHMiTRaKTUu8f2lUv_5yLf 4DUvbA4P3dHQpJIys7mTPiLh_VcAdCrz1Dd2gQp3xhtKgSMuqShuC6wN._NO3fedi2_CuZYuvMMo 91nLH2VmMug1BY4hLiFoTgAqBVCpRJnL4yKi9RjE7XXyMWTnvgCflmw8vQfSwmPm77Lc.Sme4PWv W0i1UDoFjjYCey6FdhaEIHoaHP17C4cqOs3xOURj0HOB4I3QctDtyBUFfwWFDLwx5T_S_QA5U8yC lT4G6Fpvk_yPA6ARHM9QU1KQVZGU8WodzTTk6vw6JNV_lfyUkKtZLsd.RhyhC5b5PjSYEH7HDcM9 LZHP.tyffdxUPOpGLTBQHGdz9_zhOPUKFh2uysvCuQmbvAouJ0EMYiTD10lcaNu29KwUJIMuRZtR Uk5Y0.wCmH4BzUm09qWXkQkQRoHTMoZ7SSvsQIUSoBHpg4tqv.4brUdkiZN3iAurIM0DphfE3SMM k_TRh X-Sonic-MF: X-Sonic-ID: 642ce7ca-7f04-4cfa-8ffb-42c8337b7bbe Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Aug 2023 16:10:55 +0000 Received: by hermes--production-gq1-6b7c87dcf5-sv5pn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 418567f718840511606834a6a5fc7c58; Sun, 13 Aug 2023 16:10:50 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] From: Mark Millard In-Reply-To: Date: Sun, 13 Aug 2023 09:10:39 -0700 Cc: titus , Mike Karels , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> To: Warner Losh X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RP2ZV1zS2z4LxP X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 13, 2023, at 08:17, Warner Losh wrote: > Manu just updated Linux DTS in the tree. Maybe see if you revert that = if the problem persists.=20 git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no = compatible is the fix that Manu has committed: QUOTE ofw_firmware: Only match if there is no compatible =20 If there is a compatible string it likely means that the firmware = needs a dedicated driver (like on RPI*). =20 PR: 273087 Tested-by: Mark Millard Sponsored by: Beckhoff Automation GmbH & Co. KG Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver") END QUOTE Also, FreeBSD does not use the linux DTS Files for RPi* 's. They do not produce matches to the *.dtb 's that FreeBSD does use: FreeBSD uses RPi* *.dtb files that are in the RPi* firmware releases. Those RPI* firmware releases (and *.dtb's) are gotten from: WWW=3D https://github.com/raspberrypi/firmware via the sysutils/rpi-firmware port. > Warner >=20 > On Sun, Aug 13, 2023, 12:12 AM titus wrote: > the failed devices are all linked to raspberrypi,bcm2835-firmware > (gpio, cpufreq_dt,=E2=80=A6) which does not see to be probed / = attached > check fdt ls at the loader prompt and ofwdump -a=20 > and boot -v > and nm /boot/kernel/kernel|grep bcm2835_firmware_get_revision > > On 13 Aug 2023, at 07:25, Mark Millard wrote: > >=20 > > On Aug 12, 2023, at 17:42, Mike Karels wrote: > >=20 > >> I booted 14.0-ALPHA1 on a Raspberry Pi 3B+. It boots and runs, but = there > >> are some rough edges that probably indicate things that are broken. = During > >> the boot, there are 56 occurrences of this sequence: > >>=20 > >> clk_fixed2: disabled on ofwbus0 > >> clk_fixed2: Cannot FDT parameters. > >> device_attach: clk_fixed2 attach returned 6 > >=20 > > The large count is from a small number of examples. Each > > internal scan repeats the messages for each example, > > unless eventually found. I learned this when I had > > something being looked for too early, before the > > definition was added to match up with. Everything worked > > because of the retries eventually finding things after > > they had been added, but it produced lots of messages > > first. But, in that case, there was material to find. > >=20 > > The RPi4B's get clk_fixed4's instead, with a similar > > overall count. For the RPi4B the cause is the > > "fixed-clock" material below (from a diff of .dts > > files produced from the .dtb files): > >=20 > > - cam1_reg { > > + cam0_clk { > >=20 > > + #clock-cells =3D <0x0>; > > + compatible =3D "fixed-clock"; > > + status =3D "disabled"; > > + }; > > + cam0_regulator { > > + > > compatible =3D "regulator-fixed"; > > enable-active-high; > > - gpio =3D <0xa 0x5 0x0>; > > - regulator-name =3D "cam1-reg"; > > + regulator-name =3D "cam0-reg"; > > status =3D "disabled"; > > }; > > + cam1_clk { > > + > > + #clock-cells =3D <0x0>; > > + compatible =3D "fixed-clock"; > > + status =3D "disabled"; > > + }; > > + cam1_regulator { > > + > > + compatible =3D "regulator-fixed"; > > + enable-active-high; > > + gpio =3D <0xb 0x5 0x0>; > > + regulator-name =3D "cam1-reg"; > > + status =3D "okay"; > > + }; > >=20 > > I doubt that cam0_clk and cam1_clk are ever added to later > > find, as stands, making every scan report the 2 fixed-clock > > references each time. > >=20 > > This is something that I reported on on the lists back on > > 2022-Apr-30. But it was mixed with a crash report that > > turned out to be a separate issue (and was fixed some time > > ago). > >=20 > > It would be possible to decompile the .dtb used for RPi3B+'s > > to see if cam?_clk fixed-clock's are present. > >=20 > >> Two other failures: > >>=20 > >> bcm2835_cpufreq0: on cpu0 > >> bcm2835_cpufreq0: Unable to find firmware device > >> device_attach: bcm2835_cpufreq0 attach returned 6 > >> gpioled0: on ofwbus0 > >> gpioled0: failed to map pin > >=20 > > Those are more than noise messages. > >=20 > >> The red LED that's on when the system is halted stays on after = boot; not > >> sure if that's related to the last item. > >>=20 > >> Looks like the kernel needs adjustments to correspond with the new = DTB. > >>=20 > >> I'll append the full dmesg.boot. > > . . . > >=20 > > =3D=3D=3D > > Mark Millard > > marklmi at yahoo.com > >=20 > >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Aug 13 16:25:25 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RP2vP4gj6z4mL79 for ; Sun, 13 Aug 2023 16:25:37 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RP2vP3Nksz4Ps0 for ; Sun, 13 Aug 2023 16:25:37 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 37DGPQFv037970; Sun, 13 Aug 2023 11:25:26 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1691943927; bh=GUfuhU2+6Tz3q5qza6EtYE+PkJcL5ovUkXUv7LZzdjo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=PCjqSvWb4IkIzHG/Cm3rvvKb8vM0unSj+c45tYjpoO1v/SAB/KlBVzVekxmOcD11T owpjcjr6L7nHAesDgyKyzKsOm4pCD03JPIJhsKpWJnOWLZM/WEKl73d2pTHgFD4xVh zpy1OmntVIYWFqcDJ+FEfSweWz9vGK5hM8FI1ErQDbuUIt1tZSI3WPkVhBoDmvXdGD +3vQ1+beg3ILxKNcwsx1Ia8ZddGnIpVq7273qzPDXOgT8YdgWTz2okFFX8it95CKRr oWdgi5VR+OFFhLWM6dWMxi4bxEubqVPJ93DGFMOjMI8hT9ehpjBVBZr2DK2o0RInIv 1cGIPOqBoaYTw== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id 4YkFIfYD2WRQlAAAs/W3XQ (envelope-from ); Sun, 13 Aug 2023 11:25:26 -0500 From: Mike Karels To: Mark Millard Cc: Warner Losh , titus , freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Date: Sun, 13 Aug 2023 11:25:25 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: In-Reply-To: <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4RP2vP3Nksz4Ps0 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 13 Aug 2023, at 11:10, Mark Millard wrote: > On Aug 13, 2023, at 08:17, Warner Losh wrote: > >> Manu just updated Linux DTS in the tree. Maybe see if you revert that if the problem persists. > > git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no compatible > > is the fix that Manu has committed: > > QUOTE > ofw_firmware: Only match if there is no compatible > > If there is a compatible string it likely means that the firmware needs > a dedicated driver (like on RPI*). > > PR: 273087 > Tested-by: Mark Millard > Sponsored by: Beckhoff Automation GmbH & Co. KG > Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver") > END QUOTE Just for completeness: that change fixes the bcm2835_cpufreq0/powerd problem and the gpioled0 problem, but not the clk_fixed2 problem (clk_fixed4 on rpi4). Installing an msdos boot partition from the 3 Aug image makes that problem disappear. Mike > Also, FreeBSD does not use the linux DTS Files for RPi* 's. They do > not produce matches to the *.dtb 's that FreeBSD does use: FreeBSD > uses RPi* *.dtb files that are in the RPi* firmware releases. Those > RPI* firmware releases (and *.dtb's) are gotten from: > > WWW= https://github.com/raspberrypi/firmware > > via the sysutils/rpi-firmware port. >> >> On Sun, Aug 13, 2023, 12:12 AM titus wrote: >> the failed devices are all linked to raspberrypi,bcm2835-firmware >> (gpio, cpufreq_dt,…) which does not see to be probed / attached >> check fdt ls at the loader prompt and ofwdump -a >> and boot -v >> and nm /boot/kernel/kernel|grep bcm2835_firmware_get_revision >>> On 13 Aug 2023, at 07:25, Mark Millard wrote: >>> >>> On Aug 12, 2023, at 17:42, Mike Karels wrote: >>> >>>> I booted 14.0-ALPHA1 on a Raspberry Pi 3B+. It boots and runs, but there >>>> are some rough edges that probably indicate things that are broken. During >>>> the boot, there are 56 occurrences of this sequence: >>>> >>>> clk_fixed2: disabled on ofwbus0 >>>> clk_fixed2: Cannot FDT parameters. >>>> device_attach: clk_fixed2 attach returned 6 >>> >>> The large count is from a small number of examples. Each >>> internal scan repeats the messages for each example, >>> unless eventually found. I learned this when I had >>> something being looked for too early, before the >>> definition was added to match up with. Everything worked >>> because of the retries eventually finding things after >>> they had been added, but it produced lots of messages >>> first. But, in that case, there was material to find. >>> >>> The RPi4B's get clk_fixed4's instead, with a similar >>> overall count. For the RPi4B the cause is the >>> "fixed-clock" material below (from a diff of .dts >>> files produced from the .dtb files): >>> >>> - cam1_reg { >>> + cam0_clk { >>> >>> + #clock-cells = <0x0>; >>> + compatible = "fixed-clock"; >>> + status = "disabled"; >>> + }; >>> + cam0_regulator { >>> + >>> compatible = "regulator-fixed"; >>> enable-active-high; >>> - gpio = <0xa 0x5 0x0>; >>> - regulator-name = "cam1-reg"; >>> + regulator-name = "cam0-reg"; >>> status = "disabled"; >>> }; >>> + cam1_clk { >>> + >>> + #clock-cells = <0x0>; >>> + compatible = "fixed-clock"; >>> + status = "disabled"; >>> + }; >>> + cam1_regulator { >>> + >>> + compatible = "regulator-fixed"; >>> + enable-active-high; >>> + gpio = <0xb 0x5 0x0>; >>> + regulator-name = "cam1-reg"; >>> + status = "okay"; >>> + }; >>> >>> I doubt that cam0_clk and cam1_clk are ever added to later >>> find, as stands, making every scan report the 2 fixed-clock >>> references each time. >>> >>> This is something that I reported on on the lists back on >>> 2022-Apr-30. But it was mixed with a crash report that >>> turned out to be a separate issue (and was fixed some time >>> ago). >>> >>> It would be possible to decompile the .dtb used for RPi3B+'s >>> to see if cam?_clk fixed-clock's are present. >>> >>>> Two other failures: >>>> >>>> bcm2835_cpufreq0: on cpu0 >>>> bcm2835_cpufreq0: Unable to find firmware device >>>> device_attach: bcm2835_cpufreq0 attach returned 6 >>>> gpioled0: on ofwbus0 >>>> gpioled0: failed to map pin >>> >>> Those are more than noise messages. >>> >>>> The red LED that's on when the system is halted stays on after boot; not >>>> sure if that's related to the last item. >>>> >>>> Looks like the kernel needs adjustments to correspond with the new DTB. >>>> >>>> I'll append the full dmesg.boot. >>> . . . >>> >>> === >>> Mark Millard >>> marklmi at yahoo.com >>> >>> >> > > > === > Mark Millard > marklmi at yahoo.com From nobody Sun Aug 13 17:19:24 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RP45l73d0z4mQZQ for ; Sun, 13 Aug 2023 17:19:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RP45l3t7Rz4YSC for ; Sun, 13 Aug 2023 17:19:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1691947172; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+hw6/Y/r+t5M2vyVw8LAoGku9+wd5FGA8zO57vc7ooE=; b=AtCaV+64IG2ccRJfkQWrn/UypFHrb+7Ml2Fcj3atS7gtfBgphMs9uqKumepkcdINHVwUm1 D2kKmitD71h56Enz5F0wccIumtNZONs+BYkFZjIuiH35bl1yXOxzWQSZ+kxR0OXJ0HagnO iFKHN3r21hq0ec3o9lqVGguZVzfpGjM= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 6a536278 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 13 Aug 2023 17:19:29 +0000 (UTC) Date: Sun, 13 Aug 2023 19:19:24 +0200 From: Emmanuel Vadot To: Mike Karels Cc: Mark Millard , Warner Losh , titus , freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Message-Id: <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> In-Reply-To: References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RP45l3t7Rz4YSC X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] On Sun, 13 Aug 2023 11:25:25 -0500 Mike Karels wrote: > On 13 Aug 2023, at 11:10, Mark Millard wrote: > > > On Aug 13, 2023, at 08:17, Warner Losh wrote: > > > >> Manu just updated Linux DTS in the tree. Maybe see if you revert that if the problem persists. > > > > git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no compatible > > > > is the fix that Manu has committed: > > > > QUOTE > > ofw_firmware: Only match if there is no compatible > > > > If there is a compatible string it likely means that the firmware needs > > a dedicated driver (like on RPI*). > > > > PR: 273087 > > Tested-by: Mark Millard > > Sponsored by: Beckhoff Automation GmbH & Co. KG > > Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver") > > END QUOTE > > Just for completeness: that change fixes the bcm2835_cpufreq0/powerd > problem and the gpioled0 problem, but not the clk_fixed2 problem > (clk_fixed4 on rpi4). Installing an msdos boot partition from the > 3 Aug image makes that problem disappear. > > Mike There is two fixed-clock in the DTB without clock-frequency property and with a status set to "disabled", this isn't conforming to the bindings (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/clock/fixed-clock.yaml) so we complain on this, this is normal. -- Emmanuel Vadot From nobody Sun Aug 13 17:35:31 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RP4S94pKJz4mRm8 for ; Sun, 13 Aug 2023 17:35:37 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RP4S86jtMz4cQ8 for ; Sun, 13 Aug 2023 17:35:36 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 37DHZW0V038449; Sun, 13 Aug 2023 12:35:32 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1691948133; bh=ud59gHYdMKorWF8YwZz6k+wPp0wK0DrenLQX5lDmifY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=TPqH+eh0mToqH99YXixvJ4BirQHUENwoO8I5M7cCwxQ/AGomJU4+u/kB8qG1cH4rI YtDopCT3GVnjxdymmTmuZlepmIpoqItO0xKTT9LGhtAEA7Fo6h1N3eKeKGo45OSd47 7/JpjgPDPlcTzpbkhmoaHFFqlLa3yaGXmriIaLeb6m6cge9UPGAn21mS/NM/vJOv1F VwH2ve6ehnUYP/U1GIfkjrW3e+GjSoKphGBpscLUxwpHDCx5Vwo3r8HyiUcs4t2Scj PAytwzl2SSwgzoIyK5Pe4GK0H6Gob02a/p253LCloSXyEvJteeWb6/U9rQwP9X3g8Z WmTrJkGl1Py0A== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id PG6wImQU2WQvlgAAs/W3XQ (envelope-from ); Sun, 13 Aug 2023 12:35:32 -0500 From: Mike Karels To: Emmanuel Vadot Cc: freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Date: Sun, 13 Aug 2023 12:35:31 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: In-Reply-To: <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RP4S86jtMz4cQ8 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: > On Sun, 13 Aug 2023 11:25:25 -0500 > Mike Karels wrote: > >> On 13 Aug 2023, at 11:10, Mark Millard wrote: >> >>> On Aug 13, 2023, at 08:17, Warner Losh wrote: >>> >>>> Manu just updated Linux DTS in the tree. Maybe see if you revert tha= t if the problem persists. >>> >>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no co= mpatible >>> >>> is the fix that Manu has committed: >>> >>> QUOTE >>> ofw_firmware: Only match if there is no compatible >>> >>> If there is a compatible string it likely means that the firmware= needs >>> a dedicated driver (like on RPI*). >>> >>> PR: 273087 >>> Tested-by: Mark Millard >>> Sponsored by: Beckhoff Automation GmbH & Co. KG >>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver") >>> END QUOTE >> >> Just for completeness: that change fixes the bcm2835_cpufreq0/powerd >> problem and the gpioled0 problem, but not the clk_fixed2 problem >> (clk_fixed4 on rpi4). Installing an msdos boot partition from the >> 3 Aug image makes that problem disappear. >> >> Mike > > There is two fixed-clock in the DTB without clock-frequency property > and with a status set to "disabled", this isn't conforming to the > bindings > (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/clo= ck/fixed-clock.yaml) > so we complain on this, this is normal. Would it be possible to detect the disabled status to prevent the errors (I'm guessing not) or to suppress the repeats? 150 lines of errors seems= like a lot for an out-of-spec DTB entry, and makes it hard to ignore. Mike > -- = > Emmanuel Vadot From nobody Sun Aug 13 19:26:59 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RP6wq6ptkz4q4Rm; Sun, 13 Aug 2023 19:27:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RP6wq3NZZz3SmQ; Sun, 13 Aug 2023 19:27:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 37DJR0Ng025403 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 13 Aug 2023 12:27:00 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 37DJQxFr025402; Sun, 13 Aug 2023 12:26:59 -0700 (PDT) (envelope-from fbsd) Date: Sun, 13 Aug 2023 12:26:59 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: alpha-1 armv7 git failed: fatal: pack is corrupted (SHA1 mismatch) Message-ID: References: <8DCC324C-966C-45DF-88F6-A442E348D4AA@yahoo.com> <2F080FD7-B63E-4FB6-A165-E24A3DF2730B@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F080FD7-B63E-4FB6-A165-E24A3DF2730B@yahoo.com> X-Rspamd-Queue-Id: 4RP6wq3NZZz3SmQ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Sat, Aug 12, 2023 at 08:45:54PM -0700, Mark Millard wrote: > > You might need to use the ssh alternative if your > context allows it: > > ssh://anongit@git.FreeBSD.org/src.git > > There was a time when git fetch proved unreliable > in my context and I got around it via ssh use. It > also took less time transferring. > Seemingly no dice: # git clone -o freebsd ssh://anongit@git.FreeBSD.org/src.git /usr/src Cloning into '/usr/src'... remote: Enumerating objects: 4323641, done. remote: Counting objects: 100% (381285/381285), done. remote: Compressing objects: 100% (28204/28204), done. remote: Total 4323641 (delta 375529), reused 353081 (delta 353081), pack-reused 3942356 Receiving objects: 100% (4323641/4323641), 1.54 GiB | 656.00 KiB/s, done. fatal: pack is corrupted (SHA1 mismatch) fatal: fetch-pack: invalid index-pack output # I've added freebsd-current to the cc list 8-( Thanks for writing! bob prohaska From nobody Sun Aug 13 19:45:12 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RP7L12jmwz4q5rZ for ; Sun, 13 Aug 2023 19:45:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RP7L06R1vz3Wvl for ; Sun, 13 Aug 2023 19:45:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691955926; bh=cVf/QYr6MqgeSnv2QEaSdtrRXXTmjWrPcmZ3Ja4TFqk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=cSfSL53y6jtPF3qE/+I3Nq3VulJIKQVY/pQFV/C7MOJcgU8llZxMXRtezE9Gn9WlZZaUPAAE2zpE3vG03Hy6sJ+fszMVfs1m3ZGn6JRyR0U+ArH5c+cZaDkomiuBcC15LC5n3zEOuL+BfU7Vrx6EXwWj66B6JyT7ZKrj/OzKPGMtc1qdzSquMYOmPQtq8K+usOWoFZLatDzz2dvCUMbZSSqBB8QdsDnMEVdOWt0bdq9tadcvfoEWkwRj8wv2P+WYBd7T1rNcrJoG0zGG3TxvbcNuWlby3T8NFCo2/O1rKM5g/dOa8U5qdXNCZwA+u3ZrfHFK2ixjGljV6TsMGamZYQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691955926; bh=oWstmeXeFshIJL6GHNXs2pfih1nbGvl85/wc786n1ne=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ly2Gy+AHw25ikrqAJ2t9rdmwi60By5OQO2XMiJLRgtd3JbXiWeJVmv4ehwLGDdgpCtVlPAeiXSIqSRmTVYiieoc2CmY/GqQm54iDeQxd+mxZbl01/Cm4spyPEatssT9u6nrwEPweZLsDSGPK5efaUaLQnzQkPhfm/RGhVYSIkNkBxOatURs2fkhSqIklZ68yAX14ZiDuf5diJGUAaJ8aCTLp+b75A4YSU7j4Fk0dzH+/xiBYejk4m+XtPBwHno642rGO+1PP9tG7XmvhI6+gXK6x7YH9IC/ieTz4ruY33m9rLFP85sDeyIxz6ikL2TbWPbIib6lC32CBhH6kXNUsGA== X-YMail-OSG: VvoDbpQVM1kYiHcQHUTKeRQdauz9GWWqHZA1NWGxnt8zQeUvq7ZRySZ0WWM7Pcd 9i3UjYVR5P17lfJHUBNRiKcXw5xqcpyixI9UZyETcjn9sizVZ7q.qhwnnQ_5ZAkiKhOBP5wzp03L KF9qOgPOswDtZnWJEHxlyL5IVVyGWKzPl0yX1B0Wkas9aewTFa8R2imSRRk2MH1icIxIrAnnASCd OufgDyvzrur8XUPJrXUP.wq0iku1uXprkFOl6y3HITI.Sq0CWIyKzyK77V_tRwJyhTwLbD_7AZSQ VkCDrjTNeYjh8wZQFFY8i2RRypGQJNKXXBPZdTntcXSTuSvBShxonMykoxSxFLOWs3E6iWjEvB_l vZFeU9EtbWbMviwT273tQlb2Xn7pzCn7VAcBNWeB292_OruYMf9RNsaLvMCRTlo4l0pTOomdUMOJ Uch5m73mxFtfWu5nIqz87LIY8gePTD9U3y064TdxEFOKoJn9nHTaIwNPiiJuXlHZjIsH59lv9aqZ 8mbtu9ewtZ83Nx3.LOip_G_dj9Akoe8JyIUPM4OSTnBtAmjOpL7eyFJ27FHTC8Ns_1w3tgK53E3G pGJjvUfZaxxV_rGWEQr1Zpja0yIEwQYGI.jYc8tsSc8qx1AEuLTVs7R7aEdZ4yFeOFEgGCGRoFj8 Uwenp8NM8zi4dubkRXT7YYbuzxr7NmdAB6Ox3P8YGStVUimxk9GkKIvlrbrAw3CIPWKDyF13F9BG S3SpUPPHkxHIr6Cpzsl3bqymkbKF90KAA1ccaxs8MUMW0n9oLtMtjniSFtoYcXPz8f9KrOP1gTuG 9qI1.4SQJjJJqSCLgNKA46Bm8_nEZ_5mu39EZZvpFSDcUL_KjKYurZ2aI7OnmjSHPiaXSpxRIh7O 3QnF3se2zA6TmYZJ8rbCiGSbIE41vvd6eyO4NlEsFr5G.AFvaFPauYXgFWHFv45vFxfaKjB47ias 6n4WM5xHeJgckE8v1sFtGomRv8y96oTthJMBhFJx1Qt18MScydkFekKJ6lrwgtY4KveS0ZV6dIBn WsrniSQEF5CWrr4K2niDzwH5pKUTO0ayZl7xZg_VKHLur.BSK7Jwf9rDEXlA.eChoJ0F8BQlvKEI etj86LfarqskUdQLWe01bZ0DUa2OKdQC9dgEobG.bw0QcTx_u_T0GvEn3W3EEVRaFLDlRech4MZJ tq.Ck9KhqCFwOhbqVlUi_7rezEeQk9L6vHYxdhJqEj_jQ7eKLw17N7WamDzYymCLY_kZcAA5toAg n0.cmqpcDvy5cRd6T73awhjtS3vi115rGM1tSad5pbvrOaBToVJmoAPttpUXzycsNQyyOBPAAt.O AN9KH7L.1e1AmZUVLDt442EQ.39GVruwX6H_E6DfbZ_39MtopX6fPsYpolMcub.84qChpsa4mSeW yeWs_f_5irSbaLRVq1hxrbaeppS2ivuaNOPiWRTQ_.asD0z.EE12x5.EeFEeilgDKMMvfPwdTDXo mfajyieYQpB6UtOwxe3A68gIGL8MVkbHihM_wzRAu0VfB7LqsulNoIqv_h97qx8JYWlCK9Gfe1t. 8kR23wpatvy2JbAKMh1BwsyTkfFXtyYPPmRbxSmDkW5Iq6dTIkZtBprD4V4ljf1sBlee71uWoA53 t7Ss0ATJPhSEuDmrbY.yhlBLXJiWSjJpDdESzUObrM6Uc.WnJ6vhQ1DMQ2iuL6pEcimmItYJMk2k yI.yv9loMwznZL4jJEe2PbPjdRznDsR60eqp5muioT2iGHAfd07ewnDsh5OEbFNdcLIE2y63l1Ki x3HbLIRkEDxton7YKpMjniSmReJQZ1dhvVrXocD_DezQLjiQuRl5qgQLxVgmxFw2.GidlxiTp1jD 18f.fQvV1hL.HyTqHrUICyJLXs2pMA1nvf80x3bKpYwvD5kJJNFfPzWtMYWKolFLoeS_q6ZGLmle 1ggyVzZgehVZJNyvrRFD9rAHfo9RC141NTg5dsnShbm3gQnrqkGFM6tYbvWmU_AaNTHKa3Mdjxx5 4WEOlj9iGVRYli1BbA8QMo_euPpxs2.NTggypt59THkLVsCT3M_vuF3CBK8aNMVuZE_sixvyl3DQ BXEtz44tAEFrO_cMcleVGVigFz9Rs4lR8z9xVQMJrReae9KZ8zBJSMY73UBPbOK5GpvCjdIDRGwn 84RxWZcHsQDRKmrjh2oX3s8qynC_9AAC_9GuSFaKTTMVdd0RJQkZzfVxmKsy0e21rb7TD2c37JvT WWJC6xVvzcgdXFJIrbziWn8aMX46OCoTli2OFYmj_SFaFEzYKUcQCfrUXePHIXLHBo6JTbgSMDso Ark4- X-Sonic-MF: X-Sonic-ID: 6c9d9a70-2523-4b50-9b9e-ae08b647e128 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Aug 2023 19:45:26 +0000 Received: by hermes--production-gq1-6b7c87dcf5-792fm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 32281c6c0b5f075daccc48d059ca61f9; Sun, 13 Aug 2023 19:45:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: alpha-1 armv7 git failed: fatal: pack is corrupted (SHA1 mismatch) From: Mark Millard In-Reply-To: Date: Sun, 13 Aug 2023 12:45:12 -0700 Cc: freebsd-arm , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DCC324C-966C-45DF-88F6-A442E348D4AA@yahoo.com> <2F080FD7-B63E-4FB6-A165-E24A3DF2730B@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RP7L06R1vz3Wvl X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 13, 2023, at 12:26, bob prohaska wrote: > On Sat, Aug 12, 2023 at 08:45:54PM -0700, Mark Millard wrote: >>=20 >> You might need to use the ssh alternative if your >> context allows it: >>=20 >> ssh://anongit@git.FreeBSD.org/src.git >>=20 >> There was a time when git fetch proved unreliable >> in my context and I got around it via ssh use. It >> also took less time transferring. >>=20 > Seemingly no dice: >=20 > # git clone -o freebsd ssh://anongit@git.FreeBSD.org/src.git = /usr/src > Cloning into '/usr/src'... > remote: Enumerating objects: 4323641, done. > remote: Counting objects: 100% (381285/381285), done. > remote: Compressing objects: 100% (28204/28204), done. > remote: Total 4323641 (delta 375529), reused 353081 (delta 353081), = pack-reused 3942356 > Receiving objects: 100% (4323641/4323641), 1.54 GiB | 656.00 KiB/s, = done. > fatal: pack is corrupted (SHA1 mismatch) > fatal: fetch-pack: invalid index-pack output > # >=20 > I've added freebsd-current to the cc list 8-( >=20 Wow. I'm going to suggest doing a clone (to a temporary place) on one or more different types of system, such as aarch64 or amd64. If, say, aarch64 works but armv7 does not, then the corruption may well be in some armv7 FreeBSD handling of data transfers, in places common to both https:// and ssh:// use. Note that, if you get a good clone, you can locally copy the tree over to the armv7 media. But that is not the point of my suggestion above. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Aug 13 21:01:01 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RP91B5CQTz4qBnH for ; Sun, 13 Aug 2023 21:01:02 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RP9194Nckz4GQ4 for ; Sun, 13 Aug 2023 21:01:01 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691960461; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gcWtPB41S7PX/ktBuJOn8gXnVK8SCxLA7ljsxl202hY=; b=CZCGPPCSkRKUOwJxhfO3XJ/wQdiO6cPtLFXQ3nFXSjUKMHzAYre2PNjG/5jRi0najUTzcu zTp9Y41YUG3SWw6ztD1v0zAboENoquyEzeK2hWVGjClootlZclwr4ob3N52bT8aEHCRUqv kwK+mP5M9lCzVdf3N/mQbIr7QA/wFWZ+plB/RQ69/DuQRVBvKO6B8zdN81cjmNHvzuZA99 8vWIdLbH38c8LDxGkIMtKffK79Puk/8IRsZbhppurVkwyzHa+E99yadkw8BoBcUyepACd+ o6X1R78R23qlb74btQRFj0+hL9OgXeoXCscfIEWA3ebcHJTVkzHPrKkUB0jKkQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691960461; a=rsa-sha256; cv=none; b=e3j9vDCdtg7dYtxW2KN/+AfpoOBNuP9IGS2xMZWGYrZu00liJvAdstDoZrQxDrjRFSXH5J 9mGDYY1lJMfw0tYWM0hPTRsHyWKfgWB54PlOZP6RKyQh2Qq3vIs8URrFMDjTKsS9eN+qXC nyZewoUcE9d3sS+CgRm+Ax7qBgwkv7ePXQJKETOowPL5J3wajoJdS9a/kXtyt0FQD8rtDV ioId7gJMshEsr29LFlprc+Edj6ULTi6vcnbO6uXDGTSMSi++Y63T9lxew0CaOucudHAAfq NAmruptvmhExzrWCNAyglRxzJ8uvHTei7xJ/6R5rtEUxEFjFPps8Qxa3eBsOVg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4RP9193VQGz1GfF for ; Sun, 13 Aug 2023 21:01:01 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 37DL11PM009325 for ; Sun, 13 Aug 2023 21:01:01 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 37DL113Y009324 for freebsd-arm@FreeBSD.org; Sun, 13 Aug 2023 21:01:01 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202308132101.37DL113Y009324@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 13 Aug 2023 21:01:01 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16919604614.fe5FcfA.2621" Content-Transfer-Encoding: 7bit --16919604614.fe5FcfA.2621 Date: Sun, 13 Aug 2023 21:01:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 2 problems total for which you should take action. --16919604614.fe5FcfA.2621 Date: Sun, 13 Aug 2023 21:01:01 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

2 problems total for which you should take action.
--16919604614.fe5FcfA.2621-- From nobody Sun Aug 13 22:33:11 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPC3b24tmz4qJkl; Sun, 13 Aug 2023 22:33:15 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPC3Z5KfJz4TjN; Sun, 13 Aug 2023 22:33:14 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 37DMXBMJ025936 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 13 Aug 2023 15:33:12 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 37DMXBQl025935; Sun, 13 Aug 2023 15:33:11 -0700 (PDT) (envelope-from fbsd) Date: Sun, 13 Aug 2023 15:33:11 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm , Current FreeBSD Subject: Re: alpha-1 armv7 git failed: fatal: pack is corrupted (SHA1 mismatch) Message-ID: References: <8DCC324C-966C-45DF-88F6-A442E348D4AA@yahoo.com> <2F080FD7-B63E-4FB6-A165-E24A3DF2730B@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4RPC3Z5KfJz4TjN X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] On Sun, Aug 13, 2023 at 12:45:12PM -0700, Mark Millard wrote: > > Wow. I'm going to suggest doing a clone (to a temporary > place) on one or more different types of system, such > as aarch64 or amd64. If, say, aarch64 works but armv7 > does not, then the corruption may well be in some armv7 > FreeBSD handling of data transfers, in places common > to both https:// and ssh:// use. > That seems to have worked on a Pi4 8GB running -current: root@nemesis:/usr # mv src src.old root@nemesis:/usr # git clone -o freebsd ssh://anongit@git.FreeBSD.org/src.git /usr/src Cloning into '/usr/src'... The authenticity of host 'git.freebsd.org (96.47.72.109)' can't be established. ED25519 key fingerprint is SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'git.freebsd.org' (ED25519) to the list of known hosts. remote: Enumerating objects: 4323641, done. remote: Counting objects: 100% (381285/381285), done. remote: Compressing objects: 100% (28204/28204), done. remote: Total 4323641 (delta 375527), reused 353081 (delta 353081), pack-reused 3942356 Receiving objects: 100% (4323641/4323641), 1.54 GiB | 390.00 KiB/s, done. Resolving deltas: 100% (3432012/3432012), done. Checking objects: 100% (16777216/16777216), done. Updating files: 100% (95944/95944), done. root@nemesis:/usr # > Note that, if you get a good clone, you can locally > copy the tree over to the armv7 media. But that is > not the point of my suggestion above. Under the circumstances it seems like the path of least resistance. Can I do something simple like sftp, using get -r ? Any trick to updating the copy? Many thanks! bob prohaska From nobody Sun Aug 13 22:53:58 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPCWn42Ngz4qLRT for ; Sun, 13 Aug 2023 22:54:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPCWm5s4bz4X8V for ; Sun, 13 Aug 2023 22:54:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691967249; bh=Wat27MP7HSgR3x4GkF0oFOJHeOhMso7sAvkPHkpK4A0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JOjRzCxewympbS8BROygBZmGvuPm0QgsSBTbmI79RD/S6SmxAMmsB7/L/veK+l2TpBfUkxiDsLkdCEeyQDldefFPaMDCA9hEnNy7MTa2SwUooWYGjASR/HuVOj7VM2tac59ItZ5L77eyYTWnNhrHGpUccEfSVnXUAUWw2rRod/EAyCSJCx7QTOkqkD1AymcypU/AnpJhwFGWzNyg7iIy7CMnKMyMFBNViWikX/DtwRQOVylDAKUEmIx11uwI+nCjiwi/vhVbgNgmv/WsPE7AeCx/L9gku0fhc/kba0Hr9hume7rRo5ZAlTZMqhgfWYoAq0FrdPyd83yyzlacrfHpRw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691967249; bh=j0pG7Hp5SfYpSnkcvUmXVF5l32PCX0KYGh69yuanQKa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=p4ECGuH1Qv8kuS1Ie6zV/kPjDjAMqPiF6JmBV7RRpNm70bsUJh0y6oJpaiuxUhKS8sBvTC+sSONkfiqOY81lrBQpebxWGE2Ok1DkXiPzuzyx3JfZYd2aDkWx+wvO4RiD7fin8c3mMLwByE0uwN538BGa/NCJ+4qD2ozC4n1RNIaMv8AeacBHODJ6MzlIy+ivbCDD5Ffb5As29x3wBEl1OlVvCOBz9mSQtWkPQlc1Ek4CsCFnjfeMJBxIJZa/09iqeDGOiefYYko7qnpYVg7JhaUBY0z/J33/aLtvceLhntmXtMYDbskP1KGQEHYJLwJ9wwZb4BZJhf0Y+In28qem5Q== X-YMail-OSG: _juLRxEVM1lQpQQryHmBnp3Un3JoRpPrvYe3sWMM.vI7E4l.Hzh1Il0jgsXvhXs vubCZQYzIuji.CIFqN9BWil_HPUs2Wqa9_jhQxR5.H16l8zFsAMoCu0BEX_6aZd4TQFiGA0FgEnG QAGgCSKBTwHBSwDu3gHwmJS9U6PkIzOXNxO4IGSnw9uWxfS3.CWFHQdjH1vHGhfdKWE4MEjqXdWh 52IxUlJZl1W8fXKr_eamLdi06EpSnisDyRADNOEZQB2hTnLzWCOv6RfZ4IDzryGqOJqVzC1.m_BE sWLtfUYqyYI_CHIbIXVOwiMaYJcqPtBliSTl15xmuHQldbH6PYp51SH8YAVHDUodzvnf07xRfE4a TaO92atSQAe22X6jTwDjiDgVhzWJB7dKR3e5I2Nu7rzm5IMavuNPuG93ilhzyCAG2RRbBT3Qa1.. ONDHdyz4Kis689dp6jxHFQKiKX2cbgAA2UF_dF22yji73uGMGcDfa6oqdX6DXnMWywxvCApUIo.s tAq2bqDS.Qktn8ZJDFV6eelFm_Nu51OxDAoSgv5Clv_k7Rfs9wIse6GeOxLFeOr5IrFXQ4RxyMUd XmjgSuWbrTR3GV2IAimrOWtfj7qNZUvLJ.R3ecjPWw0yrKXjtqV9vQ275sqt5yTF9WXyzCTGzEWw m0aU3FfH9U1CGNpY5qCJNY95yDpWsqz1.M6mkhTNdABLevZHjkO9PxFrmeZ1MZ2nCLCg26QuCcEE HnSxFX4TnwkSyX6VpZGsqpjkbocqG905umycGT7uCz0YzOTBO097WnK_mwhFdvwg6qgLOz9fhzZv oQscnj3qz3HrPiOmIfAs0znhAj8Qo7jIVzsD1sQhK0rauvn6C_GdG_axsTZw.8VkZrs_4qfweIon p3f2udidi4bYvetxY9DpBSQ5ArzitwGgPV_NOfxUxTK72GuyF2wc0sZhIa2_QSVJEr4mibut96IE _2UxjJV7XziFtfImIEamgjrZaGHGRSK.b2MfSvOrLI4sDDapJe_31e.VOyVdgsgsttzGqxPP1DSN WH5iTrG2PFbp2hqutuV7DWD31ahKLQw5MZ3dTTQXuEzgM3PsIGmDf50b3NjH3OwDdAJYYgBu_hdR wID5XVOaQ5bTZwtGbRE920bKuFp.yrOzKSLpVEsE2EtnDCdD4S6NZEhbycp2096mSavY1HQn1kHV 3KuEb6g7ptSg5iv_kSCFa1xCmTbrMPvW7OkGHrezsGLXB9Bk3DpgpDMgdreub4any0UlN2eeO2nr cYyiYVjxGhp3CnNERd0tX3wVLribqUrmUjHSKLadZxc8Tpq4VLwHrVvk3VA0M5b7Amvc2EjDpGX5 QbwU2FxmDUS1vB5IcXtGRQDjrf1pWgkByvhx.coLeDJl9KVnwjGxliwNFxwdkFdaBP6r7hgsizCL O1NcNBOiiJYhfw5cOaM9JknpwQpE3tKkFcxLJfULvpk8Tg2peP13Cp0Fr25HYNTAd7S4NDTNkd1K Ww8H_Yf2j2vSeg9PnwOK3BZP.2suhtEHruFWDOd9LZra.t32fB_dQM4QlT_pqK7p7zVXtElnWo7Y YcETV5o6mUD4pz8xoPvEx.7ns9Cb_vDYjIEGdegB.9H10IgqyBKNSj0y.KEu8t6Aj4rpT6DEB1zh qumejc3BebN9jkomWrO1EO_YBIn75iHF3z49lcwc31FvgxMXhfE1Uh8VG45oD9IRKTS9TsqBEcu8 BHhEC9m06e98agpG6wljwIfKvLfYFeQYvb1ZIhzPCuqP1POxfaGk0cjOhMNVlok0oafoFtoFkFKE Z7vVjsAZt48pPROu49EkATrxwgmbqzWwBoi0aEX5dGjpkllIEsb0ya_3SR9Q7FVT_UowvAYTsewD Y7N8UpuJ5faOdmRUBj.SU6yUTwcx_yLcolVtF26eOqqsJ9NeMsm1Ezq1yn0nmcbYcUNwtGisA4Jp WPnwt127eFYn2Mfrtg5v5XamG6zJWxKRQkJTKy9se6jp8tl5mDMJKvq1LJESu3ipzZYi7xWzqQec _8XY5AYKBdSepzcxaB829yE2YOogoM5JbhExNpqSKI3l12QtdQLyeq_MqdHSJ2ULLy7Bry0JISZT rME5nJFESXxYU4Vy6pTnndTi6jLupAYnsoseW7KsjDjt4oiTSHzAWlHaPKuweV7woV.XhdVjc0uU AgaNDDIE8eP54xVqJrO6cCAzGXExLVaFfh.dshlJfU78ZmlgE1wnhXvFhAciJEPmEfARPz3Vlser MFjvBaPnyNmcrIL.6ca9rrQGl9FaDLgoLEogPt7ghdIpTDbahmtjhkcho07YF_VUOsX0l4IIGmxP qGw-- X-Sonic-MF: X-Sonic-ID: c0cd8a2f-39ae-4e89-8b03-db968c165917 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Aug 2023 22:54:09 +0000 Received: by hermes--production-gq1-6b7c87dcf5-rj4xx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 93a1e15b1c659154832528f3622727ed; Sun, 13 Aug 2023 22:54:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: alpha-1 armv7 git failed: fatal: pack is corrupted (SHA1 mismatch) From: Mark Millard In-Reply-To: Date: Sun, 13 Aug 2023 15:53:58 -0700 Cc: freebsd-arm , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <0DE04A45-3D4E-4125-BD8D-221F30E3ACC7@yahoo.com> References: <8DCC324C-966C-45DF-88F6-A442E348D4AA@yahoo.com> <2F080FD7-B63E-4FB6-A165-E24A3DF2730B@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RPCWm5s4bz4X8V X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 13, 2023, at 15:33, bob prohaska wrote: > On Sun, Aug 13, 2023 at 12:45:12PM -0700, Mark Millard wrote: >>=20 >> Wow. I'm going to suggest doing a clone (to a temporary >> place) on one or more different types of system, such >> as aarch64 or amd64. If, say, aarch64 works but armv7 >> does not, then the corruption may well be in some armv7 >> FreeBSD handling of data transfers, in places common >> to both https:// and ssh:// use. >>=20 > That seems to have worked on a Pi4 8GB running -current: >=20 > root@nemesis:/usr # mv src src.old > root@nemesis:/usr # git clone -o freebsd = ssh://anongit@git.FreeBSD.org/src.git /usr/src > Cloning into '/usr/src'... > The authenticity of host 'git.freebsd.org (96.47.72.109)' can't be = established. > ED25519 key fingerprint is = SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE. > This key is not known by any other names. > Are you sure you want to continue connecting (yes/no/[fingerprint])? = yes > Warning: Permanently added 'git.freebsd.org' (ED25519) to the list of = known hosts. > remote: Enumerating objects: 4323641, done. > remote: Counting objects: 100% (381285/381285), done. > remote: Compressing objects: 100% (28204/28204), done. > remote: Total 4323641 (delta 375527), reused 353081 (delta 353081), = pack-reused 3942356 > Receiving objects: 100% (4323641/4323641), 1.54 GiB | 390.00 KiB/s, = done. > Resolving deltas: 100% (3432012/3432012), done. > Checking objects: 100% (16777216/16777216), done. > Updating files: 100% (95944/95944), done. > root@nemesis:/usr #=20 >=20 >=20 >> Note that, if you get a good clone, you can locally >> copy the tree over to the armv7 media. But that is >> not the point of my suggestion above. >=20 > Under the circumstances it seems like the path of > least resistance. Can I do something simple like > sftp, using get -r ? Any trick to updating the copy?=20 >=20 Given that you are having networking problems, I was thinking more of moving the hard disk to be temporarily connected to the system with the good copy, mounting the UFS file system (I presume UFS), and using the likes of "cp -aRx SOMEPATH/ /mnt/usr/src/" to make the copy. (Presumes the armv7 media's /usr/src/ is empty.) Then umount, disconnect, and put things back on the armv7 system, boot that, and continue on. It is less obvious what to do about future git fetch activity on the armv7 system if that activity also has problems. But, you could try local area network based copying to explore if that also has problems. That would involve having git validate the copy after the copy is done. If you found that some methods work and others do not, that would be good to report. Similarly for the limiting conditions: all network copying fails vs. local network copies always work for all techniques tried. Up to you. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Aug 14 01:21:46 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPGpP2Pl5z4Tk7c for ; Mon, 14 Aug 2023 01:22:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPGpL5dKXz4j99 for ; Mon, 14 Aug 2023 01:22:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=OxbYtxIK; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691976119; bh=SUZ+qRKcrBC4gktXdAejWVlCFiaFcmL1TNRDJITZgoU=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=OxbYtxIKPfR6ptZ/iS9NyS5jDmSfsHAQ2HO4Byna3M6quHs58EDm62VVYcNLdEWsge+kaFyrlbYOkWLVrU4gkiQcI9co8+MP/ehtZQmZkOLdyaql3F+HrFgc/ApHhk8ADNOXL5ihX9AQDHU3TfC7EciTZG0RWxLWS6I+3xdegP2C/5vGj2BkelVDWzKcIg/HK582DoukZF5nH0M5kH/5UYVFVlRAF6breGodFIYSQdmEAmEE4CVrRl9M4jfQf2ki9KGfGKNj75KchfS56ao2nIeZBeIyfD++0S3t6LcJunF1s2P9QovcGUJQASMIe86zbdq/BhnhhmVD4KfpgQYFEg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691976119; bh=Aw3gDaZujC30K5IzVhsfCoo3LVWd2956YdbRMEFoKxQ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=XdH0mME4r0q5W/AqMjWbd1cqsHzfLdbSQHsoH74Qp97HChFG7UdJ9ONHOs7EMaGIw85OB4eV6T0/2Wk9b86X3WSNarBgSx66XSP8MGW6k7Gjc3Lgv2x3pQRuD0SM9o863dQJIRXgxX60Vi+vYSLF28W0YbOKkp6RLCcizaB8p4cQGlg8/I47jj0Z1Te63afnTK59Zzx4IukN12FHd4cwWcPjpDfAv+dGpM0tgUyZYAHeSRCwRChiWcHUONAr8v7rv5jMKJ/ppkAXsWTvXLtmXjoYNpCYtHSiR8ZGbPI9kzG0RvDeBxUelnkAUcmkTGjeaLGvQsn5xAEXMBV2hLYwXA== X-YMail-OSG: eHXpPEUVM1liB7lqOiSfj3.jVvxzeFAc_tvNUBrjWGx9XjA2beqnpDkn6lMP7Be JhaikJmPGDKL3cX6Ic3tU8dcJGrWo0oWwS75adBNobyFUVJ_5sVG4H3ubNF0t0xCzC10N9aqW4SQ GRjI90oZEbFyF7TBS0LFhL.sKR6UNXr9et52TvTv43dBB.HyeYC0zYxfPUJkOlEEtgYx9WO0wsRy Pb9psHvzu5ksdNzKSHxVXEiQQVFpm_sbadz5_lrYVYh5clNiB91qc6nPgXJzbER9NcMhEzcABN8j BHI7zGpTV.XLtcDcrVLpjMxwM5JBLM3oHbFzu8ZSwyDogxOf7mONfF4Ed0DSj3DaRIow08OBE69X 7Z7FYVQXg9xXafBAVUDrUsS_4esmKRnfy0aOI2RHQExdpEeMz3CpCyUWt1mhHTEHWXe506ME1ExB Kcwmc63ZnMKtH8mMqLiYRNsFZPOevIK6u3iU.haDPIkk11AabAQ1kftp1cSiBfgbKdHTGeeZMJ.K m8tL.6t3f8PolxucnU2X3LV07JiCr3moZonUgQ6wmjN.baapOPPdeLgQawdqVWk88R521exxSkuk oWvAWpgOOluNw5AI6QkrOaPn3ife_GSlYNFwv7MFfjxRc71tPT_0lmod2jMB_WLdFZGx5lI6Aygp NpofLTdvdK4bnKZJvQFVRtXIWsdZsw3uvEdzeuz0BXVo9_H.30H1V69ni0qn4mZtc6YxFkDuULXH apeUEzyTtBYv.ULiJS.pMlQ_EwdbL_ZJMXLVJENIiyoiu20THnugQrqfcdusylbmd.EaetzbFG0K _1R5MIMyWBBkJRPq9ONr.LA0gVi9ifUdpql7E9bBgrDXEzXOTIfcxij5Pw1DnciQ5DDq6HK.YFaF s6cmnP36uzTStOlXPS6RQZT5mv08lMjdd71KR6PgnAPQslupwnurTc_E66lJQzm9UidHUW_oMP0B w6rh0VMRLXaRp6TtoXc4YY7MZfMr11diy83N4uxZvhHVOfc.KFAR4dTE.UDoW3p.0Kk.EQBMO5yn WV25YeNHiaxtM8a93ZqYbUnEFm6tzqMi0ktGJnvX0Y.vWeFll1eEeRtpuYEaq26Cr_sovIV5vQ2C ZZuA_y20AtuEYy0VwRVS3MvXyDmXd0wJf0O5uayt9bolXSJft_CQmahErvBurhzf1Iz.FpsXrgk. ouoFsWcqotIIDgXorVwV3afmGpsALJ0yXpmrTiOAHttLDv3n1_oGAHZyJnPvVLQ_VWGIhlW.LgJh wG5h0Fx.RWOWbuvvhT2d4sloCRMkLmaO_jdWuws7DKDhKCVXr3Aswwgt9GVs6.PgVJjTTRrUcVtk 0oXpk6mVL8SO1Q8sHGTRBGZOvPO2.ZzpwZQMJf8N8Km95GWH5_JMr9K96CJ7DWCiW.ehUPIm7GIG WI0KVnVh6j0xeQp5WnrMS2CY6tgG7uG9xkaHcs7Jy4XGAabjMdlkkVA_ZfUHQCf54lCXfQ9n_J6M laWSGFG1iGZaQUax8vKZTiNW4oXdcmCJZjve9BWDxFy9lLDmBLsGD8XG3ZQE3WqkIdgNAP80Vq7J d7NlQpquO0Q6IHFA3kmaLmPPxqWESA0DtxldYw5ouYspvLPmgPtmdT0IbqBenRgQrjeLnAf_LVob ECL33Z06cmJWzjaG32oRSpd5d2SQmWyMGtt_p7yS1QLFfWNXAfGKihMu05J83npcyvhVlzNuesyU 2jlxv9S8d_bIVX8_9oFuDQRJ5vIxcOrnmMgqwg7lA9sZgfo1mOErv9gbj56Fw_jgZyKCGfVL7hRT p3mVaybDnQglCjhZAPZTxES339IjuUDLePf1SCbApOC71oCGLpuqAJSIrdBFKJXto24G.ehhQkK3 E8GiW36wvUZO2JDVlOfvVZRgecuv_M4eReapTdgDXeDXXn6OconKrzRktXJqUjnKBoEN.3h89UOI EGa.KdtCgLqqUp4TX.yF8Wne1FzEA7FvYOlmOW34biq6A7g09oA0fUU9tXJP6h7d.fceKbBi2M15 sAuhKiy51jxUN7Xi4INdhNNXJXfNr8utNYEVAdk55y9VvokxsAyce6OLFdrvweDXcjmzQWYDeC.Z 1slccrgAJw2MgwDHHWw7f6SBBq1kq6VyecQvWz5VIXcauTEhWdC5RPY1K20DUdvFDsI6zWveWbAH 7nfn9_OPr.AK8gdnYI2NSaFkjVSU39A2Ik9S1W7aFkRgtlQyGHef4Tf6Kjrv_vlgXoP0XaKFNx4R N3bVUuUmKQKHiQH.MsXnHFZLgrL7Me9AqJ5YxDWxiJD4yBwQnvG9mrEFPFW9kEJtwmc2HZBSUqFC e55e6 X-Sonic-MF: X-Sonic-ID: efe00c56-2419-4654-b400-68e214c311f3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 14 Aug 2023 01:21:59 +0000 Received: by hermes--production-bf1-865889d799-2bcr6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 371e047c8729859c717d64147d97104e; Mon, 14 Aug 2023 01:21:58 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: armv7 kyua runs via chroot on aarch64: zfs tests leave behind processes from timed out tests Date: Sun, 13 Aug 2023 18:21:46 -0700 References: To: Current FreeBSD , FreeBSD ARM List In-Reply-To: Message-Id: <6DBC3E10-29D9-4395-BD4F-65ACED87D821@yahoo.com> X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-3.45 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.948]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RPGpL5dKXz4j99 On Aug 3, 2023, at 00:19, Mark Millard wrote: > This is after the patch (leading whitespace might > not have been preserved in what you see): >=20 > # git -C /usr/main-src/ diff sys/dev/md/ > diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c > index a719dccb1955..365296ec4276 100644 > --- a/sys/dev/md/md.c > +++ b/sys/dev/md/md.c > @@ -147,8 +147,15 @@ struct md_ioctl32 { > int md_fwsectors; > uint32_t md_label; > int md_pad[MDNPAD]; > +#ifdef __aarch64__ > + uint32_t md_pad0; > +#endif > } __attribute__((__packed__)); > +#ifdef __aarch64__ > +CTASSERT((sizeof(struct md_ioctl32)) =3D=3D 440); > +#else > CTASSERT((sizeof(struct md_ioctl32)) =3D=3D 436); > +#endif >=20 > #define MDIOCATTACH_32 _IOC_NEWTYPE(MDIOCATTACH, struct = md_ioctl32) > #define MDIOCDETACH_32 _IOC_NEWTYPE(MDIOCDETACH, struct = md_ioctl32) >=20 >=20 > The kyua run is still in process, but at this point there is > the following accumulation from the zfs testing timouts: >=20 > # ps -alxdww > UID PID PPID C PRI NI VSZ RSS MWCHAN STAT TT TIME = COMMAND > . . . > 0 17491 1 6 20 0 36460 12324 - T - 0:24.71 |-- = fsync_integrity /testdir2316/testfile2316 > 0 17551 1 5 20 0 10600 7512 tx->tx_s D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 > 0 17739 1 7 20 0 10600 7308 zfs tear D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 > 0 17841 1 3 20 0 10600 7316 tx->tx_s D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 > 0 17860 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17888 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17907 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17928 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17955 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17976 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 17995 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18023 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18043 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18064 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18085 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18114 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18135 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18157 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18177 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18205 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18224 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18255 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18275 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18296 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18317 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18345 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18365 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18386 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18412 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18447 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18466 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18516 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18535 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 18632 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >=20 > Lots of these are from 300s timeouts but some are from 1200s or > 1800s or 3600s timeouts. >=20 > For reference: >=20 > = sys/cddl/zfs/tests/txg_integrity/txg_integrity_test:fsync_integrity_001_po= s -> broken: Test case body timed out [1800.053s] > = sys/cddl/zfs/tests/txg_integrity/txg_integrity_test:txg_integrity_001_pos = -> passed [63.702s] > sys/cddl/zfs/tests/userquota/userquota_test:groupspace_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.003s] > sys/cddl/zfs/tests/userquota/userquota_test:groupspace_002_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_002_pos -> = broken: Test case cleanup timed out [0.148s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_003_pos -> = broken: Test case cleanup timed out [0.151s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_004_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_005_neg -> = broken: Test case body timed out [300.021s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_006_pos -> = broken: Test case body timed out [300.080s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_007_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_008_pos -> = broken: Test case body timed out [300.034s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_009_pos -> = broken: Test case body timed out [300.143s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_010_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_011_pos -> = broken: Test case body timed out [300.003s] > sys/cddl/zfs/tests/userquota/userquota_test:userquota_012_neg -> = broken: Test case body timed out [300.019s] > sys/cddl/zfs/tests/userquota/userquota_test:userspace_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/userquota/userquota_test:userspace_002_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_001_pos -> = broken: Test case body timed out [300.052s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_002_pos -> = skipped: Required program 'labelit' not found in PATH [0.002s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_003_pos -> = broken: Test case body timed out [300.076s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_004_pos -> = broken: Test case body timed out [300.106s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_005_pos -> = skipped: Required program 'ff' not found in PATH [0.002s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_006_pos -> = broken: Test case body timed out [300.015s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_007_pos -> = broken: Test case body timed out [300.005s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_008_pos -> = skipped: Required program 'ncheck' not found in PATH [0.002s] > sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_009_pos -> = broken: Test case body timed out [300.051s] > sys/cddl/zfs/tests/write_dirs/write_dirs_test:write_dirs_001_pos -> = broken: Test case body timed out [1200.056s] > sys/cddl/zfs/tests/write_dirs/write_dirs_test:write_dirs_002_pos -> = broken: Test case body timed out [1200.046s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_001_neg -> = broken: Test case body timed out [3600.055s] >=20 >=20 > . . . In more recent testing after the committed md_ioctl32 fix, including the 14.0-ALPHA1 snapshot: A) I no longer get the [300.015s] or longer timeouts. B) I instead get "failed: Setup failed" in under 1 sec for those test cases. C) I no longer get any hung up processes being left behind. (C) is likely expected, given the (A) -> (B) change. It does not look like this report will ever progress to a bugzilla submittal, given what is observed in the 14.0-ALPHA1 snapshot. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Aug 14 05:03:19 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPMjp67Jqz4mMWn for ; Mon, 14 Aug 2023 05:03:26 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPMjp1Wv7z3NtB for ; Mon, 14 Aug 2023 05:03:26 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1691989404; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZOxD468em2RhjcHyXyqJGjCg32fsFFYTPeqlirQmSkg=; b=i/mcshBgsLGvJXKNOfn75OpBFcdoI3BAN2DlE/bASMb8ltf6og/Kg9cHzzDT0v6UWHQwIg U+QKkH8ws/DY1EL3gAKOOuwM0VFwNe+qYZnpoNiT01xp6CbgWKvX28mHDxE1hyU8eQjZ2q oAYhKkyCqB2/JIlDj55uS8QPlpo3X0g= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 488638da (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 14 Aug 2023 05:03:22 +0000 (UTC) Date: Mon, 14 Aug 2023 07:03:19 +0200 From: Emmanuel Vadot To: Mike Karels Cc: freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Message-Id: <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> In-Reply-To: References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RPMjp1Wv7z3NtB X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] On Sun, 13 Aug 2023 12:35:31 -0500 Mike Karels wrote: > On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: > > > On Sun, 13 Aug 2023 11:25:25 -0500 > > Mike Karels wrote: > > > >> On 13 Aug 2023, at 11:10, Mark Millard wrote: > >> > >>> On Aug 13, 2023, at 08:17, Warner Losh wrote: > >>> > >>>> Manu just updated Linux DTS in the tree. Maybe see if you revert that if the problem persists. > >>> > >>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no compatible > >>> > >>> is the fix that Manu has committed: > >>> > >>> QUOTE > >>> ofw_firmware: Only match if there is no compatible > >>> > >>> If there is a compatible string it likely means that the firmware needs > >>> a dedicated driver (like on RPI*). > >>> > >>> PR: 273087 > >>> Tested-by: Mark Millard > >>> Sponsored by: Beckhoff Automation GmbH & Co. KG > >>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver") > >>> END QUOTE > >> > >> Just for completeness: that change fixes the bcm2835_cpufreq0/powerd > >> problem and the gpioled0 problem, but not the clk_fixed2 problem > >> (clk_fixed4 on rpi4). Installing an msdos boot partition from the > >> 3 Aug image makes that problem disappear. > >> > >> Mike > > > > There is two fixed-clock in the DTB without clock-frequency property > > and with a status set to "disabled", this isn't conforming to the > > bindings > > (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/clock/fixed-clock.yaml) > > so we complain on this, this is normal. > > Would it be possible to detect the disabled status to prevent the errors > (I'm guessing not) or to suppress the repeats? 150 lines of errors seems > like a lot for an out-of-spec DTB entry, and makes it hard to ignore. > > Mike Detecting the disabled status makes no sense, a fixed clock cannot be disable, it's always present and running. But I think that if we check that clock-frenquency isn't present in the probe function, print a message and bail we will not attempt to attach the driver at each pass. That's the only clean solution that I can see without making dirty hacks for some non-conforming DTB. -- Emmanuel Vadot From nobody Mon Aug 14 05:30:25 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPNK11rSDz4mPDp for ; Mon, 14 Aug 2023 05:30:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPNJz5WRkz3QmQ for ; Mon, 14 Aug 2023 05:30:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=KmhHn2BA; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com; dmarc=pass (policy=none) header.from=bidouilliste.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1691991025; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jH9rArbvUVFk27wGY7VlpYJJpJJbXnSr7aelGwBbf5U=; b=KmhHn2BAZP77nM3gm1XUFztg43cTijEcF0x6ISowwsJg6k7ZTMS0oCxkUwnOLmXhvoM3uL ryivEbo3vPCqjsy2FFAbWtwUJVOeOZuO6/COG+t2gcr1nnb0tHR/YFu0SxdXHkq0UWE51Q HImggCg8lI3wPCVAJtLp4V6jqe4ovwU= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id a78f12e3 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 14 Aug 2023 05:30:25 +0000 (UTC) Date: Mon, 14 Aug 2023 07:30:25 +0200 From: Emmanuel Vadot To: Mike Karels , freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Message-Id: <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> In-Reply-To: <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.36 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.962]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; DKIM_TRACE(0.00)[bidouilliste.com:+]; MID_RHS_MATCH_FROM(0.00)[]; FREEFALL_USER(0.00)[manu]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RPNJz5WRkz3QmQ On Mon, 14 Aug 2023 07:03:19 +0200 Emmanuel Vadot wrote: > On Sun, 13 Aug 2023 12:35:31 -0500 > Mike Karels wrote: > > > On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: > > > > > On Sun, 13 Aug 2023 11:25:25 -0500 > > > Mike Karels wrote: > > > > > >> On 13 Aug 2023, at 11:10, Mark Millard wrote: > > >> > > >>> On Aug 13, 2023, at 08:17, Warner Losh wrote: > > >>> > > >>>> Manu just updated Linux DTS in the tree. Maybe see if you revert that if the problem persists. > > >>> > > >>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no compatible > > >>> > > >>> is the fix that Manu has committed: > > >>> > > >>> QUOTE > > >>> ofw_firmware: Only match if there is no compatible > > >>> > > >>> If there is a compatible string it likely means that the firmware needs > > >>> a dedicated driver (like on RPI*). > > >>> > > >>> PR: 273087 > > >>> Tested-by: Mark Millard > > >>> Sponsored by: Beckhoff Automation GmbH & Co. KG > > >>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver") > > >>> END QUOTE > > >> > > >> Just for completeness: that change fixes the bcm2835_cpufreq0/powerd > > >> problem and the gpioled0 problem, but not the clk_fixed2 problem > > >> (clk_fixed4 on rpi4). Installing an msdos boot partition from the > > >> 3 Aug image makes that problem disappear. > > >> > > >> Mike > > > > > > There is two fixed-clock in the DTB without clock-frequency property > > > and with a status set to "disabled", this isn't conforming to the > > > bindings > > > (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/clock/fixed-clock.yaml) > > > so we complain on this, this is normal. > > > > Would it be possible to detect the disabled status to prevent the errors > > (I'm guessing not) or to suppress the repeats? 150 lines of errors seems > > like a lot for an out-of-spec DTB entry, and makes it hard to ignore. > > > > Mike > > Detecting the disabled status makes no sense, a fixed clock cannot be > disable, it's always present and running. > But I think that if we check that clock-frenquency isn't present in > the probe function, print a message and bail we will not attempt to > attach the driver at each pass. > That's the only clean solution that I can see without making dirty > hacks for some non-conforming DTB. Something like this : https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-there-is-no-clock-frequency-.patch Please let me know if that works. Cheers, -- Emmanuel Vadot From nobody Mon Aug 14 06:05:13 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPP5F11vlz4mRms; Mon, 14 Aug 2023 06:05:21 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from HK2P15301CU002.outbound.protection.outlook.com (mail-eastasiaazon11020017.outbound.protection.outlook.com [52.101.128.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPP5C5jsdz3TFw; Mon, 14 Aug 2023 06:05:19 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=FJDCVMZn; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.17 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com; dmarc=pass (policy=reject) header.from=microsoft.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HJANdxe8mRiGCPoFWQ/alueQer8vh72EUbAMlkUNMtzCkmutyedf1LU1YK24bQjbgkfdBA90Mwb8RfOG9TkT99eu4OZrLn8zqWAnV/ILVScsNipGc8R9T4OgyasVHIQunlr1vQm6bJ5NpAjmgy2uW4iM1MeC7qgoluVre4lij9fBHwMJ1I03LFKTk/tG82DKRdz17Oqs1tMGN9Lo8l7bfz+3+nN0eY5C9H6KnsgggFqjGqbaoLoayRNHZxXYRDn3Fd7ZCQeYWzfD1kBJkoyFnREpcL5B9Pl6UhPRhYSt3RAeoJJFnYRDbsOKdaRSIHltxL6Y+4JXs9NfAhHPHwEYIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=++3CPHI0CYZwfvOumGRIyaFvd9H/DlfaKk7ih8oqTEY=; b=N90sdd5IUhUOUSdI7Jo3NjFag9DhRJHdccw3itu3QuHBfIMlcZNGCSVdl7LdbUGQVveXFlgu8qB9CXxmWFmOYjOHG3hXi6/lCtkvG596wQMKO5EK7nfhVGtbYQwsRLeX0amZJ+f+wITZOiQbqoLP68RfS8fCUYbL+3hPZSaKeyqNr2H5FdSAmGNpBgOFdt0hnoOpKVK5GDo/0GQcKdc9Kj3Ib9VJQ2Y0BSIC8Oa7LcrMnOAWh8tiztTNqguKorRp4PfUftgsAkcQsrb8+uKmsbqhfJsc6nGLXVQX1dPY1eQ2ZFpRc1aflH6DUOOOJ+Cv7tzp0PJojvIh4+z7fI3XZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=++3CPHI0CYZwfvOumGRIyaFvd9H/DlfaKk7ih8oqTEY=; b=FJDCVMZnSlx8DgkL2i0X5LKJu3y7/g03b0d00mosmPYNZFeyfk9pT+laQzniPCct++iGtp85/bNfZp4cQVl64oX3S6lNL8kmT8TcYb16uoOgtL5ATfloDp95wWyB8Zk7a1KSKHWj1hPTOVulRB56GlMsZRN7IU8aQ5STgyG/Ixs= Received: from PUZP153MB0788.APCP153.PROD.OUTLOOK.COM (2603:1096:301:fc::10) by TYZP153MB0737.APCP153.PROD.OUTLOOK.COM (2603:1096:400:261::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.9; Mon, 14 Aug 2023 06:05:13 +0000 Received: from PUZP153MB0788.APCP153.PROD.OUTLOOK.COM ([fe80::abe0:95e:5348:dd5a]) by PUZP153MB0788.APCP153.PROD.OUTLOOK.COM ([fe80::abe0:95e:5348:dd5a%4]) with mapi id 15.20.6699.008; Mon, 14 Aug 2023 06:05:13 +0000 From: Souradeep Chakrabarti To: "freebsd-arm@FreeBSD.org" , "freebsd-hackers@FreeBSD.org" , "freebsd-net@FreeBSD.org" CC: Wei Hu Subject: Panic in add_route while rebooting in Azure ARM64 bug 272666 Thread-Topic: Panic in add_route while rebooting in Azure ARM64 bug 272666 Thread-Index: AdnOdUjFmvmJxBuLSVGs5MdJ4NrR9Q== Date: Mon, 14 Aug 2023 06:05:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=761ba4b8-aeaf-4cda-8250-2a27f1120894;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2023-08-14T05:56:59Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PUZP153MB0788:EE_|TYZP153MB0737:EE_ x-ms-office365-filtering-correlation-id: fc1d94f7-ece9-4b35-a1d9-08db9c8c6c9f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jtchdVx/5uSEySy3ceswgnS8r4kkfWQ3ctgNcwLDuwlLKmj+KAE8MVBdUiNvFtt0dBn1nAqw+8W9S2bepSvp66EjBNcn+z9RB5bP4t4CXVOy/MyNvM75FBebODAn/Fp3fxsbq5sYypZQiY0YQZqjkGCTaOwCInS0CPE7qXZNak5SaU/J20xvXcjWb/keF5HwwwMn1UQv/yOuq82WOAHVwj5LpTDiXMCnlW8Vo19Qo/bPoX1Ruu4HLPBIjTfwe2adHk5ggbZ6037WF9i50D/gi23VBR03QPSsK80vc5q48MHEKcICpn4GaCnr/OPfHRzHIZ9hmB548+t/FGiBJ6Yv4dya3Qq485tU5R80qckNGuZTYNSJ1jZkgp+QcPGOPuPdl8ll3whDI9D/RsxunW8jOLX6RX8+n2G1zJuWIbCG6nSnlmOYkgqd10Xn26hfZWew/LAghVQMy23UgNzjHAxoSKD7OK3/xMzwAH9D3DLh9p5FgLWkQZmxeze5KFRID9nZH9oqk3uwMIaAVMFgrgGUOQ8p4i+/AYiqJt2GNsHhfAPsqcDYermJpwLsewgvk6URVfwv4uG3goneWIDqkKwjJFFkgcpjgRg+st5tS4ZpMVlKP93/dBka3rwaGLQQ1Kc00xbEM3hS0qoFj3CxReBgUl8vZpOWj7Pd1wJteolJWOjUkcV8GV1ReoO7TlPyXgMH x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PUZP153MB0788.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230028)(346002)(396003)(376002)(39860400002)(366004)(136003)(186006)(451199021)(1800799006)(12101799016)(966005)(9686003)(8936002)(86362001)(55016003)(33656002)(38070700005)(122000001)(82950400001)(82960400001)(38100700002)(26005)(6506007)(2906002)(10290500003)(83380400001)(71200400001)(7696005)(478600001)(450100002)(4326008)(41300700001)(107886003)(110136005)(8676002)(316002)(66446008)(66476007)(8990500004)(5660300002)(64756008)(66946007)(66556008)(76116006)(52536014);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?gNeLjKnBvnYy6zqrIZvF6CSWVPzvvZSeHMiy0Nj8noet5k6plKU86RFmMSKA?= =?us-ascii?Q?tuF9sfrqY0AgkdwvxpiOpMso28xSngeintVxY3cp1Pp83Mdh1Zf5uBO1/VxF?= =?us-ascii?Q?iKAv8Kt9wnWuSQzYXGAoJNBvF0UQ9cw+W1uHniFWWvNz13sVly/ZhhEt2SEN?= =?us-ascii?Q?AxOz5z6yw/4+I6TFsnms9FlizsGanuyxdeT3PhGN+sOqn3uHAeNIefCeAjtT?= =?us-ascii?Q?YB9U3ykRP5y1ifQmX+TrFfWDHZBkfpEoV3WlSVf56eLEYPHOVf6BHzlIsotL?= =?us-ascii?Q?rrDrItrpH/HhRO3gy3/K9VG5+r9jKMpeMiSSefctylU2eE6QTAaKxXU2qL42?= =?us-ascii?Q?qdV43lm6OPsMGKCFqa4Gb52rLeDYUHun1ySt21CsTKVGguS+DQAlEDOBCeZn?= =?us-ascii?Q?LGTvIMNn3KzneZAA6ghNesyXzestopSrNdX1zB+h3Ccnl3hEpc4lCzrTN7+S?= =?us-ascii?Q?FS2Y+dg/AIc+RYle2d904qrbS21reOmN9IStn1e95NHd3H+1tNB0ZW8+jp90?= =?us-ascii?Q?HyaysDdbPf7DDoz8VBk7siu9lCh0wYn4zGJM3cigu8KwAK5N9yFbn+HF7GQZ?= =?us-ascii?Q?xQ20nMyp9uq+4yWJ2rqMax+SX+h9ReEWXnDZlMBJbQcnZtZ39/gPaJ0vL+XD?= =?us-ascii?Q?AfotAFO+f631UIJPgk2EQwPA8haEd+Dkpppar+9btRtgnTdF+vX7LKy0Krvy?= =?us-ascii?Q?tz9sTF1tmc+5QYfFDj7WotDhPLbT6M77WK0LN4NRLzqECBm+iJ41kV0Q5IAy?= =?us-ascii?Q?vSatj4k6ObBtlnmmum8eZnKJ0Lf1tqqE9m+PDZBagwTw1NC6wlU08M2dk2+5?= =?us-ascii?Q?X0pifoNVspcH5cSPfAlo24HdSoLSBQ1iffTu9QQSkR1d/gWyE9h21k8XMdHv?= =?us-ascii?Q?uFlb85HAcq0GTUQrjpE1Xfz3HyZMHhrT69HHnbV9VOAI61HpCvfpIWqdVRgD?= =?us-ascii?Q?U7tvW6IlfEHeVyoHx1jj6u+vhNrdNrF4lUXyFfzKcvQEhRxzXv5dSrl1cUTB?= =?us-ascii?Q?5XRcza8nWCD/+BeLRonm+GAzy0TVwetzu3r58iV1kFMRBIvXdtJW6vYh9+VP?= =?us-ascii?Q?VeDFgD7BI9DcAzB1Ikx/Hfj1RvjIjxDbtgQXur9nJCzEMWvcxVFzmLuO7nfV?= =?us-ascii?Q?tbv4VGz10IaT5qU5EcPvde7401zS0Dg7bB6aJ85MqTKsGcvbw6eXQ+/C8atC?= =?us-ascii?Q?P6PGeQbIRc2laVP0AxvHIlkPJYrtKwDvBlUKTrwbckNCE5V2CUT1wFFRG9Kl?= =?us-ascii?Q?3eZEWWbySJLSguO7ZtWw0u0zy9AUIvm5ovDKFZEjjZGk/t+v2jS+KAw5Sn9W?= =?us-ascii?Q?ya4RtToXd/hD8YYRP1gGUhV6pnuI9TC7UZs+z+ZEk/naIeMLao1MWTOT8/Bc?= =?us-ascii?Q?Y18uXcE2XyIlGUFtFrg7kA8dCSAgEssjYHN1QJitU5AuLOdpgomGZWndJGHs?= =?us-ascii?Q?QSOqQdmTtklIAIZiEvA+cyIe7AwJRz2sQVzijeEXQG1ftIup/ulGnKvoXfCN?= =?us-ascii?Q?wN5Q5QlfeiftRFXO3Igs70kliyiMsznODTYC?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PUZP153MB0788.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: fc1d94f7-ece9-4b35-a1d9-08db9c8c6c9f X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2023 06:05:13.4726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KlJjWYIKjiGD3JQn8fUTiAgesJy0vIO6sKTdZLGKdq1iGlOnWtzLxbCv67tbSBgTHJtkJdrfccPoH2R43RWFQOBkWRqZTtoTdHy8GhitqkQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYZP153MB0737 X-Spamd-Result: default: False [-9.00 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[microsoft.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org,freebsd-hackers@freebsd.org,freebsd-net@FreeBSD.org]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.101.128.17:from]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[] X-Spamd-Bar: -------- X-Rspamd-Queue-Id: 4RPP5C5jsdz3TFw Hi, We are working on bringing FreeBSD on Azure ARM64. Now with recently releas= ed FreeBSD arm64 preview image in Azure, when doing reboot from serial console, FreeBSD is going into panic w= hile coming up. It is happening almost every 2nd, or=20 3rd attempt. The below is the panic. LF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/l= ib/compat/pkg /usr/local/lib/compat/pkg lo0: link state changed to UP Kernel page fault with the following non-sleepable locks held: exclusive rm rib head lock (rib head lock) r =3D 0 (0xffffa000012278e0) loc= ked @ /usr/src/sys/net/route/route_ctl.c:797 stack backtrace: #0 0xffff0000004d2af4 at witness_debugger+0x5c #1 0xffff0000004d3cf8 at witness_warn+0x400 #2 0xffff0000007f7310 at data_abort+0xa0 #3 0xffff0000007d3014 at handle_el1h_sync+0x14 x0: 0x0000000000000001 x1: 0x0000000000000100 x2: 0xffffa00001ae7000 x3: 0xffff00004031af40 ($d.2 + 0x3efee96f) x4: 0x0000000000000100 x5: 0x0000000000000000 x6: 0x000000000000003f x7: 0x0000000000000000 x8: 0xffff000132c76c40 x9: 0x0000000000000000 x10: 0x0000000000000008 x11: 0x0000000000000000 x12: 0x000000000000003e x13: 0xffffa00001ae70fc x14: 0x0000000000000000 x15: 0x0000000000000001 x16: 0x0000000000010000 x17: 0x0000000000000005 x18: 0xffff00012d2f7e60 x19: 0xffff00012d2f8080 x20: 0xffffa00001227800 x21: 0x0000000000000000 x22: 0xdeadc0dedeadc0de x23: 0xffffa000012278e0 x24: 0xffffa00001227800 x25: 0xffffa0000c93ba00 x26: 0xffff000000960582 (digits + 0x12fbf) x27: 0xffffa0000c9338f0 x28: 0x0000000000000000 x29: 0xffff00012d2f7e60 sp: 0xffff00012d2f7e60 lr: 0xffff0000005bf63c (rib_notify + 0x50) elr: 0xffffa0000c93bb00 spsr: 0x0000000060400045 far: 0xffffa0000c93bb00 esr: 0x000000008600000e panic: data abort in critical section or under mutex cpuid =3D 3 time =3D 1690047394 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x13c panic() at panic+0x44 data_abort() at data_abort+0x30c handle_el1h_sync() at handle_el1h_sync+0x14 --- exception, esr 0x8600000e (null)() at 0xffffa0000c93bb00 add_route() at add_route+0xc4 add_route_flags() at add_route_flags+0x1b0 rib_add_route() at rib_add_route+0x324 ifa_maintain_loopback_route() at ifa_maintain_loopback_route+0xf4 in6_update_ifa() at in6_update_ifa+0x994 in6_ifattach() at in6_ifattach+0x1bc in6_if_up() at in6_if_up+0x90 if_up() at if_up+0xd8 ifhwioctl() at ifhwioctl+0xb7c ifioctl() at ifioctl+0x860 kern_ioctl() at kern_ioctl+0x2dc sys_ioctl() at sys_ioctl+0x118 do_el0_sync() at do_el0_sync+0x520 handle_el0_sync() at handle_el0_sync+0x44 --- exception, esr 0x56000000 It is happening for loopback interface IPv6 address.=20 A bug has been opened for the same https://bugs.freebsd.org/bugzilla/show_b= ug.cgi?id=3D272666 Can someone please help me here, to debug this issue. This is a blocker for FreeBSD on Azure ARM64. Thanks Souradeep=20 From nobody Mon Aug 14 14:51:27 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPcmN0Kxhz4qbVP for ; Mon, 14 Aug 2023 14:51:32 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPcmM5R8tz3Pkc for ; Mon, 14 Aug 2023 14:51:31 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 37EEpSd1045761; Mon, 14 Aug 2023 09:51:28 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1692024688; bh=fBS/je6eL/+ZHASXhOtXMiRVaTP3wILvmC0G8S4g+wE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=HtDl25Fm9rAVbMNK3NyiPL9OOMX3mBv+17SkXmMsSE9oBmOQZdWkalZmz3+kdxi00 aqPalzHrLfCd7cXcg5jrwyDrcv2cra0iNha87AkMu8sxjnhmuOYRV842uI3ezRRzli kHdSUfircpxlbqjbWARcMVFMcoWS51i/fiFOypKUCZ4IXokTaSHGt2YuHFgA2Ad6fp MP2kQi3AiNbov9zT+bSrL+9Rr7xDamTlqL0a/7Jxilw/IQRZNm3HEK0Z8w8f/e0sH/ CIw0pY87qAHVeSf3mi2F+hWWbagrdcQN28bIlM0QP9RnFbIS3vAoLZkajOpc37tF74 5hlurREwj5hJA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id RsKGCXA/2mS/sgAAs/W3XQ (envelope-from ); Mon, 14 Aug 2023 09:51:28 -0500 From: Mike Karels To: Emmanuel Vadot Cc: freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Date: Mon, 14 Aug 2023 09:51:27 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> In-Reply-To: <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RPcmM5R8tz3Pkc X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: > On Mon, 14 Aug 2023 07:03:19 +0200 > Emmanuel Vadot wrote: > >> On Sun, 13 Aug 2023 12:35:31 -0500 >> Mike Karels wrote: >> >>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: >>> >>>> On Sun, 13 Aug 2023 11:25:25 -0500 >>>> Mike Karels wrote: >>>> >>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: >>>>> >>>>>> On Aug 13, 2023, at 08:17, Warner Losh wrote: >>>>>> >>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you revert = that if the problem persists. >>>>>> >>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no= compatible >>>>>> >>>>>> is the fix that Manu has committed: >>>>>> >>>>>> QUOTE >>>>>> ofw_firmware: Only match if there is no compatible >>>>>> >>>>>> If there is a compatible string it likely means that the firmw= are needs >>>>>> a dedicated driver (like on RPI*). >>>>>> >>>>>> PR: 273087 >>>>>> Tested-by: Mark Millard >>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG >>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver"= ) >>>>>> END QUOTE >>>>> >>>>> Just for completeness: that change fixes the bcm2835_cpufreq0/power= d >>>>> problem and the gpioled0 problem, but not the clk_fixed2 problem >>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition from the >>>>> 3 Aug image makes that problem disappear. >>>>> >>>>> Mike >>>> >>>> There is two fixed-clock in the DTB without clock-frequency propert= y >>>> and with a status set to "disabled", this isn't conforming to the >>>> bindings >>>> (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/= clock/fixed-clock.yaml) >>>> so we complain on this, this is normal. >>> >>> Would it be possible to detect the disabled status to prevent the err= ors >>> (I'm guessing not) or to suppress the repeats? 150 lines of errors s= eems >>> like a lot for an out-of-spec DTB entry, and makes it hard to ignore.= >>> >>> Mike >> >> Detecting the disabled status makes no sense, a fixed clock cannot be= >> disable, it's always present and running. >> But I think that if we check that clock-frenquency isn't present in >> the probe function, print a message and bail we will not attempt to >> attach the driver at each pass. >> That's the only clean solution that I can see without making dirty >> hacks for some non-conforming DTB. > > Something like this : > https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-there-is-= no-clock-frequency-.patch > > Please let me know if that works. Not exactly. This results in: clk_fixed4: clock-fixed have no clock-frequency but this appears 1562 times. btw, "have" should be "has". I hadn't noticed them before, but there are a lock order reversal and a malloc while holding a non-sleepable lock, associated with the gpio fix: gpioled0: on ofwbus0 lock order reversal: (sleepable after non-sleepable) 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ /usr/src/sys/dev= /led/led.c:298 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi firmware= gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252 lock order LED mtx -> Raspberry Pi firmware gpio attempted at: #0 0xffff0000004d3984 at witness_checkorder+0xa98 #1 0xffff00000046ecb4 at _sx_xlock+0x7c #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 #3 0xffff0000001c7400 at led_create_state+0x158 #4 0xffff0000001910d4 at gpioled_attach+0x290 #5 0xffff00000049efa4 at device_attach+0x3f8 #6 0xffff00000049eb14 at device_probe_and_attach+0x7c #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac #10 0xffff00000049bd30 at bus_set_pass+0x4c #11 0xffff0000003ea3bc at mi_startup+0x1fc #12 0xffff0000000008ac at virtdone+0x70 uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks= held: exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) lock= ed @ /usr/src/sys/dev/led/led.c:298 stack backtrace: #0 0xffff0000004d3dc8 at witness_debugger+0x5c #1 0xffff0000004d4fcc at witness_warn+0x400 #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 #3 0xffff000000782c20 at uma_zalloc_arg+0x2c #4 0xffff000000437abc at malloc+0x8c #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 #7 0xffff0000001c7400 at led_create_state+0x158 #8 0xffff0000001910d4 at gpioled_attach+0x290 #9 0xffff00000049efa4 at device_attach+0x3f8 #10 0xffff00000049eb14 at device_probe_and_attach+0x7c #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac #14 0xffff00000049bd30 at bus_set_pass+0x4c #15 0xffff0000003ea3bc at mi_startup+0x1fc #16 0xffff0000000008ac at virtdone+0x70 uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks= held: exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) lock= ed @ /usr/src/sys/dev/led/led.c:298 stack backtrace: #0 0xffff0000004d3dc8 at witness_debugger+0x5c #1 0xffff0000004d4fcc at witness_warn+0x400 #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 #3 0xffff000000782c20 at uma_zalloc_arg+0x2c #4 0xffff000000437abc at malloc+0x8c #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 #9 0xffff0000001c7400 at led_create_state+0x158 #10 0xffff0000001910d4 at gpioled_attach+0x290 #11 0xffff00000049efa4 at device_attach+0x3f8 #12 0xffff00000049eb14 at device_probe_and_attach+0x7c #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac #16 0xffff00000049bd30 at bus_set_pass+0x4c #17 0xffff0000003ea3bc at mi_startup+0x1fc uma_zalloc_debug: zone "malloc-128" with the following non-sleepable lock= s held: exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) lock= ed @ /usr/src/sys/dev/led/led.c:298 stack backtrace: #0 0xffff0000004d3dc8 at witness_debugger+0x5c #1 0xffff0000004d4fcc at witness_warn+0x400 #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 #3 0xffff000000782c20 at uma_zalloc_arg+0x2c #4 0xffff000000437abc at malloc+0x8c #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 #9 0xffff0000001c7400 at led_create_state+0x158 #10 0xffff0000001910d4 at gpioled_attach+0x290 #11 0xffff00000049efa4 at device_attach+0x3f8 #12 0xffff00000049eb14 at device_probe_and_attach+0x7c #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac #16 0xffff00000049bd30 at bus_set_pass+0x4c #17 0xffff0000003ea3bc at mi_startup+0x1fc Mike From nobody Mon Aug 14 15:07:41 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPd76078Rz4qc41 for ; Mon, 14 Aug 2023 15:07:46 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPd753pSmz3Qm1 for ; Mon, 14 Aug 2023 15:07:45 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1692025662; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gqV069R/LhKI0Pl9szovbsmljYvKNZulWhjdVeUQIuA=; b=Lll1cDCHvacJ3+tDk+baLwqpB3qt8suPcT+tJbvKDv/abths/uqAnRbIwM7PBIcwMXYt59 Ajc0IRLSkEsNqbAY7XfmRCrZxt6sd9Hu6g/HeEnbHOC5sSk7HbBuSR4HuhrGIAPGknLhwC 05kyrmElv8B5aPuYLxtmwm6Pncuyip0= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 7635cc31 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 14 Aug 2023 15:07:42 +0000 (UTC) Date: Mon, 14 Aug 2023 17:07:41 +0200 From: Emmanuel Vadot To: Mike Karels Cc: freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Message-Id: <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> In-Reply-To: <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RPd753pSmz3Qm1 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] On Mon, 14 Aug 2023 09:51:27 -0500 Mike Karels wrote: > On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: > > > On Mon, 14 Aug 2023 07:03:19 +0200 > > Emmanuel Vadot wrote: > > > >> On Sun, 13 Aug 2023 12:35:31 -0500 > >> Mike Karels wrote: > >> > >>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: > >>> > >>>> On Sun, 13 Aug 2023 11:25:25 -0500 > >>>> Mike Karels wrote: > >>>> > >>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: > >>>>> > >>>>>> On Aug 13, 2023, at 08:17, Warner Losh wrote: > >>>>>> > >>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you revert that if the problem persists. > >>>>>> > >>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no compatible > >>>>>> > >>>>>> is the fix that Manu has committed: > >>>>>> > >>>>>> QUOTE > >>>>>> ofw_firmware: Only match if there is no compatible > >>>>>> > >>>>>> If there is a compatible string it likely means that the firmware needs > >>>>>> a dedicated driver (like on RPI*). > >>>>>> > >>>>>> PR: 273087 > >>>>>> Tested-by: Mark Millard > >>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG > >>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver") > >>>>>> END QUOTE > >>>>> > >>>>> Just for completeness: that change fixes the bcm2835_cpufreq0/powerd > >>>>> problem and the gpioled0 problem, but not the clk_fixed2 problem > >>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition from the > >>>>> 3 Aug image makes that problem disappear. > >>>>> > >>>>> Mike > >>>> > >>>> There is two fixed-clock in the DTB without clock-frequency property > >>>> and with a status set to "disabled", this isn't conforming to the > >>>> bindings > >>>> (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/clock/fixed-clock.yaml) > >>>> so we complain on this, this is normal. > >>> > >>> Would it be possible to detect the disabled status to prevent the errors > >>> (I'm guessing not) or to suppress the repeats? 150 lines of errors seems > >>> like a lot for an out-of-spec DTB entry, and makes it hard to ignore. > >>> > >>> Mike > >> > >> Detecting the disabled status makes no sense, a fixed clock cannot be > >> disable, it's always present and running. > >> But I think that if we check that clock-frenquency isn't present in > >> the probe function, print a message and bail we will not attempt to > >> attach the driver at each pass. > >> That's the only clean solution that I can see without making dirty > >> hacks for some non-conforming DTB. > > > > Something like this : > > https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-there-is-no-clock-frequency-.patch > > > > Please let me know if that works. > > Not exactly. This results in: > > clk_fixed4: clock-fixed have no clock-frequency > > but this appears 1562 times. btw, "have" should be "has". Then I don't know how to fix this properly. > I hadn't noticed them before, but there are a lock order reversal > and a malloc while holding a non-sleepable lock, associated with > the gpio fix: Are you sure that they are new ? > gpioled0: on ofwbus0 > lock order reversal: (sleepable after non-sleepable) > 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ /usr/src/sys/dev/led/led.c:298 > 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi firmware gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252 > lock order LED mtx -> Raspberry Pi firmware gpio attempted at: > #0 0xffff0000004d3984 at witness_checkorder+0xa98 > #1 0xffff00000046ecb4 at _sx_xlock+0x7c > #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 > #3 0xffff0000001c7400 at led_create_state+0x158 > #4 0xffff0000001910d4 at gpioled_attach+0x290 > #5 0xffff00000049efa4 at device_attach+0x3f8 > #6 0xffff00000049eb14 at device_probe_and_attach+0x7c > #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #10 0xffff00000049bd30 at bus_set_pass+0x4c > #11 0xffff0000003ea3bc at mi_startup+0x1fc > #12 0xffff0000000008ac at virtdone+0x70 > uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held: > exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 > stack backtrace: > #0 0xffff0000004d3dc8 at witness_debugger+0x5c > #1 0xffff0000004d4fcc at witness_warn+0x400 > #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > #4 0xffff000000437abc at malloc+0x8c > #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 > #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > #7 0xffff0000001c7400 at led_create_state+0x158 > #8 0xffff0000001910d4 at gpioled_attach+0x290 > #9 0xffff00000049efa4 at device_attach+0x3f8 > #10 0xffff00000049eb14 at device_probe_and_attach+0x7c > #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #14 0xffff00000049bd30 at bus_set_pass+0x4c > #15 0xffff0000003ea3bc at mi_startup+0x1fc > #16 0xffff0000000008ac at virtdone+0x70 > uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks held: > exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 > stack backtrace: > #0 0xffff0000004d3dc8 at witness_debugger+0x5c > #1 0xffff0000004d4fcc at witness_warn+0x400 > #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > #4 0xffff000000437abc at malloc+0x8c > #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 > #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc > #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 > #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > #9 0xffff0000001c7400 at led_create_state+0x158 > #10 0xffff0000001910d4 at gpioled_attach+0x290 > #11 0xffff00000049efa4 at device_attach+0x3f8 > #12 0xffff00000049eb14 at device_probe_and_attach+0x7c > #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #16 0xffff00000049bd30 at bus_set_pass+0x4c > #17 0xffff0000003ea3bc at mi_startup+0x1fc > uma_zalloc_debug: zone "malloc-128" with the following non-sleepable locks held: > exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 > stack backtrace: > #0 0xffff0000004d3dc8 at witness_debugger+0x5c > #1 0xffff0000004d4fcc at witness_warn+0x400 > #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > #4 0xffff000000437abc at malloc+0x8c > #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 > #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc > #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 > #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > #9 0xffff0000001c7400 at led_create_state+0x158 > #10 0xffff0000001910d4 at gpioled_attach+0x290 > #11 0xffff00000049efa4 at device_attach+0x3f8 > #12 0xffff00000049eb14 at device_probe_and_attach+0x7c > #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #16 0xffff00000049bd30 at bus_set_pass+0x4c > #17 0xffff0000003ea3bc at mi_startup+0x1fc > > Mike > -- Emmanuel Vadot From nobody Mon Aug 14 15:44:05 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPdx550qyz4qfSW for ; Mon, 14 Aug 2023 15:44:09 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPdx54T79z3TKq for ; Mon, 14 Aug 2023 15:44:09 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 37EFi64o046068; Mon, 14 Aug 2023 10:44:07 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1692027847; bh=8AwGlYKDEgN6d7UAwOAkkKdFrpW5hGsKRswPM0a59NE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=JeEuoDQaZXweBW54DAOGj0M1wUeQ7h09JzaXOU/DIZgWH/zIcV1N6TNYsWliNVmZX wtwLZAZ0TSUVCXS3dd9czXYExxNDMlS4H7USiPH9pn+tbulSgDxCQ/8ty/usBR1bSo WXjpxst0E4tTASqtuDZTe/Xa0Lv6YjlGqrEopcNxJVPx9Dl+Bb9v9U86CK9bm34oXe jpZAZj8OKHZQtjuQVfukX4jIbhvxsrT/28uU5v4QKE6Pxt0NbhQWXCM55mFHrja2Dr chtNIFH9sRH0H7CmaVDeVhQXlhIAYhXhFT8+i2HSpgXJFUXcRhHSzBiBaJsVNYr7zJ /0rjZHTVUWuKg== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id UgILK8ZL2mTyswAAs/W3XQ (envelope-from ); Mon, 14 Aug 2023 10:44:06 -0500 From: Mike Karels To: Emmanuel Vadot Cc: freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Date: Mon, 14 Aug 2023 10:44:05 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: In-Reply-To: <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RPdx54T79z3TKq X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 14 Aug 2023, at 10:07, Emmanuel Vadot wrote: > On Mon, 14 Aug 2023 09:51:27 -0500 > Mike Karels wrote: > >> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: >> >>> On Mon, 14 Aug 2023 07:03:19 +0200 >>> Emmanuel Vadot wrote: >>> >>>> On Sun, 13 Aug 2023 12:35:31 -0500 >>>> Mike Karels wrote: >>>> >>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: >>>>> >>>>>> On Sun, 13 Aug 2023 11:25:25 -0500 >>>>>> Mike Karels wrote: >>>>>> >>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: >>>>>>> >>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh wrote: >>>>>>>> >>>>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you rever= t that if the problem persists. >>>>>>>> >>>>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is = no compatible >>>>>>>> >>>>>>>> is the fix that Manu has committed: >>>>>>>> >>>>>>>> QUOTE >>>>>>>> ofw_firmware: Only match if there is no compatible >>>>>>>> >>>>>>>> If there is a compatible string it likely means that the fir= mware needs >>>>>>>> a dedicated driver (like on RPI*). >>>>>>>> >>>>>>>> PR: 273087 >>>>>>>> Tested-by: Mark Millard >>>>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG >>>>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware drive= r") >>>>>>>> END QUOTE >>>>>>> >>>>>>> Just for completeness: that change fixes the bcm2835_cpufreq0/pow= erd >>>>>>> problem and the gpioled0 problem, but not the clk_fixed2 problem >>>>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition from th= e >>>>>>> 3 Aug image makes that problem disappear. >>>>>>> >>>>>>> Mike >>>>>> >>>>>> There is two fixed-clock in the DTB without clock-frequency prope= rty >>>>>> and with a status set to "disabled", this isn't conforming to the >>>>>> bindings >>>>>> (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Binding= s/clock/fixed-clock.yaml) >>>>>> so we complain on this, this is normal. >>>>> >>>>> Would it be possible to detect the disabled status to prevent the e= rrors >>>>> (I'm guessing not) or to suppress the repeats? 150 lines of errors= seems >>>>> like a lot for an out-of-spec DTB entry, and makes it hard to ignor= e. >>>>> >>>>> Mike >>>> >>>> Detecting the disabled status makes no sense, a fixed clock cannot = be >>>> disable, it's always present and running. >>>> But I think that if we check that clock-frenquency isn't present in= >>>> the probe function, print a message and bail we will not attempt to >>>> attach the driver at each pass. >>>> That's the only clean solution that I can see without making dirty >>>> hacks for some non-conforming DTB. >>> >>> Something like this : >>> https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-there-i= s-no-clock-frequency-.patch >>> >>> Please let me know if that works. >> >> Not exactly. This results in: >> >> clk_fixed4: clock-fixed have no clock-frequency >> >> but this appears 1562 times. btw, "have" should be "has". > > Then I don't know how to fix this properly. Too bad. The new message is much more obvious, but that's a lot of spam. >> I hadn't noticed them before, but there are a lock order reversal >> and a malloc while holding a non-sleepable lock, associated with >> the gpio fix: > > Are you sure that they are new ? They were not in ALPHA1, where gpioled0 did not configure. They happen once that problem was fixed, and before this patch. I don't remember if they happened in the 3 Aug snapshot; I can test that if it helps. I would have noticed if I was watching, but I don't always connect to the serial console or check dmesg.boot. Mike >> gpioled0: on ofwbus0 >> lock order reversal: (sleepable after non-sleepable) >> 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ /usr/src/sys/= dev/led/led.c:298 >> 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi firmw= are gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252 >> lock order LED mtx -> Raspberry Pi firmware gpio attempted at: >> #0 0xffff0000004d3984 at witness_checkorder+0xa98 >> #1 0xffff00000046ecb4 at _sx_xlock+0x7c >> #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 >> #3 0xffff0000001c7400 at led_create_state+0x158 >> #4 0xffff0000001910d4 at gpioled_attach+0x290 >> #5 0xffff00000049efa4 at device_attach+0x3f8 >> #6 0xffff00000049eb14 at device_probe_and_attach+0x7c >> #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >> #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #10 0xffff00000049bd30 at bus_set_pass+0x4c >> #11 0xffff0000003ea3bc at mi_startup+0x1fc >> #12 0xffff0000000008ac at virtdone+0x70 >> uma_zalloc_debug: zone "malloc-64" with the following non-sleepable lo= cks held: >> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) l= ocked @ /usr/src/sys/dev/led/led.c:298 >> stack backtrace: >> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >> #1 0xffff0000004d4fcc at witness_warn+0x400 >> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >> #4 0xffff000000437abc at malloc+0x8c >> #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 >> #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >> #7 0xffff0000001c7400 at led_create_state+0x158 >> #8 0xffff0000001910d4 at gpioled_attach+0x290 >> #9 0xffff00000049efa4 at device_attach+0x3f8 >> #10 0xffff00000049eb14 at device_probe_and_attach+0x7c >> #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >> #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #14 0xffff00000049bd30 at bus_set_pass+0x4c >> #15 0xffff0000003ea3bc at mi_startup+0x1fc >> #16 0xffff0000000008ac at virtdone+0x70 >> uma_zalloc_debug: zone "malloc-16" with the following non-sleepable lo= cks held: >> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) l= ocked @ /usr/src/sys/dev/led/led.c:298 >> stack backtrace: >> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >> #1 0xffff0000004d4fcc at witness_warn+0x400 >> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >> #4 0xffff000000437abc at malloc+0x8c >> #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 >> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >> #9 0xffff0000001c7400 at led_create_state+0x158 >> #10 0xffff0000001910d4 at gpioled_attach+0x290 >> #11 0xffff00000049efa4 at device_attach+0x3f8 >> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #16 0xffff00000049bd30 at bus_set_pass+0x4c >> #17 0xffff0000003ea3bc at mi_startup+0x1fc >> uma_zalloc_debug: zone "malloc-128" with the following non-sleepable l= ocks held: >> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) l= ocked @ /usr/src/sys/dev/led/led.c:298 >> stack backtrace: >> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >> #1 0xffff0000004d4fcc at witness_warn+0x400 >> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >> #4 0xffff000000437abc at malloc+0x8c >> #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 >> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >> #9 0xffff0000001c7400 at led_create_state+0x158 >> #10 0xffff0000001910d4 at gpioled_attach+0x290 >> #11 0xffff00000049efa4 at device_attach+0x3f8 >> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #16 0xffff00000049bd30 at bus_set_pass+0x4c >> #17 0xffff0000003ea3bc at mi_startup+0x1fc >> >> Mike >> > > > -- = > Emmanuel Vadot From nobody Mon Aug 14 15:44:48 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPdy10l0jz4qfW2 for ; Mon, 14 Aug 2023 15:44:57 +0000 (UTC) (envelope-from titus@edc.ro) Received: from eatlas.ro (eatlas.ro [86.126.82.18]) (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 (2048 bits) client-digest SHA256) (Client CN "eatlas.ro", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPdy03Hzzz3TMh for ; Mon, 14 Aug 2023 15:44:56 +0000 (UTC) (envelope-from titus@edc.ro) Authentication-Results: mx1.freebsd.org; none Received: from mail.edc.ro ([10.1.4.58]) by eatlas.ro (8.16.1/8.16.1) with ESMTPS id 37EFiniO050546 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 14 Aug 2023 18:44:49 +0300 (EEST) (envelope-from titus@edc.ro) Received: from tituss-imac.eatlas.local (eatlas.ro [86.126.82.18]) (authenticated bits=0) by mail.edc.ro (8.16.1/8.16.1) with ESMTPSA id 37EFilAG029644 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Aug 2023 18:44:47 +0300 (EEST) (envelope-from titus@edc.ro) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=edc.ro; s=mail; t=1692027887; bh=JrGXdvSXsu9RHkdbSj0oEoFKccw3kR8zvgRuXwPRXKk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=JRIvADINk9qqISQ5T1d0WmNoJWa1JoWMmOjVngFGF0s/PhtvFGQJ5pXkDjO6NfBj+ dmkAYBdwPxu/rI9T/WBRz8jsNW1hju7loljxVeO2m9W/0OiLin4TiZCAMKl+OBQ0vu jMa7fJGQ/5fsrKzGsO1hZE6QJ87YJYg9ovGhjhVw= From: titus Message-Id: <2DF7EF89-DC3F-44D4-8708-51CB4B6C8EC4@edc.ro> Content-Type: multipart/alternative; boundary="Apple-Mail=_EBAE471D-B1EE-4BAC-916D-FA8AE81C5499" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Date: Mon, 14 Aug 2023 18:44:48 +0300 In-Reply-To: <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> Cc: Mike Karels , freebsd-arm To: Emmanuel Vadot References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ns.edc.ro X-Rspamd-Queue-Id: 4RPdy03Hzzz3TMh X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8708, ipnet:86.120.0.0/13, country:RO] --Apple-Mail=_EBAE471D-B1EE-4BAC-916D-FA8AE81C5499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii + if (OF_hasprop(ofw_bus_get_node(dev), "clock-frequency") =3D=3D = 0) { + device_printf(dev, "clock-fixed have no = clock-frequency\n"); + return (ENXIO); + } this runs before compat_data is checked so will print it for any device = clock or not > On Aug 14, 2023, at 6:07 PM, Emmanuel Vadot = wrote: >=20 > On Mon, 14 Aug 2023 09:51:27 -0500 > Mike Karels wrote: >=20 >> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: >>=20 >>> On Mon, 14 Aug 2023 07:03:19 +0200 >>> Emmanuel Vadot wrote: >>>=20 >>>> On Sun, 13 Aug 2023 12:35:31 -0500 >>>> Mike Karels wrote: >>>>=20 >>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: >>>>>=20 >>>>>> On Sun, 13 Aug 2023 11:25:25 -0500 >>>>>> Mike Karels wrote: >>>>>>=20 >>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: >>>>>>>=20 >>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh wrote: >>>>>>>>=20 >>>>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you = revert that if the problem persists. >>>>>>>>=20 >>>>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is = no compatible >>>>>>>>=20 >>>>>>>> is the fix that Manu has committed: >>>>>>>>=20 >>>>>>>> QUOTE >>>>>>>> ofw_firmware: Only match if there is no compatible >>>>>>>>=20 >>>>>>>> If there is a compatible string it likely means that the = firmware needs >>>>>>>> a dedicated driver (like on RPI*). >>>>>>>>=20 >>>>>>>> PR: 273087 >>>>>>>> Tested-by: Mark Millard >>>>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG >>>>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware = driver") >>>>>>>> END QUOTE >>>>>>>=20 >>>>>>> Just for completeness: that change fixes the = bcm2835_cpufreq0/powerd >>>>>>> problem and the gpioled0 problem, but not the clk_fixed2 problem >>>>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition from = the >>>>>>> 3 Aug image makes that problem disappear. >>>>>>>=20 >>>>>>> Mike >>>>>>=20 >>>>>> There is two fixed-clock in the DTB without clock-frequency = property >>>>>> and with a status set to "disabled", this isn't conforming to the >>>>>> bindings >>>>>> = (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/clock/= fixed-clock.yaml) >>>>>> so we complain on this, this is normal. >>>>>=20 >>>>> Would it be possible to detect the disabled status to prevent the = errors >>>>> (I'm guessing not) or to suppress the repeats? 150 lines of = errors seems >>>>> like a lot for an out-of-spec DTB entry, and makes it hard to = ignore. >>>>>=20 >>>>> Mike >>>>=20 >>>> Detecting the disabled status makes no sense, a fixed clock cannot = be >>>> disable, it's always present and running. >>>> But I think that if we check that clock-frenquency isn't present in >>>> the probe function, print a message and bail we will not attempt to >>>> attach the driver at each pass. >>>> That's the only clean solution that I can see without making dirty >>>> hacks for some non-conforming DTB. >>>=20 >>> Something like this : >>> = https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-there-is-no-= clock-frequency-.patch >>>=20 >>> Please let me know if that works. >>=20 >> Not exactly. This results in: >>=20 >> clk_fixed4: clock-fixed have no clock-frequency >>=20 >> but this appears 1562 times. btw, "have" should be "has". >=20 > Then I don't know how to fix this properly. >=20 >> I hadn't noticed them before, but there are a lock order reversal >> and a malloc while holding a non-sleepable lock, associated with >> the gpio fix: >=20 > Are you sure that they are new ? >=20 >> gpioled0: on ofwbus0 >> lock order reversal: (sleepable after non-sleepable) >> 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ = /usr/src/sys/dev/led/led.c:298 >> 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi = firmware gpio, sx) @ = /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252 >> lock order LED mtx -> Raspberry Pi firmware gpio attempted at: >> #0 0xffff0000004d3984 at witness_checkorder+0xa98 >> #1 0xffff00000046ecb4 at _sx_xlock+0x7c >> #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 >> #3 0xffff0000001c7400 at led_create_state+0x158 >> #4 0xffff0000001910d4 at gpioled_attach+0x290 >> #5 0xffff00000049efa4 at device_attach+0x3f8 >> #6 0xffff00000049eb14 at device_probe_and_attach+0x7c >> #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >> #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #10 0xffff00000049bd30 at bus_set_pass+0x4c >> #11 0xffff0000003ea3bc at mi_startup+0x1fc >> #12 0xffff0000000008ac at virtdone+0x70 >> uma_zalloc_debug: zone "malloc-64" with the following non-sleepable = locks held: >> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) = locked @ /usr/src/sys/dev/led/led.c:298 >> stack backtrace: >> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >> #1 0xffff0000004d4fcc at witness_warn+0x400 >> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >> #4 0xffff000000437abc at malloc+0x8c >> #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 >> #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >> #7 0xffff0000001c7400 at led_create_state+0x158 >> #8 0xffff0000001910d4 at gpioled_attach+0x290 >> #9 0xffff00000049efa4 at device_attach+0x3f8 >> #10 0xffff00000049eb14 at device_probe_and_attach+0x7c >> #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >> #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #14 0xffff00000049bd30 at bus_set_pass+0x4c >> #15 0xffff0000003ea3bc at mi_startup+0x1fc >> #16 0xffff0000000008ac at virtdone+0x70 >> uma_zalloc_debug: zone "malloc-16" with the following non-sleepable = locks held: >> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) = locked @ /usr/src/sys/dev/led/led.c:298 >> stack backtrace: >> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >> #1 0xffff0000004d4fcc at witness_warn+0x400 >> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >> #4 0xffff000000437abc at malloc+0x8c >> #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 >> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >> #9 0xffff0000001c7400 at led_create_state+0x158 >> #10 0xffff0000001910d4 at gpioled_attach+0x290 >> #11 0xffff00000049efa4 at device_attach+0x3f8 >> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #16 0xffff00000049bd30 at bus_set_pass+0x4c >> #17 0xffff0000003ea3bc at mi_startup+0x1fc >> uma_zalloc_debug: zone "malloc-128" with the following non-sleepable = locks held: >> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) = locked @ /usr/src/sys/dev/led/led.c:298 >> stack backtrace: >> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >> #1 0xffff0000004d4fcc at witness_warn+0x400 >> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >> #4 0xffff000000437abc at malloc+0x8c >> #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 >> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >> #9 0xffff0000001c7400 at led_create_state+0x158 >> #10 0xffff0000001910d4 at gpioled_attach+0x290 >> #11 0xffff00000049efa4 at device_attach+0x3f8 >> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >> #16 0xffff00000049bd30 at bus_set_pass+0x4c >> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>=20 >> Mike >>=20 >=20 >=20 > --=20 > Emmanuel Vadot >=20 --Apple-Mail=_EBAE471D-B1EE-4BAC-916D-FA8AE81C5499 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
+	if =
(OF_hasprop(ofw_bus_get_node(dev), "clock-frequency") =3D=3D 0) {
+		device_printf(dev, "clock-fixed have no =
clock-frequency\n");
+		return (ENXIO);
+	}
this runs before compat_data is checked so will = print it for any device clock or not

On Aug 14, 2023, at 6:07 PM, = Emmanuel Vadot <manu@bidouilliste.com> wrote:

On = Mon, 14 Aug 2023 09:51:27 -0500
Mike Karels <mike@karels.net> = wrote:

On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote:

On Mon, = 14 Aug 2023 07:03:19 +0200
Emmanuel Vadot <manu@bidouilliste.com> wrote:

On Sun, 13 Aug 2023 = 12:35:31 -0500
Mike Karels <mike@karels.net> = wrote:

On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote:

On Sun, = 13 Aug 2023 11:25:25 -0500
Mike Karels <mike@karels.net> = wrote:

On 13 Aug 2023, at 11:10, Mark Millard wrote:
On Aug 13, 2023, at = 08:17, Warner Losh <imp@bsdimp.com> wrote:

Manu just updated Linux = DTS in the tree. Maybe see if you revert that if the problem = persists.

git: 69f8cc60aa1e - = main - ofw_firmware: Only match if there is no compatible

is the fix that Manu has committed:

QUOTE
=    ofw_firmware: Only match if there is no compatible

   If there is a compatible = string it likely means that the firmware needs
=    a dedicated driver (like on RPI*).

   PR:     273087
   Tested-by: =      Mark Millard <marklmi26-fbsd@yahoo.com>
=    Sponsored by:   Beckhoff Automation GmbH = & Co. KG
   Fixes: =          fdfd3a90b6ce = ("ofw: Add a ofw_firmware driver")
END QUOTE

Just for completeness: that = change fixes the bcm2835_cpufreq0/powerd
problem and the = gpioled0 problem, but not the clk_fixed2 problem
(clk_fixed4= on rpi4).  Installing an msdos boot partition from the
3 Aug image makes that problem disappear.

= = Mike

There is two = fixed-clock in the DTB without clock-frequency property
and = with a status set to "disabled", this isn't conforming to the
bindings
(https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindi= ngs/clock/fixed-clock.yaml)
so we complain on this, = this is normal.

Would it be = possible to detect the disabled status to prevent the errors
(I'm guessing not) or to suppress the repeats?  150 = lines of errors seems
like a lot for an out-of-spec DTB = entry, and makes it hard to ignore.

Mike

Detecting the disabled status = makes no sense, a fixed clock cannot be
disable, it's = always present and running.
But I think that if we check = that clock-frenquency isn't present in
the probe function, = print a message and bail we will not attempt to
attach the = driver at each pass.
That's the only clean solution that = I can see without making dirty
hacks for some = non-conforming DTB.

Something = like this :
https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-t= here-is-no-clock-frequency-.patch

= Please let me know if that works.

Not exactly.  This results in:

clk_fixed4: clock-fixed have no clock-frequency

but this appears 1562 times.  btw, "have" = should be "has".

Then I don't = know how to fix this properly.

I hadn't noticed them before, but there are a = lock order reversal
and a malloc while holding a = non-sleepable lock, associated with
the gpio fix:

Are you sure that they are new = ?

gpioled0: <GPIO LEDs> on ofwbus0
lock = order reversal: (sleepable after non-sleepable)
1st = 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ = /usr/src/sys/dev/led/led.c:298
2nd 0xffffa00001857c10 = Raspberry Pi firmware gpio (Raspberry Pi firmware gpio, sx) @ = /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252
lock order LED mtx -> Raspberry Pi firmware gpio attempted = at:
#0 0xffff0000004d3984 at witness_checkorder+0xa98
#1 0xffff00000046ecb4 at _sx_xlock+0x7c
#2 = 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0
#3 = 0xffff0000001c7400 at led_create_state+0x158
#4 = 0xffff0000001910d4 at gpioled_attach+0x290
#5 = 0xffff00000049efa4 at device_attach+0x3f8
#6 = 0xffff00000049eb14 at device_probe_and_attach+0x7c
#7 = 0xffff0000004a0e54 at bus_generic_new_pass+0xfc
#8 = 0xffff0000004a0e04 at bus_generic_new_pass+0xac
#9 = 0xffff0000004a0e04 at bus_generic_new_pass+0xac
#10 = 0xffff00000049bd30 at bus_set_pass+0x4c
#11 = 0xffff0000003ea3bc at mi_startup+0x1fc
#12 = 0xffff0000000008ac at virtdone+0x70
uma_zalloc_debug: zone = "malloc-64" with the following non-sleepable locks held:
exclusive sleep mutex LED mtx (LED mtx) r =3D 0 = (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004d3dc8 at = witness_debugger+0x5c
#1 0xffff0000004d4fcc at = witness_warn+0x400
#2 0xffff0000007830a0 at = uma_zalloc_debug+0x30
#3 0xffff000000782c20 at = uma_zalloc_arg+0x2c
#4 0xffff000000437abc at = malloc+0x8c
#5 0xffff0000008a69b4 at = bcm2835_firmware_property+0x44
#6 0xffff0000008b1718 at = rpi_fw_gpio_pin_set+0xf8
#7 0xffff0000001c7400 at = led_create_state+0x158
#8 0xffff0000001910d4 at = gpioled_attach+0x290
#9 0xffff00000049efa4 at = device_attach+0x3f8
#10 0xffff00000049eb14 at = device_probe_and_attach+0x7c
#11 0xffff0000004a0e54 at = bus_generic_new_pass+0xfc
#12 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#13 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#14 0xffff00000049bd30 at = bus_set_pass+0x4c
#15 0xffff0000003ea3bc at = mi_startup+0x1fc
#16 0xffff0000000008ac at = virtdone+0x70
uma_zalloc_debug: zone "malloc-16" with the = following non-sleepable locks held:
exclusive sleep mutex = LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) locked @ = /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004d3dc8 at witness_debugger+0x5c
#1= 0xffff0000004d4fcc at witness_warn+0x400
#2 = 0xffff0000007830a0 at uma_zalloc_debug+0x30
#3 = 0xffff000000782c20 at uma_zalloc_arg+0x2c
#4 = 0xffff000000437abc at malloc+0x8c
#5 0xffff0000007ce15c at = bounce_bus_dmamem_alloc+0x50
#6 0xffff0000008a9404 at = bcm2835_mbox_property+0xdc
#7 0xffff0000008a69e8 at = bcm2835_firmware_property+0x78
#8 0xffff0000008b1718 at = rpi_fw_gpio_pin_set+0xf8
#9 0xffff0000001c7400 at = led_create_state+0x158
#10 0xffff0000001910d4 at = gpioled_attach+0x290
#11 0xffff00000049efa4 at = device_attach+0x3f8
#12 0xffff00000049eb14 at = device_probe_and_attach+0x7c
#13 0xffff0000004a0e54 at = bus_generic_new_pass+0xfc
#14 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#15 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#16 0xffff00000049bd30 at = bus_set_pass+0x4c
#17 0xffff0000003ea3bc at = mi_startup+0x1fc
uma_zalloc_debug: zone "malloc-128" with = the following non-sleepable locks held:
exclusive sleep = mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) locked @ = /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004d3dc8 at witness_debugger+0x5c
#1= 0xffff0000004d4fcc at witness_warn+0x400
#2 = 0xffff0000007830a0 at uma_zalloc_debug+0x30
#3 = 0xffff000000782c20 at uma_zalloc_arg+0x2c
#4 = 0xffff000000437abc at malloc+0x8c
#5 0xffff0000007ce1ac at = bounce_bus_dmamem_alloc+0xa0
#6 0xffff0000008a9404 at = bcm2835_mbox_property+0xdc
#7 0xffff0000008a69e8 at = bcm2835_firmware_property+0x78
#8 0xffff0000008b1718 at = rpi_fw_gpio_pin_set+0xf8
#9 0xffff0000001c7400 at = led_create_state+0x158
#10 0xffff0000001910d4 at = gpioled_attach+0x290
#11 0xffff00000049efa4 at = device_attach+0x3f8
#12 0xffff00000049eb14 at = device_probe_and_attach+0x7c
#13 0xffff0000004a0e54 at = bus_generic_new_pass+0xfc
#14 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#15 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#16 0xffff00000049bd30 at = bus_set_pass+0x4c
#17 0xffff0000003ea3bc at = mi_startup+0x1fc

Mike



-- =
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>


= --Apple-Mail=_EBAE471D-B1EE-4BAC-916D-FA8AE81C5499-- From nobody Mon Aug 14 15:55:39 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPfBd3lmbz4qgJt for ; Mon, 14 Aug 2023 15:55:53 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPfBd3HtRz3W45 for ; Mon, 14 Aug 2023 15:55:53 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 37EFtera046140; Mon, 14 Aug 2023 10:55:40 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1692028541; bh=LthUYL0E2esqbvBPLiiLO+nIV1UkXH3DQ11P+En9Grw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=RJ7RtAZCtGmvyMlI7sSSjJ4I4xvPyrAosPXWdUH9SrKRCh2i+k5rL8UnX+MzLZ7St K+65kJ9tuZRuVrzwRZLw3T3bN3rei78u0Po7fqXvNsZ8EjV9lonkI9qttY33TxWj01 j4TRRcxPl8wz0KIHB/IM37fPfFLOkpZa3/mNt1g/RkgbErry189L6ZmJRlHjU71zYd LycFVocECTyFKJdXuJh7aHYApit9OgFPwoxShwWXtyzr9TF3I9gZSXTD2C87WvNhZa 9TUxpgEM0oCpD6qhbqEDFD8LNPnpGCindfPZryLHNB03PZrtQYu31cD+Y3iOYi4VsG FHpuNSFbdxQ4A== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id OZNjJnxO2mQ6tAAAs/W3XQ (envelope-from ); Mon, 14 Aug 2023 10:55:40 -0500 From: Mike Karels To: titus Cc: Emmanuel Vadot , freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Date: Mon, 14 Aug 2023 10:55:39 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: <0C830898-AAAE-48BC-9844-1B9D426C0767@karels.net> In-Reply-To: <2DF7EF89-DC3F-44D4-8708-51CB4B6C8EC4@edc.ro> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> <2DF7EF89-DC3F-44D4-8708-51CB4B6C8EC4@edc.ro> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RPfBd3HtRz3W45 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 14 Aug 2023, at 10:44, titus wrote: > + if (OF_hasprop(ofw_bus_get_node(dev), "clock-frequency") =3D=3D 0) { > + device_printf(dev, "clock-fixed have no clock-frequency\n"); > + return (ENXIO); > + } > this runs before compat_data is checked so will print it for any device= clock or not Good point! Shuffling a bit to check both, I see 58 occurrences of the message. That's better than the 50+ 3-line sequences before. Mike >> On Aug 14, 2023, at 6:07 PM, Emmanuel Vadot wr= ote: >> >> On Mon, 14 Aug 2023 09:51:27 -0500 >> Mike Karels wrote: >> >>> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: >>> >>>> On Mon, 14 Aug 2023 07:03:19 +0200 >>>> Emmanuel Vadot wrote: >>>> >>>>> On Sun, 13 Aug 2023 12:35:31 -0500 >>>>> Mike Karels wrote: >>>>> >>>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: >>>>>> >>>>>>> On Sun, 13 Aug 2023 11:25:25 -0500 >>>>>>> Mike Karels wrote: >>>>>>> >>>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: >>>>>>>> >>>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh wrote: >>>>>>>>> >>>>>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you reve= rt that if the problem persists. >>>>>>>>> >>>>>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is= no compatible >>>>>>>>> >>>>>>>>> is the fix that Manu has committed: >>>>>>>>> >>>>>>>>> QUOTE >>>>>>>>> ofw_firmware: Only match if there is no compatible >>>>>>>>> >>>>>>>>> If there is a compatible string it likely means that the fir= mware needs >>>>>>>>> a dedicated driver (like on RPI*). >>>>>>>>> >>>>>>>>> PR: 273087 >>>>>>>>> Tested-by: Mark Millard >>>>>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG >>>>>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware drive= r") >>>>>>>>> END QUOTE >>>>>>>> >>>>>>>> Just for completeness: that change fixes the bcm2835_cpufreq0/po= werd >>>>>>>> problem and the gpioled0 problem, but not the clk_fixed2 problem= >>>>>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition from t= he >>>>>>>> 3 Aug image makes that problem disappear. >>>>>>>> >>>>>>>> Mike >>>>>>> >>>>>>> There is two fixed-clock in the DTB without clock-frequency prope= rty >>>>>>> and with a status set to "disabled", this isn't conforming to the= >>>>>>> bindings >>>>>>> (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindin= gs/clock/fixed-clock.yaml) >>>>>>> so we complain on this, this is normal. >>>>>> >>>>>> Would it be possible to detect the disabled status to prevent the = errors >>>>>> (I'm guessing not) or to suppress the repeats? 150 lines of error= s seems >>>>>> like a lot for an out-of-spec DTB entry, and makes it hard to igno= re. >>>>>> >>>>>> Mike >>>>> >>>>> Detecting the disabled status makes no sense, a fixed clock cannot = be >>>>> disable, it's always present and running. >>>>> But I think that if we check that clock-frenquency isn't present in= >>>>> the probe function, print a message and bail we will not attempt to= >>>>> attach the driver at each pass. >>>>> That's the only clean solution that I can see without making dirty >>>>> hacks for some non-conforming DTB. >>>> >>>> Something like this : >>>> https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-there-= is-no-clock-frequency-.patch >>>> >>>> Please let me know if that works. >>> >>> Not exactly. This results in: >>> >>> clk_fixed4: clock-fixed have no clock-frequency >>> >>> but this appears 1562 times. btw, "have" should be "has". >> >> Then I don't know how to fix this properly. >> >>> I hadn't noticed them before, but there are a lock order reversal >>> and a malloc while holding a non-sleepable lock, associated with >>> the gpio fix: >> >> Are you sure that they are new ? >> >>> gpioled0: on ofwbus0 >>> lock order reversal: (sleepable after non-sleepable) >>> 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ /usr/src/sys/= dev/led/led.c:298 >>> 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi firmw= are gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252 >>> lock order LED mtx -> Raspberry Pi firmware gpio attempted at: >>> #0 0xffff0000004d3984 at witness_checkorder+0xa98 >>> #1 0xffff00000046ecb4 at _sx_xlock+0x7c >>> #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 >>> #3 0xffff0000001c7400 at led_create_state+0x158 >>> #4 0xffff0000001910d4 at gpioled_attach+0x290 >>> #5 0xffff00000049efa4 at device_attach+0x3f8 >>> #6 0xffff00000049eb14 at device_probe_and_attach+0x7c >>> #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>> #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>> #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>> #10 0xffff00000049bd30 at bus_set_pass+0x4c >>> #11 0xffff0000003ea3bc at mi_startup+0x1fc >>> #12 0xffff0000000008ac at virtdone+0x70 >>> uma_zalloc_debug: zone "malloc-64" with the following non-sleepable l= ocks held: >>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) = locked @ /usr/src/sys/dev/led/led.c:298 >>> stack backtrace: >>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>> #4 0xffff000000437abc at malloc+0x8c >>> #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 >>> #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>> #7 0xffff0000001c7400 at led_create_state+0x158 >>> #8 0xffff0000001910d4 at gpioled_attach+0x290 >>> #9 0xffff00000049efa4 at device_attach+0x3f8 >>> #10 0xffff00000049eb14 at device_probe_and_attach+0x7c >>> #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>> #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>> #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>> #14 0xffff00000049bd30 at bus_set_pass+0x4c >>> #15 0xffff0000003ea3bc at mi_startup+0x1fc >>> #16 0xffff0000000008ac at virtdone+0x70 >>> uma_zalloc_debug: zone "malloc-16" with the following non-sleepable l= ocks held: >>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) = locked @ /usr/src/sys/dev/led/led.c:298 >>> stack backtrace: >>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>> #4 0xffff000000437abc at malloc+0x8c >>> #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 >>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>> #9 0xffff0000001c7400 at led_create_state+0x158 >>> #10 0xffff0000001910d4 at gpioled_attach+0x290 >>> #11 0xffff00000049efa4 at device_attach+0x3f8 >>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>> #16 0xffff00000049bd30 at bus_set_pass+0x4c >>> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>> uma_zalloc_debug: zone "malloc-128" with the following non-sleepable = locks held: >>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) = locked @ /usr/src/sys/dev/led/led.c:298 >>> stack backtrace: >>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>> #4 0xffff000000437abc at malloc+0x8c >>> #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 >>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>> #9 0xffff0000001c7400 at led_create_state+0x158 >>> #10 0xffff0000001910d4 at gpioled_attach+0x290 >>> #11 0xffff00000049efa4 at device_attach+0x3f8 >>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>> #16 0xffff00000049bd30 at bus_set_pass+0x4c >>> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>> >>> Mike >>> >> >> >> -- = >> Emmanuel Vadot >> From nobody Mon Aug 14 16:19:21 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPfjm71h3z4qhng for ; Mon, 14 Aug 2023 16:19:24 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPfjm4xMqz3X2G for ; Mon, 14 Aug 2023 16:19:24 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1692029962; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mHp4BSZ6b57DU/4NevozCHGYCT8JlUuhO6oBxFZdCZg=; b=Jy9QuHQBl167UPsuy7cuNnRT7sdfWCLGSX2m5uRBOciokY4iHdiqKBMWUpdVkdxI3Wd4p0 SdT4+dfD2Vd6XN4TO/YSLBU7An/ZqgK2IwA8G9eIGwPsn0A9wXB7VLWecfH6rdck2grePP vB2sSrRPNUk6oLs2L36/YTToNQzqREs= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id e5954229 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 14 Aug 2023 16:19:21 +0000 (UTC) Date: Mon, 14 Aug 2023 18:19:21 +0200 From: Emmanuel Vadot To: Mike Karels Cc: titus , freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Message-Id: <20230814181921.70596c64343261a24351837a@bidouilliste.com> In-Reply-To: <0C830898-AAAE-48BC-9844-1B9D426C0767@karels.net> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> <2DF7EF89-DC3F-44D4-8708-51CB4B6C8EC4@edc.ro> <0C830898-AAAE-48BC-9844-1B9D426C0767@karels.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RPfjm4xMqz3X2G X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] On Mon, 14 Aug 2023 10:55:39 -0500 Mike Karels wrote: > On 14 Aug 2023, at 10:44, titus wrote: > > > + if (OF_hasprop(ofw_bus_get_node(dev), "clock-frequency") == 0) { > > + device_printf(dev, "clock-fixed have no clock-frequency\n"); > > + return (ENXIO); > > + } > > this runs before compat_data is checked so will print it for any device clock or not Meh, that's why I should do code at 7am :) > Good point! Shuffling a bit to check both, I see 58 occurrences > of the message. That's better than the 50+ 3-line sequences before. > > Mike Is that more or less than the previous message ? If it's the same there is no point to commit this. > >> On Aug 14, 2023, at 6:07 PM, Emmanuel Vadot wrote: > >> > >> On Mon, 14 Aug 2023 09:51:27 -0500 > >> Mike Karels wrote: > >> > >>> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: > >>> > >>>> On Mon, 14 Aug 2023 07:03:19 +0200 > >>>> Emmanuel Vadot wrote: > >>>> > >>>>> On Sun, 13 Aug 2023 12:35:31 -0500 > >>>>> Mike Karels wrote: > >>>>> > >>>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: > >>>>>> > >>>>>>> On Sun, 13 Aug 2023 11:25:25 -0500 > >>>>>>> Mike Karels wrote: > >>>>>>> > >>>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: > >>>>>>>> > >>>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh wrote: > >>>>>>>>> > >>>>>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you revert that if the problem persists. > >>>>>>>>> > >>>>>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no compatible > >>>>>>>>> > >>>>>>>>> is the fix that Manu has committed: > >>>>>>>>> > >>>>>>>>> QUOTE > >>>>>>>>> ofw_firmware: Only match if there is no compatible > >>>>>>>>> > >>>>>>>>> If there is a compatible string it likely means that the firmware needs > >>>>>>>>> a dedicated driver (like on RPI*). > >>>>>>>>> > >>>>>>>>> PR: 273087 > >>>>>>>>> Tested-by: Mark Millard > >>>>>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG > >>>>>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver") > >>>>>>>>> END QUOTE > >>>>>>>> > >>>>>>>> Just for completeness: that change fixes the bcm2835_cpufreq0/powerd > >>>>>>>> problem and the gpioled0 problem, but not the clk_fixed2 problem > >>>>>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition from the > >>>>>>>> 3 Aug image makes that problem disappear. > >>>>>>>> > >>>>>>>> Mike > >>>>>>> > >>>>>>> There is two fixed-clock in the DTB without clock-frequency property > >>>>>>> and with a status set to "disabled", this isn't conforming to the > >>>>>>> bindings > >>>>>>> (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/clock/fixed-clock.yaml) > >>>>>>> so we complain on this, this is normal. > >>>>>> > >>>>>> Would it be possible to detect the disabled status to prevent the errors > >>>>>> (I'm guessing not) or to suppress the repeats? 150 lines of errors seems > >>>>>> like a lot for an out-of-spec DTB entry, and makes it hard to ignore. > >>>>>> > >>>>>> Mike > >>>>> > >>>>> Detecting the disabled status makes no sense, a fixed clock cannot be > >>>>> disable, it's always present and running. > >>>>> But I think that if we check that clock-frenquency isn't present in > >>>>> the probe function, print a message and bail we will not attempt to > >>>>> attach the driver at each pass. > >>>>> That's the only clean solution that I can see without making dirty > >>>>> hacks for some non-conforming DTB. > >>>> > >>>> Something like this : > >>>> https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-there-is-no-clock-frequency-.patch > >>>> > >>>> Please let me know if that works. > >>> > >>> Not exactly. This results in: > >>> > >>> clk_fixed4: clock-fixed have no clock-frequency > >>> > >>> but this appears 1562 times. btw, "have" should be "has". > >> > >> Then I don't know how to fix this properly. > >> > >>> I hadn't noticed them before, but there are a lock order reversal > >>> and a malloc while holding a non-sleepable lock, associated with > >>> the gpio fix: > >> > >> Are you sure that they are new ? > >> > >>> gpioled0: on ofwbus0 > >>> lock order reversal: (sleepable after non-sleepable) > >>> 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ /usr/src/sys/dev/led/led.c:298 > >>> 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi firmware gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252 > >>> lock order LED mtx -> Raspberry Pi firmware gpio attempted at: > >>> #0 0xffff0000004d3984 at witness_checkorder+0xa98 > >>> #1 0xffff00000046ecb4 at _sx_xlock+0x7c > >>> #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 > >>> #3 0xffff0000001c7400 at led_create_state+0x158 > >>> #4 0xffff0000001910d4 at gpioled_attach+0x290 > >>> #5 0xffff00000049efa4 at device_attach+0x3f8 > >>> #6 0xffff00000049eb14 at device_probe_and_attach+0x7c > >>> #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > >>> #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>> #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>> #10 0xffff00000049bd30 at bus_set_pass+0x4c > >>> #11 0xffff0000003ea3bc at mi_startup+0x1fc > >>> #12 0xffff0000000008ac at virtdone+0x70 > >>> uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held: > >>> exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 > >>> stack backtrace: > >>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c > >>> #1 0xffff0000004d4fcc at witness_warn+0x400 > >>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > >>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > >>> #4 0xffff000000437abc at malloc+0x8c > >>> #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 > >>> #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > >>> #7 0xffff0000001c7400 at led_create_state+0x158 > >>> #8 0xffff0000001910d4 at gpioled_attach+0x290 > >>> #9 0xffff00000049efa4 at device_attach+0x3f8 > >>> #10 0xffff00000049eb14 at device_probe_and_attach+0x7c > >>> #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > >>> #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>> #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>> #14 0xffff00000049bd30 at bus_set_pass+0x4c > >>> #15 0xffff0000003ea3bc at mi_startup+0x1fc > >>> #16 0xffff0000000008ac at virtdone+0x70 > >>> uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks held: > >>> exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 > >>> stack backtrace: > >>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c > >>> #1 0xffff0000004d4fcc at witness_warn+0x400 > >>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > >>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > >>> #4 0xffff000000437abc at malloc+0x8c > >>> #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 > >>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc > >>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 > >>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > >>> #9 0xffff0000001c7400 at led_create_state+0x158 > >>> #10 0xffff0000001910d4 at gpioled_attach+0x290 > >>> #11 0xffff00000049efa4 at device_attach+0x3f8 > >>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c > >>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > >>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>> #16 0xffff00000049bd30 at bus_set_pass+0x4c > >>> #17 0xffff0000003ea3bc at mi_startup+0x1fc > >>> uma_zalloc_debug: zone "malloc-128" with the following non-sleepable locks held: > >>> exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 > >>> stack backtrace: > >>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c > >>> #1 0xffff0000004d4fcc at witness_warn+0x400 > >>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > >>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > >>> #4 0xffff000000437abc at malloc+0x8c > >>> #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 > >>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc > >>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 > >>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > >>> #9 0xffff0000001c7400 at led_create_state+0x158 > >>> #10 0xffff0000001910d4 at gpioled_attach+0x290 > >>> #11 0xffff00000049efa4 at device_attach+0x3f8 > >>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c > >>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > >>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>> #16 0xffff00000049bd30 at bus_set_pass+0x4c > >>> #17 0xffff0000003ea3bc at mi_startup+0x1fc > >>> > >>> Mike > >>> > >> > >> > >> -- > >> Emmanuel Vadot > >> -- Emmanuel Vadot From nobody Mon Aug 14 17:44:03 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPhbk5GhMz4Tmbr for ; Mon, 14 Aug 2023 17:44:18 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPhbk2PWzz3gJK for ; Mon, 14 Aug 2023 17:44:18 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 37EHi3W0046829; Mon, 14 Aug 2023 12:44:04 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1692035045; bh=EguyAW97GF1DS5ECVVa3JlL99ElYTG1sS+/tg3+tXAc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=JKmZNaBUZR4RErDYd104sfeLo1Lk/YYLo1FS0kHYUPHCFVI3/jAu9EuLSW9ES+4jI 2xrXMrlzZPt6szt4tIs4N5w2Jl87T7xpdcl1AvX+fINcNfwQ4vHIpblVrAyp6Jf5oc BV+W4GX4vFQg96sTN4FZqtMsDvtDVosPDpjKVLa0cS334YiyV/GDU7VI7fBquz7KlS heMIfLhj1KssSi1nukJstKjk/c8YS2X5dTn25NCQgM60a8ZwkI1ekZkGS/p/DYxS56 9kxXjMRTbz2O/2jQL30jgSq6jDE1ag1H8T8GhaCCVClh4q1+gP/+bK6IONupvZBEq7 o8sQ3W58TnRwQ== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id fCxJNuNn2mTrtgAAs/W3XQ (envelope-from ); Mon, 14 Aug 2023 12:44:03 -0500 From: Mike Karels To: Emmanuel Vadot Cc: titus , freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Date: Mon, 14 Aug 2023 12:44:03 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: In-Reply-To: <20230814181921.70596c64343261a24351837a@bidouilliste.com> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> <2DF7EF89-DC3F-44D4-8708-51CB4B6C8EC4@edc.ro> <0C830898-AAAE-48BC-9844-1B9D426C0767@karels.net> <20230814181921.70596c64343261a24351837a@bidouilliste.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RPhbk2PWzz3gJK X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 14 Aug 2023, at 11:19, Emmanuel Vadot wrote: > On Mon, 14 Aug 2023 10:55:39 -0500 > Mike Karels wrote: > >> On 14 Aug 2023, at 10:44, titus wrote: >> >>> + if (OF_hasprop(ofw_bus_get_node(dev), "clock-frequency") =3D=3D 0) = { >>> + device_printf(dev, "clock-fixed have no clock-frequency\n"); >>> + return (ENXIO); >>> + } >>> this runs before compat_data is checked so will print it for any devi= ce clock or not > > Meh, that's why I should do code at 7am :) > >> Good point! Shuffling a bit to check both, I see 58 occurrences >> of the message. That's better than the 50+ 3-line sequences before. >> >> Mike > > Is that more or less than the previous message ? If it's the same > there is no point to commit this. It's the same number of occurrences, but before there were 3 lines per occurrence. Now it's 1, and it's more clear what it means. I'd say it's worth it. Mike >>>> On Aug 14, 2023, at 6:07 PM, Emmanuel Vadot = wrote: >>>> >>>> On Mon, 14 Aug 2023 09:51:27 -0500 >>>> Mike Karels wrote: >>>> >>>>> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: >>>>> >>>>>> On Mon, 14 Aug 2023 07:03:19 +0200 >>>>>> Emmanuel Vadot wrote: >>>>>> >>>>>>> On Sun, 13 Aug 2023 12:35:31 -0500 >>>>>>> Mike Karels wrote: >>>>>>> >>>>>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: >>>>>>>> >>>>>>>>> On Sun, 13 Aug 2023 11:25:25 -0500 >>>>>>>>> Mike Karels wrote: >>>>>>>>> >>>>>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: >>>>>>>>>> >>>>>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh wrote= : >>>>>>>>>>> >>>>>>>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you re= vert that if the problem persists. >>>>>>>>>>> >>>>>>>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there = is no compatible >>>>>>>>>>> >>>>>>>>>>> is the fix that Manu has committed: >>>>>>>>>>> >>>>>>>>>>> QUOTE >>>>>>>>>>> ofw_firmware: Only match if there is no compatible >>>>>>>>>>> >>>>>>>>>>> If there is a compatible string it likely means that the f= irmware needs >>>>>>>>>>> a dedicated driver (like on RPI*). >>>>>>>>>>> >>>>>>>>>>> PR: 273087 >>>>>>>>>>> Tested-by: Mark Millard >>>>>>>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG >>>>>>>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware dri= ver") >>>>>>>>>>> END QUOTE >>>>>>>>>> >>>>>>>>>> Just for completeness: that change fixes the bcm2835_cpufreq0/= powerd >>>>>>>>>> problem and the gpioled0 problem, but not the clk_fixed2 probl= em >>>>>>>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition from= the >>>>>>>>>> 3 Aug image makes that problem disappear. >>>>>>>>>> >>>>>>>>>> Mike >>>>>>>>> >>>>>>>>> There is two fixed-clock in the DTB without clock-frequency pro= perty >>>>>>>>> and with a status set to "disabled", this isn't conforming to t= he >>>>>>>>> bindings >>>>>>>>> (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bind= ings/clock/fixed-clock.yaml) >>>>>>>>> so we complain on this, this is normal. >>>>>>>> >>>>>>>> Would it be possible to detect the disabled status to prevent th= e errors >>>>>>>> (I'm guessing not) or to suppress the repeats? 150 lines of err= ors seems >>>>>>>> like a lot for an out-of-spec DTB entry, and makes it hard to ig= nore. >>>>>>>> >>>>>>>> Mike >>>>>>> >>>>>>> Detecting the disabled status makes no sense, a fixed clock canno= t be >>>>>>> disable, it's always present and running. >>>>>>> But I think that if we check that clock-frenquency isn't present = in >>>>>>> the probe function, print a message and bail we will not attempt = to >>>>>>> attach the driver at each pass. >>>>>>> That's the only clean solution that I can see without making dirt= y >>>>>>> hacks for some non-conforming DTB. >>>>>> >>>>>> Something like this : >>>>>> https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-ther= e-is-no-clock-frequency-.patch >>>>>> >>>>>> Please let me know if that works. >>>>> >>>>> Not exactly. This results in: >>>>> >>>>> clk_fixed4: clock-fixed have no clock-frequency >>>>> >>>>> but this appears 1562 times. btw, "have" should be "has". >>>> >>>> Then I don't know how to fix this properly. >>>> >>>>> I hadn't noticed them before, but there are a lock order reversal >>>>> and a malloc while holding a non-sleepable lock, associated with >>>>> the gpio fix: >>>> >>>> Are you sure that they are new ? >>>> >>>>> gpioled0: on ofwbus0 >>>>> lock order reversal: (sleepable after non-sleepable) >>>>> 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ /usr/src/sy= s/dev/led/led.c:298 >>>>> 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi fir= mware gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:25= 2 >>>>> lock order LED mtx -> Raspberry Pi firmware gpio attempted at: >>>>> #0 0xffff0000004d3984 at witness_checkorder+0xa98 >>>>> #1 0xffff00000046ecb4 at _sx_xlock+0x7c >>>>> #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 >>>>> #3 0xffff0000001c7400 at led_create_state+0x158 >>>>> #4 0xffff0000001910d4 at gpioled_attach+0x290 >>>>> #5 0xffff00000049efa4 at device_attach+0x3f8 >>>>> #6 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>> #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>> #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>> #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>> #10 0xffff00000049bd30 at bus_set_pass+0x4c >>>>> #11 0xffff0000003ea3bc at mi_startup+0x1fc >>>>> #12 0xffff0000000008ac at virtdone+0x70 >>>>> uma_zalloc_debug: zone "malloc-64" with the following non-sleepable= locks held: >>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8= ) locked @ /usr/src/sys/dev/led/led.c:298 >>>>> stack backtrace: >>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>> #4 0xffff000000437abc at malloc+0x8c >>>>> #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 >>>>> #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>> #7 0xffff0000001c7400 at led_create_state+0x158 >>>>> #8 0xffff0000001910d4 at gpioled_attach+0x290 >>>>> #9 0xffff00000049efa4 at device_attach+0x3f8 >>>>> #10 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>> #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>> #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>> #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>> #14 0xffff00000049bd30 at bus_set_pass+0x4c >>>>> #15 0xffff0000003ea3bc at mi_startup+0x1fc >>>>> #16 0xffff0000000008ac at virtdone+0x70 >>>>> uma_zalloc_debug: zone "malloc-16" with the following non-sleepable= locks held: >>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8= ) locked @ /usr/src/sys/dev/led/led.c:298 >>>>> stack backtrace: >>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>> #4 0xffff000000437abc at malloc+0x8c >>>>> #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 >>>>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >>>>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >>>>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>> #9 0xffff0000001c7400 at led_create_state+0x158 >>>>> #10 0xffff0000001910d4 at gpioled_attach+0x290 >>>>> #11 0xffff00000049efa4 at device_attach+0x3f8 >>>>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>> #16 0xffff00000049bd30 at bus_set_pass+0x4c >>>>> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>>>> uma_zalloc_debug: zone "malloc-128" with the following non-sleepabl= e locks held: >>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8= ) locked @ /usr/src/sys/dev/led/led.c:298 >>>>> stack backtrace: >>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>> #4 0xffff000000437abc at malloc+0x8c >>>>> #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 >>>>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >>>>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >>>>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>> #9 0xffff0000001c7400 at led_create_state+0x158 >>>>> #10 0xffff0000001910d4 at gpioled_attach+0x290 >>>>> #11 0xffff00000049efa4 at device_attach+0x3f8 >>>>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>> #16 0xffff00000049bd30 at bus_set_pass+0x4c >>>>> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>>>> >>>>> Mike >>>>> >>>> >>>> >>>> -- = >>>> Emmanuel Vadot >>>> > > > -- = > Emmanuel Vadot From nobody Mon Aug 14 18:44:13 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPjwz1QPQz4Trn0 for ; Mon, 14 Aug 2023 18:44:19 +0000 (UTC) (envelope-from titus@edc.ro) Received: from eatlas.ro (eatlas.ro [86.126.82.18]) (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 (2048 bits) client-digest SHA256) (Client CN "eatlas.ro", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPjwx43fzz4JSc for ; Mon, 14 Aug 2023 18:44:17 +0000 (UTC) (envelope-from titus@edc.ro) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=edc.ro header.s=mail header.b=F2Jr+jN0; spf=pass (mx1.freebsd.org: domain of titus@edc.ro designates 86.126.82.18 as permitted sender) smtp.mailfrom=titus@edc.ro; dmarc=none Received: from mail.edc.ro ([10.1.4.58]) by eatlas.ro (8.16.1/8.16.1) with ESMTPS id 37EIiDDu052287 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Mon, 14 Aug 2023 21:44:13 +0300 (EEST) (envelope-from titus@edc.ro) Received: from [192.168.1.9] (86-120-200-242.rdsnet.ro [86.120.200.242] (may be forged)) (authenticated bits=0) by mail.edc.ro (8.16.1/8.16.1) with ESMTPSA id 37EIiBfP033202 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 14 Aug 2023 21:44:11 +0300 (EEST) (envelope-from titus@edc.ro) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=edc.ro; s=mail; t=1692038651; bh=TPZuMigpkTmAA6nqiLVzEce0R6wu9W7feVwEhvUgo74=; h=From:Subject:Date:References:To:In-Reply-To; b=F2Jr+jN0PFCxNQmIBabzJyyMaNp+dObsrrzwIYe7EEjKPCrsnGyyx9Tz23rjQEgi2 lDnebZQwxy+n23oN3xXHMjpAMvAfC7ILbog+iQplus42xiJjJvIGuLC3mm9lEELaO8 OHi15jNFyt3q7eB94dcWgn1ptRleLmZm5OiYkQUc= From: titus Content-Type: multipart/alternative; boundary="Apple-Mail=_A8815CCB-4989-402C-855D-69C7C1977D62" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Date: Mon, 14 Aug 2023 21:44:13 +0300 References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> <2DF7EF89-DC3F-44D4-8708-51CB4B6C8EC4@edc.ro> <0C830898-AAAE-48BC-9844-1B9D426C0767@karels.net> <20230814181921.70596c64343261a24351837a@bidouilliste.com> To: freebsd-arm In-Reply-To: Message-Id: <94A67CE4-8530-4080-AC54-DFBB6B8613EF@edc.ro> X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ns.edc.ro X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:86.126.82.18/32]; R_DKIM_ALLOW(-0.20)[edc.ro:s=mail]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:8708, ipnet:86.120.0.0/13, country:RO]; DKIM_TRACE(0.00)[edc.ro:+]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[edc.ro]; RCVD_TLS_ALL(0.00)[] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RPjwx43fzz4JSc --Apple-Mail=_A8815CCB-4989-402C-855D-69C7C1977D62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 can=E2=80=99t we OF_setprop some bogus string in the compatible property = after the first failure so it won=E2=80=99t come back at every bus scan > On 14 Aug 2023, at 20:44, Mike Karels wrote: >=20 > On 14 Aug 2023, at 11:19, Emmanuel Vadot wrote: >=20 >> On Mon, 14 Aug 2023 10:55:39 -0500 >> Mike Karels wrote: >>=20 >>> On 14 Aug 2023, at 10:44, titus wrote: >>>=20 >>>> + if (OF_hasprop(ofw_bus_get_node(dev), "clock-frequency") =3D=3D = 0) { >>>> + device_printf(dev, "clock-fixed have no = clock-frequency\n"); >>>> + return (ENXIO); >>>> + } >>>> this runs before compat_data is checked so will print it for any = device clock or not >>=20 >> Meh, that's why I should do code at 7am :) >>=20 >>> Good point! Shuffling a bit to check both, I see 58 occurrences >>> of the message. That's better than the 50+ 3-line sequences before. >>>=20 >>> Mike >>=20 >> Is that more or less than the previous message ? If it's the same >> there is no point to commit this. >=20 > It's the same number of occurrences, but before there were 3 lines per > occurrence. Now it's 1, and it's more clear what it means. I'd say > it's worth it. >=20 > Mike >=20 >>>>> On Aug 14, 2023, at 6:07 PM, Emmanuel Vadot = wrote: >>>>>=20 >>>>> On Mon, 14 Aug 2023 09:51:27 -0500 >>>>> Mike Karels wrote: >>>>>=20 >>>>>> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: >>>>>>=20 >>>>>>> On Mon, 14 Aug 2023 07:03:19 +0200 >>>>>>> Emmanuel Vadot wrote: >>>>>>>=20 >>>>>>>> On Sun, 13 Aug 2023 12:35:31 -0500 >>>>>>>> Mike Karels wrote: >>>>>>>>=20 >>>>>>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: >>>>>>>>>=20 >>>>>>>>>> On Sun, 13 Aug 2023 11:25:25 -0500 >>>>>>>>>> Mike Karels wrote: >>>>>>>>>>=20 >>>>>>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you = revert that if the problem persists. >>>>>>>>>>>>=20 >>>>>>>>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if = there is no compatible >>>>>>>>>>>>=20 >>>>>>>>>>>> is the fix that Manu has committed: >>>>>>>>>>>>=20 >>>>>>>>>>>> QUOTE >>>>>>>>>>>> ofw_firmware: Only match if there is no compatible >>>>>>>>>>>>=20 >>>>>>>>>>>> If there is a compatible string it likely means that the = firmware needs >>>>>>>>>>>> a dedicated driver (like on RPI*). >>>>>>>>>>>>=20 >>>>>>>>>>>> PR: 273087 >>>>>>>>>>>> Tested-by: Mark Millard >>>>>>>>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG >>>>>>>>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware = driver") >>>>>>>>>>>> END QUOTE >>>>>>>>>>>=20 >>>>>>>>>>> Just for completeness: that change fixes the = bcm2835_cpufreq0/powerd >>>>>>>>>>> problem and the gpioled0 problem, but not the clk_fixed2 = problem >>>>>>>>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition = from the >>>>>>>>>>> 3 Aug image makes that problem disappear. >>>>>>>>>>>=20 >>>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>> There is two fixed-clock in the DTB without clock-frequency = property >>>>>>>>>> and with a status set to "disabled", this isn't conforming to = the >>>>>>>>>> bindings >>>>>>>>>> = (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/clock/= fixed-clock.yaml) >>>>>>>>>> so we complain on this, this is normal. >>>>>>>>>=20 >>>>>>>>> Would it be possible to detect the disabled status to prevent = the errors >>>>>>>>> (I'm guessing not) or to suppress the repeats? 150 lines of = errors seems >>>>>>>>> like a lot for an out-of-spec DTB entry, and makes it hard to = ignore. >>>>>>>>>=20 >>>>>>>>> Mike >>>>>>>>=20 >>>>>>>> Detecting the disabled status makes no sense, a fixed clock = cannot be >>>>>>>> disable, it's always present and running. >>>>>>>> But I think that if we check that clock-frenquency isn't = present in >>>>>>>> the probe function, print a message and bail we will not = attempt to >>>>>>>> attach the driver at each pass. >>>>>>>> That's the only clean solution that I can see without making = dirty >>>>>>>> hacks for some non-conforming DTB. >>>>>>>=20 >>>>>>> Something like this : >>>>>>> = https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-there-is-no-= clock-frequency-.patch >>>>>>>=20 >>>>>>> Please let me know if that works. >>>>>>=20 >>>>>> Not exactly. This results in: >>>>>>=20 >>>>>> clk_fixed4: clock-fixed have no clock-frequency >>>>>>=20 >>>>>> but this appears 1562 times. btw, "have" should be "has". >>>>>=20 >>>>> Then I don't know how to fix this properly. >>>>>=20 >>>>>> I hadn't noticed them before, but there are a lock order reversal >>>>>> and a malloc while holding a non-sleepable lock, associated with >>>>>> the gpio fix: >>>>>=20 >>>>> Are you sure that they are new ? >>>>>=20 >>>>>> gpioled0: on ofwbus0 >>>>>> lock order reversal: (sleepable after non-sleepable) >>>>>> 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ = /usr/src/sys/dev/led/led.c:298 >>>>>> 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi = firmware gpio, sx) @ = /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252 >>>>>> lock order LED mtx -> Raspberry Pi firmware gpio attempted at: >>>>>> #0 0xffff0000004d3984 at witness_checkorder+0xa98 >>>>>> #1 0xffff00000046ecb4 at _sx_xlock+0x7c >>>>>> #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 >>>>>> #3 0xffff0000001c7400 at led_create_state+0x158 >>>>>> #4 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>> #5 0xffff00000049efa4 at device_attach+0x3f8 >>>>>> #6 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>> #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>> #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>> #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>> #10 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>> #11 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>> #12 0xffff0000000008ac at virtdone+0x70 >>>>>> uma_zalloc_debug: zone "malloc-64" with the following = non-sleepable locks held: >>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 = (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 >>>>>> stack backtrace: >>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>>> #4 0xffff000000437abc at malloc+0x8c >>>>>> #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 >>>>>> #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>>> #7 0xffff0000001c7400 at led_create_state+0x158 >>>>>> #8 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>> #9 0xffff00000049efa4 at device_attach+0x3f8 >>>>>> #10 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>> #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>> #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>> #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>> #14 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>> #15 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>> #16 0xffff0000000008ac at virtdone+0x70 >>>>>> uma_zalloc_debug: zone "malloc-16" with the following = non-sleepable locks held: >>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 = (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 >>>>>> stack backtrace: >>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>>> #4 0xffff000000437abc at malloc+0x8c >>>>>> #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 >>>>>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >>>>>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >>>>>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>>> #9 0xffff0000001c7400 at led_create_state+0x158 >>>>>> #10 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>> #11 0xffff00000049efa4 at device_attach+0x3f8 >>>>>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>> #16 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>> uma_zalloc_debug: zone "malloc-128" with the following = non-sleepable locks held: >>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 = (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 >>>>>> stack backtrace: >>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>>> #4 0xffff000000437abc at malloc+0x8c >>>>>> #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 >>>>>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >>>>>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >>>>>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>>> #9 0xffff0000001c7400 at led_create_state+0x158 >>>>>> #10 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>> #11 0xffff00000049efa4 at device_attach+0x3f8 >>>>>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>> #16 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>>=20 >>>>>> Mike >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Emmanuel Vadot >>>>>=20 >>=20 >>=20 >> --=20 >> Emmanuel Vadot --Apple-Mail=_A8815CCB-4989-402C-855D-69C7C1977D62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 can=E2=80=99t we OF_setprop some bogus string in the = compatible property after the first failure so it won=E2=80=99t come = back at every bus scan

On 14 Aug 2023, at 20:44, Mike = Karels <mike@karels.net> wrote:

On 14 Aug 2023, at 11:19, = Emmanuel Vadot wrote:

On Mon, 14 Aug 2023 10:55:39 -0500
Mike Karels <mike@karels.net> wrote:

On 14 Aug 2023, at = 10:44, titus wrote:

+ = if (OF_hasprop(ofw_bus_get_node(dev), "clock-frequency") =3D=3D = 0) {
+ device_printf(dev, "clock-fixed have no = clock-frequency\n");
+ return (ENXIO);
+ = }
this runs before compat_data is checked so will = print it for any device clock or not

Meh, that's why I = should do code at 7am :)

Good point!  Shuffling a bit to check = both, I see 58 occurrences
of the message.  That's = better than the 50+ 3-line sequences before.

= = Mike

Is that more or = less than the previous message ? If it's the same
there is = no point to commit this.

It's the same number of = occurrences, but before there were 3 lines per
occurrence.  Now it's 1, = and it's more clear what it means.  I'd say
it's worth it.

Mike

On Aug 14, 2023, at 6:07 PM, Emmanuel Vadot <manu@bidouilliste.com> wrote:

On Mon, 14 Aug 2023 09:51:27 -0500
Mike Karels = <mike@karels.net> = wrote:

On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote:

On Mon, = 14 Aug 2023 07:03:19 +0200
Emmanuel Vadot <manu@bidouilliste.com> wrote:

On Sun, 13 Aug 2023 = 12:35:31 -0500
Mike Karels <mike@karels.net> = wrote:

On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote:

On Sun, = 13 Aug 2023 11:25:25 -0500
Mike Karels <mike@karels.net> = wrote:

On 13 Aug 2023, at 11:10, Mark Millard wrote:
On Aug 13, 2023, at = 08:17, Warner Losh <imp@bsdimp.com> wrote:

Manu just updated Linux = DTS in the tree. Maybe see if you revert that if the problem = persists.

git: 69f8cc60aa1e - = main - ofw_firmware: Only match if there is no compatible

is the fix that Manu has committed:

QUOTE
  ofw_firmware: = Only match if there is no compatible

  If there is a compatible string it likely means = that the firmware needs
  a dedicated driver = (like on RPI*).

  PR: =     273087
  Tested-by: =      Mark Millard <marklmi26-fbsd@yahoo.com>
  Sponsored by:   Beckhoff Automation = GmbH & Co. KG
  Fixes: =          fdfd3a90b6ce = ("ofw: Add a ofw_firmware driver")
END QUOTE

Just for completeness: that = change fixes the bcm2835_cpufreq0/powerd
problem and the = gpioled0 problem, but not the clk_fixed2 problem
(clk_fixed4= on rpi4).  Installing an msdos boot partition from the
3 Aug image makes that problem disappear.

= = Mike

There is two = fixed-clock in the DTB without clock-frequency property
and = with a status set to "disabled", this isn't conforming to the
bindings
(https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindi= ngs/clock/fixed-clock.yaml)
so we complain on this, = this is normal.

Would it be = possible to detect the disabled status to prevent the errors
(I'm guessing not) or to suppress the repeats?  150 = lines of errors seems
like a lot for an out-of-spec DTB = entry, and makes it hard to ignore.

Mike

Detecting the disabled status = makes no sense, a fixed clock cannot be
disable, it's = always present and running.
But I think that if we check = that clock-frenquency isn't present in
the probe function, = print a message and bail we will not attempt to
attach the = driver at each pass.
That's the only clean solution that I = can see without making dirty
hacks for some non-conforming = DTB.

Something like this :
https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-t= here-is-no-clock-frequency-.patch

Please = let me know if that works.

Not = exactly.  This results in:

clk_fixed4: = clock-fixed have no clock-frequency

but = this appears 1562 times.  btw, "have" should be "has".

Then I don't know how to fix this = properly.

I hadn't noticed them before, but there are a lock order = reversal
and a malloc while holding a non-sleepable lock, = associated with
the gpio fix:
Are you sure that they are new ?

gpioled0: <GPIO = LEDs> on ofwbus0
lock order reversal: (sleepable after = non-sleepable)
1st 0xffff000000d0f6f8 LED mtx (LED mtx, = sleep mutex) @ /usr/src/sys/dev/led/led.c:298
2nd = 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi firmware = gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252
lock order LED mtx -> Raspberry Pi firmware gpio attempted = at:
#0 0xffff0000004d3984 at witness_checkorder+0xa98
#1 0xffff00000046ecb4 at _sx_xlock+0x7c
#2 = 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0
#3 = 0xffff0000001c7400 at led_create_state+0x158
#4 = 0xffff0000001910d4 at gpioled_attach+0x290
#5 = 0xffff00000049efa4 at device_attach+0x3f8
#6 = 0xffff00000049eb14 at device_probe_and_attach+0x7c
#7 = 0xffff0000004a0e54 at bus_generic_new_pass+0xfc
#8 = 0xffff0000004a0e04 at bus_generic_new_pass+0xac
#9 = 0xffff0000004a0e04 at bus_generic_new_pass+0xac
#10 = 0xffff00000049bd30 at bus_set_pass+0x4c
#11 = 0xffff0000003ea3bc at mi_startup+0x1fc
#12 = 0xffff0000000008ac at virtdone+0x70
uma_zalloc_debug: zone = "malloc-64" with the following non-sleepable locks held:
exclusive sleep mutex LED mtx (LED mtx) r =3D 0 = (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004d3dc8 at = witness_debugger+0x5c
#1 0xffff0000004d4fcc at = witness_warn+0x400
#2 0xffff0000007830a0 at = uma_zalloc_debug+0x30
#3 0xffff000000782c20 at = uma_zalloc_arg+0x2c
#4 0xffff000000437abc at = malloc+0x8c
#5 0xffff0000008a69b4 at = bcm2835_firmware_property+0x44
#6 0xffff0000008b1718 at = rpi_fw_gpio_pin_set+0xf8
#7 0xffff0000001c7400 at = led_create_state+0x158
#8 0xffff0000001910d4 at = gpioled_attach+0x290
#9 0xffff00000049efa4 at = device_attach+0x3f8
#10 0xffff00000049eb14 at = device_probe_and_attach+0x7c
#11 0xffff0000004a0e54 at = bus_generic_new_pass+0xfc
#12 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#13 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#14 0xffff00000049bd30 at = bus_set_pass+0x4c
#15 0xffff0000003ea3bc at = mi_startup+0x1fc
#16 0xffff0000000008ac at = virtdone+0x70
uma_zalloc_debug: zone "malloc-16" with the = following non-sleepable locks held:
exclusive sleep mutex = LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) locked @ = /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004d3dc8 at witness_debugger+0x5c
#1= 0xffff0000004d4fcc at witness_warn+0x400
#2 = 0xffff0000007830a0 at uma_zalloc_debug+0x30
#3 = 0xffff000000782c20 at uma_zalloc_arg+0x2c
#4 = 0xffff000000437abc at malloc+0x8c
#5 0xffff0000007ce15c at = bounce_bus_dmamem_alloc+0x50
#6 0xffff0000008a9404 at = bcm2835_mbox_property+0xdc
#7 0xffff0000008a69e8 at = bcm2835_firmware_property+0x78
#8 0xffff0000008b1718 at = rpi_fw_gpio_pin_set+0xf8
#9 0xffff0000001c7400 at = led_create_state+0x158
#10 0xffff0000001910d4 at = gpioled_attach+0x290
#11 0xffff00000049efa4 at = device_attach+0x3f8
#12 0xffff00000049eb14 at = device_probe_and_attach+0x7c
#13 0xffff0000004a0e54 at = bus_generic_new_pass+0xfc
#14 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#15 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#16 0xffff00000049bd30 at = bus_set_pass+0x4c
#17 0xffff0000003ea3bc at = mi_startup+0x1fc
uma_zalloc_debug: zone "malloc-128" with = the following non-sleepable locks held:
exclusive sleep = mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8) locked @ = /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004d3dc8 at witness_debugger+0x5c
#1= 0xffff0000004d4fcc at witness_warn+0x400
#2 = 0xffff0000007830a0 at uma_zalloc_debug+0x30
#3 = 0xffff000000782c20 at uma_zalloc_arg+0x2c
#4 = 0xffff000000437abc at malloc+0x8c
#5 0xffff0000007ce1ac at = bounce_bus_dmamem_alloc+0xa0
#6 0xffff0000008a9404 at = bcm2835_mbox_property+0xdc
#7 0xffff0000008a69e8 at = bcm2835_firmware_property+0x78
#8 0xffff0000008b1718 at = rpi_fw_gpio_pin_set+0xf8
#9 0xffff0000001c7400 at = led_create_state+0x158
#10 0xffff0000001910d4 at = gpioled_attach+0x290
#11 0xffff00000049efa4 at = device_attach+0x3f8
#12 0xffff00000049eb14 at = device_probe_and_attach+0x7c
#13 0xffff0000004a0e54 at = bus_generic_new_pass+0xfc
#14 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#15 0xffff0000004a0e04 at = bus_generic_new_pass+0xac
#16 0xffff00000049bd30 at = bus_set_pass+0x4c
#17 0xffff0000003ea3bc at = mi_startup+0x1fc

Mike



-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>



-- 
Emmanuel = Vadot <manu@bidouilliste.com> <manu@freebsd.org>
<= br class=3D"">= --Apple-Mail=_A8815CCB-4989-402C-855D-69C7C1977D62-- From nobody Tue Aug 15 13:51:24 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RQCPH4qHQz4mRHw for ; Tue, 15 Aug 2023 13:52:03 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RQCPG5ZbQz4J8r for ; Tue, 15 Aug 2023 13:52:02 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mit.edu header.s=outgoing header.b=GTBgwkU1; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.13 as permitted sender) smtp.mailfrom=jfc@mit.edu; dmarc=pass (policy=none) header.from=mit.edu Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 37FDpGq3011295 for ; Tue, 15 Aug 2023 09:51:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1692107519; bh=qwQoWv6X11U6g4asq6ioA0BkqylFkk6BS0eK890G93k=; h=From:Subject:Date:Message-ID:Content-Type:MIME-Version; b=GTBgwkU1admwpu2g8JmMcQXXWdmnEFJO+aP3HK0636q0ai4gaWAJhvF0PEFMfx/Ka uxYf3vzBOGVG2qL93wP+Vqm6qSHMaK0ifJv1mD+AhcvrRJaPYW0lTcpI8UMJknYUcm a6SuilqUM73qJ2ABlWPX4v8+vI2pFyZdtr9mlpFLrwc+osXTMJjMxmhg0vsSa1PjSc PZCDdn5Gufvhz70TlQxlzXxAlCkICd7Ih04Muu3RaBwh2MDp9yqYU9mi9zbnt2vNFI AiasdpwZGBDZajhbwiOsArZcmF759xLmuU7s+0SYwiHP9hrRJT/ZgvOeoAsyezQJxO EJSv8xH31BQug== Received: from oc11expo13.exchange.mit.edu (18.9.4.18) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Tue, 15 Aug 2023 09:51:21 -0400 Received: from oc11exhyb4.exchange.mit.edu (18.9.1.100) by oc11expo13.exchange.mit.edu (18.9.4.18) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Tue, 15 Aug 2023 09:51:26 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.57.42) by oc11exhyb4.exchange.mit.edu (18.9.1.100) with Microsoft SMTP Server (TLS) id 15.0.1497.48 via Frontend Transport; Tue, 15 Aug 2023 09:51:26 -0400 Received: from SA3PR01MB8450.prod.exchangelabs.com (2603:10b6:806:382::17) by SJ2PR01MB8281.prod.exchangelabs.com (2603:10b6:a03:53d::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6678.26; Tue, 15 Aug 2023 13:51:24 +0000 Received: from SA3PR01MB8450.prod.exchangelabs.com ([fe80::c9e9:4c4a:86ad:dc9b]) by SA3PR01MB8450.prod.exchangelabs.com ([fe80::c9e9:4c4a:86ad:dc9b%4]) with mapi id 15.20.6678.025; Tue, 15 Aug 2023 13:51:24 +0000 From: "John F Carr" To: freebsd-arm Subject: Float ABI confusion for armv7 Thread-Topic: Float ABI confusion for armv7 Thread-Index: AQHZz3+UBgx8E6qY20WQh3JugHx3xg== Date: Tue, 15 Aug 2023 13:51:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR01MB8450:EE_|SJ2PR01MB8281:EE_ x-ms-office365-filtering-correlation-id: e116e39b-3a2b-4629-dbe1-08db9d96b6df x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YLpL+LuQdWO5ypr/fueWABQ1UZZwUjxksRHER98fB9F7WVUSDY4g3U5HOprdzjlmbZFFHCbF/lB889hQgSYq1Fdxd2EMNdTfRrc8n/Z5cBW5Yqvh5S2tE8J4FO7MJF6Uk8xkJNrZBb8s5W2xc7oESi2bQL8W66U09sNV6IgSJf/I40s1ga+dMWy3lII2/Z+rbmaDS/cGybNnfvP75oBabNmrdldcRvYE8kpK8+ur1vx3mhCpPvCuYOFMpQN/zuCJeqD2Jks2VXOrhDvWIcJHich3FeULN7EN3a5fUHBzZ2W6z7fvGfidUkE/dxrfr3WXcv1iC4rxMBQfw1ZnUtNqC2f6uWH3KKMOFKKwKORLpA98DcF6Jdi665a6i7Y6psTpIkj7bYIFjvS9fVQbjdZC6nnwMO+40KpUZr7057vpIrKLXt9ttvVu83vaZvGw8wqVA7E+FhkNxdN/cO0lXxeF+r04sli4n9ReN8TmfjoRHrvlXvphQm2Zx0SUJ618Nh9qq067v2unhb9J+70v/4/Q4MtVSLadmw3Rm+k+PmRQpWL+b1VHa6xpHc2fAWWTb05NXbDmHQenJeA6b2KlTWRLAjm15jr8DUC50e4j+JYJllM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR01MB8450.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230031)(376002)(346002)(136003)(366004)(396003)(39860400002)(1800799009)(186009)(451199024)(75432002)(38070700005)(38100700002)(66946007)(66556008)(66476007)(66446008)(64756008)(6916009)(786003)(316002)(76116006)(91956017)(478600001)(122000001)(4744005)(2906002)(41300700001)(5660300002)(8936002)(8676002)(83380400001)(6512007)(6486002)(71200400001)(6506007)(26005)(2616005)(86362001)(33656002)(36756003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?FM14nOMc3NB8Jq3YSasg2Toql3AaGJNFGmNegYYY6nHXYmgbTH4MN/nRTp9L?= =?us-ascii?Q?I47s7bPqxXjqUsymjXUXsfKQJC2a0kNjIqi9s9Kho74uI3g39RasToy4o6UM?= =?us-ascii?Q?RSfPeblAx3mR9mwvmtrILIHqrwQV8TdVtYUJC0yFYyZcnC+H17Ua/UTpwmTs?= =?us-ascii?Q?/A5/l5pusNTRYkhZMDeiLBk1VoTTS7YviQRna0yNfNznlpGUeOwaMq/xyxBA?= =?us-ascii?Q?ClbfxWFMfqc2Vgs20Uh0GOEFd6EywKVdiF/drgWx3Uz9bHWRpQcfYjfFDft7?= =?us-ascii?Q?XoFf7voIfMsuqfX4x2kcJHhGc9qyN7ePI7vTuNQMYGVAwx53cJI1F+HlnJbf?= =?us-ascii?Q?6HkA+Y13hlMpRILAHqZ0BjkyT/UD7xL/7JFa8FuMtFr2F6aNg94UTLjDy6Cm?= =?us-ascii?Q?IIroyQh/4M3sXTT7/zrwmqbLhz6t/CXOyeeEQiDp22PeH6rYRK5TQxvAL6Km?= =?us-ascii?Q?0iaIEpNWSDQMRW0X/x03olONuTBDr65sPylvn27OzukCP8ZkL6koWSTbRBTV?= =?us-ascii?Q?b7Bj7yKk05uNHb7MkOOWlHrv4tCGAjwL604TlpG6D4InafcN7kcV72ccSraa?= =?us-ascii?Q?gyMh87M2GtpBCSQ7WsHnSPgODK/fKd8m4Oi+mCfwQUqs/7ij2f5+REw3L9NJ?= =?us-ascii?Q?rhDpKWWCRyIV0zdz9hGC0pkjuyjX72gf2XVMeEKL2YrIufjoYQlR9/hD1Hb0?= =?us-ascii?Q?3N4/EMkSD1OCkxfgykqoqs2ZE8cJRx1secm6ygQ62RG+uubHcLBk16ibkHZq?= =?us-ascii?Q?JayCoTGlROQ855TJJy0CL8p5M2Yhcg6OoKBgfx4yp5N5HqP+R9xEkqgWJxdP?= =?us-ascii?Q?QK5yqfuu9Op4LKB/70QRf0i77M/juwoGlJbDdJI6RZBwA33OeDKOj6y3PFcO?= =?us-ascii?Q?IFq0lYrNHNks/+YEQhCZ6SYVbRtrjW6EIz+L/SYWx0LEEdKeoqTfYKv0Q6oK?= =?us-ascii?Q?8nYeBfV/iCuzemgRwlpGD7BhDiRhyLDLdGzyDMM9LSC9hUvUTCeFO/JtYVBQ?= =?us-ascii?Q?z4L+hybRTCidwN+YoyyQoEnyNVJUnb06IVXwqtELcXdgrFqFAU1HWtm/aWlA?= =?us-ascii?Q?UNCf9/PQKpPphaApfahTDuVnISe5xlgTvapOtGXXlf3zfM69srca4SXCxb+X?= =?us-ascii?Q?/dmJerRtqt31joQl/CBUo30Gu963yo3NDr5XM3yL8wvIc7BgFuO7FmYiuKwc?= =?us-ascii?Q?OMvbn2wCWECgyr7ZYHUvOsWbXpSbftP8sCHNRycZIHJTVLBf+r+BFFbo2Xyv?= =?us-ascii?Q?mFap3Tdix50/N4DPPQdlcmkdrSFeWfWZ2Rp4+ykV6y5OGkAB8T29Q9cuyYCP?= =?us-ascii?Q?XfpyG/ECrHv1o9LY6BcGwrfPA6q8nbsZT64QjLyg3SukcA1WIvhpf9m3cXxB?= =?us-ascii?Q?MeOirLLAIW2hhGgpLjHZj9Pwr4TdPM1c7enlnBlPHOUS9fLGJpc/TjyYu3Hs?= =?us-ascii?Q?i3pZ9cJPrO4iZXCIvCEbI58bKOsrQQwfXSgeyb5jEzDDyka6puXXUYMaR7Rz?= =?us-ascii?Q?6Cg+nywMiomn6qe/aD+h/eTBLTZdTx74xzlSeppD/8CIgiC/y47dJJMnYMG5?= =?us-ascii?Q?xkSyY6i1+01JafmiXzc=3D?= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR01MB8450.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: e116e39b-3a2b-4629-dbe1-08db9d96b6df X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2023 13:51:24.1471 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: df+vz8JyUfZ3jHXaWOYeSo76LbyrdCUv7hYx/TY0rG537ixADGd1f/Lpyza8bx/L X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR01MB8281 X-OriginatorOrg: mit.edu X-Spamd-Result: default: False [-5.79 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[mit.edu:dkim]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.99)[-0.986]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[mit.edu,none]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.13:from]; R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[18.9.3.18:received]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[mit.edu:+]; FROM_EQ_ENVFROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[104.47.57.42:received]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Spamd-Bar: ----- X-Rspamd-Queue-Id: 4RQCPG5ZbQz4J8r Has something changed in llvm to cause soft float to be the default for arm= v7? I am cross-compiling using poudriere on a 64 bit ARM host to target armv7. This used to work. After updating my jail (poudriere jail -u -msrc=3D...) = I get an unnecessarily mysterious failure building pkg. Poudriere erases the eviden= ce, poudriere -i does not work as advertised, pkg's configure script spawns sub= shells to prevent set -x from working, and the subshell directs error messages to = /dev/null. After getting past all that, # cc -target armv7-freebsd -o /tmp/a.out autosetup/jimsh0.c=20 in the pkg source directory results in undefined symbols such as __eqdf2. # cc -target armv7-freebsd-gnueabihf -o /tmp/a.out autosetup/jimsh0.c works fine. # cc -v FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvm= org-16.0.6-0-g7cbf1a259152) Target: armv7-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin From nobody Tue Aug 15 14:24:45 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RQD7J0lZLz4mTV0 for ; Tue, 15 Aug 2023 14:25:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RQD7H5N7sz4KmY for ; Tue, 15 Aug 2023 14:24:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-52256241c50so7441380a12.3 for ; Tue, 15 Aug 2023 07:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1692109497; x=1692714297; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8r8xPuE1HNAyxpPAXkoAEBKEsiv8KDNkXRhmBqu2WYw=; b=r9fkQ7yKTBVtiBqmB6OhGcR3Te8UqTWRWryusK7b4rxDPW0JZETyBG4bO+BfTB1+0y 14S9TYRgIr2d3SteqocGlNDyQaKDQSF9AlTP0dqej1Nv2WC7Ez4U/Pqrj7EdJg27f+Ic ZiR1MnGqYWJckaEHu1jiT/gp73wuhLkbqtOws9VchvXarYf+nSs3sTj5PggrVT4RZuJK ArfXbDWRG+h8Yl9UkAPMbDOs/1u7Ux8faEw+IfyABvGlAzyPMKckOpds3jcKyIGmD6rq Uyq+Sc52dADUMj70IbP1eNUdu/aKIQSqiamIWNfjfSMabM0mqGQe0B3+Cd7m40g5umQW SOgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692109497; x=1692714297; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8r8xPuE1HNAyxpPAXkoAEBKEsiv8KDNkXRhmBqu2WYw=; b=WzHi5b7kABpRuph6fH7C6U69Ev8skCWs6tPMrZDS87830XmnFEuGLbw7Yuqp8CLC9v Tr+P1dTFlq4ANW3WlA1ioOfSAa6f6kTYYuLIOU+DAVWdAEXqIlkxO6Z7z70KAWU5rekC 0WPoojvyCB6b8WBj59zUGhi/h0fhX0iaCMK5F4I9o8ItGRwWAwDLOLIqhjnrYZN/l850 Yy/nJt5YCOg2Emm+E0PcsU+dtg64aRBYTcAkCBCT9p5m3pB9a4bBjC4jwvSmkpfJONYx w2F/RuoLaAZ4jg9msyqMpL4RB2zQcZWAwsGEl+IejVKQ6K4SVHZ704CRYRvKFhjXvZMe 5Qwg== X-Gm-Message-State: AOJu0Yw5gPJvqJATaiL9H9tPz1MFMbz+awM0dXx4PGwKFO8cbUapjdxt UTl7+OxPbaFFP/ThRCmKwyDRcdy+4NCGykZ9MWkYXU2VQSczSmleeLk= X-Google-Smtp-Source: AGHT+IEcJuQDy+zrl+CpuBrBJsOisSVbtyhhTx4IO88fzF5aFNtgCp8hzTmosu0Afepli0cuP7rFnYJjbnQnF3Th/ow= X-Received: by 2002:a05:6402:1245:b0:525:5ed2:abed with SMTP id l5-20020a056402124500b005255ed2abedmr5365077edw.30.1692109496490; Tue, 15 Aug 2023 07:24:56 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 15 Aug 2023 08:24:45 -0600 Message-ID: Subject: Re: Float ABI confusion for armv7 To: John F Carr Cc: freebsd-arm Content-Type: multipart/alternative; boundary="00000000000075b2c20602f6f131" X-Rspamd-Queue-Id: 4RQD7H5N7sz4KmY X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --00000000000075b2c20602f6f131 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There's two changes you should look into: (1) The -m32 for arm llvm change (which has been implicated for other issues in other email threads): commit f1d5183124d3e18d410ded61e45adb9a23b23c83 Author: Mike Karels Date: Tue Jul 25 18:58:51 2023 -0500 arm64 lib32: change clang to allow -m32 on arm64 The FreeBSD driver support for clang tested explicitly for 32-bit Intel, MIPS, or PowerPC targets where /usr/lib32/libcrt1.o was present to decide whether -m32 should use /usr/lib32. At jrtc27's suggestion, simply test for a 32-bit platform rather than adding arm to the list. Upstreamed as https://github.com/llvm/llvm-project/commit/3450272fc281979388bb845a9fffb59= b42cc2e7e Bump the freebsd version to force a bootstrap build. This is one step in adding support for -m32 on arm64. Reviewed by: jrtc27, brooks, dim Differential Revision: https://reviews.freebsd.org/D40943 and (2) Some of my cleanup: commit 2726978bd801ceca07075f150d6ad9ef55470a21 Author: Warner Losh Date: Tue Jul 5 10:16:19 2022 -0600 Makefile.inc1: Remove redundant test for armv[67] If MACHINE is arm, then MACHINE_ARCH is going to be either armv6* or armv7*. Sponsored by: Netflix I suspect #1, but maybe #2 is implicated as well. Despite looking like it had an earlier date, #2 landed later. Warner On Tue, Aug 15, 2023 at 7:52=E2=80=AFAM John F Carr wrote: > Has something changed in llvm to cause soft float to be the default for > armv7? > > I am cross-compiling using poudriere on a 64 bit ARM host to target armv7= . > This used to work. After updating my jail (poudriere jail -u -msrc=3D...= ) I > get an > unnecessarily mysterious failure building pkg. Poudriere erases the > evidence, > poudriere -i does not work as advertised, pkg's configure script spawns > subshells > to prevent set -x from working, and the subshell directs error messages t= o > /dev/null. > After getting past all that, > > # cc -target armv7-freebsd -o /tmp/a.out autosetup/jimsh0.c > > in the pkg source directory results in undefined symbols such as __eqdf2. > > # cc -target armv7-freebsd-gnueabihf -o /tmp/a.out autosetup/jimsh0.c > > works fine. > > # cc -v > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git > llvmorg-16.0.6-0-g7cbf1a259152) > Target: armv7-unknown-freebsd14.0 > Thread model: posix > InstalledDir: /usr/bin > > > --00000000000075b2c20602f6f131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There's two changes you should look into:

(1) The -m32 for arm llvm change (which has been implicated for othe= r issues in other email threads):

commit f1d518312= 4d3e18d410ded61e45adb9a23b23c83
Author: Mike Karels <karels@FreeBSD.o= rg>
Date: =C2=A0 Tue Jul 25 18:58:51 2023 -0500

=C2=A0 =C2=A0 = arm64 lib32: change clang to allow -m32 on arm64

=C2=A0 =C2=A0 The F= reeBSD driver support for clang tested explicitly for 32-bit
=C2=A0 =C2= =A0 Intel, MIPS, or PowerPC targets where /usr/lib32/libcrt1.o was
=C2= =A0 =C2=A0 present to decide whether -m32 should use /usr/lib32.=C2=A0 At j= rtc27's
=C2=A0 =C2=A0 suggestion, simply test for a 32-bit platform = rather than adding
=C2=A0 =C2=A0 arm to the list.=C2=A0 Upstreamed as=C2=A0 =C2=A0 https://github.com/llvm/llvm-project/c= ommit/3450272fc281979388bb845a9fffb59b42cc2e7e
=C2=A0 =C2=A0 Bump th= e freebsd version to force a bootstrap build.=C2=A0 This is one
=C2=A0 = =C2=A0 step in adding support for -m32 on arm64.

=C2=A0 =C2=A0 Revie= wed by: =C2=A0 =C2=A0jrtc27, brooks, dim
=C2=A0 =C2=A0 Differential Revi= sion: =C2=A0https://reviews.= freebsd.org/D40943

and (2) Some of my clea= nup:

commit 2726978bd801ceca07075f150d6ad9ef55470a= 21
Author: Warner Losh <imp@FreeBSD.org>
Date: =C2=A0 Tue Jul 5= 10:16:19 2022 -0600

=C2=A0 =C2=A0 Makefile.inc1: Remove redundant t= est for armv[67]

=C2=A0 =C2=A0 If MACHINE is arm, then MACHINE_ARCH = is going to be either armv6* or
=C2=A0 =C2=A0 armv7*.

=C2=A0 =C2= =A0 Sponsored by: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netflix
=
I suspect #1, but maybe #2 is implicated as well.=C2=A0 Desp= ite looking like it had an earlier
date, #2 landed later.

Warner


On Tue, Aug 15, 2023 at 7:52= =E2=80=AFAM John F Carr <jfc@mit.edu&= gt; wrote:
Has s= omething changed in llvm to cause soft float to be the default for armv7?
I am cross-compiling using poudriere on a 64 bit ARM host to target armv7.<= br> This used to work.=C2=A0 After updating my jail (poudriere jail -u -msrc=3D= ...) I get an
unnecessarily mysterious failure building pkg.=C2=A0 Poudriere erases the e= vidence,
poudriere -i does not work as advertised, pkg's configure script spawns= subshells
to prevent set -x from working, and the subshell directs error messages to = /dev/null.
After getting past all that,

# cc -target armv7-freebsd -o /tmp/a.out autosetup/jimsh0.c

in the pkg source directory results in undefined symbols such as __eqdf2.
# cc -target armv7-freebsd-gnueabihf -o /tmp/a.out autosetup/jimsh0.c

works fine.

# cc -v
FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-p= roject.git llvmorg-16.0.6-0-g7cbf1a259152)
Target: armv7-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin


--00000000000075b2c20602f6f131-- From nobody Tue Aug 15 20:54:20 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RQNmt0FSDz4qQ5P for ; Tue, 15 Aug 2023 20:54:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RQNmr179Rz3bs3 for ; Tue, 15 Aug 2023 20:54:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=uRgtgSJx; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692132873; bh=7msghKQp/uyIgRdRIhuk0LEv7ElkECJMN1dJo2mBuBs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=uRgtgSJxYHYnsXKpKuYPG4VURQiObtfzdNhzMuC/AYU9gE8fE4lhsCSjEliafHMliSY7rH+ruca8sHRg/+sMA2rQlPJ7PE1lVo/GtUV5yS+iOQ0UBJMklESmXp5I3ru1P96OKgGuN3OiBNdgL8AEieA/K4vRCqqVWA2ipcbTR719SLmii7eDr0/bQxY+PNNwPLL//jddoGCMYksIaTjv+E5nBnzt11fVicfN2EIQYMxUvrsAshnC+18qVFJjxIp18c6Y4ciN2z7yBAqph048NR+5VGB4YvKQgkjVTusAMT6UaHrV8NkZFreWlUR/YW05A5p+FPmY7sy8z52O/SS5mg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692132873; bh=f/wmzX5pybl4b++l0kOwlkeIiZcg1h7AGfotfD7NzK6=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=HraFK43PE6QkxOv1+BuuDRshkCvuSuzHGZRuxzgZoUsIwGk+KCRuBBzE79gU3OEcg6inpYR48gdhdfmGuZ7rdMyk5UG/6Os1c3VuoWnQTPsRAvxSe+itShTFTBj9llKpxHyT07Jgtn3xT1VUEm8e2uOUk7tcJbmlxi7awtsdBJVJ3oA0UqV1O4Q5qRoeA1ZSVbqZlAH9oorm+SUMdCDH67PxFdgBnCkG8U5q/a2UqhZJWUBntSKPTRO1tDPKlOjJP1h8EZBF+k7/eoCkiwdNjXdzQt5N/qJiGnBx93QC7tJtWuq+kjUkaDKnxDADfcS+AW3BEMDCVBoq8P+gpzxkpg== X-YMail-OSG: jjXJlvoVM1ns34Bh7yqwkybCAUFW3OCm2gQPVXGtxXq3Igq6ATt5RjppBMJZvx. 18eWumIpWFqhJT_i0xFgxQ9ZpKtvyxbzT0S.xrFENUwVtcDvVfTvxatYGQMrt1fTuBTLORpNS1FJ ozXegeWXa_trR.RsnfxoewGJeDYCZDCQeGJVhmzaSTafslSeBI.uG3rf.50PoZNRWhD1UtBlA9W5 navoRVkT7B.uwk12IjmRx05DqNRhUXcJ3p6a9JUOi3MFVrfAhmMO1coTcpsWyi5WjWJInCjmFtMM NWzZXQPFopCvF8bzMsFHgpvR_Bpm6U2x_IbL5xu5kHBQB5OD0ccCX2V0MjimQRSOi1AQrKDCF1sD ytDnXAPuHge4xaCfeFrDi_vixC0UDUrFltkRyhj.VO9Wd26I7q.kZAp6AH_ILx6waZ.iEFGYjeRE vqCGhplw.kqRDEgTQgDLAQ24yk0RXd1G1vop9V.qrpJFgXuG_rHv5NifGAGNoDbN7R7CFciXVWtP bQaVescBLAXipc3RyNRJ44WxaSt42Xk5eDVabUxiWDqDHP1yLP4KqqlM2c1hnD0_3UOVajbeqX18 1L0cC_nR6esw9tX0Phyg2vvFsLLTTMYAzz2_4TXCCAbgjPGMt3n6REYJUSmrwLodCQXE2pCAEPs_ Ryw9P2e0y3So.d1FujHjDjONUqVwjU5nsTT6Mwf8uBgdTsbsQOOvQXBFH.tZ23MGYIKxPlUC24fd 8HAT8OQPB6tahWJT1eZTzyDg2twLq5nl8TbkDItiS.bOGEXuU2jx5ESKs86xNNc8zmWBN20vsWVz gGk22fuEIywqQuALH5EyE9b5c3eBw6dmdqGEcfidfNMQp_i7znAEFxHE6n7w4rC0w2CgE.Qu7s.r lhp_4n9Sm2oIliI_H1G7QooYtFWG.gczGNZucB99RGhtiGYbmsjvLTK3fOXwHr687RADBlgteuIc phzL9hSAfvaHqUWymuCh23aNhSDcYRrQ2xOV4YCnYqtaNeR_.Oncasqf17JjIj.2iS2vC7UfEuM_ IgduRM8n3_.nqfMaBiYQr7zBNhAim3Sy3cuQwVDUrc47WHSu_QkG4v2cUKTqt4mP0AENNCaWpAfl LNlZEP2dd1ziKA7uR.VrxpnIojiiscxT56OBs3CrBAy8lRFWNs.D0Pjz8Mg6sRwAGWAUAfPTNE74 l22jvRQwPkdi7eo.XrS8KF1DWYpCiScJwjN5CfkxfUE1jjJ_oey_OOLg7EH2slg0WjGbShUsBt7m XosH4cMc28WHB1mTj9FQqS5Qmq_v8M5V8_MPE1XYyZLhXLd8_LeixpI12eGUXN2ct533Qw.8eNth zGJuac_FGJn6cgJ5.R1DsvIPD4QfpCpMrwgNidQE0AchtuJrJ.GCEZYPVYcGroMIudq7jiTtd_wB maZZS3aU_1OYlkKJZKIwCpcYEw9kxcrVL.ERl6fKYqpV4NSQLPvmBTOY1oEseTfqat_c_xDHenQB 4HXzOFu_xS_TOJRX_1_X5Qp8BriGhNuRz5HwR8g8Q7CjWkkx.89B9QHjt89kwVA4ngRdyNNjYWKj uO39Eg1.yv45rXD1pnLMkxmBz6hs.DwlpnJ_Uf1V9oPvThOVKCl3tbc4_fooIrtqzttLBhF9G.qz omImxaVQZn4vMTSF2J68tr84DYATdRZl6D_xY65DllIL_CSYU.4qZ7QEw3TZksCJX.zLjJgGPjIB tjl70y0wKhI3QVLSI5NaxeStM3hqRn6Z8LwLvgpeO6iJ1wpRwMRcisfzvKuZUgoq4OnOxppM.4LA Z_b1EL68lIZvE_c2gfRJaUekoosq_dFEkdJkCCCpN1XTs4FI3OkcT7hvrpjic2y1svdRcw4fPBdn LY8W.CpONrZF0oq.nPzT0raUmNQCYiNHv0RtALmUnToz.zuBxnTNRTMwxwDtvVkADBr1cy_748_V O6kDW4ns.Tdsy9Ey8z8CWLVjP7R.mJxXHlKfTyv8r5c_bXgMR6H5tls4clwqL0kC7tC92TRCrt51 SEA78s1H4bhZPtnOPQM2VLCmHLeelpVG5sQRWwKAug9Qx9N3DNP9.Nb_NAstu1BZKgSbsTAZwBbq .QrHuXkp.vusMYLTIQ58r2LUH.F3kAybgTovgZnlUQlk_2qpDleNduA3IHg.3CUmjdlTwShB8.yl qvuBaTmXkCvC9hVUnQ0BwMir6RpANgxbFdIHq7L6ZJHtLl.Z03vuyrSVNqUHxtdUeWPZXFr2GPct RPTbYQZu95RqNGCiBjJvXF0.r6zdFfhbH3tH73VwUOYG1_S_AymwRQ3EWatcZ.Cu0AfqfP4_6EQ- - X-Sonic-MF: X-Sonic-ID: d9485ae4-c873-4dda-8264-ff4e0e451087 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Aug 2023 20:54:33 +0000 Received: by hermes--production-gq1-6b7c87dcf5-rj4xx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8c48c3ab19bf87692ea874fda1d96928; Tue, 15 Aug 2023 20:54:31 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Float ABI confusion for armv7 Message-Id: <9A9C620C-B8D0-4366-AEEC-CF59E0848A16@yahoo.com> Date: Tue, 15 Aug 2023 13:54:20 -0700 To: John F Carr , freebsd-arm X-Mailer: Apple Mail (2.3731.700.6) References: <9A9C620C-B8D0-4366-AEEC-CF59E0848A16.ref@yahoo.com> X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RQNmr179Rz3bs3 John F Carr write on Date: Tue, 15 Aug 2023 13:51:24 UTC : >=20 > Has something changed in llvm to cause soft float to be the default = for armv7? >=20 > I am cross-compiling using poudriere on a 64 bit ARM host to target = armv7. > This used to work. After updating my jail (poudriere jail -u = -msrc=3D...) I get an > unnecessarily mysterious failure building pkg. Poudriere erases the = evidence, > poudriere -i does not work as advertised, pkg's configure script = spawns subshells > to prevent set -x from working, and the subshell directs error = messages to /dev/null. > After getting past all that, >=20 > # cc -target armv7-freebsd -o /tmp/a.out autosetup/jimsh0.c=20 >=20 > in the pkg source directory results in undefined symbols such as = __eqdf2. >=20 > # cc -target armv7-freebsd-gnueabihf -o /tmp/a.out autosetup/jimsh0.c >=20 > works fine. >=20 > # cc -v > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git = llvmorg-16.0.6-0-g7cbf1a259152) > Target: armv7-unknown-freebsd14.0 > Thread model: posix > InstalledDir: /usr/bin >=20 Exploring my context that does not get the problem . . . # uname -apKU FreeBSD CA72-16Gp-ZFS 14.0-ALPHA1 FreeBSD 14.0-ALPHA1 aarch64 1400094 = #107 main-n264683-6b405053c997-dirty: Sat Aug 12 23:43:37 PDT 2023 = root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400094 1400094 So: aarch64 But . . .=20 # poudriere jail -jmain-CA7-bulk_a -i Jail name: main-CA7-bulk_a Jail version: 14.0-ALPHA1 Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/main-CA7-poud-bulk_a . . . # chroot /usr/obj/DESTDIRs/main-CA7-poud-bulk_a uname -apKU FreeBSD CA72-16Gp-ZFS 14.0-ALPHA1 FreeBSD 14.0-ALPHA1 aarch64 1400094 = #107 main-n264683-6b405053c997-dirty: Sat Aug 12 23:43:37 PDT 2023 = root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm armv7 1400094 1400094 So: an armv7 poudriere jail context on an aarch64 system. . . . [00:00:09] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.20.4 [00:03:05] [01] [00:02:56] Finished ports-mgmt/pkg | pkg-1.20.4: Success Looking at the log file: . . . =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 env: NO_DEPENDS=3Dyes USER=3Droot UID=3D0 GID=3D0 =3D=3D=3D> Configuring for pkg-1.20.4 No installed jimsh or tclsh, building local bootstrap jimsh0 Host System...armv7-unknown-freebsd14.0 Build System...armv7-unknown-freebsd14.0 . . .=20 But: # chroot /usr/obj/DESTDIRs/main-CA7-poud-bulk_a cc -v FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git = llvmorg-16.0.6-0-g7cbf1a259152) Target: armv7-unknown-freebsd14.0-gnueabihf Thread model: posix InstalledDir: /usr/bin So my buildworld and installworld sequence into: /usr/obj/DESTDIRs/main-CA7-poud-bulk_a got clang for a default of: armv7-unknown-freebsd14.0-gnueabihf The only thing that I know of that might contribute that is specific to my environment is that I cause use of -mcpu=3Dcortex-a7 in the buildworld used to fill in /usr/obj/DESTDIRs/main-CA7-poud-bulk_a . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Aug 15 21:02:25 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RQNy82bGxz4qQNj for ; Tue, 15 Aug 2023 21:02:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RQNy7526gz3cTC for ; Tue, 15 Aug 2023 21:02:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Nmtxa6m2; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692133358; bh=WS3G4r9Qw3tKf7dQhLcsAhR39ZNZcqUWuL+pICiG6CQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=Nmtxa6m2osVipOSi+l8avnneClOajLQU9WzYpA4XyAQJwMYqF4ifTczHCgMUO6yiiAb7b/aUc1+G2LYtAqEWV2ZGbt6g6lT+i7FGkXoqLcEr51gaZK90sxIU/qRgDUqQDOg2L66fOPbIMtsBi+hDf+6dYVTBz6YCTH3JT3E9+K3uC2trwbpvD9ReHbHwbbz8t35lwk3GETxTI3QgAIle9+NtKBXebr39eYh7Q+0XuB2RDlQCOryg17YxHnB5pduAJeMijgVs/yLbnU1oDCTv2QcK3DTxpfUPRKOqn8CRuDaDVIT4E+mkb5fr9bXWsMRmhLYpqycZluEkmt6agwR8Nw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692133358; bh=ZpyPf3nK5TrTh8/HbyYj1Znn9AQjsYcdNkLdXItFi4T=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=LBPn2KA217s/qt3ULx1h8/mfWp3ahyzWQEIX2ANe5d55NXJHMSFiV2NW0I8KzHZa7RruYt+EhdJSigC/qE5emcpQZj7stjqFcARuxuu+P1wFBkcPXwFWaTYcKm9r7fi8fpmT27RaG8qtiQ5OjnBiEIbCJogoL2vu33IRsZSC4fXzIMdXTecr6DpyemDc1UQKoExbMw8sKEby2tluvLoQpTJk2hVnA76pLqyeTiNVrR45oqVBenQqS47iEAv9wYCOAQcVia6hfoYdzTaB5jppAI0Wito4X1AC0jpVa1lVnBlB++5s80aqEJLCFkKwL6ZCTq35wEVkDzY+bPXyUEpr0Q== X-YMail-OSG: IItbTtQVM1ntVH4vlBr3IUblL7Ea3VULshpKvULE.4ZQX4EMYl18lKwNyBu7giC WhomhaOINyNjbQ4voW5C1M9TVoRJqr93ZbwhTanwrVb3PS0bAdS3WofeEruvXMjdHj2PCVjuERGw LPJzhqiciGFC8.tCFdczWfIFkttIMR9ti3mznXCF.u_ZV5T_PcaLCCCnzVNUy4fgMFqdBlZw7x_c Vd3XUlgMZYJigpFw539ablNwkhQjQUf2Bu02AHUTcQMzq08l8wk6rBc7ETmJKYtJd7kA0xnSmDg4 eYAR8DdnDbPHA9qZbMoL7gRuQZMQsESIXSOjADRYxSEm_V5VONOgGXztP8oofsWhy6rY2zSoIaT_ Jyj4QgxbkYPNmjbECAeoHIsH39BkuVV.cV3kuF3AoI1M4_t.u1uEKJ8IWkjAyGKZ8YLf4_IaawnI I7.YLpiAvFzNjKrMInMN.aXvddCDUdQ7C7lkp2jdtoclb4Wm61eSGi_C6zvNqMM7l6E4tPwguJKg LMokNiUrGiLkfNZw7EEV1YJWS8E88YteApZCi8XJsNGxpbuluu_MMkl3ZCu9lE.cK.fGqvR944gz xu394kA7tCjWi45eUeaQ7w2dIbo42Et_AkxxH20FE648NV1oGIx33G74KLtMhQf9B1VhYcNq4gCk giJiONQrALxYTr55MDJ62WLlnmEchAczJwly1iwNOKaZw7W5vgqo7U7Xlh8RDLBeo4z1ZJotJUf. 5ezRPl3.O8Mc1VB.p.MQ737VTqqiqQXpxh885AXttEIy8XOWW6uEdnFzKkB47UhGKYbDnUdE9kh2 mmRzuMuwbQ0Lq5.G36yrNXVsofutbACkdrMed9dZYscdLp_fXA_3EcDRq0dOmpcjIhk6lnFmWpFR DEw4FA_FN4txnmy08iZl1zpK98z7fswBuMcOD22GPRXeFFeSVRt4NWl9HzMjhgMlQrD0UKQ4KRCE RsfWSI0nYZzuq89BU6p1qfJO4LLZaAQw6VPz2_E9V7J7VNwUtKzdMXendOWj3bNjaKVAO1qjzmA6 q6FDgR0meCTyjOT8_OhGH7NNkAVljOj_N2.wOxeESigqSWWL1K3pG5lgGvyjgIxz18hvAo47_kSE hkdO5SXSKWiYoQJYs3dD9FnKcW01Yq_z6TsYDvgSHqQtKiCSjMHJ1NEN5nYofAF7qPBiq5aeu64f 0oyPftFtKuZLDbgZQz05Xn_zptmgoDZ0zutwfiZDywr68l2pj1OmDQgdMjyIfskV53z3G3AH3XNI WFQwh5w1GcC6kPdpwrQVG37Ao53dk9WU607jNUcpTK3E4mpZhjnm8EGC7ViLH7tZDeqDF4CaeDfw RidPYa8toT8jt4IgPSCMOE6DtJbYdjf7oWUA2qnpAQ7qqxH2i9X8uz4l6SyVpuWkcyPtLsLrwOo7 LfWA8zdVEaPBYM_rjYc57jklDrY7kJ9mzn.O.DBuUvlElbcjtLNYbgRqK6nNYUynpie0TOqpHJ5w APOGwrihmblPioUJESpjHgEmbxCaEPURGYwgAWZk81ELiS2_wW_Up0nV4jsC6Dy668qZiLLyjH8g JbkuEkGE5OWHC0V1RUpKL0SC_VWe72fFTXhlN9cY.XtrOhmD.G45c0L1vanb9c67LWdtOdB7llZ2 MlL30dBJRjJBKeqH0jJvdxkxT8rAv2Ls82W0Twnh7K6pW72uhWK24lai_BIGGh3S6jaLXlAkD5L8 zFOEEFTYFnmwRDSb6HX9sfMMASBfV62DqKcvD2UvBxRixN8_PJuygrw.WxXvzqBqEUYBgOaMzxOQ O_Pr7Y0raCa7pqT.2JWX7Da4uJjp0c1.ixSLAtV68xxWOIaD1dLo3FnpOuDCv8p3y1SfUR5GEkDJ wZpXx73t8Etf2hUPc269.LC.EN0qtqRp9XlR9wICw5vjME_GPBDJseJbCkV6ifTcuavn45nqBWbK 7xkINKLu_bEzYU6Wj009ziaurmfI4hzaGWduZHqT_KKvhtVld6muBP.LO3qa1Tlnpuuiv5Wy.G3p 0gUxcnrMJDDbCOTrr2gHzadsjcHAO4ndGXmeAWnb7B7oocf5BHRPLMfecIaJQKo9IWhRCnVMhh1y RIxcxzdx227kvWq77Xb4ffjj5t06rJ4CtWGhRjygUxilBQuNEV98ZxUdj286xCzAtJ9Uv1TKUxst UlkBodYw89K5ECsnw8gbRQNcMrXT5pWsz.VLNlm7Zxo_I84c1N6VBtbYGFmlQhJKDDard1xA6lwm jX1f1iV.BbGNFcUaXiIrnESlvw.9iPL4h2Bsu.Y19fsmI0TTZd9cBU0CJn53S5.99yaid8zbbEzA v X-Sonic-MF: X-Sonic-ID: 663dd266-95ad-44af-b885-32f9395945da Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Aug 2023 21:02:38 +0000 Received: by hermes--production-ne1-7b767b77cc-7tm2h (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID adf9928e37854217bc295f890c09f82e; Tue, 15 Aug 2023 21:02:36 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Float ABI confusion for armv7 Date: Tue, 15 Aug 2023 14:02:25 -0700 References: <9A9C620C-B8D0-4366-AEEC-CF59E0848A16@yahoo.com> To: John F Carr , freebsd-arm In-Reply-To: <9A9C620C-B8D0-4366-AEEC-CF59E0848A16@yahoo.com> Message-Id: <488A7616-5500-47F6-9BDD-2472D3CA21FC@yahoo.com> X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RQNy7526gz3cTC On Aug 15, 2023, at 13:54, Mark Millard wrote: > John F Carr write on > Date: Tue, 15 Aug 2023 13:51:24 UTC : >>=20 >> Has something changed in llvm to cause soft float to be the default = for armv7? >>=20 >> I am cross-compiling using poudriere on a 64 bit ARM host to target = armv7. >> This used to work. After updating my jail (poudriere jail -u = -msrc=3D...) I get an >> unnecessarily mysterious failure building pkg. Poudriere erases the = evidence, >> poudriere -i does not work as advertised, pkg's configure script = spawns subshells >> to prevent set -x from working, and the subshell directs error = messages to /dev/null. >> After getting past all that, >>=20 >> # cc -target armv7-freebsd -o /tmp/a.out autosetup/jimsh0.c=20 >>=20 >> in the pkg source directory results in undefined symbols such as = __eqdf2. >>=20 >> # cc -target armv7-freebsd-gnueabihf -o /tmp/a.out autosetup/jimsh0.c >>=20 >> works fine. >>=20 >> # cc -v >> FreeBSD clang version 16.0.6 = (https://github.com/llvm/llvm-project.git = llvmorg-16.0.6-0-g7cbf1a259152) >> Target: armv7-unknown-freebsd14.0 >> Thread model: posix >> InstalledDir: /usr/bin >>=20 >=20 > Exploring my context that does not get the problem . . . >=20 > # uname -apKU > FreeBSD CA72-16Gp-ZFS 14.0-ALPHA1 FreeBSD 14.0-ALPHA1 aarch64 1400094 = #107 main-n264683-6b405053c997-dirty: Sat Aug 12 23:43:37 PDT 2023 = root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400094 1400094 >=20 > So: aarch64 >=20 > But . . .=20 >=20 > # poudriere jail -jmain-CA7-bulk_a -i > Jail name: main-CA7-bulk_a > Jail version: 14.0-ALPHA1 > Jail arch: arm.armv7 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/main-CA7-poud-bulk_a > . . . >=20 > # chroot /usr/obj/DESTDIRs/main-CA7-poud-bulk_a uname -apKU > FreeBSD CA72-16Gp-ZFS 14.0-ALPHA1 FreeBSD 14.0-ALPHA1 aarch64 1400094 = #107 main-n264683-6b405053c997-dirty: Sat Aug 12 23:43:37 PDT 2023 = root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm armv7 1400094 1400094 >=20 > So: an armv7 poudriere jail context on an aarch64 system. >=20 > . . . > [00:00:09] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.20.4 > [00:03:05] [01] [00:02:56] Finished ports-mgmt/pkg | pkg-1.20.4: = Success >=20 > Looking at the log file: >=20 > . . . > =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 env: NO_DEPENDS=3Dyes USER=3Droot UID=3D0 GID=3D0 > =3D=3D=3D> Configuring for pkg-1.20.4 > No installed jimsh or tclsh, building local bootstrap jimsh0 > Host System...armv7-unknown-freebsd14.0 > Build System...armv7-unknown-freebsd14.0 > . . .=20 >=20 > But: >=20 > # chroot /usr/obj/DESTDIRs/main-CA7-poud-bulk_a cc -v > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git = llvmorg-16.0.6-0-g7cbf1a259152) > Target: armv7-unknown-freebsd14.0-gnueabihf > Thread model: posix > InstalledDir: /usr/bin >=20 >=20 > So my buildworld and installworld sequence into: >=20 > /usr/obj/DESTDIRs/main-CA7-poud-bulk_a >=20 > got clang for a default of: armv7-unknown-freebsd14.0-gnueabihf >=20 > The only thing that I know of that might contribute that is specific > to my environment is that I cause use of -mcpu=3Dcortex-a7 in the > buildworld used to fill in /usr/obj/DESTDIRs/main-CA7-poud-bulk_a . >=20 >=20 Never mind. I see Warner has fixed it and that my context somewhat predates the bad commit (2023-Aug-12): =E2=80=A2 git: 0bc26e325450 - main - clang: Minor build = simplification now that armv[45] is not supported Warner Losh fixed by (2023-Aug-14): =E2=80=A2 git: 43b41bee90c7 - main - llvm: fix armv[67] after = 0bc26e325450 Warner Losh =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Aug 16 02:17:29 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RQWxW0V2Bz4q2lw for ; Wed, 16 Aug 2023 02:17:35 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Received: from mx3.mx00.net (mx3.mx00.net [IPv6:2600:3c01:e000:872::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx3.mx00.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RQWxV0Ms2z4f7Y for ; Wed, 16 Aug 2023 02:17:34 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of list-freebsd-arm@box559.com designates 2600:3c01:e000:872::1 as permitted sender) smtp.mailfrom=list-freebsd-arm@box559.com; dmarc=pass (policy=quarantine) header.from=box559.com Received: from razz.mx00.net [2600:3c01::f03c:91ff:fed5:a231] by mx3.mx00.net with ESMTP id 20230519-1qW66F-0007zT-16 for ; Wed, 16 Aug 2023 02:17:31 +0000 Message-ID: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> Date: Tue, 15 Aug 2023 19:17:29 -0700 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Language: en-US To: freebsd-arm@freebsd.org From: Peter G Subject: Unable to boot Pi 3b+ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-0.63 / 15.00]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; NEURAL_SPAM_LONG(0.85)[0.852]; DMARC_POLICY_ALLOW(-0.50)[box559.com,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_SPAM_SHORT(0.19)[0.188]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; TO_DN_NONE(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:63949, ipnet:2600:3c01::/32, country:SG]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RQWxV0Ms2z4f7Y I am unable to get FreeBSD-13.2-RELEASE-arm64-aarch64 to boot on either of two brand new Raspberry Pi 3B+ boards. (Just as a diagnostic, I checked that both work perfectly well with Raspberry Pi OS.) I have tried several different brands and sizes of SD card (which all boot fine with Raspberry Pi OS). I have redone the image downloads multiple times and verified the checksums. I burn images to the SD card on another machine using dd with bs=1M. If I mount the prepared SD cards on that other machine, I can confirm the files are readable. I have tried both /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img and /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-disc1.iso. Neither boots. The first image gives green LED blinks: slow four and then fast seven. The second never blinks. Any advice on what I'm missing would be appreciated. From nobody Wed Aug 16 03:25:58 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RQYSl6hrRz4q6tC for ; Wed, 16 Aug 2023 03:26:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RQYSl2DLNz4pCs for ; Wed, 16 Aug 2023 03:26:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692156373; bh=2XxhnZAZ3KTh44wy39DHqiERPyt6n32EX4XuZyBj3GE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NIZ0Z/8j17HMD348xjsTg1n/Isij8g10RQjwFLHJyVJo9TcM5U1yLkYNLTDFh0MRqOr/ihlny8FOtC6wfw6P1QMnET92mQ8/u/oryUxHO5MWzf0cBPXsthn92PwEg5OLn6LZbs9RJiJoS+KJuqQHBvihd9WH4Ds7fVp+Kw4hkvDsDd9VIBuQZatf51dZNxyHfl2XXgu2DSCgBwtyzV7EwPIhUAvkkUdfNm4FQbEcMK5VWtR/zVBr1qAvWn+GP+/GaYetNFGGTfXGXg+xKD5arB1R9ydZa9cY9wIyyKc7hjJ5IOuTdwfGxKgF00av2HTxZTHYf3m+pepSzG7L8KpVZg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692156373; bh=c/UdNQZv7UTMBeCEq4J0WbySBiFcQmsBASFGFcDIppR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Z6S5edL1QYylMTd3L0kkFaZ5DYrh41EhJRwnI7ECBG1IKrfMmK/GA81hOzm61rIdn/XasNNpsU3XBGqa5yPBRa9/NNsUZOGruTxsxaBprcHjLiOROGS+0wK1BPX92AaSwUtOQ8KH5s83H16qalJ8KT8jb4wvgPs1rvnINawUuZTG4WPVADLGiCoVuNzVQwycwNbwX2DnWD/yos4u0454A4LCTkSgWMkSpz+Qrl6C8+c9AtKWMzGz+wbQYWKv0wAaItCOAMy65c2fL9nqw3KZEK0xEgIrfgovWTxhx1U0FZTvmiVjHTAG8cmTFr+f3EwAXfbfhttZMqbxa+boYpukww== X-YMail-OSG: ewBKTu4VM1ldOEj_JDxKZ2mE36bkOawN8kd9fOKcIbbY9oNhFX4C7GVNeiWmtnE euZlRFdLCV0hoj2iJbqD3MH..Ts3pEHUaMCkAMRhu6QXL4d7xXrwdfnAmRrt46XjUeiotXN3xryB Meg3s.58FU.PoRwsOOeOoW.Vtt5PWZyftNDom.x5vIb_4FFLxjY8THq6rPyhrD0Ar268pLttcD.D rg.GtAFkplFstRURPz6r.76MX6XVJfeUS3KhJO0tUfIwowNbAHN2ipwXTFzoarpmS_qypTDY5SIN BmDaipm.K4jnm4V4kXW9shnF5G88Gp22DlOWLXBBBZjf_8SS9WyakHdehufnsxdHR730s1zK1NXq pYGbi9G..5e.WHo0W7earGbkc5TxwwGvqmF5U.u0ShENqDnYxwkfaHWJ8cAOsTr5hGRLmHvyzAnm G7aDeOWbfE5BZb58jcQr.S9GmV_a7RDJPZIvbjutl2oaV79TR2pgFlNo2fps4_xa45NYvAd_sJ9k WDERV5JMtOTUfVG0v.gxpSTWcvHg6fgE1MxSBIaqIoLCNW8DKnz9hr3vU7mGIgKVP_koxyhgzVUe 3g.iW6U9K_JgIUg3EI7RnoEAiS2vyvZ0JduSxfDtkV96_Nn9xNFaV.ZciApqsuOSOWuLlm1k4m.N cDjdCoq3zJwiiS2Ri3fWkH_Hy.W.wtZ1KuBpMo4ZRqq46m51QroFergbLy_7Obtu380hcBEIKH1E TTxfqL1Wti_aqVrND_wLGkYpiHbEF7HcKYFOS2dLJQkPvPPhdnv.HtkZ9TykV0SlwYVYe1HuXrz0 Vxa99xmGSmFTjTiOKCYmdm_N8yhDUme3z.iRJJeQknOJADQNE.khD0dpcPO3ysVZV6Ik8UdCIqpl FoRTTHJHRxIER8ovzXu0_MiEBodtDY8ngeyh2lfsfBpLlRFA3fmpD3PqgjI6uY5KWGubn1Fgv2ll pQDH3gmuo4Jrq8BcdO2zz2aXO9LCBeCX4EhUUg7LqHOft2DuQajjSuM7uuJqf0sN_t_cGWQtPcmg 2emcj3p.Wg.ZUb4aSxhkuf_K4STNtcXsmH0DBnWpUeRpIz25xSq06GGSYTv3gfJWpWijiHRhFQs_ MEmnS9F96F7DstKc9Y61llmZzsIo_I.LtYXPIEGJqxYhN0CioDhkLzTanhKtvgY0T.xniHyQ29ZA YFj_wRZ5jXxlpgwzOYzQHvnizX3YloHEhI71FhKK1UenG0bcktDF8PMZZj1n5MVR.GK06L4ukk3. dpkyK21jnZl5LeMfsswr2wWbk2sQRhYslsAukAA1sg68bNtGRUYUk6w_l6nlB65yK.sNPdKnJnoI C.cPpM5HkoXnQJuaGSnAoEWjkcb8wI.jY.9gLGhYmi4yvpMfEwxd7BSLlFf4Jfj2ZLE5_XJAMxaZ Zx_bFJj5ZjBL5WrODFSw6gOdZyORZ83XifVXZQ.Mr8XXlU0Zrva6lTHOOrGnosujmIaSSAhVXi1X _JaL5ThBD_l_yPMqCfsQevYux1EnGd9RUAHbLr9RJnlmNO1uUTAC.Y12up4HjYapAHsDcH4lT.0a k7JNgWt27dO7JAuIoIYJVwcb.Ujm42i2p_DRLSmKhmKUNLQioidqX_wXS4gnKe.ks1i4QvmMHKie S_OlNfk_PxeUlXJ3IyJnL8ipuKvsS1QHaQhQK_8VTlO0r6Py2Aepp02GTZGAHBnOJuHoZHFZetjt RE2YAzWKrKQwXTofIx6lBWKTTSB.gQ0ZimlpRtfaSq7eqDIpUf7TGBwXSis4pJYjLu28Z3xM4JHM yrtP1nMzKus5zCfEzfvPE2GN7bCGwxyzZ39nvTmZY4agOcjTzb_9_TxDo9ECV3IU0UOfKYzjrMbf zWa0SL0wYUM7LC5r12Oe3cDSZVK80JePwhT5FxdVtnB5za6STKWQxDUiAlcAEpHMDTuYZX5HsSwJ CtX0aRJwJBhyWPse.KH3Q4RtYDZ9wpWvoSf6MmkLmv1k050kNT1RAZ5hJdSIo8eGoJEPeWe0BVop iaudswlTHG79jSe0fJfhIQphPYjvT8W1F88.WgQnLAP3TPxKGKM_Pz1K0wrV.13pPpcL2FXAY6A8 F9tv3DLvjqEXKDHi_HW7O6pACGx3f6dVLqnqNOuLF383YYQzaFWeqDN6Jw8pi_q_.VfN5bScgOwf d5MkE5oWUy82giijwuDxpE.WimyxjEDpKURm5kkAJjUVmA5xIL0_21Lq.BAEbnDVYOg5kqzO5UG8 pb0AJ7wbr_l0dLNvyOPMuH9sPrVnLL.qwUOGbWlFfQoRejmK4Lxag.DzInHozYNWU18qPQsSHvsb N X-Sonic-MF: X-Sonic-ID: 6a394b90-e314-455f-a9fe-375c8b1c40a4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 16 Aug 2023 03:26:13 +0000 Received: by hermes--production-ne1-7b767b77cc-4t526 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 977143a125a7ecd140bedaa72e612b08; Wed, 16 Aug 2023 03:26:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Unable to boot Pi 3b+ From: Mark Millard In-Reply-To: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> Date: Tue, 15 Aug 2023 20:25:58 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> To: Peter G X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RQYSl2DLNz4pCs X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 15, 2023, at 19:17, Peter G wrote: > I am unable to get FreeBSD-13.2-RELEASE-arm64-aarch64 to boot on = either of two brand new Raspberry Pi 3B+ boards. (Just as a diagnostic, = I checked that both work perfectly well with Raspberry Pi OS.) I have = tried several different brands and sizes of SD card (which all boot fine = with Raspberry Pi OS). I have redone the image downloads multiple times = and verified the checksums. I burn images to the SD card on another = machine using dd with bs=3D1M. If I mount the prepared SD cards on that = other machine, I can confirm the files are readable. >=20 > I have tried both > = /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aar= ch64-RPI.img It may not be likely to be the issue, but you did not mention it explicitly, so . . . I instead see: = http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-= RELEASE-arm64-aarch64-RPI.img.xz Note the *.xz naming. I do not see a: = FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img to download After downloading FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz , using: # unxz FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz would produce a: FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img That, in turn, would be dd'd to the microsd card. > and > = /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aar= ch64-disc1.iso. Definitely the wrong media: no RPi* firmware, no U-Boot for the aarch64 RPi* , and so on. > Neither boots. > The first image gives green LED blinks: slow four and then fast seven. = The second never blinks. >=20 > Any advice on what I'm missing would be appreciated. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Aug 16 08:49:10 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RQhdR74Wrz4qQc4 for ; Wed, 16 Aug 2023 08:49:15 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Received: from mx3.mx00.net (mx3.mx00.net [IPv6:2600:3c01:e000:872::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx3.mx00.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RQhdR2ltmz4BCH for ; Wed, 16 Aug 2023 08:49:15 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Authentication-Results: mx1.freebsd.org; none Received: from razz.mx00.net [2600:3c01::f03c:91ff:fed5:a231] by mx3.mx00.net with ESMTP id 20230519-1qWCDH-00015M-2o; Wed, 16 Aug 2023 08:49:11 +0000 Message-ID: Date: Wed, 16 Aug 2023 01:49:10 -0700 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Subject: Re: Unable to boot Pi 3b+ Content-Language: en-US To: Mark Millard Cc: freebsd-arm@freebsd.org References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> From: Peter G In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RQhdR2ltmz4BCH X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:63949, ipnet:2600:3c01::/32, country:SG] Mark Millard wrote on 2023-08-15 20:25: > On Aug 15, 2023, at 19:17, Peter G wrote: > >> I am unable to get FreeBSD-13.2-RELEASE-arm64-aarch64 to boot on either of two brand new Raspberry Pi 3B+ boards. (Just as a diagnostic, I checked that both work perfectly well with Raspberry Pi OS.) I have tried several different brands and sizes of SD card (which all boot fine with Raspberry Pi OS). I have redone the image downloads multiple times and verified the checksums. I burn images to the SD card on another machine using dd with bs=1M. If I mount the prepared SD cards on that other machine, I can confirm the files are readable. >> >> I have tried both >> /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img > > It may not be likely to be the issue, but you did not mention > it explicitly, so . . . > > I instead see: > > http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz Yes, this is what I used. Sorry to not have been more explicit; I used unxz -k to extract the .img file before dd'ing it to the SD card. > > Note the *.xz naming. I do not see a: FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img > to download > > After downloading FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz , > using: > > # unxz FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz > > would produce a: > > FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img > > That, in turn, would be dd'd to the microsd card. > >> and >> /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-disc1.iso. > > Definitely the wrong media: no RPi* firmware, no U-Boot for the > aarch64 RPi* , and so on. Lack of a boot loader would explain why I get no green LED at all with the disc1.iso The other image, the RPI.img one, at least tries to boot, as evidenced by the 4 long and 7 short blinks of the green LED. As a further diagnostic, I took that same SD card that blinks the LED and fails to boot in the 3B+ and put it in a Pi 4, where it boots fine. So the RPI.img, the one you suggested above, is booting and working well in the Pi 4 but the exact same SD card fails to boot in the Pi 3B+. Since my two Pi 3B+s both work fine with other (non-FreeBSD) images, it seems that there must be a problem with that FreeBSD image on the PI 3B+. Are there any known issues with the boot loader on the Pi 3B+? Again, perhaps I'm missing something, but I don't know what else to try. Suggestions most welcome. > >> Neither boots. >> The first image gives green LED blinks: slow four and then fast seven. The second never blinks. >> >> Any advice on what I'm missing would be appreciated. > > > > === > Mark Millard > marklmi at yahoo.com > > From nobody Wed Aug 16 13:45:25 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RQqCZ3htqz4qhVf for ; Wed, 16 Aug 2023 13:45:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RQqCY6xVjz4ZVT for ; Wed, 16 Aug 2023 13:45:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692193542; bh=iLgJ+SrZqwed3b4y3BltSIwglqi1Q+os7hV+IZ+GCNs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZpULIxwEj09bydEtdVCVOdD0AtHtYmFu+qbh+01xYxZfJkkeKYiQSbS6KGiZgAAT/hfrquSpcuck4y3t5XPCv11byG6LF6cscwREWCAUzkESVDri6Sb1TVgOaQBIUZRoQukbMIEZ6ev93qM7fPnp4YEJ9qsUDwZ6KfTCW8qXwqe/g9AL2e33yvi4my4Lo6YCEEX78qsStt9ACI1nx7lYbcEVOJ3LDMi/B5JHkwJ3azeVEd1vvdv3/qt2c0ESU0Qhl6seX4Y/S2/OhPm07sw3Qy72rTMCm04xCLgUGxOnsJWaafaJ5GClwj5Q4iIiChx2kRwvPa2GCaU5zjwbbH6TXQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692193542; bh=V6tMqaXEiUJrjXcVi94Wybj/eQVJmc7cSrJ1l/c70bM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=O3KH9iA6uZh9gSVdMGYsPczwe73t4TBOM5KIq7Os80rEwSLi/jlbxgHXMbsr+C/NC1YiU3OL8Jk56fFdP1d0++js4rAOo2ZNBlEcLH/k6dE+mmuURMoQBmvOp6AdLEA8P10xGRJL5QS4HgdPANEWyipZctAsOpFPt7Cn8pMoLx296i2dXGiPGFdrn6OVqWKVnOi6Zdao18vhFBurhKi2MtPRMVZX1zQTNVii2+ch8ABZ9VSSaW23hbycffPEPtbONZxxtwAGinvbFLh+Im5ozuvkvmUB+6o46J7LbRYdzf6T45XuDARDKPhIAlhTYRkZaAX7z0IUYclPg/mYbfygLA== X-YMail-OSG: 1RQyjc4VM1lm2U690ig_y1WxtqJwh_2avNePS6aunbYMdxivBuorWMGoxqVu95O 4V7wboNQsK_SfndBj0076cTdTCMBPA5Py2kwpZJQCvYdMb4XWH9GIyO1qU5o0lOzuDcm2dTvgWhD crSNsTR1T8HBHLhcCE7l8sx3isLje3wLDWp5gkNJOR06E8AaDHjnzsyW4VfEupeeiZDRssZrPxsK HJ5wrjtP3zaP.VCNFCJH6vs_uJ_xhXnlORPpusGZzIOmrDDRMGNQ2DYByrNTKlowPZLu9a7eJmQT UKVpRgxuWffsmCSH11cPqyB1kASaQFfV9QZ8xBeYUfA5p.m4D053UcGEu_4.A9k3R1al73Jr8ULa chx06qdU9h6t8ebU9wcSH9Ho2PshquZrJozt8koEr881.QY_gaAE3jpquWgYZUCLt7IHFVos87cT ZXWk7UJfSDBiq4ATCUA5ibmTywJGASqcuE7heYGmnPPejRzdc2kJRUJWxtVfzPP1qQPMHuGYaFRt TpMebP35hXzS.RXuIwKF1tAUX4HcZp2Ys3xg1Ri.CiH9_IaKRzrc2AwpJu1ZncWHbT0qqZZ5JyBs a5R_VvgGma49ZL1DwW191UzMyURDcrM0e7dTgiJQ7qFpuA4H8NtZO4oG1NUKH2cpq83WSu9Vz8mf x6oCrwKaHG2bivGIAE_7DP6who7SbMr2CXcSr7DOJnQyY2XgnveyB.iJDF.2lYRuo.Uela05xERj 6FR0k5B_HdnCTxEgs2OG0dozMSgr1hceaRXWSIAv5ZsoCr3.63bYJre_SfG9BkcghazuaMVpah4R 3CuUL6Z8x9EXli625KL.E6dU9ljZLYZnp95mM_lSLm7H3qFkSLELBFQ.I8YJgGKVJqVnjdcFxlNV 8GSK3dVDcG1HFcw5dQFzt_yP9MpQWlmOjK2mmbinx9dDxL83G5jr.et9VvXAH9CPzMAPxpBNWcyR 9w253Ue13ik6821jsn.ZJ0rKwO5lBhr2aFr2OaFBx4N3bxPtJlbSWfLWYBRkHdpCkPg16yhhs21W v8NHHF9BOwgB9xreDsrpGavxD_gFRXQ81IyriOmDTET4.8QCfEte2eSprsGqFyAYF6MY.zmayKRh WOBpKoTIbepzO.ziDgpg4QnsqcwXB3coIpGmKvHFbkm7s2CCxYNleSJ10AcexrDnsfWky0uhmBFX e95c8jVIzlyAMVCUtD0xyMNZD39aziEHV20feZ8rmZJlJxfyiIBkLcnPLmEm2YI.O42HmRMeO_Xn 4qw47qPS8.fim6gDMIHHYb58R4aC6WwXlNZzXokgOs6IK_MuhkqA1CPm5kYE12SrzVWPcWGBKb80 x8knEp6t2P87k0LE9uFBSfFMfGA_nWz_xYSays11LYot.E8L2TTLHjlrkkOgf202FjKYMhx7zUFC 13iUPwmXpVaeTTIzV2lBxTd53k.OWnR10C2KA3YkNsqywe16rLLcpgv4QiPeu5HOQvVVnXE11J_e kxaM3IoDark1w0ZLkxIk4XDkT2M_rv5DmNgeYxzAFsmozju4m3S96qox6JVXnkC4S10lgfF08Rz4 PQCFBGXl.PZx82Cml6tYVmFc8TJ_ZLElaWMHqLDy4uUiaCP4_IW3JF8VFi2OJ8FFuoWIPJ9BsBzf iOCXew0TGxcn9EjMi666ROCuhsJl7IYpf88.MRNFVRN9fgHmayMpu4ODsbAglyIHDQLIG6_w70_3 JWqOXJMJy51VPeDmo31uHATqyZPTcJTThRe9Ugulycg_A4UIUdQBY1v1Hbb7letpgspVcvsFdOrY zaU2kYPZO3F4KA8vqaRPKOIWW1620GuCuwgKqPv7PCA6QHGUQZNEH.UBkDMpi0C446xs4yAL_Cgc UUBm_r6g1bIqH8dgFOlc1e.TBx_QuLI8B2.asJUNzquvLYV_vrKLsKWQvjGEMCt0jrKBzRKSTOmF ym16I2Hzaz5ZkdfzdesgxtoeULLMJhzqbOLgjhfKAaGBrj5XL2J8i9S_HC5zCXmhz0Ad5mqt5YdU GUCxn9tCaVYZL08rcmi.5Yxe7CoJxsmzTwEMpM9ul93Kz31laDQIzHumjuM7rnFmeKKqp36klBLj iJDtAQSrxXoBixIQX0pB_RpamyOYLJDm7DRq_oXsPOBVGYrho8dQ78l8IHM8SNdUy77McT32DKcn QU2xoyrp98Ku1oMH1QBpIr0IPM5h_Hgfhow40cdnI1U1KQpsBzxnzLP3Tu4M3qyflRqAa4JmW3YA VzLrN4Bgb30TuBKWX_AFNW1EHrypbMrH4g7J2B29qUuv_KolvY77zqIwXTVSrcKPaQujRHRMwmbI - X-Sonic-MF: X-Sonic-ID: 552d5ce8-e4dd-42d7-a36e-9f04e8dc7d45 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 16 Aug 2023 13:45:42 +0000 Received: by hermes--production-gq1-6b7c87dcf5-j6k2s (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6a158dda014c00ae275f21fe296d64e5; Wed, 16 Aug 2023 13:45:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Unable to boot Pi 3b+ From: Mark Millard In-Reply-To: Date: Wed, 16 Aug 2023 06:45:25 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> To: Peter G X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RQqCY6xVjz4ZVT X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 16, 2023, at 01:49, Peter G wrote: > Mark Millard wrote on 2023-08-15 20:25: >> On Aug 15, 2023, at 19:17, Peter G = wrote: >>> I am unable to get FreeBSD-13.2-RELEASE-arm64-aarch64 to boot on = either of two brand new Raspberry Pi 3B+ boards. (Just as a diagnostic, = I checked that both work perfectly well with Raspberry Pi OS.) I have = tried several different brands and sizes of SD card (which all boot fine = with Raspberry Pi OS). I have redone the image downloads multiple times = and verified the checksums. I burn images to the SD card on another = machine using dd with bs=3D1M. If I mount the prepared SD cards on that = other machine, I can confirm the files are readable. >>>=20 >>> I have tried both >>> = /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aar= ch64-RPI.img >> It may not be likely to be the issue, but you did not mention >> it explicitly, so . . . >> I instead see: >> = http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-= RELEASE-arm64-aarch64-RPI.img.xz >=20 > Yes, this is what I used. Sorry to not have been more explicit; I used = unxz -k to extract the .img file before dd'ing it to the SD card. >=20 >> Note the *.xz naming. I do not see a: = FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img >> to download >> After downloading FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz , >> using: >> # unxz FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz >> would produce a: >> FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img >> That, in turn, would be dd'd to the microsd card. >>> and >>> = /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aar= ch64-disc1.iso. >> Definitely the wrong media: no RPi* firmware, no U-Boot for the >> aarch64 RPi* , and so on. >=20 > Lack of a boot loader would explain why I get no green LED at all with = the disc1.iso >=20 > The other image, the RPI.img one, at least tries to boot, as evidenced = by the 4 long and 7 short blinks of the green LED. As a further = diagnostic, I took that same SD card that blinks the LED and fails to = boot in the 3B+ and put it in a Pi 4, where it boots fine. >=20 > So the RPI.img, the one you suggested above, is booting and working = well in the Pi 4 but the exact same SD card fails to boot in the Pi 3B+. = Since my two Pi 3B+s both work fine with other (non-FreeBSD) images, it = seems that there must be a problem with that FreeBSD image on the PI = 3B+. Are there any known issues with the boot loader on the Pi 3B+? >=20 > Again, perhaps I'm missing something, but I don't know what else to = try. Suggestions most welcome. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259438 comment #4 = indicates 13.2 booting an example (older) RPi3B+ for someone that has one. (I do not have = access to any vintage of RPi3B+ .) This, with your finding that your media does boot a RPi4B, suggests that = modern RPi*3B+'s have some sort of technical change that requires newer RPi* firmware = than releng/13.2 contains. (I do not expect that U-Boot would do the blinking activity, = for example.) You could try a microsd card made from a modern snapshot. If that works, = you could replace appropriate msdosfs material on the releng/13.2 media with materials from the modern snapshot and then see if that boots. I've used: = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0= -ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-264678.img.xz and know it has the modern RPi* firmware. Likely the following would as = well, but I've done nothing that would confirm or deny that: = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/FreeBSD-13.2= -STABLE-arm64-aarch64-RPI-20230810-5abba9619cbb-256019.img.xz Do you have a serial console environment for the RPi3B+'s? It is hard to = get evidence from early problems without such. Capturing and reporting the = serial console output (if any) would be relevant evidence. For example, it = would likely be obvious if it reached the U-Boot stage or not. >>> Neither boots. >>> The first image gives green LED blinks: slow four and then fast = seven. The second never blinks. >>>=20 >>> Any advice on what I'm missing would be appreciated. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Aug 17 01:37:02 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RR70T5Mplz4mVq4 for ; Thu, 17 Aug 2023 01:37:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RR70R5XSNz4ZbW for ; Thu, 17 Aug 2023 01:37:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 37H1b3pp040842 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 16 Aug 2023 18:37:03 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 37H1b3qp040841 for freebsd-arm@freebsd.org; Wed, 16 Aug 2023 18:37:03 -0700 (PDT) (envelope-from fbsd) Date: Wed, 16 Aug 2023 18:37:02 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Odd sysctl -a output on armv7 alpha1 Message-ID: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [0.25 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.88)[-0.875]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; NEURAL_SPAM_LONG(0.22)[0.218]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; DMARC_NA(0.00)[zefox.net]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; BLOCKLISTDE_FAIL(0.00)[50.1.20.27:server fail]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RR70R5XSNz4ZbW Ordinarily one can read cpu temperature by using # sysctl -a | grep -i emper hw.cpufreq.temperature: 65209 dev.cpu.0.temperature: 64.6C This example is on a Pi4 running -current. On a fresh install of armv7 alpha1 (pi2, v1.1) I get # sysctl -a | grep -i emper # There are also a few stray brackets: sleeping_thread_stacks = { }, Perhaps not wrong, but certainly unexpected. This is on the fresh install, so maybe it'll clear up after a sucessful build/install cycle. Thanks for reading, bob prohaska From nobody Thu Aug 17 02:04:15 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RR7by5tRGz4q1dD; Thu, 17 Aug 2023 02:04:30 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RR7bx4WMsz4cdy; Thu, 17 Aug 2023 02:04:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.208.171 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com; dmarc=none Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-2b9c0391749so115528081fa.0; Wed, 16 Aug 2023 19:04:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692237868; x=1692842668; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KWmM1JCV2qWUa7gGd0M/cc/Jkx7cBvp14Lr+YwXTUVY=; b=XxmphxuUWvVPh1E6BHwg+62eFgtAy3+MIdypsWDp70rIDZIl1qKSoA9f8fX4+L5mY+ MS7SgtJo9yT3J7W3LKdW8eMbVmUVDbtDdjx9zGqbtKDYK99tZ4RT91mC732qaaVk/qqr sLM8w9T50CrsWX3ocbsGVMygMNvQfr/TvqO+p/Ca4s6j7a+TI9T8k1gJSsfCuuVuB4R9 SY827nFm4M2xyLS3aSegbG7X5KT+W5CC0BnEg9gYUbxxc01T/2rUOdvO+KEziOx9KLYp IAgi8TB3lYg8hPmy1hgWyNxt8jhhRE5F0/I0NSmfDeD/i4RVkBQHil9SrMNquHh4T3W4 Nm7Q== X-Gm-Message-State: AOJu0YyzWzNVJMZiKu59QRQWIEYeqsMzCYX7jI0Cnj/bxxw2mtzRSeiC /7hNKV3u0FBmPyj0tL8RG211wFPmmNN3mNvDR3Q= X-Google-Smtp-Source: AGHT+IEZkVtjuqkAHqojhzgNIJ/uxAFBLjXVU9bxlrG92D7FOOyL7KZ+Y9sDrNiN94gahBvXwAHvtn+gUZTQV3/bB68= X-Received: by 2002:a2e:9804:0:b0:2b6:e196:68c4 with SMTP id a4-20020a2e9804000000b002b6e19668c4mr2945408ljj.39.1692237867746; Wed, 16 Aug 2023 19:04:27 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Wed, 16 Aug 2023 22:04:15 -0400 Message-ID: Subject: Re: aarch64 buildworld via aarch64-gcc12 got multiple: "undefined reference to `__aarch64_ldadd4_sync'" To: Mark Millard Cc: freebsd-arm , FreeBSD Toolchain Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-toolchain@freebsd.org]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.171:from]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.171:from] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RR7bx4WMsz4cdy On Thu, 20 Apr 2023 at 04:27, Mark Millard wrote: > > Are both tier 1 architectures intended to be ARCH-gcc12 > buildable? I decided to try an aarch64-gcc12 since the > amd64-gcc12 builds of main shown on ci.freebsd.org are > generally finishing these days. amd64-gcc12 is currently broken, after the GoogleTest update, and arm64-gcc12 is still broken with the error you reported. While we'd like tier-1 architectures to be buildable with GCC, it's not something we've committed to. From nobody Thu Aug 17 03:00:40 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RR8s45xQVz4q4Pn for ; Thu, 17 Aug 2023 03:00:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RR8s40l5Qz3DWg for ; Thu, 17 Aug 2023 03:00:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692241253; bh=Ir7AzvCqLnOAyQ8W+9uGIv9PRX+cEl8oUFXznGkM5FU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ygb5rD1YA3jcNQNCfaJyve2uFQEyrS6HkubSYtEroHWX6R53bHiu0XKNMmh1rM0qFgfafQWiiv6mZpqBdlDx6eE8s/RYM2BSHdWtSRLo9rjsOQhqMndmvgGpAzVXt7rppwRovtLaGD/HDhrBkmTmwEHBkCiC/1TA9cg4micFcNb5ChNaHJ8AGL0NdhfH0ppZRsWzL67yNfy3/oYZgVy+abWqJ5gnKgosCBGdBSGlN9TtjMi8HY8H5wKaCl2eWOpkt5BMX4RrzO/CXxgfHXJ09/tGdeMb6HcLK0X6R/K6mw73hb38Pojr9xHkm8507QKcYQ5Es7aJViQrHcbtF+V5jA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692241253; bh=19RhKPbZv5WNg8J+EVZ5LLbEKfwoGpAvx2bSIzTCqZM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AX/e1ZLuQjQiFgYTwGirxlGPiYyTca2wmgsCEvq9aDwAjAI1bz6K54Zyn0B8FamxOJNExGf05uawVlDQuLLgPACS62f7qktbQ/yHN08orxAQOEnjHFc8mHyxGu3fcdWCD3e3edtAPIJrEfw2hjhVanDLypaIqZba4MlhQr5YbBvbPxZp40YFMtNtwIV9BNTqwj86vLRTDFqD26K87P1Z2UdIbWpr1cGtgkuNQz2C+xker3US/jYwlZxy0o4Vxi2mlIrpirnoboU8mPKSSQTyGGOfsHSYswQzCX9AYUVsBAA+7uu4Dgpj5+MBTfAG9XhnZn6CjT4mGqIuHlbKkpZxTA== X-YMail-OSG: Tqy.UUUVM1k1pkRzETkb1Q1_3uutOGB.nUFR9LNUuuLe9FE8pAEWRPBxBziVDwX KGXdfAjJw9pDtZJGGkDM.QM6k4z5bBTjouAA1qlt3o.dIBuM81.kHrS3ReOjlOVp6IGr4yITu_dw oEn.a5G1rmJf53i_RkQRKf4D9vJnv.AzU7sJFUkRVHob3kphdcrqvsXqSpNkoa0Wd9ttuL4lEcbn clrVQiAmWdi2Rc61YbUWL.mPGc54Q8rx2DQly6PEj063sWnUb0bdWWi4oUmPwiOAcQA_6YVHMUrj WdcDwXiXZHa2PxXX6Y7IfHioSosrWHMZghbnl1mLm1078zcD21XeDmZBjNxZIPI.mhb1UQnQtA6u ror3wgUUAOwn5d.F.nW6HKbgU2ylV3tKL4JbGhjsXMSh0AOCK0G13DalPL5.YTQSEHYj1FMNNUmr ZW6uFQsdQAwb1eoQFwumflD1a8p3Fjyl_g3rR82jBVP9fqYtH03Quf4ByeRlU9YMx.pN2yqwVaEH kABF0UnQkqqkCDlAeoYTz8AJT4.Kioo.JCPnYzcmVuIbdxlJj6nuQeKoekgZwT8YOO6unT6bvvGw IneGM9.zN2f.HBY17mVKrUmz2T6a4UTs2LqgadSWpd6Y_W3kSF5Iv94xgvxVtiC6QTOV6PMVJ3PJ .Gmv7fkw0_dQiXzzDjm4Za_ZVQyWCa_c3rIvoQS8Yu6I5EZ81wpDy1y7O2u6GxxgcB7mmJVvGvLq t5IJrPxwC42IC2KcTHGR4GtwDsAYc2wfw67bAZpRbLX1OY19UW9gxOmUg3A3wXrOkNGO5LDKrz30 3x34dRqwAI7fG6r6LICb_cUEHNKVvukV5eSugAXfrajpbg589tPM54hkm04zfPhmNmLGmezwCheo wVMGZceNkySa3e1rY19pvZo6sh107DQlMV4BJiMi0IVxAqd39KdbKt_1JP2BkpndlCNQMqMW5TlD _SQhFgm0oRL3POZEdqRpdXTL9kLe0C9qFQtzqJwSl8qCAZVX_JBOHGjVHOnKWEJ5ondIhFq85aw1 J.p2Mb8CrDDw8mEsOYMaqWh2VSZdRvbyYkWOmopU71zy_TPfVZIAB7xo.QqD6.xc9NyPbH.YkI98 rElNTvTuXMcXtQ2..LAgwEQIRqvyyvbzQ2P1Bba96prcVJQCAJaUj1j2TLa_.kJUCNJjD.fI58SN PlvbPljPXvmuJ_826pcbvulNg76qs79oMVxQOEtVhmVTuwViDhUcNXvtfw_2S5n_iW8D.ym3GxGt 0fTQfJ6tzNTS2EsmfslLWz1gHdXLrlyYp5EpNK7LSq7iONcvBMCy9cBDfvFhJvyQ206k3wMcDvi0 rIxzFZtiubCms89_VpbBBnuL5e28obqUP8LR_U_cJLp.DV.o2H7c0Kmbf_3c.UukshMeJwc6h_AP KFmkKFaVe6.96lbofxZQ65s8PkA7HETTUCMwsZMehKQg4aPScDBRZtgEnDtbhSPxRbGAl4DiOlKj hy4MwDoOYZnap4Ktnzj3KpWPUifFiy8y5uYfJd7FO71a3gNq.TohqeW28PVUJNNNFT.wrg0XMENb DperL2Uo3ZuKMLIm9O8X7ZvgfrzuPtH.D_g3UX9T703bHUekzNM0wWPx_ABszvo1GUegAExAv1_z UFrx2C_eCYEiuSXe5aWGRRI6lfQy7qVzPeRQghe9SjilY0Z0MudguxhEjWV.6L6mK1FM6RlZHtqD uDkabfOe_sZjr0EjHz_hK0e8byKxvA1jLftA0uzomafrC1bp4bSgbXIEaxjokWr3Tx3vBY.M35q4 m6X1WaEd4rjPqZ6czoI7UuvCubjU66Somw1ItuCQrWa0DJ2jLQ9tRoybdDQsclEk60grU_TUnxkb hWlvQIC6Q_puYkp7Z6gEAqXwCmDKRQfUjsQzOs5FgWPt8PJrFnIo_Laxw2UTPVA3W2faK4TSQurh tKdX6lxMJvHu9fRYJvTqyfh8WkR8b5PKz6OdMKPkeajbI2cUoRcjV6pxkbOK_ZgTUVR9HpNYSII7 6R9kI9o6Jriqcz4kNVZ6LXKbZiA7pUY05t3AhSg12.BsWsrDmNvC4MajSX35cdGwHIy57rJJHJrA kJo4aFCKICTx43eIvBNn6UMqRalUIEEBhOpbjxhYH6mXQDjBsmD29eMFtnY.6kGV.0KWM5k.rZml 9WCV2E1gmyIQ3l16ilfqam2.IdkAPLnym38fyWcCvb0QtLvbF0znihykhrkmmV3FwADgAr38KRcv 7dTPM1hjz_XVDdUuIlzTxheXDgM.VdS7OTW_KbB.Asg..dtD_yoqlmv4ubD4R7evgUbULFkkIabH HCOM- X-Sonic-MF: X-Sonic-ID: 8ba870bb-d6a9-4bbc-bda3-620c7037999f Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 17 Aug 2023 03:00:53 +0000 Received: by hermes--production-ne1-7b767b77cc-4t526 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f299f8d3b5d43020ed400237c4c64791; Thu, 17 Aug 2023 03:00:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Odd sysctl -a output on armv7 alpha1 From: Mark Millard In-Reply-To: Date: Wed, 16 Aug 2023 20:00:40 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5FD06339-FF4D-48E6-9701-C6A8AD3822ED@yahoo.com> References: To: bob prohaska X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RR8s40l5Qz3DWg X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 16, 2023, at 18:37, bob prohaska wrote: > Ordinarily one can read cpu temperature by using > # sysctl -a | grep -i emper > hw.cpufreq.temperature: 65209 > dev.cpu.0.temperature: 64.6C >=20 > This example is on a Pi4 running -current. >=20 > On a fresh install of armv7 alpha1 (pi2, v1.1) I get > # sysctl -a | grep -i emper > # >=20 > There are also a few stray brackets: > sleeping_thread_stacks =3D { > }, >=20 > Perhaps not wrong, but certainly unexpected. >=20 > This is on the fresh install, so maybe it'll > clear up after a sucessful build/install cycle. >=20 Sun, 13 Aug 2023 . . . git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no = compatible Emmanuel Vadot is a fix that ends up re-enabling cpufreq on RPi*'s. It later got an improvement update: Tue, 15 Aug 2023 . . . git: 81b41b2ef5bf - main - ofw_firmware: Return BUS_PROBE_GENERIC = instead of 0 Emmanuel Vadot The fix should be in the next RPi* snapshots. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Aug 17 12:40:37 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RRPjy5RTJz4qcnH for ; Thu, 17 Aug 2023 12:40:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RRPjx5hnxz4crX for ; Thu, 17 Aug 2023 12:40:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1692276037; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=WcCT954tBLZA9L0S+kqPaxr3AB9QoiJ4HRZCNawkpQ8=; b=Iyx2v1zP1keKL6iJa+oDUZ/jEWkzGlCk4GpaqdX45nFqquEM3Srl6tTNzXTYKCLyLD6tb3 EAIsacDTHyHvaLHK1s8h1cvKQasYAhpaVcwSbJaZDkPZOAWccOdOQ52nLaDspV/q+CiAe5 PtUWsvlkZApqjWgfbadeXgTCWEfJmvC56j9Y/v4Wl5ZvAKsDiSsbYKWXK6KYKN2EWQYfqR sNa9u/mvwd85/ynO6t2n7g2+ZWaHNmfm0aWZ/zbRwVPZkXDm5Ht6Tj3ouypT3dcvO+yTvp yBY5hC1sFGKQuHyjoRUW2YuhQm2JALaR+XgOHMVK9y+0V/w75N71A60V3ignrQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1692276037; a=rsa-sha256; cv=none; b=tQv6X2+ykGS5iaG3L11+lMBtBR4Zpp5fUGNzUPBR0qcZvUB1BZ5hx09Ej9d0ARk1stQ/A3 A27og4O+yXAut++25hQnKKq3GscUMDz7iUXKw8G1vKldu9f02rDoo7FjmQ241yE0T596vF RZKJAl78jCm+0PWGInhj4SEL4Nzwuq+MBsMk5T9hgV5KicK4aoNdhVtyJGwEvDJck7nMcw 8JDoowPyCvBriD/IdaoXxt1k9EWNRxHGRBFhDLhcYowBbjwdSJIi0Mc/jgU7p0SDc7JzYZ RoDpNFK3/P84uifPWb8XBRjEhSZa5s1GdEuBIiLg9JE68XZryoIoZ99Gcmuqxg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4RRPjx4n8rzZQB for ; Thu, 17 Aug 2023 12:40:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 37HCeb63078586 for ; Thu, 17 Aug 2023 12:40:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 37HCebME078585 for freebsd-arm@FreeBSD.org; Thu, 17 Aug 2023 12:40:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 273178] FreeBSD 14.0-ALPHA1 unable to boot on Raspberry Pi 4 4GB v1.2 Date: Thu, 17 Aug 2023 12:40:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dennis.r.friedrichsen@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273178 Bug ID: 273178 Summary: FreeBSD 14.0-ALPHA1 unable to boot on Raspberry Pi 4 4GB v1.2 Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: dennis.r.friedrichsen@gmail.com Created attachment 244168 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D244168&action= =3Dedit screenshot of panic error May be related to 272792, but seems somewhat different. May also be somewhat related to 259353. I am using this image: FreeBSD-14.0-ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-264678.img Written to SD via dd on MacOS. Booting on a (Raspberry Pi 3B+ 1GB): works Booting on a Raspberry Pi 4 4GB v1.2: does not work and ends at debugger pr= ompt The boot cycles through a lot of "clk_fixed4: Cannot FDT parameters." before panicing. Screenshot attached. Note: a fresh SD image using FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img wor= ks on BOTH. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Aug 17 18:08:47 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RRY0q1PR1z4mTm2 for ; Thu, 17 Aug 2023 18:08:59 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Received: from mx3.mx00.net (mx3.mx00.net [IPv6:2600:3c01:e000:872::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx3.mx00.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RRY0p2nbhz3NDd for ; Thu, 17 Aug 2023 18:08:58 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of list-freebsd-arm@box559.com designates 2600:3c01:e000:872::1 as permitted sender) smtp.mailfrom=list-freebsd-arm@box559.com; dmarc=pass (policy=quarantine) header.from=box559.com Received: from razz.mx00.net [2600:3c01::f03c:91ff:fed5:a231] by mx3.mx00.net with ESMTP id 20230519-1qWhQP-0007Y5-2j; Thu, 17 Aug 2023 18:08:49 +0000 Message-ID: Date: Thu, 17 Aug 2023 11:08:47 -0700 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Subject: Re: Unable to boot Pi 3b+ UPDATED Content-Language: en-US To: freebsd-arm@freebsd.org Cc: Mark Millard References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> From: Peter G In-Reply-To: <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.64 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.94)[-0.940]; DMARC_POLICY_ALLOW(-0.50)[box559.com,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:63949, ipnet:2600:3c01::/32, country:SG]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[yahoo.com]; R_DKIM_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RRY0p2nbhz3NDd Apologies for top posting, but now that I understand the problem better, most of the stuff below is not relevant. Here's the whole issue: Late last year there was a new hardware release of the Raspberry Pi 3B+ board. The PMIC chip was changed; more information is here: https://pip.raspberrypi.com/categories/797-pcn/documents/RP-003337-PC/Pi3B-Revision-9-PCN.pdf The new board is Rev. 1.4, a.k.a. a020d4. The FreeBSD image at http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz boots fine on the old Rev. 1.3 version of the board but it fails to boot on the Rev 1.4 version. I have tried it on more than one example of each version of the board. 1.3 boards boot fine, 1.4 boards fail to boot and flash the green LED in 4 long - 7 short pattern. Not sure what to do about this. Is it a known problem? Should I file a bug report? Mark Millard wrote on 2023-08-16 06:45: > On Aug 16, 2023, at 01:49, Peter G wrote: > >> Mark Millard wrote on 2023-08-15 20:25: >>> On Aug 15, 2023, at 19:17, Peter G wrote: >>>> I am unable to get FreeBSD-13.2-RELEASE-arm64-aarch64 to boot on either of two brand new Raspberry Pi 3B+ boards. (Just as a diagnostic, I checked that both work perfectly well with Raspberry Pi OS.) I have tried several different brands and sizes of SD card (which all boot fine with Raspberry Pi OS). I have redone the image downloads multiple times and verified the checksums. I burn images to the SD card on another machine using dd with bs=1M. If I mount the prepared SD cards on that other machine, I can confirm the files are readable. >>>> >>>> I have tried both >>>> /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img >>> It may not be likely to be the issue, but you did not mention >>> it explicitly, so . . . >>> I instead see: >>> http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz >> >> Yes, this is what I used. Sorry to not have been more explicit; I used unxz -k to extract the .img file before dd'ing it to the SD card. >> >>> Note the *.xz naming. I do not see a: FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img >>> to download >>> After downloading FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz , >>> using: >>> # unxz FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz >>> would produce a: >>> FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img >>> That, in turn, would be dd'd to the microsd card. >>>> and >>>> /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-disc1.iso. >>> Definitely the wrong media: no RPi* firmware, no U-Boot for the >>> aarch64 RPi* , and so on. >> >> Lack of a boot loader would explain why I get no green LED at all with the disc1.iso >> >> The other image, the RPI.img one, at least tries to boot, as evidenced by the 4 long and 7 short blinks of the green LED. As a further diagnostic, I took that same SD card that blinks the LED and fails to boot in the 3B+ and put it in a Pi 4, where it boots fine. >> >> So the RPI.img, the one you suggested above, is booting and working well in the Pi 4 but the exact same SD card fails to boot in the Pi 3B+. Since my two Pi 3B+s both work fine with other (non-FreeBSD) images, it seems that there must be a problem with that FreeBSD image on the PI 3B+. Are there any known issues with the boot loader on the Pi 3B+? >> >> Again, perhaps I'm missing something, but I don't know what else to try. Suggestions most welcome. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259438 comment #4 indicates 13.2 booting > an example (older) RPi3B+ for someone that has one. (I do not have access to any vintage > of RPi3B+ .) > > This, with your finding that your media does boot a RPi4B, suggests that modern RPi*3B+'s > have some sort of technical change that requires newer RPi* firmware than releng/13.2 > contains. (I do not expect that U-Boot would do the blinking activity, for example.) > > You could try a microsd card made from a modern snapshot. If that works, you > could replace appropriate msdosfs material on the releng/13.2 media with > materials from the modern snapshot and then see if that boots. > > I've used: > > http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-264678.img.xz > > and know it has the modern RPi* firmware. Likely the following would as well, > but I've done nothing that would confirm or deny that: > > http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/FreeBSD-13.2-STABLE-arm64-aarch64-RPI-20230810-5abba9619cbb-256019.img.xz > > > Do you have a serial console environment for the RPi3B+'s? It is hard to get > evidence from early problems without such. Capturing and reporting the serial > console output (if any) would be relevant evidence. For example, it would > likely be obvious if it reached the U-Boot stage or not. > >>>> Neither boots. >>>> The first image gives green LED blinks: slow four and then fast seven. The second never blinks. >>>> >>>> Any advice on what I'm missing would be appreciated. >> > > > === > Mark Millard > marklmi at yahoo.com > > > From nobody Thu Aug 17 19:22:30 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RRZdx6xkVz4q3Rc for ; Thu, 17 Aug 2023 19:22:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RRZdx4Qpgz3YNK for ; Thu, 17 Aug 2023 19:22:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692300163; bh=rKLQLQncxO2/LNJ+GDOwCkoMcQeEmU3LJzJRGa3UbrQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NfAzOGPB4YBpJhMuN/cotF+8jCrkpdkgrmnDlX0e3LuI/KN2wnQC7gz46i8NT+iWJKP9jNbGLE7lXFCtzU8Sml1beMV7sULHFhqBHCdEXq7Cx3hL4C7+DXHpOjpifC5x3dasjznakTAfj/7PDlJBowP6NuEVYqBYlAevlAfQwXnQ7sTT1F5hgKDGGfoKik6pzoRObek+Pz8wQHUZ0eRCnNpfKs1tdFH9voY7J1P5wpP9HLR8bfmrFnCAhHvf1msgAD4YkjAgfEAkGOS7zZabqjHhOeECdgdIVG6e1iYLi7PGsvkFc9aqEcJ6dCAIeKO+MFLB47gwfP1AEfHjk9o+vA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692300163; bh=/8AKLJfrPw+g0VXxc9JS9tp8h5JjBXu/n7xVThzqCeu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AdNKMKDoh4RYngYDBLSMA+3DjIMe20W9aZaHRXC/0sSfVE0Z2fQ0m+9N5YarnLD49rJVmJvqO3WaehWTOkHCBxtD05oeKdVmUdqNiTjQXbiaZxR6Inr1aCg6qsC5I6NL/octaM6poyxMACZTDZgVRhajGFEvtbbhts7ERi3rEmgIL83nEUa4JxdZoHWhar8V73zlRDidGWDKzuvR4deTeu95YMxik6D/T9o23C3KtLcYlPGH9ktkIJ8/KMIWYMjXE7LZmgQXCeloyBfovVIkmA0mpxmLdyi8rhSi4e1HJv00jKnQKfw1Kh6sav0lzfhH/XtneAYQqp+Va+wPx2QkUA== X-YMail-OSG: sj8xp9cVM1nsEbAbm9QZIyVf_dHMqou4ol7HVvsEQ5RL5K7lU10gggRxUQv8lnv 5aOuLBUe5MDFPL0erLOaS2AqEVIJlNBEsDdP.oV2bK7Gw8OBoJniCt0ixqg9eJJOIr1Zg_50MElI 94NgleeAiNnVI7ndCz4e7id9DS93H8wDKVv02KRIbV_6yibV1ITpBjqLsEx8PGky04arzhwFOVSo phN0wlYQutY2aNtc.tv18YM7mhJQ5rWB8anJNGItW9TGQnQAj8uy1mZFOtSqXp3kUWEidZ4ckV0e a.K36ss2CBH1xOAMTINh1And2GzQQezbSMktl8UiXAfryrZrFWFJU1TjRNgL68Vm_rlDBdFvf.oJ GRyuTYfpjktF4tWixyYeqFeaswV5SOuQsLwdPI1oiUlhebmdolq4cCJNj9b3yA.ZNMtvREa4tJcq Vo8wtxtHXdC1FquRuNL_EZpASoTCQ5saVp0_oBQTsddNwIhCnfJZfjZxJZxQIuFNLyiRqdu8ijPj L9ye8Pabq8N2ynherXiAoiOXcqICz.oxQeLVSuVhRwo2oEqi5wXfPA4NQP7QGzKo7IyjvQjULfVg 1qOvxySChGMu3QurXcRoxy8oZoIz_xH2rL1s.bUodEdWsUMuTmdSrmj17EGavm7kMTGotq3mEXIO LHY4lasQiomhicUYWH8L8jAoBFC2J0aN2IL_k.FK2lQn5B7M0qEkOPl0GtPnTQKocV6o2HY5hWqw MDFAwPkPQkfOWsrjUGUevGltEIhn2WqxdSPieQhaiBN4AwSSg1QjswNMSs5BS9xE1IT9MogK0H0h duztEmT.JCnX9WOzzm3altPqjz0GV5zoi8XZeAKaiPihM5QANS4Vcl_zSYwOWAKFrbixLPpVOMt6 XrPy05dNg5WJdYWOzYRtFhPxMZOcSYCLisLtdU9YlLu.I4Q88A9XoFHzAhdR3y9iWVfuI9lzQZpH uvZ8McTMlwSXPqvFpo.RXzKA0krgFK0ZVVGfV_Bh8l7tine04yy5U94oCjUjepVuQu9zPayOaJ88 A_sCD2oUTmqRDbrSKxtf2dgYYlmogAQ2..v1R7UbJt5_KeF4kRyOHrVg_z1Rw1NUiFKOc90xdYYZ HXdS.921VEvESxOae3Dh8yrShqxvm3EAYQQhlpK1N4VX7g3XkS0oCy2IGnQ6QTC5s4KUAycchp0Y aLcA2Qh__srdx5CJKaiWwrCHXtFtRdQzdgY7vYuXthRGQ1uakhaKckSKQ_oTT9UNCA2MsoLCFdYr GcUP79TFtDgbRs2xTV6wsx77A9catjobbm.lzYRvSiHfGdxiGI48RhHjCdM0QY_novIwp7bvJaZf hXjt6rBYrstPMOtInQg4CVhmLRnqbd6gyHODtSlAShmgQ8U9U0Mj_sI83a7pbz5vmGzk8XFqK8FV iKh8GVozmv3iSs0T6NVUWm2bAFRIwjHfvsaxiIeE256MVxB.sUtRr4eqvO6Z9w2wO_z.cLca1qY3 k3x6l44Ub7bNVfZWwietVettmt5leeLskYH_Y3b9ZTYDnyBTl_5.JxymW6cX7AJlaiKGnZtqUw1q 4P0nHStCKbsKNFJ4TZd8i7S.UEx_Zzrew9Hnp3DTnoqSDGHtIgfMIW8KiZKhisFR_WbN5vw4BYmo lggLoRKZB8AxJuxCYJa02NqI15zFuKftAWybhRZt1MTeuEMMNiAgjosyrHRWtbgCy1S84a.0Jl3g fcwhrRW6gD51UITU1R6IeVALMapUCfAdJLfoBbx8FYMSkaBHa9zhYKW.JxWaoV..v8oRhY.OWxY5 wmkimOBZW2Q8iTHdE5Z0hk.KyEPlU_cuJy43Z4WtoXtO9YSJunVF1Q5HjwCQYs9sD8itgsCGqQiX qsYgq.rg6eR4iRvUEHQuOcOszLqvivl_dP7zb.jmiHR0hkFkevuBwHTZS74XiXwvsaM958PRhhut 1X6CCkW2_.bWWyhe1gQTaFS9lgAtU0wa_FckY1BCfojGmWJXzf6z3yQ53td_.8n1pLDGe9q1DUew q1HvmG41vEoltITFZyHTbnZVsSXgEpNop3QVyo1vkXY2yJ7DqtDhQdwQSExP4VYB5H9uBN9YWOP0 K3UX.VVjxjJyEARKyyDQJDqow3bazr61i4.nz2OfxrfA3uBFm185hnNgIbxYPrtdenFJ2PU2enwm aXc7XezAacc8Hoz1_cxYbgvEFCiSWh5UsL5ERWjqSdaAtuGNNMc7jWHY85JCjAI59ZkjAGawccKO YJB2w66dnaJI_YA8S8.12G5Cu.6mW3cLltuhFrerRkNu52tNJ7cbZQY89Riql7aILFAlQHfQV5Gi Oag-- X-Sonic-MF: X-Sonic-ID: 8984ffae-7cc9-43a6-a078-3214fca5d3b9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 17 Aug 2023 19:22:43 +0000 Received: by hermes--production-gq1-6b7c87dcf5-qfzfj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 78a17d3eef107774b89aba8984949aa0; Thu, 17 Aug 2023 19:22:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Unable to boot Pi 3b+ UPDATED From: Mark Millard In-Reply-To: Date: Thu, 17 Aug 2023 12:22:30 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> To: Peter G X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RRZdx4Qpgz3YNK X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 17, 2023, at 11:08, Peter G wrote: > Apologies for top posting, but now that I understand the problem = better, most of the stuff below is not relevant. Here's the whole issue: >=20 > Late last year there was a new hardware release of the Raspberry Pi = 3B+ board. The PMIC chip was changed; more information is here: > = https://pip.raspberrypi.com/categories/797-pcn/documents/RP-003337-PC/Pi3B= -Revision-9-PCN.pdf > The new board is Rev. 1.4, a.k.a. a020d4. >=20 > The FreeBSD image at > = http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-= RELEASE-arm64-aarch64-RPI.img.xz > boots fine on the old Rev. 1.3 version of the board but it fails to = boot on the Rev 1.4 version. I have tried it on more than one example of = each version of the board. 1.3 boards boot fine, 1.4 boards fail to boot = and flash the green LED in 4 long - 7 short pattern. >=20 > Not sure what to do about this. Is it a known problem? Should I file a = bug report? =46rom the *.pdf document that you referenced: QUOTE Software/Firmware Changes Required This new product revision is supported in firmware versions from = September 2021 onwards. The firmware version . . . It can also be found for an image by running strings /boot/start.elf | grep VC_BUILD END QUOTE (The /boot/ path is not from FreeBSD, so replace with a FreeBSD path. Also, start4.elf is of more direct interest here.) Until the recent change in systuil/rpi-firmware , FreeBSD simply used too old of an RPI* firmware version (over 2 years old) to work for the RPi3B+ Rev 1.4 (or later) parts. I'm not aware of FreeBSD re-releasing the likes of a releng/X.Y with just updated RPi* firmware (or an updated U-Boot since such is also available now). Any solution must involve replacing the older firmware with newer firmware. But the port to package builder is not done yet --and once it is there is also distribution time after that before the update will be available. One way to do that replacement now is to get the material from the msdosfs for one of the snapshot builds that I referenced: = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0= -ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-264678.img.xz or, possibly one that I've not validated that it has the new RPi* firmware and U-Boot: = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/FreeBSD-13.2= -STABLE-arm64-aarch64-RPI-20230810-5abba9619cbb-256019.img.xz There is a newer stable/13 one today: = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/FreeBSD-13.2= -STABLE-arm64-aarch64-RPI-20230817-31d385e78eba-256060.img.xz The main snapshot build had its own systuil/rpi-firmware build that was used. The stable/13 ones may have as well. > Mark Millard wrote on 2023-08-16 06:45: >> On Aug 16, 2023, at 01:49, Peter G = wrote: >>> Mark Millard wrote on 2023-08-15 20:25: >>>> On Aug 15, 2023, at 19:17, Peter G = wrote: >>>>> I am unable to get FreeBSD-13.2-RELEASE-arm64-aarch64 to boot on = either of two brand new Raspberry Pi 3B+ boards. (Just as a diagnostic, = I checked that both work perfectly well with Raspberry Pi OS.) I have = tried several different brands and sizes of SD card (which all boot fine = with Raspberry Pi OS). I have redone the image downloads multiple times = and verified the checksums. I burn images to the SD card on another = machine using dd with bs=3D1M. If I mount the prepared SD cards on that = other machine, I can confirm the files are readable. >>>>>=20 >>>>> I have tried both >>>>> = /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aar= ch64-RPI.img >>>> It may not be likely to be the issue, but you did not mention >>>> it explicitly, so . . . >>>> I instead see: >>>> = http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-= RELEASE-arm64-aarch64-RPI.img.xz >>>=20 >>> Yes, this is what I used. Sorry to not have been more explicit; I = used unxz -k to extract the .img file before dd'ing it to the SD card. >>>=20 >>>> Note the *.xz naming. I do not see a: = FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img >>>> to download >>>> After downloading FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz , >>>> using: >>>> # unxz FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz >>>> would produce a: >>>> FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img >>>> That, in turn, would be dd'd to the microsd card. >>>>> and >>>>> = /ftp/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aar= ch64-disc1.iso. >>>> Definitely the wrong media: no RPi* firmware, no U-Boot for the >>>> aarch64 RPi* , and so on. >>>=20 >>> Lack of a boot loader would explain why I get no green LED at all = with the disc1.iso >>>=20 >>> The other image, the RPI.img one, at least tries to boot, as = evidenced by the 4 long and 7 short blinks of the green LED. As a = further diagnostic, I took that same SD card that blinks the LED and = fails to boot in the 3B+ and put it in a Pi 4, where it boots fine. >>>=20 >>> So the RPI.img, the one you suggested above, is booting and working = well in the Pi 4 but the exact same SD card fails to boot in the Pi 3B+. = Since my two Pi 3B+s both work fine with other (non-FreeBSD) images, it = seems that there must be a problem with that FreeBSD image on the PI = 3B+. Are there any known issues with the boot loader on the Pi 3B+? >>>=20 >>> Again, perhaps I'm missing something, but I don't know what else to = try. Suggestions most welcome. >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259438 comment #4 = indicates 13.2 booting >> an example (older) RPi3B+ for someone that has one. (I do not have = access to any vintage >> of RPi3B+ .) >> This, with your finding that your media does boot a RPi4B, suggests = that modern RPi*3B+'s >> have some sort of technical change that requires newer RPi* firmware = than releng/13.2 >> contains. (I do not expect that U-Boot would do the blinking = activity, for example.) >> You could try a microsd card made from a modern snapshot. If that = works, you >> could replace appropriate msdosfs material on the releng/13.2 media = with >> materials from the modern snapshot and then see if that boots. >> I've used: >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0= -ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-264678.img.xz >> and know it has the modern RPi* firmware. Likely the following would = as well, >> but I've done nothing that would confirm or deny that: >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/FreeBSD-13.2= -STABLE-arm64-aarch64-RPI-20230810-5abba9619cbb-256019.img.xz >> Do you have a serial console environment for the RPi3B+'s? It is hard = to get >> evidence from early problems without such. Capturing and reporting = the serial >> console output (if any) would be relevant evidence. For example, it = would >> likely be obvious if it reached the U-Boot stage or not. >>>>> Neither boots. >>>>> The first image gives green LED blinks: slow four and then fast = seven. The second never blinks. >>>>>=20 >>>>> Any advice on what I'm missing would be appreciated. >>>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Aug 18 01:17:35 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RRkWR33rRz4qQx8 for ; Fri, 18 Aug 2023 01:17:39 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Received: from mx3.mx00.net (mx3.mx00.net [IPv6:2600:3c01:e000:872::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx3.mx00.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RRkWR0bYGz3PGl for ; Fri, 18 Aug 2023 01:17:39 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Authentication-Results: mx1.freebsd.org; none Received: from razz.mx00.net [2600:3c01::f03c:91ff:fed5:a231] by mx3.mx00.net with ESMTP id 20230519-1qWo7M-0008Gc-1T; Fri, 18 Aug 2023 01:17:36 +0000 Message-ID: <32684f44-cb45-438b-a48b-a09b8a02454a@box559.com> Date: Thu, 17 Aug 2023 18:17:35 -0700 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Subject: Re: Unable to boot Pi 3b+ UPDATED Content-Language: en-US To: freebsd-arm@freebsd.org Cc: Mark Millard References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> From: Peter G In-Reply-To: <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RRkWR0bYGz3PGl X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:63949, ipnet:2600:3c01::/32, country:SG] Mark Millard wrote on 2023-08-17 12:22: > On Aug 17, 2023, at 11:08, Peter G wrote: > >> Apologies for top posting, but now that I understand the problem better, most of the stuff below is not relevant. Here's the whole issue: >> >> Late last year there was a new hardware release of the Raspberry Pi 3B+ board. The PMIC chip was changed; more information is here: >> https://pip.raspberrypi.com/categories/797-pcn/documents/RP-003337-PC/Pi3B-Revision-9-PCN.pdf >> The new board is Rev. 1.4, a.k.a. a020d4. >> >> The FreeBSD image at >> http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz >> boots fine on the old Rev. 1.3 version of the board but it fails to boot on the Rev 1.4 version. I have tried it on more than one example of each version of the board. 1.3 boards boot fine, 1.4 boards fail to boot and flash the green LED in 4 long - 7 short pattern. >> >> Not sure what to do about this. Is it a known problem? Should I file a bug report? > > From the *.pdf document that you referenced: > > QUOTE > Software/Firmware Changes Required > This new product revision is supported in firmware versions from September 2021 onwards. > The firmware version . . . It can also be found for an image by running > strings /boot/start.elf | grep VC_BUILD > END QUOTE > > (The /boot/ path is not from FreeBSD, so replace > with a FreeBSD path. Also, start4.elf is of more > direct interest here.) > > Until the recent change in systuil/rpi-firmware , > FreeBSD simply used too old of an RPI* firmware > version (over 2 years old) to work for the RPi3B+ > Rev 1.4 (or later) parts. > > I'm not aware of FreeBSD re-releasing the likes of > a releng/X.Y with just updated RPi* firmware (or an > updated U-Boot since such is also available now). > > Any solution must involve replacing the older > firmware with newer firmware. But the port to > package builder is not done yet --and once it > is there is also distribution time after that > before the update will be available. > > One way to do that replacement now is to get the > material from the msdosfs for one of the snapshot > builds that I referenced: > > http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-264678.img.xz As you suggest, I tried substituting the msdos files from this 14.0 image into the 13.2-RELEASE image. First, I replaced all the files in the first (msdos) partition. That booted, but crashed when the kernel started, which caused it to reboot, and so on in loop. Next, I tried replacing only the start4.elf file, leaving the others alone. That didn't boot at all, returning to the now familiar 4 slow - 7 fast pattern of green LED flashes. Any thoughts on which files should be substituted for a successful boot? [...] From nobody Fri Aug 18 04:00:55 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RRp8B75DZz4qc2R for ; Fri, 18 Aug 2023 04:01:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RRp8B01X5z3dCW for ; Fri, 18 Aug 2023 04:01:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692331271; bh=WBDZ6TpjHepJuXLk9KKZuSrWmXYDKcJ3MoaGjleTauo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=q49cWIE4Nhf29pUot9e/6WgV7+r0vwY2YCNDPBzfNTvFR2ZSVDDZpaI1ZXYA3QT6Cf2bbH9SJC8pjowKnIUp4a7TtWwhN5pGUATCIlcPQGZUbdpChvt0bVB8SMd5H+L8+3jLG7/6cLE7Lm8hJTNmGNlwjRDCBaNKj7SAFDtSdDnknUMMBmBmHnTSi3WEcmzYmjAaLYVK/e8LuSaE8pcsfB2HvFRqNoT3V9b1WGmf9Ak25IWPLgjexYQYXEf8hdYsjRWL+7nf5Was4pillkYkNlpmd2MCUMC8OswG8nkm/WaQUmp29iXgQOulBtiiUjwDmwTnTw/bBmb3kO7h32HwGA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692331271; bh=qE63lxtpwJ4USSDrXxsv9twx/2uDA/8G5nCLvQLLNYw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=WBA+wF6svfu4oQKswEqYUELBMyTImFVtTaGI5te5fRWtvQdoJ4RPKNiY3mUpEDcGO+vfL4Hxd5Y+DyQHM9VoaiGrQ1N3BlHxpB7UqeMxim5cZqv/Vg5Euei4zCn2SyGaATDglVjgWYioB0skNJ0JrQscXL9ps9Glx9itC931ySVC3VB8s89MHTibTTZ1dlGxbZpSBzDbMdwG2J2N0+CHQSPMvMjWzefnL3GAW6VDKLXbQymF9MwwFUg8gH2+uJsbRuzILQ9NyK6s+2PpQbUMWJmDLVr36Rsw06GkEu7TLPqqM/l1HTfQQhWLQkfWtv9o9OPpSLGeMFkaTNkGcQs7nQ== X-YMail-OSG: f3JoLrIVM1l0GAWFWS1YDfxayoYipR61IuUGKiqZrGAFw_5APe2tQ2fIvFxRjWL EErM5svw4yVjfhaPhnaW5lDm8Ce9dXqyWtRnyUUf3e0Wwsk6oRwL9Nadr7Rr5SZCqHMNSrrm.lWo UIMkPfuyOdzzgamS1QdLc7IY39jIPsVZU2rl49zMk4GSvbear6jKuDeC4utmQlYoNTVrfBCrNB2p AA0JFhWRahPgtZnGHJZlsLbnfCeNRNmDLyplFiq4TSNBSjOTZXF5rL8n1kDc3CyWEWM9cBKK5w84 in2UkjUr6AHIrwVrdl3raDf2ynitKw3kW9eFzEVsUPXEaE5bQoWXxMnaR04aK4cDo_Vfz_Bpquvk kkgYVRWvVA87.ykRlR87booTJyxqIxlZqAR5OXz_im03Awtui6aREK.n531m3Azxiqn1QMb7DkBP bp97nRFoUelQe7iHgIEe4a49qp3nWuxrcJ.XYvUGwFKNAkfUDxREWV5aYn3SwucI9gxr5SOdAWR6 85.OOyH8qfItf6toVAOFEQyZDmBwfDX9UafjdYJeqJ1fzgLJL9IJdLn8pQdYvO9pwzocR3lumGHQ jp39NapJG4EgP7F3mJAEuMgntQl_M5w8bPmVakCb._b8Rt_0G06bBJnmJ8EDOP7isjnBzzP21cJq qlL.H_pOS5ZehKTyhsw0aKX3ix9tpiF1OaiPuYyJSe57oiMHey1i3zdZpURK4733dHVUSphyt6.f nVHLHFhjpuGSQPGXPH2DcKFJ9v_B2aCblg9D.g9hh.nZeCqj6wwpR57TXUWdTkuCAlAWBc8TGRzo R44515b9LtPYafy22z8iqp5SqtbCPiJALNdtP5ca0eODT8euVj7fL8h5HExQXhT6.Bg59EaYYtY6 AIZYI733G2YJA__Ra0ZlnVHyRNbLK0a3hR_h6SMIA0eEZZoa23mJiCCYgTNCZ1psG2IAp3ahQyQT ku7Z_HiTn_vFt2avSnK0YLWy2LRGSl3U5u55elSUz4JkIHkHdP.1m3T7GR_A7Ti38jAUpR6jP6d0 7w5ugZ9puwMtFoqT1XVewC2c0CdCVb8szgC86IoxFgDlNuZ1OoXqRGO.lKcEQhwDzm1XhBFwQxt. PVu7cQwkvD7eFA5O6_9UVyHP9DDXqv3LbK40ws606JFnQMvcnefJipDlTkRLngTYpCS17dWPB0De DFGyVIBpwMO3Yt5HwCkCDhC9PUpgI2dQ2e0Ipfs_MrmrRGVYuQ6.0fLA2QY3v2TJOoLjKF05sN44 oP7.PtyABQiukzvnGculf3fhn93Kl1HVDy_ZV2cs9_eJPOHlex1p_3u4ZtkzLv3BpJqkPuxG9DEK 87skXyFzRD9KHLMsvS3cq6nZjYNl0rodpigF9pCcyMg91MAL2KHeCttxtcwGtGYe5EvcldhCjZDm ZGOKiC5PgMk_V4HzyJpA3A5TTmuuJ3g6hx8_2uINbmibwPpWs7FycfTALTIfjtz1GpGN.FQCi0e9 sRq5Fz4CgkdraZfKsDE.zprQ0f7S9rZ_DiDLPF4JYs_Bzs9ne0TnfS9burywXFy_eicu3IzaaTn1 hsSVs2supRVuXDwRwYPEjvFrqjXT.a4tKoWSCGfiO7kFGEVmzBV08lzQfpEYCusoyTQkT9Tf6gHf o5QBh6kdUqLMqDZb0W6xVAWssgwARurl_RR8tsW_JUIG5it6w4OrS4HrUOeWBZanvSIkA5UdtYWN iabgFX0QjqjRwDcK3C.0VkziDMUb9GJw2tdPpaD_Av13uvL80cVVszG_4VBtWzAGRhV8YxN8EBCr eULtaRqjobRT1ZlHBazzIG4TB0p5TSwSTGVRvXju9_RLR1JnHS0Z5wMRKPeWt9ceri_Pf8gpGTAg wlw7UwKy3VbXuaDK7F1xV1PnrOFIqkCClbJ6t.GyznjWVrv5fvGMudr4s4LLJxGP8RPB5IJX5WB3 p.jrrmhy6LqURA6mLHphPjzYrpE.5lS9eKCZskB7MP9h569s9y3X219BwJ6ifw_KFOoqjIWut4Cy qNeZBM_LNKohZIx8KnwKtcVHTPs2K.X5K0QU38mkG9_U1._77a8IutLJT84aA246n0Lx7LAOQtQJ cDVELfTe3IuyzLbD0JWq0RQN1DstwM5sRp04HXUExg8HOJrppeykkaltQ6sLpfHWFLZ53t9lU1Di 07fWitwkLatqVEkBgLP.kS0PagqlSpv8YjsRFV2stqiLwQemDrPm7nI_lY5hvRTiFhy17gG.Tbw1 QiDwC8V5dZwd7J57gifj0WTz6j9RTeeBhy2Ia0fsBZak3SsEtFSAWrHJFgoXNImCLZ2x8Jk6XYWv a X-Sonic-MF: X-Sonic-ID: 97d595fa-953e-41bb-8b87-68072c2f4233 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 18 Aug 2023 04:01:11 +0000 Received: by hermes--production-bf1-865889d799-jmdc5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0dea11690b3bab3b89cc2ac65998d5b1; Fri, 18 Aug 2023 04:01:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Unable to boot Pi 3b+ UPDATED From: Mark Millard In-Reply-To: <32684f44-cb45-438b-a48b-a09b8a02454a@box559.com> Date: Thu, 17 Aug 2023 21:00:55 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7D95EB12-B628-44D4-B01A-42EEF98C1E07@yahoo.com> References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> <32684f44-cb45-438b-a48b-a09b8a02454a@box559.com> To: Peter G X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RRp8B01X5z3dCW X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 17, 2023, at 18:17, Peter G wrote: > Mark Millard wrote on 2023-08-17 12:22: >> On Aug 17, 2023, at 11:08, Peter G = wrote: >>> Apologies for top posting, but now that I understand the problem = better, most of the stuff below is not relevant. Here's the whole issue: >>>=20 >>> Late last year there was a new hardware release of the Raspberry Pi = 3B+ board. The PMIC chip was changed; more information is here: >>> = https://pip.raspberrypi.com/categories/797-pcn/documents/RP-003337-PC/Pi3B= -Revision-9-PCN.pdf >>> The new board is Rev. 1.4, a.k.a. a020d4. >>>=20 >>> The FreeBSD image at >>> = http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-= RELEASE-arm64-aarch64-RPI.img.xz >>> boots fine on the old Rev. 1.3 version of the board but it fails to = boot on the Rev 1.4 version. I have tried it on more than one example of = each version of the board. 1.3 boards boot fine, 1.4 boards fail to boot = and flash the green LED in 4 long - 7 short pattern. >>>=20 >>> Not sure what to do about this. Is it a known problem? Should I file = a bug report? >> =46rom the *.pdf document that you referenced: >> QUOTE >> Software/Firmware Changes Required >> This new product revision is supported in firmware versions from = September 2021 onwards. >> The firmware version . . . It can also be found for an image by = running >> strings /boot/start.elf | grep VC_BUILD >> END QUOTE >> (The /boot/ path is not from FreeBSD, so replace >> with a FreeBSD path. Also, start4.elf is of more >> direct interest here.) >> Until the recent change in systuil/rpi-firmware , >> FreeBSD simply used too old of an RPI* firmware >> version (over 2 years old) to work for the RPi3B+ >> Rev 1.4 (or later) parts. >> I'm not aware of FreeBSD re-releasing the likes of >> a releng/X.Y with just updated RPi* firmware (or an >> updated U-Boot since such is also available now). >> Any solution must involve replacing the older >> firmware with newer firmware. But the port to >> package builder is not done yet --and once it >> is there is also distribution time after that >> before the update will be available. >> One way to do that replacement now is to get the >> material from the msdosfs for one of the snapshot >> builds that I referenced: >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0= -ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-264678.img.xz >=20 > As you suggest, I tried substituting the msdos files from this 14.0 = image into the 13.2-RELEASE image. >=20 > First, I replaced all the files in the first (msdos) partition. That = booted, but crashed when the kernel started, which caused it to reboot, = and so on in loop. Interesting. What was the evidence that it was the kernel instead of, say, U-Boot or even earlier? (Currently working boots are noisy with 150+ extra console message lines that should be ignored/skipped, unfortunately. The 150+ is in part because of 3 lines per original example of the underlying issue. That type of issue ends up being tried 2*25+ times.) > Next, I tried replacing only the start4.elf file, leaving the others = alone. First off, I'm so used to a RPi4B context that I stupidly referenced start4.elf despite your RPi3B+ context. Sorry. start.elf and fixup.dat are appropriate to your context, not start4.elf and fixup4.dat . Normally start.elf replaced by itself is incoherent. start.elf and fixup.dat go together as a pair, for example. But the *.dtb files are not fully independent of start.elf either. Compatibility across the 2 years seems unlikely. Some files are not RPi* firmware at all: Not part of FreeBSD but used in booting FreeBSD . . . armstub8-gic.bin (This one is for RPi4B's and the like.) armstub8.bin u-boot.bin FreeBSD files used by aarch64 RPi*'s . . . EFI/BOOT/bootaa64.efi (The FreeBSD UEFI loader.) FreeBSD files not used by RPi*'s . . . dtb/* dtb/*/* Technically, the FreeBSD sysutils/rpi-firmware port supplied the config.txt used. It looks like: [all] arm_64bit=3D1 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Ddisable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin [pi4] hdmi_safe=3D1 armstub=3Darmstub8-gic.bin > That didn't boot at all, returning to the now familiar 4 slow - 7 fast = pattern of green LED flashes. Yea, even ignoring other issues with doing partial replacements, my referencing start4.elf was wrong and the file would be ignored on a RPi3B+ . > Any thoughts on which files should be substituted for a successful = boot? >=20 > [...] We are driving blind here. Do you have a serial console setup? If not, can you? If you get to the point of having a serial console, can you record it and post the content someplace? Recording and posting the output would give evidence: the the FreeBSD kernel messages (or whatever) as it progresses. I'll note that Friday there should be a new 14.0-ALPHA2 snapshot. It does contain one fix to main's RPi* kernel code. It might be worth seeing if it boots the RPi3B+ well or not, separately from the releng/13.2 effort. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Aug 18 16:41:21 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RS71M2Yfdz4qm9G for ; Fri, 18 Aug 2023 16:41:27 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Received: from mx3.mx00.net (mx3.mx00.net [IPv6:2600:3c01:e000:872::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx3.mx00.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RS71M0jtLz3Rr4 for ; Fri, 18 Aug 2023 16:41:27 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Authentication-Results: mx1.freebsd.org; none Received: from razz.mx00.net [2600:3c01::f03c:91ff:fed5:a231] by mx3.mx00.net with ESMTP id 20230519-1qX2XK-0001BF-1x; Fri, 18 Aug 2023 16:41:22 +0000 Message-ID: Date: Fri, 18 Aug 2023 09:41:21 -0700 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Subject: Re: Unable to boot Pi 3b+ SOLVED Content-Language: en-US To: freebsd-arm@freebsd.org Cc: Mark Millard References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> <32684f44-cb45-438b-a48b-a09b8a02454a@box559.com> <7D95EB12-B628-44D4-B01A-42EEF98C1E07@yahoo.com> From: Peter G In-Reply-To: <7D95EB12-B628-44D4-B01A-42EEF98C1E07@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RS71M0jtLz3Rr4 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:63949, ipnet:2600:3c01::/32, country:SG] Mark Millard wrote on 2023-08-17 21:00: > On Aug 17, 2023, at 18:17, Peter G wrote: > >> Mark Millard wrote on 2023-08-17 12:22: >>> On Aug 17, 2023, at 11:08, Peter G wrote: >>>> Apologies for top posting, but now that I understand the problem better, most of the stuff below is not relevant. Here's the whole issue: >>>> >>>> Late last year there was a new hardware release of the Raspberry Pi 3B+ board. The PMIC chip was changed; more information is here: >>>> https://pip.raspberrypi.com/categories/797-pcn/documents/RP-003337-PC/Pi3B-Revision-9-PCN.pdf >>>> The new board is Rev. 1.4, a.k.a. a020d4. >>>> >>>> The FreeBSD image at >>>> http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz >>>> boots fine on the old Rev. 1.3 version of the board but it fails to boot on the Rev 1.4 version. I have tried it on more than one example of each version of the board. 1.3 boards boot fine, 1.4 boards fail to boot and flash the green LED in 4 long - 7 short pattern. >>>> >>>> Not sure what to do about this. Is it a known problem? Should I file a bug report? >>> From the *.pdf document that you referenced: >>> QUOTE >>> Software/Firmware Changes Required >>> This new product revision is supported in firmware versions from September 2021 onwards. >>> The firmware version . . . It can also be found for an image by running >>> strings /boot/start.elf | grep VC_BUILD >>> END QUOTE >>> (The /boot/ path is not from FreeBSD, so replace >>> with a FreeBSD path. Also, start4.elf is of more >>> direct interest here.) >>> Until the recent change in systuil/rpi-firmware , >>> FreeBSD simply used too old of an RPI* firmware >>> version (over 2 years old) to work for the RPi3B+ >>> Rev 1.4 (or later) parts. >>> I'm not aware of FreeBSD re-releasing the likes of >>> a releng/X.Y with just updated RPi* firmware (or an >>> updated U-Boot since such is also available now). >>> Any solution must involve replacing the older >>> firmware with newer firmware. But the port to >>> package builder is not done yet --and once it >>> is there is also distribution time after that >>> before the update will be available. >>> One way to do that replacement now is to get the >>> material from the msdosfs for one of the snapshot >>> builds that I referenced: >>> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-264678.img.xz >> >> As you suggest, I tried substituting the msdos files from this 14.0 image into the 13.2-RELEASE image. >> >> First, I replaced all the files in the first (msdos) partition. That booted, but crashed when the kernel started, which caused it to reboot, and so on in loop. > > Interesting. What was the evidence that it was the kernel > instead of, say, U-Boot or even earlier? > > (Currently working boots are noisy with 150+ extra console > message lines that should be ignored/skipped, unfortunately. > The 150+ is in part because of 3 lines per original example > of the underlying issue. That type of issue ends up being > tried 2*25+ times.) > >> Next, I tried replacing only the start4.elf file, leaving the others alone. > > First off, I'm so used to a RPi4B context that I stupidly referenced > start4.elf despite your RPi3B+ context. Sorry. start.elf and fixup.dat > are appropriate to your context, not start4.elf and fixup4.dat . > > Normally start.elf replaced by itself is incoherent. start.elf > and fixup.dat go together as a pair, for example. But the *.dtb > files are not fully independent of start.elf either. Compatibility > across the 2 years seems unlikely. > > Some files are not RPi* firmware at all: > > Not part of FreeBSD but used in booting FreeBSD . . . > > armstub8-gic.bin (This one is for RPi4B's and the like.) > armstub8.bin > > u-boot.bin > > FreeBSD files used by aarch64 RPi*'s . . . > > EFI/BOOT/bootaa64.efi (The FreeBSD UEFI loader.) > > FreeBSD files not used by RPi*'s . . . > > dtb/* > dtb/*/* > > > > Technically, the FreeBSD sysutils/rpi-firmware port supplied > the config.txt used. It looks like: > > [all] > arm_64bit=1 > dtparam=audio=on,i2c_arm=on,spi=on > dtoverlay=mmc > dtoverlay=disable-bt > device_tree_address=0x4000 > kernel=u-boot.bin > > [pi4] > hdmi_safe=1 > armstub=armstub8-gic.bin > > > >> That didn't boot at all, returning to the now familiar 4 slow - 7 fast pattern of green LED flashes. > > Yea, even ignoring other issues with doing partial replacements, > my referencing start4.elf was wrong and the file would be > ignored on a RPi3B+ . > >> Any thoughts on which files should be substituted for a successful boot? >> >> [...] > > We are driving blind here. Do you have a serial console > setup? If not, can you? If you get to the point of having > a serial console, can you record it and post the content > someplace? > > Recording and posting the output would give evidence: the > the FreeBSD kernel messages (or whatever) as it progresses. > > I'll note that Friday there should be a new 14.0-ALPHA2 > snapshot. It does contain one fix to main's RPi* kernel > code. It might be worth seeing if it boots the RPi3B+ > well or not, separately from the releng/13.2 effort. > > === > Mark Millard > marklmi at yahoo.com Okay, finally working! I replaced start.elf and fixup.dat, and only those two files, in 13.2-RELEASE with the ones from 14.0-ALPHA1, and that boots (usually). I say usually because sometimes the boot hangs indefinitely between loading the keyboard USB device and bringing up the network stuff (lo0, mue0, and ue0), but usually it just pauses there and then continues. When it does hang, ctrl-alt-del works to try again. As expected, once it's up there are no apparent problems. The wired ethernet works fine for ssh and freebsd-update. I haven't stressed the system much so far, but still looks good after half a day of uptime. From nobody Fri Aug 18 17:12:34 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RS7jf1ys5z4qntT for ; Fri, 18 Aug 2023 17:12:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RS7jd6Qr1z3VbW for ; Fri, 18 Aug 2023 17:12:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692378770; bh=Xm3ZkEY2q0865IBOr6Z5fvdIRjoYXu90XUfMezLWeDA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ohCf9ieetBSo/xgXDANVmQwp5pYA0YkGQ63ql8218wtEKdZ7OF5t1+j+/uLSOYTvEW+fqRqa1GbgQ5sfhX5Es2hxDzs3wtyLKeAEGx+s5kch4LubSShwi9yjUC/f3Iy9NzFo/MEkuqi4qqPv1ZNRKIm4CzS9xtrgEjGAO9xux5GUPGac1BKnbNMD2NvHXNg/qnKSZEdIHG4KKKOoMPHArckJ+VQXe4642TR3sgZE1/CC8osU7Fslmk4WsSt3hJGSs5cjSORS/0MRz9UEMCTPABxMtpQCxXvRityoNQFtlvjoWdrfURAGMAAIKDw7A/HijhYEpopUf5sApTyQN0mLkg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692378770; bh=+4g1oh7ruwYZZRPnH/+MCYvo4meQ9pelrRe9kqhbfgr=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=H8w5mFMQQXlA3rL9WtIAAXgxlVbKZjWvjxCGnC3mE4MamKbdvnxI+TAdrT8aTKqT5TBH5fLGxSItjJ9agrsMVxXXfM7zed4y/QX7bb/ZZbJheED1kqABCxKXt1Id0uqzAocYDTm9Q4Fjq4qoksUiiXlkvohWsjrDpc2Y1AdjCW2AowdBrmMUygTP4WR1TW1zRNQYgCkGWi9AKGSUCt7vbTvAQZUT1JWBokUzSRxiiWDncBkX7yInEqnj9j2Yimo2ucFQOZd+DMelQxWvUvTpS+78Iq5qM7BtMJgmmbFDY7W/l1Xw0WfqD86efuCh3momuQ2fVjOx5RIC+5Va1Yrnkw== X-YMail-OSG: 7GFQNXMVM1m2bLczxRTIJGGxYppmv0UScv5eW_d3TBM7sZtDm_cI1X_nb_xo6bT eI1Pg1atCCh.s_n_VAP54gkaT6cH21kYNrLTAnSjLHx.yx7Ob8dyblCHhiblZE.5m5ROKXA7wcSN UgRX5wd2bwzG7TR5P_A2dWehms9.DEMVLC9Ki0gutguENUX_vtS1zuELd.TM7dufZfZiQARv9Oo6 2XfQgT6P3.w6W6wJJgPplbpGEZOKNl8N5cIHtVwDe_An9od.HJWuloPZwEFLa2N_czatFfC6EVXC FDOJVOjuECKvO7fccNf.BSLk91mN3HvXr07dIfaNnGyOnAPsBcJgWgvbjYtk6beLWgJqGQULSNw4 7DF70iKZS2MRCeJSyI1YnkQYHINTjapyyRtKI3IJRY1oHo77Pqgr_ywYtAoUv4XHgyCk65wIIH_O lzFEiVUbyXOqE_w2.XtXoll_eAkFkQQdw9MEe5SgY9I39k65wU9t1jRzaElM00IcYv8TXhN__FTn jm0fHXKUpNJLDw.D5yyZAA9EOB6asODPyh_aViSWeMWU0Rn_lAkvw_bmzvhLmr65LqgR5Qyt6qZo SQIIzYHNJBRDe5WKACgppG5vP8SHuR6aQQ60ylu0BJji1tEZ4WYA3KErJsw9uaafG3RCc36A.dR. Y1wB03cxPkf63BWlKVzm.FdXepTN7uzyfB4pdzs6_Zmi7NLmVdIyhSZAtoRUPKOwEAdDPUmD0Pf4 K9PMTRGqqITUts3Z4A2WUaIbCxPET_eNEKCRirR6ll2t.DUDYkEpf3uaAhO2DB.L3wKjtegAiRCH FWbuVruCpD0G10V_ArY9IAnk8QkFkRXTjGyf.gQ2Rf0dVOOrjbxzZTANeFiRQMIkbsZqCgwHE6Dq KxpI.emqy1rhGF51LR.v1hsR0Z3HXH0ueEuF4svDoSCAeTMwyiw.PTXhPOze0439VvdFs_qV6zb3 YRjOCEolgUoH6mtoSRJ0r9HVWCEuCg70Vn3t8opXzlnhXfuaeGoQ0_h6x7NGWwJdGN8YOOP7ZYjM 1rtE2S3tGvyubva8PaMo6FQglQitaZLFsm6cTV8QJmy_HvkenOxSGpWRqGQYp2UV69JXve.Gv15C lzoOtTUEGkxySkC0QfNutflnpnHSCtHGnIGsQDDdxVvjg4jSxTaxDIH5ZcXrL_PX.y5rLMZS4270 JLtkEugyX99YrcnqMvri1XIpMrKj3Gq._DPqsqgptgTG4V7ldIC01mL4Ef6099o679BvOwnjpwRY DisLBE2Mrq3kI0E3Fp2JxTmVjbqmRsbvaJTh4fEK1LoHrcJb.7MkNX_onchMNCAF1AYq7Xzy2hJy 0WUZZJzVnCpftaqW1WFznbXAE1U2x2FMOm6jH6soJsk36wSEE4Bv6V4C_4GijHiVpRB.s0fVAt0n cMoxjxhOGCFKuEkNsLEaWznqGeQ5UOYNNbxA0l.XuQHIFx7uOtTiRw4uGd3inOQY0tVCZcxItlxa N_CYIokJpXckaN_WbRDCBO7qeH97.An4BF17ufM5wIz3NdIk7GT4AytgcB_RTz68C4lSJAbNscwm bxmu1Zf0ij2XqlN191CIBmnxxvqesg9k64TJ7Q0TyFf9_xJFf4h_IlYAUg4kPPgUxMbSwRIVfts. W2pwRanSL9w12zAZ3SKjQ7bsTA.QPNzG8Yd.lsUpzocY8Gq7KIc79dCoqm.BuoHe.fPrxKGenCoz zy5nHM3OdJnu5VdWwxkblSJu15NW3p_lxIeaOiCDxFyXE9T1eF5HbB08_oAgy0SEx6Gcw1VagRii 9eASe6dYDhU6x4JVlj3sf_klOVnvoyoZvTJ5kZhpjGLUIHhOPpTYDhiBNVCOc1ns_P8xrUCdUcfD ENAvw8BoT_lgFedaiu.n77mtZf1QbA6Slp2jnUQQS562z5Cai7Ji32NenUH1zjiZ8CKtS.g16fSp xQGY7bKNNH7eRsLztotpt_RBhCRUUd4ahMOzvAMZ2iglWrkmQErGcKK8qYAae9Drb.K_PwgoPPbQ FCrpLo7.cRAbyvmBEpDZS691M6VOfmOXcCb_Hp7NyLLIa3b5Fxdog5tiuKK.U_Y.PY49yiaW9ufW FW0L9Hn3PWl2uq6gqDFfZNk7H1hOA7SwUdw52rTHwQjYSGDXj6DUj9SUIF0HdNMTGyvzbvGsNDhY 0_.JpptsJFoWA9A945iJSfLaa8xZ_6KxEapR_8tjQtoyeDDXRnyMIVdOuxjtYy8BLJOLzKOORak4 yX8nE5v_rJzDB_ZikNtBIX6fYY_wxb1oFq3SZ4khyyQzvn7xQ4JryHPF1ztgSpGa.xo4jHCbzEVR USg-- X-Sonic-MF: X-Sonic-ID: e571bef3-5737-4d3e-9956-327ba7e0addd Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 18 Aug 2023 17:12:50 +0000 Received: by hermes--production-bf1-865889d799-xc84r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a0fb4105ba876d92013c9ba7f5f66f3d; Fri, 18 Aug 2023 17:12:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Unable to boot Pi 3b+ SOLVED From: Mark Millard In-Reply-To: Date: Fri, 18 Aug 2023 10:12:34 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <19C95492-994B-4137-AE78-EFFD4D016F87@yahoo.com> References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> <32684f44-cb45-438b-a48b-a09b8a02454a@box559.com> <7D95EB12-B628-44D4-B01A-42EEF98C1E07@yahoo.com> To: Peter G X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RS7jd6Qr1z3VbW X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 18, 2023, at 09:41, Peter G wrote: > . . . >=20 > Okay, finally working! Cool. > I replaced start.elf and fixup.dat, and only those two files, in = 13.2-RELEASE with the ones from 14.0-ALPHA1, and that boots (usually). So the old *.dtb is still in use vs. the newer one for using the pure 14.0-ALPHA* RPi* firmware. For what you report, both with the releng/13.2 kernel. At some point I'll generate the 2 *.dts's from the *.dtb's in the sorted order and diff the outputs. (This does not deal with live adjustments that are also involved.) Does 14.0-ALPHA* have a panic when not changed? In essence the comparison/contrast checks the older kernel ( releng/13.2 ) vs. the newer kernel for the modern *.dtb case. (Unfortunatey, you have the only known test context. So I ask. But you may not want to be the tester for such questions.) > I say usually because sometimes the boot hangs indefinitely between = loading the keyboard USB device and bringing up the network stuff (lo0, = mue0, and ue0), but usually it just pauses there and then continues. = When it does hang, ctrl-alt-del works to try again. Interesting. > As expected, once it's up there are no apparent problems. The wired = ethernet works fine for ssh and freebsd-update. I haven't stressed the = system much so far, but still looks good after half a day of uptime. As you have the only known panic context, could you gather the serial console output for a context that leads to a panic(/reboot loop) when using just the 14.0-ALPHA* firmware (modern *.dtb) and then report it someplace folks can have access to? Absent such evidence, the FreeBSD kernel will stay broken for your type of context using modern RPi* firmware and FreeBSD's kernel. (Presuming the evidence points to the kernel mishandling something badly to cause a reboot loop.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 19 05:00:58 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RSRQf5nGMz4q9k8 for ; Sat, 19 Aug 2023 05:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RSRQf3ZKdz4Gb3 for ; Sat, 19 Aug 2023 05:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1692421258; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gfS+tHmjft3hRwD2P+KdRWiTiDyCOoCaYBmqlYFr+Pk=; b=HjraCgvCZXkDxqv0S+cD3SNOQsXKcrkhbtclXLVhKUsBP5suphlcM/5y4LEIqVfxDWK7Wq yPgN02+PQwPFiEewXr/njcVpfDYQ9cqrE5Rpr8718EwKEHHwgc8pa4dtiZcg5sTzmG1AQl kVIPslVQbf9HcF0gjh4x0pgcsDIqjz0O4jrIwpyL1uaITHB6Omk89vVfFkXCzsBSTYFtNT nf1UJTUHMBh7S4F3AqdVC55FUy5lc2YZ9toGJdjOjCZxdHZI2QvzDmyevU8MC18vvguba9 xNHIBLv+DQAeimkA6fza6UW8Q2tBgxqCUNOn8UtwsWv2yJ0tSqfLfVUNbxTz0A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1692421258; a=rsa-sha256; cv=none; b=CKJNXDe/pr4eIVsD1j7NlhMXV7lxAwb0TAzPaGt75DkMN+SUuJwNRk0ulsfbmQN5vFauls WM5qd4a1yU++QDe0Ofqx7hyjs3d9fEu3T/2qst9g6bSSjp7NQaqzxibajmCPjrsV9kRRvt pUnVQGjbxGxLC1haeLI0+qfzST3mkOj0QQDQ5oWfVYlu5g4ffYJ3VtP/QNGRLOwwQiu8hj 3bOd+tmNonnAk/J1KUZH33tegLIxLlCuxZw5LJy3Ml7rcw/vlTuxcPCRHlNWYXfLMgqJV6 ZDp//QkzRX2LCp8yrxn40r2cqx1ZVKaSxy81Bn4yTBHlK7Xfcob6PWnFNHwx8w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4RSRQf2f1Rzlf3 for ; Sat, 19 Aug 2023 05:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 37J50wb3008469 for ; Sat, 19 Aug 2023 05:00:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 37J50whN008468 for freebsd-arm@FreeBSD.org; Sat, 19 Aug 2023 05:00:58 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 273223] FreeBSD 14.0-ALPHA2 unable to boot on Raspberry Pi 4 8GB v1.5 Date: Sat, 19 Aug 2023 05:00:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: yklaxds@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273223 Bug ID: 273223 Summary: FreeBSD 14.0-ALPHA2 unable to boot on Raspberry Pi 4 8GB v1.5 Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: yklaxds@gmail.com I installed FreeBSD-14.0-ALPHA2-arm64-aarch64-RPI-20230818-77013f29d048-264841.img.xz today. However, the rainbow screen issue still occurs. In theory, the uboot= has been updated. Yet, the problem persists. My Raspberry Pi firmware is up to date. The problem was resolved after replacing the mentioned old uboot(13.2-release). --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Aug 19 05:15:57 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RSRsw6g85z4qC7y for ; Sat, 19 Aug 2023 05:21:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RSRsv55R0z4Hvb for ; Sat, 19 Aug 2023 05:21:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net; dmarc=none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 0F6FB8D4A142 for ; Sat, 19 Aug 2023 05:20:59 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 27CBB5C3A82F for ; Sat, 19 Aug 2023 05:20:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id AHHCs4A92FJn for ; Sat, 19 Aug 2023 05:15:58 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1D3795C3A82E for ; Sat, 19 Aug 2023 05:15:57 +0000 (UTC) Date: Sat, 19 Aug 2023 05:15:57 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-arm@FreeBSD.org Subject: fsl,esdhc implementation? or mmc ACPI attachments? Message-ID: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spamd-Result: default: False [-1.86 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.56)[-0.561]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zabbadoz.net]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RSRsv55R0z4Hvb Hi, does anyone have any work in progress for (1) an fsl,esdhc implementation? or (2) support for mmc ACPI attachments? Lots of health, /bz -- Bjoern A. Zeeb r15:7 From nobody Sat Aug 19 05:31:10 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RSS5w07G2z4qCkW for ; Sat, 19 Aug 2023 05:31:32 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RSS5v1Q9Kz4K8F for ; Sat, 19 Aug 2023 05:31:31 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net; dmarc=none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id DD1928D4A142 for ; Sat, 19 Aug 2023 05:31:22 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 352935C3A830 for ; Sat, 19 Aug 2023 05:31:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id sdmAk1VDxw2s for ; Sat, 19 Aug 2023 05:31:11 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6E5595C3A82F for ; Sat, 19 Aug 2023 05:31:11 +0000 (UTC) Date: Sat, 19 Aug 2023 05:31:10 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-arm@FreeBSD.org Subject: Re: fsl,esdhc implementation? or mmc ACPI attachments? In-Reply-To: Message-ID: References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spamd-Result: default: False [-1.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.69)[-0.693]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zabbadoz.net]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RSS5v1Q9Kz4K8F On Sat, 19 Aug 2023, Bjoern A. Zeeb wrote: > Hi, > > does anyone have any work in progress for > > (1) an fsl,esdhc implementation? > or > (2) support for mmc ACPI attachments? Disregard. It's almost all there just not for the bits I was looking for. /bz -- Bjoern A. Zeeb r15:7 From nobody Sat Aug 19 06:06:08 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RSSt94bWtz4qGMC for ; Sat, 19 Aug 2023 06:06:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RSSt836Yjz4Lqn for ; Sat, 19 Aug 2023 06:06:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZpbCTFy4; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692425182; bh=xDQrBtPfH6qXV9EDTMlRg1RipqvGzjux7Hqy/SpwCsk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZpbCTFy454yVbDRmM2CNVa6R0vAghNUlBRC6hGwwzkS6aKOkzm/QgNCLiQsKbYGMZ1R90ZJLfZXAZxsbUsvcpRCnc3v09hjS0wkY/k73XUB+1Lgn2/Z12TC7fsJLHeaTcNcA3fJrgScVlXj2d6bJq4GEk0RfG7zVDbM+/84EE2EDh3coLERXT3MoW7O5vAL+ZoZZW5TCJ3QuKdgRcuyD6gQPzoIm+sRsqQ+kDm6xax9yJzisdbS0sCB9ms6xS5q0Nn3mWuFciOl4fxr8mEAOPSldG2l3aoKoC8ePagq5AhWVqYyCRBXfeOMLv47349MJX8FVMHqfrrmPPsw93te+DA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692425182; bh=gBCWk0BIBOQShJpObJOOpbuptuBqIgyV2E2W3Uc7gVV=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XakscnbCYxidBdB/pBi56GaEGw6sA8JD+oCjPPp5JIluM9nzIRYFyeXudfak8K3I0WI/55dyF7o4B4Az215SaRZKZ7QvYwryEz3ADmoQHPmzFJdrV4spE8TLzewkHpVk/hTRnaYWw2qIqDMNvhodxrQk89YAsN/DF04WtkctvBi96ucTpUD76lVO2czdcwX5k0Hbl6U+WHlLWqRi0ShFPWFMqq+UDHJqEwxQ/qriU3p8FnNGrGhmkxh4HvC0D7teS4DIyvHNEANrXzaKCrEm5ay3isbTdxt1Zaat9oEQOREpFMqryBgY6O8kziBjFm06k1Fejag7ixjCifUKBZZXRQ== X-YMail-OSG: 3nry4t4VM1lPmH.t5EXYtI0FTdumOnvGtLoG3ewhN7zQxS6rnzeZ_RYt.4ZoaYZ 7m4VJe5e.bxuMcIUD3Yo7EASRST4FXDy1_z_UIEBepWlBdCc4nUQfPpKIB5stkiwcMJ_RB8aIVTx h1i3EhOD2xXsPuJlaxttTInWcA2YoWOgfCwW3QJPNoIS5fzShrGDm.5Bfs0YkjCq7E8STI.GAMyb WLGzRe8Qaw6W5Om3_fCbxwHOy_COR54HM0mzCenJodNGDxj25O7DjXhitr_rscIzNkdIjteTXv57 VE95_V7MY4Phpc_QXWL3jtgVv.HH.VDTvNlsB_sHlPF.yNdC.S28wR7_GKJ3I47qjskimdVZDRD. zO31SEBuwem2_6WO69_KZqcMxm9xncZsBcvKqfCUQPzSPXJ9YmUO0sxK0MrwmroDsqhMN_gZoX31 u8l7F_rr8BuyinxSAnMb.8ZaGP0QyWt93iayvig63RNIHrK2_JLTVl.U9DJXNuqqJx.WBQW8KKSt m8DJpF.cvRtrihyM_R63g2naQvA0Gkwg2EVKJd.V2IjVHDVYSo2VTheDXAVgw3P9md0WTaGeojoD Kkm4lUSFMa0tNcWO6TvilQTPzYL9pT72pBIQ4f7JYFjBeD7zIAPxwiwJxwzS59uSmvXB45yAQ0OD nbYYE6mS8eAYRedZ55Ty7wxB2Fl.WUzHsckFB1FKVU13MEe5Va1BQ8d2_KqVV4EnCYdmokPhYge1 fpIBPou0l6HSXlaR6wOwPhRm6AEs0E2xLc1OzwoFtPPIX3S4W8erHzxWeWN0BRpDZ3Ytbx0mWwh9 S_iCtApXl2h0hWsMFLziEl.apVmJzj1q4N7pnVNPdhvtDOBMX8ZVGLvyoxeyrQBFBMF3suSA90RQ dZdi2XvqzJ_qkSPLjofsvn1pkfqUMiN5HIds2TtqcLl01_y9Qsdvb6rL0dHepeHMDlZUTYZEmiUR ecdlEkBSRNnG_4tTGs0oI7X5kaZz.8aw6WzW4AbGOKdzpGf5ZEC.DgCzxfWbAMr9878BwRTOvVep zmpcSAKCDmz5yzWiiMh_COgkt_Owe0.y2W3ElgQwY0k8IuItno0LhS3yeyuHkzcAhkogJNEP2hoH b.VzQKQhP1YbztxwMTltJsxD.U13t0cMUB0MrdGdHAjz3k5GJ4ONHB5e4GvdMd.dIILrhzKnWWE. rrd.pORLWHKY_pEhPECXZEYsPSZTx7Ippr5Nw1OGbMdEU6jOpJDbEjpmCXVKbXeGEodgYkrIzBwM 0VV7BMsbWmRlHGHfUtUPozSIBrAin33McH6kiYhtf.ydp03ZeVBOaUx_eBe_GsDuVeUlCNNLWEUi w6ZQINdJGYj4gM1Gn.aYYzfAqGqmAXl.IRd1DBvY8ZYyd_LUIkpw38pJXnaAmCVKnRKLrkTZs8TN nVob5Te7Flgi.ok9muD4MkQuujUCfejuNsXSc5WImd7hjobmQeWBHXsip1sSVDUEHzWe4NB1VBP_ cb9T6DzuIsTZojyb0Er9fo65INHWSl9c6J1WP73TuY_X8dRxR1LJ_d9NA5YieGqo5at0r8hoqcOf cEYYZviPcuIhw3EAlw5b8icZ8bW6WMph9EuNYu0Datjzvy.f28bbsDrQ8RgbiZ5QQc_TTEfkcNYI Vl94JqZ_X7_ltVc7sSsDaGEfHYCMsolw0y6HceUh5KhA8erIORb2nnfOw2hF9fVPoiQ6JIh_KwLI .ocTAZPY9MMnmsRqfFhHN82a9Erl4u4_0DdBp.shq8Si8C_f306sMvKEGMmjIrqnANc1Cu3FN5Np cP6g7njjlagUkNyGSAskacocTr_0FfHtew9Vn834KsJeL2vyG.5lGXv0i.JT7ilg5M99lsGBV3Oc AcLxyGBdBj_gIkfSSmX.C0tDFvhSXbVzR4uCa.KZAerW.VvLBJUz7Kfudx0wnE6bIqr23mmUeHYa UTT_daImP15FS7K.WUU9Sj_so6vtcRyJrrFnpT9GVTvjx.oOXDp7gQvagyPC1B8MkP2KfQKHzJV_ LZO6unzDBe4MePBPYPbPbDqYwoUPRW_eEZa_K25AogGIx3eFYTibU3fJu5Fww0LmcQ_RuQSo_Ofv IEw.NmgfZiYeNy9Rd_p3A9IfI14sORquMu_JkH.LZ4vmRQJOFFRoxlYTrfTTMt0KiCyzvU.sNE_z HUfX8DtTq4ewcl2fEILa2Tl3XBazcHW8enIjx75JSCNvDGZL5DvhxoIzyYdpGKlo8oA3h6fFgTUS NJsUIVPlVW0Q5q6nR_mVBN8y0JX7mcwGsaiYatpHT950tpWdvhkum0INdjmfeUy4jx08BYVk_Lch Lcb_B X-Sonic-MF: X-Sonic-ID: 76b3c23e-3c3e-4a42-87bb-5a4979f4929a Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Aug 2023 06:06:22 +0000 Received: by hermes--production-ne1-7b767b77cc-62qqp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 408ea553490178116080ce36eac9843d; Sat, 19 Aug 2023 06:06:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Unable to boot Pi 3b+ SOLVED From: Mark Millard In-Reply-To: <19C95492-994B-4137-AE78-EFFD4D016F87@yahoo.com> Date: Fri, 18 Aug 2023 23:06:08 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <5FC423D5-4EA4-4B98-87F7-1F73C20828F3@yahoo.com> References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> <32684f44-cb45-438b-a48b-a09b8a02454a@box559.com> <7D95EB12-B628-44D4-B01A-42EEF98C1E07@yahoo.com> <19C95492-994B-4137-AE78-EFFD4D016F87@yahoo.com> To: Peter G X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RSSt836Yjz4Lqn Here is what I find for the RPI3B+ *.dtb file differences, ignoring phandle lines (stripped out). Leading whitespace might not have been preserved. This does not report on live differences and the PMIC variations may well lead to live differences, as might the different RPi* firmware *.elf/*.dat file versions. # diff -u ~/RPi3B+-dtb-file-olderFBSD-nophandles.dts = ~/RPi3B+-dtb-file-nophandles.dts | less --- /usr/home/root/RPi3B+-dtb-file-olderFBSD-nophandles.dts = 2023-08-18 22:42:44.990040000 -0700 +++ /usr/home/root/RPi3B+-dtb-file-nophandles.dts 2023-08-18 = 11:51:42.032538000 -0700 @@ -11,62 +11,71 @@ model =3D "Raspberry Pi 3 Model B+"; __overrides__ { =20 - act_led_activelow =3D <0x33 0x6770696f 0x733a3800>; - act_led_gpio =3D <0x33 0x6770696f 0x733a3400>; - act_led_trigger =3D [00 00 00 33 6c 69 6e 75 78 2c 64 65 = 66 61 75 6c 74 2d 74 72 69 67 67 65 72 00]; - arm_freq =3D <0x21 0x636c6f63 0x6b2d6672 0x65717565 = 0x6e63793a 0x30000000 0x22636c 0x6f636b2d 0x66726571 0x75656e63 = 0x793a3000 0x23 0x636c6f63 0x6b2d6672 0x65717565 0x6e63793a 0x30000000 = 0x24636c 0x6f636b2d 0x66726571 0x75656e63 0x793a3000>; - audio =3D [00 00 00 2b 73 74 61 74 75 73 00]; + act_led_activelow =3D <0x35 0x6770696f 0x733a3800>; + act_led_gpio =3D <0x35 0x6770696f 0x733a3400>; + act_led_trigger =3D [00 00 00 35 6c 69 6e 75 78 2c 64 65 = 66 61 75 6c 74 2d 74 72 69 67 67 65 72 00]; + arm_freq =3D <0x22 0x636c6f63 0x6b2d6672 0x65717565 = 0x6e63793a 0x30000000 0x23636c 0x6f636b2d 0x66726571 0x75656e63 = 0x793a3000 0x24 0x636c6f63 0x6b2d6672 0x65717565 0x6e63793a 0x30000000 = 0x25636c 0x6f636b2d 0x66726571 0x75656e63 0x793a3000>; + audio =3D [00 00 00 34 62 6f 6f 74 61 72 67 73 7b 6f 6e = 3d 27 73 6e 64 5f 62 63 6d 32 38 33 35 2e 65 6e 61 62 6c 65 5f 68 65 61 = 64 70 68 6f 6e 65 73 3d 31 20 73 6e 64 5f 62 63 6d 32 38 33 35 2e 65 6e = 61 62 6c 65 5f 68 64 6d 69 3d 31 27 2c 6f 66 66 3d 27 73 6e 64 5f 62 63 = 6d 32 38 33 35 2e 65 6e 61 62 6c 65 5f 68 65 61 64 70 68 6f 6e 65 73 3d = 30 20 73 6e 64 5f 62 63 6d 32 38 33 35 2e 65 6e 61 62 6c 65 5f 68 64 6d = 69 3d 30 27 7d 00]; axiperf =3D [00 00 00 31 73 74 61 74 75 73 00]; cache_line_size; cam0-led; cam0-led-ctrl; cam0-pwdn; cam0-pwdn-ctrl; - eee =3D [00 00 00 35 6d 69 63 72 6f 63 68 69 70 2c 65 65 = 65 2d 65 6e 61 62 6c 65 64 3f 00]; - eth_downshift_after =3D <0x35 0x6d696372 0x6f636869 = 0x702c646f 0x776e7368 0x6966742d 0x61667465 0x723a3000>; - eth_led0 =3D [00 00 00 35 6d 69 63 72 6f 63 68 69 70 2c = 6c 65 64 2d 6d 6f 64 65 73 3a 30 00]; - eth_led1 =3D [00 00 00 35 6d 69 63 72 6f 63 68 69 70 2c = 6c 65 64 2d 6d 6f 64 65 73 3a 34 00]; - eth_max_speed =3D <0x35 0x6d61782d 0x73706565 = 0x643a3000>; - i2c0 =3D [00 00 00 11 73 74 61 74 75 73 00 00 00 00 29 = 73 74 61 74 75 73 00]; - i2c0_baudrate =3D [00 00 00 11 63 6c 6f 63 6b 2d 66 72 = 65 71 75 65 6e 63 79 3a 30 00]; - i2c1 =3D [00 00 00 2a 73 74 61 74 75 73 00]; - i2c1_baudrate =3D [00 00 00 2a 63 6c 6f 63 6b 2d 66 72 = 65 71 75 65 6e 63 79 3a 30 00]; - i2c2_baudrate =3D [00 00 00 1b 63 6c 6f 63 6b 2d 66 72 = 65 71 75 65 6e 63 79 3a 30 00]; - i2c2_iknowwhatimdoing =3D [00 00 00 1b 73 74 61 74 75 73 = 00]; - i2s =3D [00 00 00 27 73 74 61 74 75 73 00]; - krnbt =3D [00 00 00 32 73 74 61 74 75 73 00]; - krnbt_baudrate =3D <0x32 0x6d61782d 0x73706565 = 0x643a3000>; - pwr_led_activelow =3D <0x34 0x6770696f 0x733a3800>; - pwr_led_gpio =3D <0x34 0x6770696f 0x733a3400>; - pwr_led_trigger =3D [00 00 00 34 6c 69 6e 75 78 2c 64 65 = 66 61 75 6c 74 2d 74 72 69 67 67 65 72 00]; + eee =3D [00 00 00 37 6d 69 63 72 6f 63 68 69 70 2c 65 65 = 65 2d 65 6e 61 62 6c 65 64 3f 00]; + eth_downshift_after =3D <0x37 0x6d696372 0x6f636869 = 0x702c646f 0x776e7368 0x6966742d 0x61667465 0x723a3000>; + eth_led0 =3D [00 00 00 37 6d 69 63 72 6f 63 68 69 70 2c = 6c 65 64 2d 6d 6f 64 65 73 3a 30 00]; + eth_led1 =3D [00 00 00 37 6d 69 63 72 6f 63 68 69 70 2c = 6c 65 64 2d 6d 6f 64 65 73 3a 34 00]; + eth_max_speed =3D <0x37 0x6d61782d 0x73706565 = 0x643a3000>; + hdmi =3D [00 00 00 32 73 74 61 74 75 73 00]; + i2c0 =3D [00 00 00 1c 73 74 61 74 75 73 00 00 00 00 2a = 73 74 61 74 75 73 00]; + i2c0_baudrate =3D [00 00 00 1c 63 6c 6f 63 6b 2d 66 72 = 65 71 75 65 6e 63 79 3a 30 00]; + i2c1 =3D [00 00 00 2b 73 74 61 74 75 73 00]; + i2c1_baudrate =3D [00 00 00 2b 63 6c 6f 63 6b 2d 66 72 = 65 71 75 65 6e 63 79 3a 30 00]; + i2c2_baudrate =3D [00 00 00 1a 63 6c 6f 63 6b 2d 66 72 = 65 71 75 65 6e 63 79 3a 30 00]; + i2c2_iknowwhatimdoing =3D [00 00 00 1a 73 74 61 74 75 73 = 00]; + i2s =3D [00 00 00 28 73 74 61 74 75 73 00]; + krnbt =3D [00 00 00 33 73 74 61 74 75 73 00]; + krnbt_baudrate =3D <0x33 0x6d61782d 0x73706565 = 0x643a3000>; + pwr_led_activelow =3D <0x36 0x6770696f 0x733a3800>; + pwr_led_gpio =3D <0x36 0x6770696f 0x733a3400>; + pwr_led_trigger =3D [00 00 00 36 6c 69 6e 75 78 2c 64 65 = 66 61 75 6c 74 2d 74 72 69 67 67 65 72 00]; random =3D [00 00 00 2d 73 74 61 74 75 73 00]; + sd =3D [00 00 00 2e 73 74 61 74 75 73 00]; sd_debug =3D [00 00 00 2e 62 72 63 6d 2c 64 65 62 75 67 = 00]; sd_force_pio =3D <0x2e 0x6272636d 0x2c666f72 0x63652d70 = 0x696f3f00>; sd_overclock =3D <0x2e 0x6272636d 0x2c6f7665 0x72636c6f = 0x636b2d35 0x303a3000>; sd_pio_limit =3D [00 00 00 2e 62 72 63 6d 2c 70 69 6f 2d = 6c 69 6d 69 74 3a 30 00]; sd_poll_once =3D [00 00 00 2e 6e 6f 6e 2d 72 65 6d 6f 76 = 61 62 6c 65 3f 00]; sdio_overclock =3D <0x2f 0x6272636d 0x2c6f7665 = 0x72636c6f 0x636b2d35 0x303a3000 0x30 0x6272636d 0x2c6f7665 0x72636c6f = 0x636b2d35 0x303a3000>; - spi =3D [00 00 00 28 73 74 61 74 75 73 00]; - tx_lpi_timer =3D [00 00 00 35 6d 69 63 72 6f 63 68 69 70 = 2c 74 78 2d 6c 70 69 2d 74 69 6d 65 72 3a 30 00]; - uart0 =3D [00 00 00 25 73 74 61 74 75 73 00]; - uart1 =3D [00 00 00 26 73 74 61 74 75 73 00]; + spi =3D [00 00 00 29 73 74 61 74 75 73 00]; + tx_lpi_timer =3D [00 00 00 37 6d 69 63 72 6f 63 68 69 70 = 2c 74 78 2d 6c 70 69 2d 74 69 6d 65 72 3a 30 00]; + uart0 =3D [00 00 00 26 73 74 61 74 75 73 00]; + uart1 =3D [00 00 00 27 73 74 61 74 75 73 00]; watchdog =3D [00 00 00 2c 73 74 61 74 75 73 00]; }; __symbols__ { =20 - act_led =3D "/leds/act"; + act_led =3D "/leds/led-act"; alt0 =3D "/soc/gpio@7e200000/alt0"; - audio =3D "/soc/mailbox@7e00b840/bcm2835_audio"; audio_pins =3D "/soc/gpio@7e200000/audio_pins"; aux =3D "/soc/aux@7e215000"; axiperf =3D "/soc/axiperf"; + brcmf =3D "/soc/mmcnr@7e300000/wifi@1"; bt =3D "/soc/serial@7e201000/bluetooth"; bt_pins =3D "/soc/gpio@7e200000/bt_pins"; - cam1_reg =3D "/cam1_reg"; + cam0_clk =3D "/cam0_clk"; + cam0_reg =3D "/cam_dummy_reg"; + cam0_regulator =3D "/cam0_regulator"; + cam1_clk =3D "/cam1_clk"; + cam1_reg =3D "/cam1_regulator"; + cam_dummy_reg =3D "/cam_dummy_reg"; + chosen =3D "/chosen"; clk_osc =3D "/clocks/clk-osc"; clk_usb =3D "/clocks/clk-usb"; clocks =3D "/soc/cprman@7e101000"; cma =3D "/reserved-memory/linux,cma"; + cooling_maps =3D = "/thermal-zones/cpu-thermal/cooling-maps"; cpu0 =3D "/cpus/cpu@0"; cpu1 =3D "/cpus/cpu@1"; cpu2 =3D "/cpus/cpu@2"; @@ -77,6 +86,12 @@ csi1 =3D "/soc/csi@7e801000"; dma =3D "/soc/dma@7e007000"; dpi =3D "/soc/dpi@7e208000"; + dpi_16bit_cpadhi_gpio0 =3D = "/soc/gpio@7e200000/dpi_16bit_cpadhi_gpio0"; + dpi_16bit_cpadhi_gpio2 =3D = "/soc/gpio@7e200000/dpi_16bit_cpadhi_gpio2"; + dpi_16bit_gpio0 =3D = "/soc/gpio@7e200000/dpi_16bit_gpio0"; + dpi_16bit_gpio2 =3D = "/soc/gpio@7e200000/dpi_16bit_gpio2"; + dpi_18bit_cpadhi_gpio0 =3D = "/soc/gpio@7e200000/dpi_18bit_cpadhi_gpio0"; + dpi_18bit_cpadhi_gpio2 =3D = "/soc/gpio@7e200000/dpi_18bit_cpadhi_gpio2"; dpi_18bit_gpio0 =3D = "/soc/gpio@7e200000/dpi_18bit_gpio0"; dpi_18bit_gpio2 =3D = "/soc/gpio@7e200000/dpi_18bit_gpio2"; dpi_gpio0 =3D "/soc/gpio@7e200000/dpi_gpio0"; @@ -121,6 +136,7 @@ intc =3D "/soc/interrupt-controller@7e00b200"; jtag_gpio22 =3D "/soc/gpio@7e200000/jtag_gpio22"; jtag_gpio4 =3D "/soc/gpio@7e200000/jtag_gpio4"; + l2 =3D "/cpus/l2-cache0"; leds =3D "/leds"; local_intc =3D "/soc/local_intc@40000000"; mailbox =3D "/soc/mailbox@7e00b880"; @@ -142,7 +158,7 @@ pwm1_gpio19 =3D "/soc/gpio@7e200000/pwm1_gpio19"; pwm1_gpio41 =3D "/soc/gpio@7e200000/pwm1_gpio41"; pwm1_gpio45 =3D "/soc/gpio@7e200000/pwm1_gpio45"; - pwr_led =3D "/leds/pwr"; + pwr_led =3D "/leds/led-pwr"; random =3D "/soc/rng@7e104000"; rmem =3D "/reserved-memory"; sdhci =3D "/soc/mmc@7e300000"; @@ -165,6 +181,7 @@ spidev0 =3D "/soc/spi@7e204000/spidev@0"; spidev1 =3D "/soc/spi@7e204000/spidev@1"; thermal =3D "/soc/thermal@7e212000"; + thermal_trips =3D "/thermal-zones/cpu-thermal/trips"; txp =3D "/soc/txp@7e004000"; uart0 =3D "/soc/serial@7e201000"; uart0_ctsrts_gpio16 =3D = "/soc/gpio@7e200000/uart0_ctsrts_gpio16"; @@ -187,7 +204,7 @@ v3d =3D "/soc/v3d@7ec00000"; vc4 =3D "/soc/gpu"; vchiq =3D "/soc/mailbox@7e00b840"; - vcsm =3D "/soc/vcsm"; + vcio =3D "/soc/firmware/vcio"; vdd_3v3_reg =3D "/fixedregulator_3v3"; vdd_5v0_reg =3D "/fixedregulator_5v0"; vec =3D "/soc/vec@7e806000"; @@ -195,7 +212,6 @@ }; aliases { =20 - audio =3D "/soc/mailbox@7e00b840/bcm2835_audio"; aux =3D "/soc/aux@7e215000"; axiperf =3D "/soc/axiperf"; dma =3D "/soc/dma@7e007000"; @@ -231,20 +247,45 @@ arm-pmu { =20 compatible =3D "arm,cortex-a53-pmu", = "arm,cortex-a7-pmu"; - interrupt-parent =3D <0x1a>; + interrupt-parent =3D <0x18>; interrupts =3D <0x9 0x4>; }; - cam1_reg { + cam0_clk { =20 + #clock-cells =3D <0x0>; + compatible =3D "fixed-clock"; + status =3D "disabled"; + }; + cam0_regulator { + compatible =3D "regulator-fixed"; enable-active-high; - gpio =3D <0xa 0x5 0x0>; - regulator-name =3D "cam1-reg"; + regulator-name =3D "cam0-reg"; status =3D "disabled"; }; + cam1_clk { + + #clock-cells =3D <0x0>; + compatible =3D "fixed-clock"; + status =3D "disabled"; + }; + cam1_regulator { + + compatible =3D "regulator-fixed"; + enable-active-high; + gpio =3D <0xb 0x5 0x0>; + regulator-name =3D "cam1-reg"; + status =3D "okay"; + }; + cam_dummy_reg { + + compatible =3D "regulator-fixed"; + regulator-name =3D "cam-dummy-reg"; + status =3D "okay"; + }; chosen { =20 - bootargs =3D "coherent_pool=3D1M 8250.nr_uarts=3D1 = snd_bcm2835.enable_compat_alsa=3D0 snd_bcm2835.enable_hdmi=3D1"; + bootargs =3D "coherent_pool=3D1M 8250.nr_uarts=3D1 = snd_bcm2835.enable_headphones=3D0"; }; clocks { =20 @@ -272,34 +313,70 @@ =20 compatible =3D "arm,cortex-a53"; cpu-release-addr =3D <0x0 0xd8>; + d-cache-line-size =3D <0x40>; + d-cache-sets =3D <0x80>; + d-cache-size =3D <0x8000>; device_type =3D "cpu"; enable-method =3D "spin-table"; + i-cache-line-size =3D <0x40>; + i-cache-sets =3D <0x100>; + i-cache-size =3D <0x8000>; + next-level-cache =3D <0x21>; reg =3D <0x0>; }; cpu@1 { =20 compatible =3D "arm,cortex-a53"; cpu-release-addr =3D <0x0 0xe0>; + d-cache-line-size =3D <0x40>; + d-cache-sets =3D <0x80>; + d-cache-size =3D <0x8000>; device_type =3D "cpu"; enable-method =3D "spin-table"; + i-cache-line-size =3D <0x40>; + i-cache-sets =3D <0x100>; + i-cache-size =3D <0x8000>; + next-level-cache =3D <0x21>; reg =3D <0x1>; }; cpu@2 { =20 compatible =3D "arm,cortex-a53"; cpu-release-addr =3D <0x0 0xe8>; + d-cache-line-size =3D <0x40>; + d-cache-sets =3D <0x80>; + d-cache-size =3D <0x8000>; device_type =3D "cpu"; enable-method =3D "spin-table"; + i-cache-line-size =3D <0x40>; + i-cache-sets =3D <0x100>; + i-cache-size =3D <0x8000>; + next-level-cache =3D <0x21>; reg =3D <0x2>; }; cpu@3 { =20 compatible =3D "arm,cortex-a53"; cpu-release-addr =3D <0x0 0xf0>; + d-cache-line-size =3D <0x40>; + d-cache-sets =3D <0x80>; + d-cache-size =3D <0x8000>; device_type =3D "cpu"; enable-method =3D "spin-table"; + i-cache-line-size =3D <0x40>; + i-cache-sets =3D <0x100>; + i-cache-size =3D <0x8000>; + next-level-cache =3D <0x21>; reg =3D <0x3>; }; + l2-cache0 { + + cache-level =3D <0x2>; + cache-line-size =3D <0x40>; + cache-sets =3D <0x200>; + cache-size =3D <0x80000>; + compatible =3D "cache"; + }; }; fixedregulator_3v3 { =20 @@ -320,17 +397,18 @@ leds { =20 compatible =3D "gpio-leds"; - act { + led-act { =20 - default-state =3D "keep"; - gpios =3D <0x10 0x1d 0x0>; - label =3D "led0"; + default-state =3D "off"; + gpios =3D <0x7 0x1d 0x0>; + label =3D "ACT"; linux,default-trigger =3D "mmc0"; }; - pwr { + led-pwr { =20 - gpios =3D <0xa 0x2 0x1>; - label =3D "led1"; + default-state =3D "off"; + gpios =3D <0xb 0x2 0x1>; + label =3D "PWR"; linux,default-trigger =3D "default-on"; }; }; @@ -367,7 +445,7 @@ aux@7e215000 { =20 #clock-cells =3D <0x1>; - clocks =3D <0x7 0x14>; + clocks =3D <0x8 0x14>; compatible =3D "brcm,bcm2835-aux"; reg =3D <0x7e215000 0x8>; }; @@ -392,10 +470,10 @@ #clock-cells =3D <0x1>; #size-cells =3D <0x0>; clock-names =3D "lp", "vpu"; - clocks =3D <0x7 0x2d 0x1e 0x4>; + clocks =3D <0x8 0x2d 0x19 0x4>; compatible =3D "brcm,bcm2835-unicam"; interrupts =3D <0x2 0x6>; - power-domains =3D <0x14 0xc>; + power-domains =3D <0x11 0xc>; reg =3D <0x7e800000 0x800 0x7e802000 0x4>; status =3D "disabled"; }; @@ -406,10 +484,10 @@ #size-cells =3D <0x0>; brcm,num-data-lanes =3D <0x2>; clock-names =3D "lp", "vpu"; - clocks =3D <0x7 0x2e 0x1e 0x4>; + clocks =3D <0x8 0x2e 0x19 0x4>; compatible =3D "brcm,bcm2835-unicam"; interrupts =3D <0x2 0x7>; - power-domains =3D <0x14 0xd>; + power-domains =3D <0x11 0xd>; reg =3D <0x7e801000 0x800 0x7e802004 0x4>; status =3D "disabled"; }; @@ -424,10 +502,8 @@ }; dpi@7e208000 { =20 - #address-cells =3D <0x1>; - #size-cells =3D <0x0>; clock-names =3D "core", "pixel"; - clocks =3D <0x7 0x14 0x7 0x2c>; + clocks =3D <0x8 0x14 0x8 0x2c>; compatible =3D "brcm,bcm2835-dpi"; reg =3D <0x7e208000 0x8c>; status =3D "disabled"; @@ -439,10 +515,10 @@ #size-cells =3D <0x0>; clock-names =3D "phy", "escape", "pixel"; clock-output-names =3D "dsi0_byte", "dsi0_ddr2", = "dsi0_ddr"; - clocks =3D <0x7 0x20 0x7 0x2f 0x7 0x31>; + clocks =3D <0x8 0x20 0x8 0x2f 0x8 0x31>; compatible =3D "brcm,bcm2835-dsi0"; interrupts =3D <0x2 0x4>; - power-domains =3D <0x14 0x11>; + power-domains =3D <0x11 0x11>; reg =3D <0x7e209000 0x78>; status =3D "disabled"; }; @@ -453,10 +529,10 @@ #size-cells =3D <0x0>; clock-names =3D "phy", "escape", "pixel"; clock-output-names =3D "dsi1_byte", "dsi1_ddr2", = "dsi1_ddr"; - clocks =3D <0x7 0x23 0x7 0x30 0x7 0x32>; + clocks =3D <0x8 0x23 0x8 0x30 0x8 0x32>; compatible =3D "brcm,bcm2835-dsi1"; interrupts =3D <0x2 0xc>; - power-domains =3D <0x14 0x12>; + power-domains =3D <0x11 0x12>; reg =3D <0x7e700000 0x8c>; status =3D "disabled"; }; @@ -483,8 +559,13 @@ #gpio-cells =3D <0x2>; compatible =3D = "raspberrypi,firmware-gpio"; gpio-controller; + gpio-line-names =3D "BT_ON", "WL_ON", = "PWR_LED_R", "LAN_RUN", "NC", "CAM_GPIO0", "CAM_GPIO1", "NC"; status =3D "okay"; }; + vcio { + + compatible =3D "raspberrypi,vcio"; + }; }; firmwarekms@7e600000 { =20 @@ -500,6 +581,8 @@ #interrupt-cells =3D <0x2>; compatible =3D "brcm,bcm2835-gpio"; gpio-controller; + gpio-line-names =3D "ID_SDA", "ID_SCL", "SDA1", = "SCL1", "GPIO_GCLK", "GPIO5", "GPIO6", "SPI_CE1_N", "SPI_CE0_N", = "SPI_MISO", "SPI_MOSI", "SPI_SCLK", "GPIO12", "GPIO13", "TXD1", "RXD1", = "GPIO16", "GPIO17", "GPIO18", "GPIO19", "GPIO20", "GPIO21", "GPIO22", = "GPIO23", "GPIO24", "GPIO25", "GPIO26", "GPIO27", "HDMI_HPD_N", = "STATUS_LED_G", "CTS0", "RTS0", "TXD0", "RXD0", "SD1_CLK", "SD1_CMD", = "SD1_DATA0", "SD1_DATA1", "SD1_DATA2", "SD1_DATA3", "PWM0_OUT", = "PWM1_OUT", "ETH_CLK", "WIFI_CLK", "SDA0", "SCL0", "SMPS_SCL", = "SMPS_SDA", "SD_CLK_R", "SD_CMD_R", "SD_DATA0_R", "SD_DATA1_R", = "SD_DATA2_R", "SD_DATA3_R"; + gpio-ranges =3D <0x7 0x0 0x0 0x36>; interrupt-controller; interrupts =3D <0x2 0x11 0x2 0x12>; pinctrl-names =3D "default"; @@ -513,6 +596,7 @@ =20 brcm,function =3D <0x4>; brcm,pins =3D <0x28 0x29>; + brcm,pull =3D <0x0>; }; bt_pins { =20 @@ -520,6 +604,37 @@ brcm,pins =3D <0x2b>; brcm,pull =3D <0x0>; }; + dpi_16bit_cpadhi_gpio0 { + + brcm,function =3D <0x6>; + brcm,pins =3D <0x0 0x1 0x2 0x3 0x4 0x5 = 0x6 0x7 0x8 0xc 0xd 0xe 0xf 0x10 0x11 0x14 0x15 0x16 0x17 0x18>; + }; + dpi_16bit_cpadhi_gpio2 { + + brcm,function =3D <0x6>; + brcm,pins =3D <0x2 0x3 0x4 0x5 0x6 0x7 = 0x8 0xc 0xd 0xe 0xf 0x10 0x11 0x14 0x15 0x16 0x17 0x18>; + }; + dpi_16bit_gpio0 { + + brcm,function =3D <0x6>; + brcm,pins =3D <0x0 0x1 0x2 0x3 0x4 0x5 = 0x6 0x7 0x8 0x9 0xa 0xb 0xc 0xd 0xe 0xf 0x10 0x11 0x12 0x13>; + }; + dpi_16bit_gpio2 { + + brcm,function =3D <0x6>; + brcm,pins =3D <0x2 0x3 0x4 0x5 0x6 0x7 = 0x8 0x9 0xa 0xb 0xc 0xd 0xe 0xf 0x10 0x11 0x12 0x13>; + }; + dpi_18bit_cpadhi_gpio0 { + + brcm,function =3D <0x6>; + brcm,pins =3D <0x0 0x1 0x2 0x3 0x4 0x5 = 0x6 0x7 0x8 0x9 0xc 0xd 0xe 0xf 0x10 0x11 0x14 0x15 0x16 0x17 0x18 = 0x19>; + brcm,pull =3D <0x0>; + }; + dpi_18bit_cpadhi_gpio2 { + + brcm,function =3D <0x6>; + brcm,pins =3D <0x2 0x3 0x4 0x5 0x6 0x7 = 0x8 0x9 0xc 0xd 0xe 0xf 0x10 0x11 0x14 0x15 0x16 0x17 0x18 0x19>; + }; dpi_18bit_gpio0 { =20 brcm,function =3D <0x6>; @@ -811,19 +926,20 @@ gpu { =20 compatible =3D "brcm,bcm2835-vc4"; + raspberrypi,firmware =3D <0x6>; status =3D "disabled"; }; hdmi@7e902000 { =20 clock-names =3D "pixel", "hdmi"; - clocks =3D <0x7 0x10 0x7 0x19>; + clocks =3D <0x19 0x9 0x19 0xd>; compatible =3D "brcm,bcm2835-hdmi"; - ddc =3D <0x1b>; + ddc =3D <0x1a>; dma-names =3D "audio-rx"; - dmas =3D <0xb 0x9000011>; - hpd-gpios =3D <0x10 0x1c 0x1>; + dmas =3D <0xc 0x9000011>; + hpd-gpios =3D <0x7 0x1c 0x1>; interrupts =3D <0x2 0x8 0x2 0x9>; - power-domains =3D <0x14 0x5>; + power-domains =3D <0x11 0x5>; reg =3D <0x7e902000 0x600 0x7e808000 0x100>; reg-names =3D "hdmi", "hd"; status =3D "disabled"; @@ -840,7 +956,7 @@ #address-cells =3D <0x1>; #size-cells =3D <0x0>; clock-frequency =3D <0x186a0>; - clocks =3D <0x7 0x14>; + clocks =3D <0x8 0x14>; compatible =3D "brcm,bcm2835-i2c"; interrupts =3D <0x2 0x15>; reg =3D <0x7e205000 0x200>; @@ -851,10 +967,10 @@ #address-cells =3D <0x1>; #size-cells =3D <0x0>; clock-frequency =3D <0x186a0>; - clocks =3D <0x7 0x14>; + clocks =3D <0x8 0x14>; compatible =3D "brcm,bcm2835-i2c"; interrupts =3D <0x2 0x15>; - pinctrl-0 =3D <0x17>; + pinctrl-0 =3D <0x15>; pinctrl-names =3D "default"; reg =3D <0x7e804000 0x1000>; status =3D "disabled"; @@ -864,7 +980,7 @@ #address-cells =3D <0x1>; #size-cells =3D <0x0>; clock-frequency =3D <0x186a0>; - clocks =3D <0x7 0x14>; + clocks =3D <0x8 0x14>; compatible =3D "brcm,bcm2835-i2c"; interrupts =3D <0x2 0x15>; reg =3D <0x7e805000 0x1000>; @@ -875,9 +991,9 @@ #address-cells =3D <0x1>; #size-cells =3D <0x0>; compatible =3D "i2c-mux-pinctrl"; - i2c-parent =3D <0x11>; - pinctrl-0 =3D <0x12>; - pinctrl-1 =3D <0x13>; + i2c-parent =3D <0x1c>; + pinctrl-0 =3D <0x1d>; + pinctrl-1 =3D <0x1e>; pinctrl-names =3D "i2c0", "i2c_csi_dsi"; status =3D "disabled"; i2c@0 { @@ -896,11 +1012,11 @@ i2s@7e203000 { =20 #sound-dai-cells =3D <0x0>; - clocks =3D <0x7 0x1f>; + clocks =3D <0x8 0x1f>; compatible =3D "brcm,bcm2835-i2s"; dma-names =3D "tx", "rx"; - dmas =3D <0xb 0x2 0xb 0x3>; - pinctrl-0 =3D <0xd>; + dmas =3D <0xc 0x2 0xc 0x3>; + pinctrl-0 =3D <0xe>; pinctrl-names =3D "default"; reg =3D <0x7e203000 0x24>; status =3D "disabled"; @@ -910,7 +1026,7 @@ #interrupt-cells =3D <0x2>; compatible =3D "brcm,bcm2836-armctrl-ic"; interrupt-controller; - interrupt-parent =3D <0x1a>; + interrupt-parent =3D <0x18>; interrupts =3D <0x8 0x4>; reg =3D <0x7e00b200 0x200>; }; @@ -919,22 +1035,16 @@ #interrupt-cells =3D <0x2>; compatible =3D "brcm,bcm2836-l1-intc"; interrupt-controller; - interrupt-parent =3D <0x1a>; + interrupt-parent =3D <0x18>; reg =3D <0x40000000 0x100>; }; mailbox@7e00b840 { =20 compatible =3D "brcm,bcm2836-vchiq", = "brcm,bcm2835-vchiq"; interrupts =3D <0x0 0x2>; + pinctrl-0 =3D <0x20>; + pinctrl-names =3D "default"; reg =3D <0x7e00b840 0x3c>; - bcm2835_audio { - - brcm,pwm-channels =3D <0x8>; - compatible =3D "brcm,bcm2835-audio"; - pinctrl-0 =3D <0x20>; - pinctrl-names =3D "default"; - status =3D "disabled"; - }; }; mailbox@7e00b880 { =20 @@ -948,12 +1058,13 @@ brcm,overclock-50 =3D <0x0>; brcm,pio-limit =3D <0x1>; bus-width =3D <0x4>; - clocks =3D <0x7 0x14>; + clocks =3D <0x8 0x14>; compatible =3D "brcm,bcm2835-sdhost"; dma-names =3D "rx-tx"; - dmas =3D <0xb 0x2000000d>; + dmas =3D <0xc 0x2000000d>; + firmware =3D <0x6>; interrupts =3D <0x2 0x18>; - pinctrl-0 =3D <0xc>; + pinctrl-0 =3D <0xd>; pinctrl-names =3D "default"; reg =3D <0x7e202000 0x100>; status =3D "okay"; @@ -962,30 +1073,37 @@ =20 brcm,overclock-50 =3D <0x0>; bus-width =3D <0x4>; - clocks =3D <0x7 0x1c>; + clocks =3D <0x8 0x1c>; compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; dma-names =3D "rx-tx"; - dmas =3D <0xb 0xb>; + dmas =3D <0xc 0xb>; interrupts =3D <0x2 0x1e>; - pinctrl-0 =3D <0x1c>; + pinctrl-0 =3D <0x14>; pinctrl-names =3D "default"; reg =3D <0x7e300000 0x100>; status =3D "disabled"; }; mmcnr@7e300000 { =20 + #address-cells =3D <0x1>; + #size-cells =3D <0x0>; brcm,overclock-50 =3D <0x0>; bus-width =3D <0x4>; - clocks =3D <0x7 0x1c>; + clocks =3D <0x8 0x1c>; compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; dma-names =3D "rx-tx"; - dmas =3D <0xb 0xb>; + dmas =3D <0xc 0xb>; interrupts =3D <0x2 0x1e>; non-removable; - pinctrl-0 =3D <0x1d>; + pinctrl-0 =3D <0x1b>; pinctrl-names =3D "default"; reg =3D <0x7e300000 0x100>; status =3D "okay"; + wifi@1 { + + compatible =3D "brcm,bcm4329-fmac"; + reg =3D <0x1>; + }; }; pixelvalve@7e206000 { =20 @@ -1018,8 +1136,8 @@ =20 #pwm-cells =3D <0x2>; assigned-clock-rates =3D <0x989680>; - assigned-clocks =3D <0x7 0x1e>; - clocks =3D <0x7 0x1e>; + assigned-clocks =3D <0x8 0x1e>; + clocks =3D <0x8 0x1e>; compatible =3D "brcm,bcm2835-pwm"; reg =3D <0x7e20c000 0x28>; status =3D "disabled"; @@ -1034,11 +1152,11 @@ =20 arm,primecell-periphid =3D <0x241011>; clock-names =3D "uartclk", "apb_pclk"; - clocks =3D <0x7 0x13 0x7 0x14>; + clocks =3D <0x8 0x13 0x8 0x14>; compatible =3D "arm,pl011", "arm,primecell"; cts-event-workaround; interrupts =3D <0x2 0x19>; - pinctrl-0 =3D <0x8 0x9>; + pinctrl-0 =3D <0x9 0xa>; pinctrl-names =3D "default"; reg =3D <0x7e201000 0x200>; skip-init; @@ -1047,16 +1165,16 @@ =20 compatible =3D "brcm,bcm43438-bt"; max-speed =3D <0x2dc6c0>; - shutdown-gpios =3D <0xa 0x0 0x0>; + shutdown-gpios =3D <0xb 0x0 0x0>; status =3D "disabled"; }; }; serial@7e215040 { =20 - clocks =3D <0x15 0x0>; + clocks =3D <0x12 0x0>; compatible =3D "brcm,bcm2835-aux-uart"; interrupts =3D <0x1 0x1d>; - pinctrl-0 =3D <0x16>; + pinctrl-0 =3D <0x13>; pinctrl-names =3D "default"; reg =3D <0x7e215040 0x40>; skip-init; @@ -1065,18 +1183,18 @@ =20 compatible =3D "brcm,bcm43438-bt"; max-speed =3D <0x70800>; - shutdown-gpios =3D <0xa 0x0 0x0>; + shutdown-gpios =3D <0xb 0x0 0x0>; status =3D "disabled"; }; }; smi@7e600000 { =20 assigned-clock-rates =3D <0x7735940>; - assigned-clocks =3D <0x7 0x2a>; - clocks =3D <0x7 0x2a>; + assigned-clocks =3D <0x8 0x2a>; + clocks =3D <0x8 0x2a>; compatible =3D "brcm,bcm2835-smi"; dma-names =3D "rx-tx"; - dmas =3D <0xb 0x4>; + dmas =3D <0xc 0x4>; interrupts =3D <0x2 0x10>; reg =3D <0x7e600000 0x100>; status =3D "disabled"; @@ -1089,13 +1207,13 @@ =20 #address-cells =3D <0x1>; #size-cells =3D <0x0>; - clocks =3D <0x7 0x14>; + clocks =3D <0x8 0x14>; compatible =3D "brcm,bcm2835-spi"; - cs-gpios =3D <0x10 0x8 0x1 0x10 0x7 0x1>; + cs-gpios =3D <0x7 0x8 0x1 0x7 0x7 0x1>; dma-names =3D "tx", "rx"; - dmas =3D <0xb 0x6 0xb 0x7>; + dmas =3D <0xc 0x6 0xc 0x7>; interrupts =3D <0x2 0x16>; - pinctrl-0 =3D <0xe 0xf>; + pinctrl-0 =3D <0xf 0x10>; pinctrl-names =3D "default"; reg =3D <0x7e204000 0x200>; status =3D "disabled"; @@ -1120,7 +1238,7 @@ =20 #address-cells =3D <0x1>; #size-cells =3D <0x0>; - clocks =3D <0x15 0x1>; + clocks =3D <0x12 0x1>; compatible =3D "brcm,bcm2835-aux-spi"; interrupts =3D <0x1 0x1d>; reg =3D <0x7e215080 0x40>; @@ -1130,7 +1248,7 @@ =20 #address-cells =3D <0x1>; #size-cells =3D <0x0>; - clocks =3D <0x15 0x2>; + clocks =3D <0x12 0x2>; compatible =3D "brcm,bcm2835-aux-spi"; interrupts =3D <0x1 0x1d>; reg =3D <0x7e2150c0 0x40>; @@ -1139,7 +1257,7 @@ thermal@7e212000 { =20 #thermal-sensor-cells =3D <0x0>; - clocks =3D <0x7 0x1b>; + clocks =3D <0x8 0x1b>; compatible =3D "brcm,bcm2837-thermal"; reg =3D <0x7e212000 0x8>; status =3D "okay"; @@ -1156,13 +1274,13 @@ #address-cells =3D <0x1>; #size-cells =3D <0x0>; clock-names =3D "otg"; - clocks =3D <0x18>; + clocks =3D <0x16>; compatible =3D "brcm,bcm2708-usb"; interrupt-names =3D "usb", "soft"; interrupts =3D <0x1 0x9 0x2 0x0>; phy-names =3D "usb2-phy"; - phys =3D <0x19>; - power-domains =3D <0x14 0x6>; + phys =3D <0x17>; + power-domains =3D <0x11 0x6>; reg =3D <0x7e980000 0x10000 0x7e006000 0x1000>; usb-port@1 { =20 @@ -1201,22 +1319,16 @@ =20 compatible =3D "brcm,vc4-v3d"; interrupts =3D <0x1 0xa>; - power-domains =3D <0x14 0xa>; + power-domains =3D <0x11 0xa>; reg =3D <0x7ec00000 0x1000>; status =3D "disabled"; }; - vcsm { - - compatible =3D "raspberrypi,bcm2835-vcsm"; - firmware =3D <0x6>; - status =3D "okay"; - }; vec@7e806000 { =20 - clocks =3D <0x7 0x18>; + clocks =3D <0x19 0xf>; compatible =3D "brcm,bcm2835-vec"; interrupts =3D <0x2 0x1b>; - power-domains =3D <0x14 0x7>; + power-domains =3D <0x11 0x7>; reg =3D <0x7e806000 0x1000>; status =3D "disabled"; }; @@ -1225,9 +1337,10 @@ #power-domain-cells =3D <0x1>; #reset-cells =3D <0x1>; clock-names =3D "v3d", "peri_image", "h264", = "isp"; - clocks =3D <0x7 0x15 0x7 0x1d 0x7 0x17 0x7 = 0x16>; + clocks =3D <0x8 0x15 0x8 0x1d 0x8 0x17 0x8 = 0x16>; compatible =3D "brcm,bcm2835-pm", = "brcm,bcm2835-pm-wdt"; reg =3D <0x7e100000 0x114 0x7e00a000 0x24>; + reg-names =3D "pm", "asb"; system-power-controller; }; }; @@ -1242,13 +1355,22 @@ cooling-maps { =20 }; + trips { + + cpu-crit { + + hysteresis =3D <0x0>; + temperature =3D <0x1adb0>; + type =3D "critical"; + }; + }; }; }; timer { =20 always-on; compatible =3D "arm,armv7-timer"; - interrupt-parent =3D <0x1a>; + interrupt-parent =3D <0x18>; interrupts =3D <0x0 0x4 0x1 0x4 0x3 0x4 0x2 0x4>; }; }; =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 19 08:16:01 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RSWlw3TBJz4qP80 for ; Sat, 19 Aug 2023 08:16:12 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Received: from mx3.mx00.net (mx3.mx00.net [IPv6:2600:3c01:e000:872::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx3.mx00.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RSWlw1dz7z4Zl3 for ; Sat, 19 Aug 2023 08:16:12 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Authentication-Results: mx1.freebsd.org; none Received: from razz.mx00.net [2600:3c01::f03c:91ff:fed5:a231] by mx3.mx00.net with ESMTP id 20230519-1qXH7q-0002Sd-0o; Sat, 19 Aug 2023 08:16:02 +0000 Message-ID: <0ef0907d-17a7-45cd-ab5a-c2cbd482aed8@box559.com> Date: Sat, 19 Aug 2023 01:16:01 -0700 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Subject: Re: Unable to boot Pi 3b+ To: Mark Millard Cc: freebsd-arm@freebsd.org References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> <32684f44-cb45-438b-a48b-a09b8a02454a@box559.com> <7D95EB12-B628-44D4-B01A-42EEF98C1E07@yahoo.com> <19C95492-994B-4137-AE78-EFFD4D016F87@yahoo.com> Content-Language: en-US From: Peter G In-Reply-To: <19C95492-994B-4137-AE78-EFFD4D016F87@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RSWlw1dz7z4Zl3 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:63949, ipnet:2600:3c01::/32, country:SG] Mark Millard wrote on 2023-08-18 10:12: > On Aug 18, 2023, at 09:41, Peter G wrote: > >> . . . >> >> Okay, finally working! > > Cool. > >> I replaced start.elf and fixup.dat, and only those two files, in 13.2-RELEASE with the ones from 14.0-ALPHA1, and that boots (usually). > > So the old *.dtb is still in use vs. the newer one > for using the pure 14.0-ALPHA* RPi* firmware. For > what you report, both with the releng/13.2 kernel. > > At some point I'll generate the 2 *.dts's from > the *.dtb's in the sorted order and diff the > outputs. (This does not deal with live adjustments > that are also involved.) > > Does 14.0-ALPHA* have a panic when not changed? In > essence the comparison/contrast checks the older > kernel ( releng/13.2 ) vs. the newer kernel for the > modern *.dtb case. > > (Unfortunatey, you have the only known test context. > So I ask. But you may not want to be the tester for > such questions.) > >> I say usually because sometimes the boot hangs indefinitely between loading the keyboard USB device and bringing up the network stuff (lo0, mue0, and ue0), but usually it just pauses there and then continues. When it does hang, ctrl-alt-del works to try again. > > Interesting. > >> As expected, once it's up there are no apparent problems. The wired ethernet works fine for ssh and freebsd-update. I haven't stressed the system much so far, but still looks good after half a day of uptime. > > As you have the only known panic context, could you > gather the serial console output for a context that > leads to a panic(/reboot loop) when using just the > 14.0-ALPHA* firmware (modern *.dtb) and then report > it someplace folks can have access to? Absent such > evidence, the FreeBSD kernel will stay broken for > your type of context using modern RPi* firmware and > FreeBSD's kernel. (Presuming the evidence points to > the kernel mishandling something badly to cause a > reboot loop.) Okay, duty calls ... I dragged out some dusty boxes and scrounged around for old adapters and cables and hooked up the serial console. I booted the modified 13.2-RELEASE, 14.0-ALPHA1 and 14.2-ALPHA2 images. The logs are here: https://box559.com/pi3Bconsole.tgz But, now all three boot! I'm beginning to fear for my sanity after this whole thing. I know I didn't dream it, but the crash is not happening now. To check, I reverted to the HDMI console with 14.0-ALPHA1 where I had the looping crash before, and it booted fine (albeit with the zillion error messages you mentioned). So, hmm... I'm puzzled by what happened, but I'm glad it works now. Happy to send any other info that might be useful, but a working system probably isn't all that interesting. Mark, thank you for your kind assistance. > > > === > Mark Millard > marklmi at yahoo.com > > > From nobody Sat Aug 19 09:14:33 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RSY3Y5gK1z4qSSP for ; Sat, 19 Aug 2023 09:14:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RSY3Y1JHhz3CwF for ; Sat, 19 Aug 2023 09:14:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692436487; bh=j69i30awE80mQNepa0jC4k9DZ+1aakPnXRI3dbnRhHo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XV/5kKrgmenAPnoEqp+BOzDYkPDU0lTxk/U34ywEYf7RKpKPU6d7+rUs7QcZj2IFW9zHB1hazj47F3uO9QELVlyKG2FOdAvf5gEvyhOcYryjPlmUnlo5WVBDLREj0Y6mRZF4ykvfVKv9XbXfNsaC6ywH3kOtcv+o9nxq32MZXzm7nwPU9oOrVZzLRODzDTzbk9KXUBSNEM2T0UXSl0H9YVyJJaiXKKSHagFnVnFExhjKkCinvEUWItwuigPIy2dAYmo7wR/qo7ovS7vZ+D8bqCNTK2lTYV3ghBcma0PKP0TpDdLg5ZyJY+ZTyzWJaGSTc+KguJpDJ3fvDWBZCrajXQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692436487; bh=cTcTa7ut6n9jaUemRuE0+KjSJQ06wpqAwDKOFO2NCJj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jtsnC1MnDSeBr5FXLzvfFAePwtnIuzALdttyt02r7nNBcg4+xQWuW0lEVQFFZKxkot2anUSIbTfPzNZzyopZZEYznLMfYDZyJNRiy6syfzVCexFCv3tbTluQD2WROPOzsP88U2D5M3n+jjfVl/w2KvAgzEksGQ80fNm0QOhXKnOJz5mp/PfzKlXjqVhxO1wMtUlXozF7AJNWCrWcdYcFTO7B5fzyD1DJEDUwSrrPk/Ec8SWNrf4h5sp8OuzS2n2LtxF0qxXJMgfWzqK3xo4rgU8cTRXMMMmxkm0iD9yt8cjGYOpK65yHinUA+4gEjP7ygMW7Dl6bZKxmdzx7NUZcCw== X-YMail-OSG: dHUfaJ8VM1n9AeHwgULPN.rahgtilZ7aqd0LAiAL_.84pg6BCRxY4rFhRywDjSb zwYiBpwbUCyzQc4X6VqkfLzwUyJS5vpwXieMflSFFSL2nqdFANeUJh5w50PE.NQ7dsL6PzM58zT9 cD6YIviQkLcklDCXP640saewfKJzEnGj3EaDi.yk09WhkCdTPtJaoquSwcH84V05M_u8G3sADW.s GVDuL1ZA8Wfsn652ZeUVHISOzGPMDn0csmSHadHawUeoZdoy6vb4xMb64SBh9IrEAXbh2x4p28h3 HvyxAjzHhdktNHySGRXviA8gzF7qRYOYsZL3WaCxTc8OWk5iY3ih_fomCNLxw2j9umuK8Lyg5L0k PPHqZVykxDFRYRg5Db.eOgriIVbi1Del1Tvj.Nl4O836JaquPXtPNrpu5jZQE4xqj7yAMzz7zGxK KCNj3fRlYHzCPdslDgM4FSpcL_NXrRF8tvzWgqecQ88Ttw6yreSyQyqshnSNG8gahiXpJJQ2VVH. F47gSFafNrz9LJqWHOwEe5.KFhStRM6lbs_RkRgZUhBllbZnO2_bup1JOs2OVAmpUgPp2zKT9M11 QBIZaz5gOAbkXUa_ZzkqSf59EKYPlspyGFdi7xrb0yYk68UjP209tg.yl.KnCd2lpwRsSZ2IkzzB vhYmR3qTIUomF39qlvVsYApUNCdkwgqom25SLPweU4kqlADqvcCplRND7V94b66Dv_F25i1FKySv J7vrWNxLaZP3V9WhMwewVNcRaXO3xhz.RCtISWnBDf4XjWjyoyYHxuOzvE916PblqaOGi_MwQGT0 DFdkrXC6qW90FNO.9HQ4rhUZg8TXqX13G_33k_IigozlYELfeOsHZH9t.tjAkQM1_OnyxYOZ2NI4 8OC.r4dkb5HsPW82riXhGcgkL.Pq7vOnNXF0Z_QMlrxwRh9qLBZxqFBvXloj9W0oJJZSJbuOpwHl XGUHIiVEBe5QNIcXK80JNut4SyEYMvn6AEXTH_v0fGfucvtS9a9fbwMRCg.Yb.Z7ddVZICBTyJ33 TpvCvnz_51miyshglVgcfHyNnKGkpOf2ah9I5IuQj8.xlsXl6.2WZW7SoSQ18QdqMLvhORPepXgi dL_SECiuNE2yDuOG8pdfabcceIc8qh4tlhccj96X36YdWH.r_fvHyjp1qOYnWvNz1fhYgU2VSiRS SU3ijv2kZFTm_3EQ0RGDIysaBKBADQzVALnZ.dhO3TEkdNz8wvPnLO9pBaY6EdT3km2M5GmamBTt C_qnisdRFz_lvoNS86Or0TyDFZAlDrZUkbZTuExPDQ5nj7Hox196Wyn0cAT2rtvMHPY.2pdjaHX7 Gq.erZjxnRhiIXvv2a8Z6SSURYrv6CEFJf2JE4w4_rmhAI4WbFd425cekvKnwE1dn.q6KJ06ZOau AoG9HKQK3II_K1jzyMsSKfe901OeaBNkU_tIRfqcfdqVeG5NYd2iCkAl3bK6UtHdQ0J4DVAV.uvr EErAc3MJl91QIdPalNFIxhDwYg6_HqWvXUiFKhE8xJ2j_onCLLN3WWLTyBTZ1u0Mx3sCR6mc59T1 7ugV1zCgEr2NM2pMIut0Pebqbqkm3baXW1LBbS2rBLz9wsJcVU1uhLF5lmD.SRmmA8XNDKJFT1YB vsC9PDcy80yQqKXCuPyKAHyMUX2YL5IJH7lDDJ1zd63Va3OPZa9oht6r_yG7pHKFuOamNu4HsoQt 8xSO1uitr01jtS3dimtgfgpYsXX06EA6YBcQ.z6Rkp0RAE8W5TB_9dh24mXd4g1JDF3Jenc7eQK4 mRKdN6rf2mVj57M3iUhE5eVZPb2uy4WZheX6ujdvz3dMZCkHrKtpzdsczPF_rx88mFxIIqq2dZsu YKllbFsSPdsdKJRxD44I1_2qCvkwBtJiuowrqIcGLVarSwlX_mvREjtBrYSoAAO9hVvMU5NmcsVM a2kacfLhiWO.7za70fewSCnO3kWg3rjYlbxIevszQ5hYcok6Fzvlzk5jU30Jl3fm3fI5tQEI1PFg Z2RgQt9VaFHPzC.P5PYBCAL5qILZumontj16zT2NCDdDYgNmfug.VsqAGCyPZ4tuQ39TfOMs9Se4 X3Yht3OokQgZx3cGQOFEVJSj1opZgpVm63.PjqQdfop2xbEfjg_LmoOuQuQRLPsQ99LXQG1Bcp8F L_906QUobwWYzKfFpIKJ2AYrsxoWZDD.l8c04.ItYdqahMd55TlUmYR5KYuW6PzI.rqGdRbSPyPK tlBUAahEf3WsJ746UcgBjzEmuPBlQh7WbKKZOG.w7T.ENpV5xWSutucs4KV19ANd41ecl99ZqjZh NOg-- X-Sonic-MF: X-Sonic-ID: e7becc6b-963d-412b-978b-be1f30184778 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Aug 2023 09:14:47 +0000 Received: by hermes--production-ne1-7b767b77cc-6mpms (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 94d8c5ec1f3c1dcb27628e52690ab246; Sat, 19 Aug 2023 09:14:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Unable to boot Pi 3b+ From: Mark Millard In-Reply-To: <0ef0907d-17a7-45cd-ab5a-c2cbd482aed8@box559.com> Date: Sat, 19 Aug 2023 02:14:33 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> <32684f44-cb45-438b-a48b-a09b8a02454a@box559.com> <7D95EB12-B628-44D4-B01A-42EEF98C1E07@yahoo.com> <19C95492-994B-4137-AE78-EFFD4D016F87@yahoo.com> <0ef0907d-17a7-45cd-ab5a-c2cbd482aed8@box559.com> To: Peter G X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RSY3Y1JHhz3CwF X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 19, 2023, at 01:16, Peter G wrote: > Mark Millard wrote on 2023-08-18 10:12: >> On Aug 18, 2023, at 09:41, Peter G = wrote: >>> . . . >>>=20 >>> Okay, finally working! >> Cool. >>> I replaced start.elf and fixup.dat, and only those two files, in = 13.2-RELEASE with the ones from 14.0-ALPHA1, and that boots (usually). >> So the old *.dtb is still in use vs. the newer one >> for using the pure 14.0-ALPHA* RPi* firmware. For >> what you report, both with the releng/13.2 kernel. >> At some point I'll generate the 2 *.dts's from >> the *.dtb's in the sorted order and diff the >> outputs. (This does not deal with live adjustments >> that are also involved.) >> Does 14.0-ALPHA* have a panic when not changed? In >> essence the comparison/contrast checks the older >> kernel ( releng/13.2 ) vs. the newer kernel for the >> modern *.dtb case. >> (Unfortunatey, you have the only known test context. >> So I ask. But you may not want to be the tester for >> such questions.) >>> I say usually because sometimes the boot hangs indefinitely between = loading the keyboard USB device and bringing up the network stuff (lo0, = mue0, and ue0), but usually it just pauses there and then continues. = When it does hang, ctrl-alt-del works to try again. >> Interesting. >>> As expected, once it's up there are no apparent problems. The wired = ethernet works fine for ssh and freebsd-update. I haven't stressed the = system much so far, but still looks good after half a day of uptime. >> As you have the only known panic context, could you >> gather the serial console output for a context that >> leads to a panic(/reboot loop) when using just the >> 14.0-ALPHA* firmware (modern *.dtb) and then report >> it someplace folks can have access to? Absent such >> evidence, the FreeBSD kernel will stay broken for >> your type of context using modern RPi* firmware and >> FreeBSD's kernel. (Presuming the evidence points to >> the kernel mishandling something badly to cause a >> reboot loop.) >=20 > Okay, duty calls ... I dragged out some dusty boxes and scrounged = around for old adapters and cables and hooked up the serial console. I = booted the modified 13.2-RELEASE, 14.0-ALPHA1 and 14.2-ALPHA2 images. = The logs are here: > https://box559.com/pi3Bconsole.tgz Of the 3 log files, only console-14.0-ALPHA2.txt indicates a first-time boot: . . . Growing root partition to fill device Adding swap partition GEOM_PART: mmcsd0s2 was automatically resized. Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` = to revert them. mmcsd0s2 resized mmcsd0s2b added mmcsd0s2a resized super-block backups (for fsck_ffs -b #) at: 11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912, 20487360, 21767808, 23048256, 24328704, 25609152, 26889600, 28170048, 29450496, 30730944, 32011392, 33291840, 34572288, 35852736, 37133184, 38413632, 39694080, 40974528, 42254976, 43535424, 44815872, 46096320, 47376768, 48657216, 49937664, 51218112, 52498560, 53779008, 55059456, 56339904, 57620352 Metadata value stored on mmcsd0s2b. . . . (These steps take some extra time.) Such had already occured during prior boot activity for the other 2 log files. > But, now all three boot! I'm beginning to fear for my sanity after = this whole thing. I know I didn't dream it, but the crash is not = happening now. To check, I reverted to the HDMI console with 14.0-ALPHA1 = where I had the looping crash before, and it booted fine (albeit with = the zillion error messages you mentioned). >=20 > So, hmm... I'm puzzled by what happened, but I'm glad it works now. >=20 > Happy to send any other info that might be useful, but a working = system probably isn't all that interesting. Mark, thank you for your = kind assistance. The thing to log would probably be a boot attempt of a fresh 13.2-RELEASE that has had the RPi* firmware ( including bcm271*.dtb files and overlays/ ) from 14.0-ALPHA2 (or ALPHA1) substituted, probably also having had u-boot.bin substituted. In other words, avoiding having any old vintages of those materials. I'd suggest leaving EFI/ and dtb/ alone. Those have files built as part of FreeBSD. If nothing else, this could help with identifying analogous contexts in the future if others have problems. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 19 09:21:24 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RSYCR0R10z4qT1X for ; Sat, 19 Aug 2023 09:21:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RSYCP54gRz3DRR for ; Sat, 19 Aug 2023 09:21:37 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=roRFkc2Y; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com; dmarc=pass (policy=none) header.from=bidouilliste.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1692436888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g38BYGZYkH1DT0HC95kl3yLOs8FM5GgA1zSysqFalEo=; b=roRFkc2YUvg88mwzLCcFx9OUnW+STLlaBb2Jo0lyiZE723g7+l7BZ4yodJ1RySqKde1icw MIgSmcrzr819gzY7XQ6l2c2QhYlt8hKEMN4zbwLJpzwPIvmdShJLV82AWdwXXiG81ggHW8 lv2vNjNWnBrWxnRfXP0e0jra1Q47C+0= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id a4ab7d69 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 19 Aug 2023 09:21:28 +0000 (UTC) Date: Sat, 19 Aug 2023 11:21:24 +0200 From: Emmanuel Vadot To: titus Cc: freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Message-Id: <20230819112124.46e66629ca18071f11d9d361@bidouilliste.com> In-Reply-To: <94A67CE4-8530-4080-AC54-DFBB6B8613EF@edc.ro> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> <2DF7EF89-DC3F-44D4-8708-51CB4B6C8EC4@edc.ro> <0C830898-AAAE-48BC-9844-1B9D426C0767@karels.net> <20230814181921.70596c64343261a24351837a@bidouilliste.com> <94A67CE4-8530-4080-AC54-DFBB6B8613EF@edc.ro> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; DKIM_TRACE(0.00)[bidouilliste.com:+]; MID_RHS_MATCH_FROM(0.00)[]; FREEFALL_USER(0.00)[manu]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RSYCP54gRz3DRR On Mon, 14 Aug 2023 21:44:13 +0300 titus wrote: > can?t we OF_setprop some bogus string in the compatible property after th= e first failure so it won?t come back at every bus scan karels@ sent me a patch that do this. TBH I'm totally against patching a live dtb because of some non-conforming node. There is two things that should be done to "fix" this : 1/ Open an issue on the rpi-firmware github project saying that they're using some non-standard node and that they should fix this. 2/ Crafting an overlay for us that either remove the node or fix the props. Cheers, > > On 14 Aug 2023, at 20:44, Mike Karels wrote: > >=20 > > On 14 Aug 2023, at 11:19, Emmanuel Vadot wrote: > >=20 > >> On Mon, 14 Aug 2023 10:55:39 -0500 > >> Mike Karels wrote: > >>=20 > >>> On 14 Aug 2023, at 10:44, titus wrote: > >>>=20 > >>>> + if (OF_hasprop(ofw_bus_get_node(dev), "clock-frequency") =3D=3D 0)= { > >>>> + device_printf(dev, "clock-fixed have no clock-frequency\n"); > >>>> + return (ENXIO); > >>>> + } > >>>> this runs before compat_data is checked so will print it for any dev= ice clock or not > >>=20 > >> Meh, that's why I should do code at 7am :) > >>=20 > >>> Good point! Shuffling a bit to check both, I see 58 occurrences > >>> of the message. That's better than the 50+ 3-line sequences before. > >>>=20 > >>> Mike > >>=20 > >> Is that more or less than the previous message ? If it's the same > >> there is no point to commit this. > >=20 > > It's the same number of occurrences, but before there were 3 lines per > > occurrence. Now it's 1, and it's more clear what it means. I'd say > > it's worth it. > >=20 > > Mike > >=20 > >>>>> On Aug 14, 2023, at 6:07 PM, Emmanuel Vadot = wrote: > >>>>>=20 > >>>>> On Mon, 14 Aug 2023 09:51:27 -0500 > >>>>> Mike Karels wrote: > >>>>>=20 > >>>>>> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: > >>>>>>=20 > >>>>>>> On Mon, 14 Aug 2023 07:03:19 +0200 > >>>>>>> Emmanuel Vadot wrote: > >>>>>>>=20 > >>>>>>>> On Sun, 13 Aug 2023 12:35:31 -0500 > >>>>>>>> Mike Karels wrote: > >>>>>>>>=20 > >>>>>>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: > >>>>>>>>>=20 > >>>>>>>>>> On Sun, 13 Aug 2023 11:25:25 -0500 > >>>>>>>>>> Mike Karels wrote: > >>>>>>>>>>=20 > >>>>>>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: > >>>>>>>>>>>=20 > >>>>>>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh wrot= e: > >>>>>>>>>>>>=20 > >>>>>>>>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you r= evert that if the problem persists. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there= is no compatible > >>>>>>>>>>>>=20 > >>>>>>>>>>>> is the fix that Manu has committed: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> QUOTE > >>>>>>>>>>>> ofw_firmware: Only match if there is no compatible > >>>>>>>>>>>>=20 > >>>>>>>>>>>> If there is a compatible string it likely means that the f= irmware needs > >>>>>>>>>>>> a dedicated driver (like on RPI*). > >>>>>>>>>>>>=20 > >>>>>>>>>>>> PR: 273087 > >>>>>>>>>>>> Tested-by: Mark Millard > >>>>>>>>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG > >>>>>>>>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware dri= ver") > >>>>>>>>>>>> END QUOTE > >>>>>>>>>>>=20 > >>>>>>>>>>> Just for completeness: that change fixes the bcm2835_cpufreq0= /powerd > >>>>>>>>>>> problem and the gpioled0 problem, but not the clk_fixed2 prob= lem > >>>>>>>>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition fro= m the > >>>>>>>>>>> 3 Aug image makes that problem disappear. > >>>>>>>>>>>=20 > >>>>>>>>>>> Mike > >>>>>>>>>>=20 > >>>>>>>>>> There is two fixed-clock in the DTB without clock-frequency pr= operty > >>>>>>>>>> and with a status set to "disabled", this isn't conforming to = the > >>>>>>>>>> bindings > >>>>>>>>>> (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bin= dings/clock/fixed-clock.yaml) > >>>>>>>>>> so we complain on this, this is normal. > >>>>>>>>>=20 > >>>>>>>>> Would it be possible to detect the disabled status to prevent t= he errors > >>>>>>>>> (I'm guessing not) or to suppress the repeats? 150 lines of er= rors seems > >>>>>>>>> like a lot for an out-of-spec DTB entry, and makes it hard to i= gnore. > >>>>>>>>>=20 > >>>>>>>>> Mike > >>>>>>>>=20 > >>>>>>>> Detecting the disabled status makes no sense, a fixed clock cann= ot be > >>>>>>>> disable, it's always present and running. > >>>>>>>> But I think that if we check that clock-frenquency isn't present= in > >>>>>>>> the probe function, print a message and bail we will not attempt= to > >>>>>>>> attach the driver at each pass. > >>>>>>>> That's the only clean solution that I can see without making dir= ty > >>>>>>>> hacks for some non-conforming DTB. > >>>>>>>=20 > >>>>>>> Something like this : > >>>>>>> https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-the= re-is-no-clock-frequency-.patch > >>>>>>>=20 > >>>>>>> Please let me know if that works. > >>>>>>=20 > >>>>>> Not exactly. This results in: > >>>>>>=20 > >>>>>> clk_fixed4: clock-fixed have no clock-frequency > >>>>>>=20 > >>>>>> but this appears 1562 times. btw, "have" should be "has". > >>>>>=20 > >>>>> Then I don't know how to fix this properly. > >>>>>=20 > >>>>>> I hadn't noticed them before, but there are a lock order reversal > >>>>>> and a malloc while holding a non-sleepable lock, associated with > >>>>>> the gpio fix: > >>>>>=20 > >>>>> Are you sure that they are new ? > >>>>>=20 > >>>>>> gpioled0: on ofwbus0 > >>>>>> lock order reversal: (sleepable after non-sleepable) > >>>>>> 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ /usr/src/s= ys/dev/led/led.c:298 > >>>>>> 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi fi= rmware gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252 > >>>>>> lock order LED mtx -> Raspberry Pi firmware gpio attempted at: > >>>>>> #0 0xffff0000004d3984 at witness_checkorder+0xa98 > >>>>>> #1 0xffff00000046ecb4 at _sx_xlock+0x7c > >>>>>> #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 > >>>>>> #3 0xffff0000001c7400 at led_create_state+0x158 > >>>>>> #4 0xffff0000001910d4 at gpioled_attach+0x290 > >>>>>> #5 0xffff00000049efa4 at device_attach+0x3f8 > >>>>>> #6 0xffff00000049eb14 at device_probe_and_attach+0x7c > >>>>>> #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > >>>>>> #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>>>>> #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>>>>> #10 0xffff00000049bd30 at bus_set_pass+0x4c > >>>>>> #11 0xffff0000003ea3bc at mi_startup+0x1fc > >>>>>> #12 0xffff0000000008ac at virtdone+0x70 > >>>>>> uma_zalloc_debug: zone "malloc-64" with the following non-sleepabl= e locks held: > >>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f= 8) locked @ /usr/src/sys/dev/led/led.c:298 > >>>>>> stack backtrace: > >>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c > >>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 > >>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > >>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > >>>>>> #4 0xffff000000437abc at malloc+0x8c > >>>>>> #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 > >>>>>> #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > >>>>>> #7 0xffff0000001c7400 at led_create_state+0x158 > >>>>>> #8 0xffff0000001910d4 at gpioled_attach+0x290 > >>>>>> #9 0xffff00000049efa4 at device_attach+0x3f8 > >>>>>> #10 0xffff00000049eb14 at device_probe_and_attach+0x7c > >>>>>> #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > >>>>>> #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>>>>> #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>>>>> #14 0xffff00000049bd30 at bus_set_pass+0x4c > >>>>>> #15 0xffff0000003ea3bc at mi_startup+0x1fc > >>>>>> #16 0xffff0000000008ac at virtdone+0x70 > >>>>>> uma_zalloc_debug: zone "malloc-16" with the following non-sleepabl= e locks held: > >>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f= 8) locked @ /usr/src/sys/dev/led/led.c:298 > >>>>>> stack backtrace: > >>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c > >>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 > >>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > >>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > >>>>>> #4 0xffff000000437abc at malloc+0x8c > >>>>>> #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 > >>>>>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc > >>>>>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 > >>>>>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > >>>>>> #9 0xffff0000001c7400 at led_create_state+0x158 > >>>>>> #10 0xffff0000001910d4 at gpioled_attach+0x290 > >>>>>> #11 0xffff00000049efa4 at device_attach+0x3f8 > >>>>>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c > >>>>>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > >>>>>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>>>>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>>>>> #16 0xffff00000049bd30 at bus_set_pass+0x4c > >>>>>> #17 0xffff0000003ea3bc at mi_startup+0x1fc > >>>>>> uma_zalloc_debug: zone "malloc-128" with the following non-sleepab= le locks held: > >>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f= 8) locked @ /usr/src/sys/dev/led/led.c:298 > >>>>>> stack backtrace: > >>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c > >>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 > >>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > >>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > >>>>>> #4 0xffff000000437abc at malloc+0x8c > >>>>>> #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 > >>>>>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc > >>>>>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 > >>>>>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > >>>>>> #9 0xffff0000001c7400 at led_create_state+0x158 > >>>>>> #10 0xffff0000001910d4 at gpioled_attach+0x290 > >>>>>> #11 0xffff00000049efa4 at device_attach+0x3f8 > >>>>>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c > >>>>>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > >>>>>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>>>>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac > >>>>>> #16 0xffff00000049bd30 at bus_set_pass+0x4c > >>>>>> #17 0xffff0000003ea3bc at mi_startup+0x1fc > >>>>>>=20 > >>>>>> Mike > >>>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> --=20 > >>>>> Emmanuel Vadot > >>>>>=20 > >>=20 > >>=20 > >> --=20 > >> Emmanuel Vadot >=20 --=20 Emmanuel Vadot From nobody Sat Aug 19 10:58:19 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RSbMR5Qf1z4qYsW for ; Sat, 19 Aug 2023 10:58:43 +0000 (UTC) (envelope-from titus@edc.ro) Received: from eatlas.ro (eatlas.ro [86.126.82.18]) (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 (2048 bits) client-digest SHA256) (Client CN "eatlas.ro", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RSbMR1XKJz3PZZ for ; Sat, 19 Aug 2023 10:58:42 +0000 (UTC) (envelope-from titus@edc.ro) Authentication-Results: mx1.freebsd.org; none Received: from mail.edc.ro ([10.1.4.58]) by eatlas.ro (8.16.1/8.16.1) with ESMTPS id 37JAwUBg057676 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 19 Aug 2023 13:58:30 +0300 (EEST) (envelope-from titus@edc.ro) Received: from smtpclient.apple (79-113-65-76.rdsnet.ro [79.113.65.76] (may be forged)) (authenticated bits=0) by mail.edc.ro (8.16.1/8.16.1) with ESMTPSA id 37JAwS8D051503 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 19 Aug 2023 13:58:28 +0300 (EEST) (envelope-from titus@edc.ro) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=edc.ro; s=mail; t=1692442709; bh=9o64mwBQdgl+DTJL1tScAWEaO8QDYnqFBN0HEq84Tr4=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=5Mn1GExDxvK6xy/Ne7FeJATPKqE3sQZMnSx84JWf/uQi7bLpGn4xVEalq5PKtJ6m3 x4t+JOfNEmtw6BO7J11hdX4iZ4zWjWPsF2NE+iwsYfPnzXU94LliyHmwEIZws6Rl4M mP4FfLsoy5bCn86MriARIutHx4Efja0mOj1ZrjOY= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: titus manea List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Date: Sat, 19 Aug 2023 13:58:19 +0300 Message-Id: References: <20230819112124.46e66629ca18071f11d9d361@bidouilliste.com> Cc: freebsd-arm In-Reply-To: <20230819112124.46e66629ca18071f11d9d361@bidouilliste.com> To: Emmanuel Vadot X-Mailer: iPhone Mail (20G75) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ns.edc.ro X-Rspamd-Queue-Id: 4RSbMR1XKJz3PZZ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8708, ipnet:86.120.0.0/13, country:RO] the overlay route is probably the best. there are other cases with upstream/= vendor dts where fdt data is incomplete because some stuff is hardcoded in t= he linux kernel like clock-output-names and stuff > On Aug 19, 2023, at 12:21, Emmanuel Vadot wrote: >=20 > =EF=BB=BFOn Mon, 14 Aug 2023 21:44:13 +0300 > titus wrote: >=20 >> can?t we OF_setprop some bogus string in the compatible property after th= e first failure so it won?t come back at every bus scan >=20 > karels@ sent me a patch that do this. > TBH I'm totally against patching a live dtb because of some > non-conforming node. > There is two things that should be done to "fix" this : > 1/ Open an issue on the rpi-firmware github project saying that > they're using some non-standard node and that they should fix this. > 2/ Crafting an overlay for us that either remove the node or fix the > props. >=20 > Cheers, >=20 >>>> On 14 Aug 2023, at 20:44, Mike Karels wrote: >>>=20 >>>> On 14 Aug 2023, at 11:19, Emmanuel Vadot wrote: >>>=20 >>>> On Mon, 14 Aug 2023 10:55:39 -0500 >>>> Mike Karels wrote: >>>>=20 >>>>> On 14 Aug 2023, at 10:44, titus wrote: >>>>>=20 >>>>>> + if (OF_hasprop(ofw_bus_get_node(dev), "clock-frequency") =3D=3D 0= ) { >>>>>> + device_printf(dev, "clock-fixed have no clock-frequency\n");= >>>>>> + return (ENXIO); >>>>>> + } >>>>>> this runs before compat_data is checked so will print it for any devi= ce clock or not >>>>=20 >>>> Meh, that's why I should do code at 7am :) >>>>=20 >>>>> Good point! Shuffling a bit to check both, I see 58 occurrences >>>>> of the message. That's better than the 50+ 3-line sequences before. >>>>>=20 >>>>> Mike >>>>=20 >>>> Is that more or less than the previous message ? If it's the same >>>> there is no point to commit this. >>>=20 >>> It's the same number of occurrences, but before there were 3 lines per >>> occurrence. Now it's 1, and it's more clear what it means. I'd say >>> it's worth it. >>>=20 >>> Mike >>>=20 >>>>>>> On Aug 14, 2023, at 6:07 PM, Emmanuel Vadot w= rote: >>>>>>>=20 >>>>>>> On Mon, 14 Aug 2023 09:51:27 -0500 >>>>>>> Mike Karels wrote: >>>>>>>=20 >>>>>>>> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: >>>>>>>>=20 >>>>>>>>> On Mon, 14 Aug 2023 07:03:19 +0200 >>>>>>>>> Emmanuel Vadot wrote: >>>>>>>>>=20 >>>>>>>>>> On Sun, 13 Aug 2023 12:35:31 -0500 >>>>>>>>>> Mike Karels wrote: >>>>>>>>>>=20 >>>>>>>>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> On Sun, 13 Aug 2023 11:25:25 -0500 >>>>>>>>>>>> Mike Karels wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh wrote= : >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you re= vert that if the problem persists. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there i= s no compatible >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> is the fix that Manu has committed: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> QUOTE >>>>>>>>>>>>>> ofw_firmware: Only match if there is no compatible >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> If there is a compatible string it likely means that the fir= mware needs >>>>>>>>>>>>>> a dedicated driver (like on RPI*). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> PR: 273087 >>>>>>>>>>>>>> Tested-by: Mark Millard >>>>>>>>>>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG >>>>>>>>>>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware drive= r") >>>>>>>>>>>>>> END QUOTE >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Just for completeness: that change fixes the bcm2835_cpufreq0/= powerd >>>>>>>>>>>>> problem and the gpioled0 problem, but not the clk_fixed2 probl= em >>>>>>>>>>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition from= the >>>>>>>>>>>>> 3 Aug image makes that problem disappear. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Mike >>>>>>>>>>>>=20 >>>>>>>>>>>> There is two fixed-clock in the DTB without clock-frequency pro= perty >>>>>>>>>>>> and with a status set to "disabled", this isn't conforming to t= he >>>>>>>>>>>> bindings >>>>>>>>>>>> (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bind= ings/clock/fixed-clock.yaml) >>>>>>>>>>>> so we complain on this, this is normal. >>>>>>>>>>>=20 >>>>>>>>>>> Would it be possible to detect the disabled status to prevent th= e errors >>>>>>>>>>> (I'm guessing not) or to suppress the repeats? 150 lines of err= ors seems >>>>>>>>>>> like a lot for an out-of-spec DTB entry, and makes it hard to ig= nore. >>>>>>>>>>>=20 >>>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>> Detecting the disabled status makes no sense, a fixed clock canno= t be >>>>>>>>>> disable, it's always present and running. >>>>>>>>>> But I think that if we check that clock-frenquency isn't present i= n >>>>>>>>>> the probe function, print a message and bail we will not attempt t= o >>>>>>>>>> attach the driver at each pass. >>>>>>>>>> That's the only clean solution that I can see without making dirt= y >>>>>>>>>> hacks for some non-conforming DTB. >>>>>>>>>=20 >>>>>>>>> Something like this : >>>>>>>>> https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-ther= e-is-no-clock-frequency-.patch >>>>>>>>>=20 >>>>>>>>> Please let me know if that works. >>>>>>>>=20 >>>>>>>> Not exactly. This results in: >>>>>>>>=20 >>>>>>>> clk_fixed4: clock-fixed have no clock-frequency >>>>>>>>=20 >>>>>>>> but this appears 1562 times. btw, "have" should be "has". >>>>>>>=20 >>>>>>> Then I don't know how to fix this properly. >>>>>>>=20 >>>>>>>> I hadn't noticed them before, but there are a lock order reversal >>>>>>>> and a malloc while holding a non-sleepable lock, associated with >>>>>>>> the gpio fix: >>>>>>>=20 >>>>>>> Are you sure that they are new ? >>>>>>>=20 >>>>>>>> gpioled0: on ofwbus0 >>>>>>>> lock order reversal: (sleepable after non-sleepable) >>>>>>>> 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ /usr/src/sy= s/dev/led/led.c:298 >>>>>>>> 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi fir= mware gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252 >>>>>>>> lock order LED mtx -> Raspberry Pi firmware gpio attempted at: >>>>>>>> #0 0xffff0000004d3984 at witness_checkorder+0xa98 >>>>>>>> #1 0xffff00000046ecb4 at _sx_xlock+0x7c >>>>>>>> #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 >>>>>>>> #3 0xffff0000001c7400 at led_create_state+0x158 >>>>>>>> #4 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>>>> #5 0xffff00000049efa4 at device_attach+0x3f8 >>>>>>>> #6 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>>>> #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>>>> #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>> #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>> #10 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>>>> #11 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>>>> #12 0xffff0000000008ac at virtdone+0x70 >>>>>>>> uma_zalloc_debug: zone "malloc-64" with the following non-sleepable= locks held: >>>>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8= ) locked @ /usr/src/sys/dev/led/led.c:298 >>>>>>>> stack backtrace: >>>>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>>>>> #4 0xffff000000437abc at malloc+0x8c >>>>>>>> #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 >>>>>>>> #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>>>>> #7 0xffff0000001c7400 at led_create_state+0x158 >>>>>>>> #8 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>>>> #9 0xffff00000049efa4 at device_attach+0x3f8 >>>>>>>> #10 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>>>> #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>>>> #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>> #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>> #14 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>>>> #15 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>>>> #16 0xffff0000000008ac at virtdone+0x70 >>>>>>>> uma_zalloc_debug: zone "malloc-16" with the following non-sleepable= locks held: >>>>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8= ) locked @ /usr/src/sys/dev/led/led.c:298 >>>>>>>> stack backtrace: >>>>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>>>>> #4 0xffff000000437abc at malloc+0x8c >>>>>>>> #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 >>>>>>>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >>>>>>>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >>>>>>>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>>>>> #9 0xffff0000001c7400 at led_create_state+0x158 >>>>>>>> #10 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>>>> #11 0xffff00000049efa4 at device_attach+0x3f8 >>>>>>>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>>>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>>>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>> #16 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>>>> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>>>> uma_zalloc_debug: zone "malloc-128" with the following non-sleepabl= e locks held: >>>>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0f6f8= ) locked @ /usr/src/sys/dev/led/led.c:298 >>>>>>>> stack backtrace: >>>>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>>>>> #4 0xffff000000437abc at malloc+0x8c >>>>>>>> #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 >>>>>>>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >>>>>>>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >>>>>>>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>>>>> #9 0xffff0000001c7400 at led_create_state+0x158 >>>>>>>> #10 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>>>> #11 0xffff00000049efa4 at device_attach+0x3f8 >>>>>>>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>>>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>>>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>> #16 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>>>> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>>>>=20 >>>>>>>> Mike >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> Emmanuel Vadot >>>>>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Emmanuel Vadot >>=20 >=20 >=20 > --=20 > Emmanuel Vadot >=20 From nobody Sat Aug 19 11:55:54 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RScdn5bF4z4qcmT for ; Sat, 19 Aug 2023 11:56:13 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RScdn3NNYz3XTS for ; Sat, 19 Aug 2023 11:56:13 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 37JBttIj092446; Sat, 19 Aug 2023 06:55:55 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1692446156; bh=2BcU1E4XFEL3XyzQ2/idPq1U/rDt0vYGEMtJjSDUtdc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=BSncnSzm9Qhv4uGRXghwgCCVAXF3UIrVei0ZnzGqCrMb6Kg1gcDx646tErm5Gxtij QQP5bRbIGAaR0cKRdlQyFY5zRGcZLoehQ4c12xVIjU02KCIg0S1EmhqnRjMctNMu3N Nxx/uy6BL1Gfq9C28B1kNpVQGicHPovN8/V7caWtTJod5ESMSI2d4BmCS6Z8Au/TvI EQJqcKxogtm0fao3bYzRaPuq/SE0JnrmulILpQFzFlh9yfySsBumUM169PjXpHIbyF S0J9Ah+G5HYzxi5G3TA0iUWu7jZeGDKG4V9JvDmeItGnM0RjBWF0voSC0PP3AmYqZ+ sEtFy28f8B0pw== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id 2LIXEMut4GQcaQEAs/W3XQ (envelope-from ); Sat, 19 Aug 2023 06:55:55 -0500 From: Mike Karels To: titus manea Cc: Emmanuel Vadot , freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Date: Sat, 19 Aug 2023 06:55:54 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: In-Reply-To: References: <20230819112124.46e66629ca18071f11d9d361@bidouilliste.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RScdn3NNYz3XTS X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 19 Aug 2023, at 5:58, titus manea wrote: > the overlay route is probably the best. there are other cases with upst= ream/vendor dts where fdt data is incomplete because some stuff is hardco= ded in the linux kernel like clock-output-names and stuff > >> On Aug 19, 2023, at 12:21, Emmanuel Vadot wrot= e: >> >> =EF=BB=BFOn Mon, 14 Aug 2023 21:44:13 +0300 >> titus wrote: >> >>> can?t we OF_setprop some bogus string in the compatible property afte= r the first failure so it won?t come back at every bus scan >> >> karels@ sent me a patch that do this. To be clear, my patch had two parts. One part reduced the number of bogus messages by 2/3 by testing for this specific problem. The other attempted an OF_setprop to zap the node, but this failed (it made other things stop working). If anyone else wants to try getting this to work, I can send what I have. Mike >> TBH I'm totally against patching a live dtb because of some >> non-conforming node. >> There is two things that should be done to "fix" this : >> 1/ Open an issue on the rpi-firmware github project saying that >> they're using some non-standard node and that they should fix this. >> 2/ Crafting an overlay for us that either remove the node or fix the >> props. >> >> Cheers, >> >>>>> On 14 Aug 2023, at 20:44, Mike Karels wrote: >>>> >>>>> On 14 Aug 2023, at 11:19, Emmanuel Vadot wrote: >>>> >>>>> On Mon, 14 Aug 2023 10:55:39 -0500 >>>>> Mike Karels wrote: >>>>> >>>>>> On 14 Aug 2023, at 10:44, titus wrote: >>>>>> >>>>>>> + if (OF_hasprop(ofw_bus_get_node(dev), "clock-frequency") =3D= =3D 0) { >>>>>>> + device_printf(dev, "clock-fixed have no clock-frequency\= n"); >>>>>>> + return (ENXIO); >>>>>>> + } >>>>>>> this runs before compat_data is checked so will print it for any = device clock or not >>>>> >>>>> Meh, that's why I should do code at 7am :) >>>>> >>>>>> Good point! Shuffling a bit to check both, I see 58 occurrences >>>>>> of the message. That's better than the 50+ 3-line sequences befor= e. >>>>>> >>>>>> Mike >>>>> >>>>> Is that more or less than the previous message ? If it's the same >>>>> there is no point to commit this. >>>> >>>> It's the same number of occurrences, but before there were 3 lines p= er >>>> occurrence. Now it's 1, and it's more clear what it means. I'd say= >>>> it's worth it. >>>> >>>> Mike >>>> >>>>>>>> On Aug 14, 2023, at 6:07 PM, Emmanuel Vadot wrote: >>>>>>>> >>>>>>>> On Mon, 14 Aug 2023 09:51:27 -0500 >>>>>>>> Mike Karels wrote: >>>>>>>> >>>>>>>>> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: >>>>>>>>> >>>>>>>>>> On Mon, 14 Aug 2023 07:03:19 +0200 >>>>>>>>>> Emmanuel Vadot wrote: >>>>>>>>>> >>>>>>>>>>> On Sun, 13 Aug 2023 12:35:31 -0500 >>>>>>>>>>> Mike Karels wrote: >>>>>>>>>>> >>>>>>>>>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Sun, 13 Aug 2023 11:25:25 -0500 >>>>>>>>>>>>> Mike Karels wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh w= rote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Manu just updated Linux DTS in the tree. Maybe see if yo= u revert that if the problem persists. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if th= ere is no compatible >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> is the fix that Manu has committed: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> QUOTE >>>>>>>>>>>>>>> ofw_firmware: Only match if there is no compatible >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If there is a compatible string it likely means that the= firmware needs >>>>>>>>>>>>>>> a dedicated driver (like on RPI*). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PR: 273087 >>>>>>>>>>>>>>> Tested-by: Mark Millard >>>>>>>>>>>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG >>>>>>>>>>>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware d= river") >>>>>>>>>>>>>>> END QUOTE >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just for completeness: that change fixes the bcm2835_cpufr= eq0/powerd >>>>>>>>>>>>>> problem and the gpioled0 problem, but not the clk_fixed2 p= roblem >>>>>>>>>>>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition = from the >>>>>>>>>>>>>> 3 Aug image makes that problem disappear. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mike >>>>>>>>>>>>> >>>>>>>>>>>>> There is two fixed-clock in the DTB without clock-frequency= property >>>>>>>>>>>>> and with a status set to "disabled", this isn't conforming = to the >>>>>>>>>>>>> bindings >>>>>>>>>>>>> (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/= Bindings/clock/fixed-clock.yaml) >>>>>>>>>>>>> so we complain on this, this is normal. >>>>>>>>>>>> >>>>>>>>>>>> Would it be possible to detect the disabled status to preven= t the errors >>>>>>>>>>>> (I'm guessing not) or to suppress the repeats? 150 lines of= errors seems >>>>>>>>>>>> like a lot for an out-of-spec DTB entry, and makes it hard t= o ignore. >>>>>>>>>>>> >>>>>>>>>>>> Mike >>>>>>>>>>> >>>>>>>>>>> Detecting the disabled status makes no sense, a fixed clock c= annot be >>>>>>>>>>> disable, it's always present and running. >>>>>>>>>>> But I think that if we check that clock-frenquency isn't pres= ent in >>>>>>>>>>> the probe function, print a message and bail we will not atte= mpt to >>>>>>>>>>> attach the driver at each pass. >>>>>>>>>>> That's the only clean solution that I can see without making = dirty >>>>>>>>>>> hacks for some non-conforming DTB. >>>>>>>>>> >>>>>>>>>> Something like this : >>>>>>>>>> https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-= there-is-no-clock-frequency-.patch >>>>>>>>>> >>>>>>>>>> Please let me know if that works. >>>>>>>>> >>>>>>>>> Not exactly. This results in: >>>>>>>>> >>>>>>>>> clk_fixed4: clock-fixed have no clock-frequency >>>>>>>>> >>>>>>>>> but this appears 1562 times. btw, "have" should be "has". >>>>>>>> >>>>>>>> Then I don't know how to fix this properly. >>>>>>>> >>>>>>>>> I hadn't noticed them before, but there are a lock order revers= al >>>>>>>>> and a malloc while holding a non-sleepable lock, associated wit= h >>>>>>>>> the gpio fix: >>>>>>>> >>>>>>>> Are you sure that they are new ? >>>>>>>> >>>>>>>>> gpioled0: on ofwbus0 >>>>>>>>> lock order reversal: (sleepable after non-sleepable) >>>>>>>>> 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ /usr/sr= c/sys/dev/led/led.c:298 >>>>>>>>> 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi= firmware gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.= c:252 >>>>>>>>> lock order LED mtx -> Raspberry Pi firmware gpio attempted at: >>>>>>>>> #0 0xffff0000004d3984 at witness_checkorder+0xa98 >>>>>>>>> #1 0xffff00000046ecb4 at _sx_xlock+0x7c >>>>>>>>> #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 >>>>>>>>> #3 0xffff0000001c7400 at led_create_state+0x158 >>>>>>>>> #4 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>>>>> #5 0xffff00000049efa4 at device_attach+0x3f8 >>>>>>>>> #6 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>>>>> #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>>>>> #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>>> #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>>> #10 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>>>>> #11 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>>>>> #12 0xffff0000000008ac at virtdone+0x70 >>>>>>>>> uma_zalloc_debug: zone "malloc-64" with the following non-sleep= able locks held: >>>>>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0= f6f8) locked @ /usr/src/sys/dev/led/led.c:298 >>>>>>>>> stack backtrace: >>>>>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>>>>>> #4 0xffff000000437abc at malloc+0x8c >>>>>>>>> #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 >>>>>>>>> #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>>>>>> #7 0xffff0000001c7400 at led_create_state+0x158 >>>>>>>>> #8 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>>>>> #9 0xffff00000049efa4 at device_attach+0x3f8 >>>>>>>>> #10 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>>>>> #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>>>>> #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>>> #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>>> #14 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>>>>> #15 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>>>>> #16 0xffff0000000008ac at virtdone+0x70 >>>>>>>>> uma_zalloc_debug: zone "malloc-16" with the following non-sleep= able locks held: >>>>>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0= f6f8) locked @ /usr/src/sys/dev/led/led.c:298 >>>>>>>>> stack backtrace: >>>>>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>>>>>> #4 0xffff000000437abc at malloc+0x8c >>>>>>>>> #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 >>>>>>>>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >>>>>>>>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >>>>>>>>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>>>>>> #9 0xffff0000001c7400 at led_create_state+0x158 >>>>>>>>> #10 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>>>>> #11 0xffff00000049efa4 at device_attach+0x3f8 >>>>>>>>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>>>>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>>>>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>>> #16 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>>>>> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>>>>> uma_zalloc_debug: zone "malloc-128" with the following non-slee= pable locks held: >>>>>>>>> exclusive sleep mutex LED mtx (LED mtx) r =3D 0 (0xffff000000d0= f6f8) locked @ /usr/src/sys/dev/led/led.c:298 >>>>>>>>> stack backtrace: >>>>>>>>> #0 0xffff0000004d3dc8 at witness_debugger+0x5c >>>>>>>>> #1 0xffff0000004d4fcc at witness_warn+0x400 >>>>>>>>> #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 >>>>>>>>> #3 0xffff000000782c20 at uma_zalloc_arg+0x2c >>>>>>>>> #4 0xffff000000437abc at malloc+0x8c >>>>>>>>> #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 >>>>>>>>> #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc >>>>>>>>> #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 >>>>>>>>> #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 >>>>>>>>> #9 0xffff0000001c7400 at led_create_state+0x158 >>>>>>>>> #10 0xffff0000001910d4 at gpioled_attach+0x290 >>>>>>>>> #11 0xffff00000049efa4 at device_attach+0x3f8 >>>>>>>>> #12 0xffff00000049eb14 at device_probe_and_attach+0x7c >>>>>>>>> #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc >>>>>>>>> #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>>> #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac >>>>>>>>> #16 0xffff00000049bd30 at bus_set_pass+0x4c >>>>>>>>> #17 0xffff0000003ea3bc at mi_startup+0x1fc >>>>>>>>> >>>>>>>>> Mike >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- = >>>>>>>> Emmanuel Vadot >>>>>>>> >>>>> >>>>> >>>>> -- = >>>>> Emmanuel Vadot >>> >> >> >> -- = >> Emmanuel Vadot >> From nobody Sat Aug 19 18:59:29 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RSp2F0TDjz4mLGQ for ; Sat, 19 Aug 2023 18:59:33 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Received: from mx3.mx00.net (mx3.mx00.net [IPv6:2600:3c01:e000:872::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx3.mx00.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RSp2D5jcmz4bxd for ; Sat, 19 Aug 2023 18:59:32 +0000 (UTC) (envelope-from list-freebsd-arm@box559.com) Authentication-Results: mx1.freebsd.org; none Received: from razz.mx00.net [2600:3c01::f03c:91ff:fed5:a231] by mx3.mx00.net with ESMTP id 20230519-1qXRAY-0003Gi-0r; Sat, 19 Aug 2023 18:59:30 +0000 Message-ID: <7d49ebe8-89c7-4483-ae8c-7de27049a59c@box559.com> Date: Sat, 19 Aug 2023 11:59:29 -0700 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Subject: Re: Unable to boot Pi 3b+ Content-Language: en-US To: Mark Millard Cc: freebsd-arm@freebsd.org References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> <32684f44-cb45-438b-a48b-a09b8a02454a@box559.com> <7D95EB12-B628-44D4-B01A-42EEF98C1E07@yahoo.com> <19C95492-994B-4137-AE78-EFFD4D016F87@yahoo.com> <0ef0907d-17a7-45cd-ab5a-c2cbd482aed8@box559.com> From: Peter G In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RSp2D5jcmz4bxd X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:63949, ipnet:2600:3c01::/32, country:SG] Mark Millard wrote on 2023-08-19 02:14: [...] > > The thing to log would probably be a boot attempt of a fresh > 13.2-RELEASE that has had the RPi* firmware ( including > bcm271*.dtb files and overlays/ ) from 14.0-ALPHA2 (or ALPHA1) > substituted, probably also having had u-boot.bin substituted. > In other words, avoiding having any old vintages of those > materials. I'd suggest leaving EFI/ and dtb/ alone. Those have > files built as part of FreeBSD. > > If nothing else, this could help with identifying analogous > contexts in the future if others have problems. > > > === > Mark Millard > marklmi at yahoo.com > I copied these files start*.elf fixup*.dat bcm* overlays/* u-boot.bin from FreeBSD-14.0-ALPHA2-arm64-aarch64-RPI-20230818-77013f29d048-264841.img to FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img and booted the modified image. The crash is back. The console log is at: https://box559.com/console-13.2-RELEASE-mod4.txt From nobody Sat Aug 19 19:12:52 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RSpKw2BGsz4mM62 for ; Sat, 19 Aug 2023 19:13:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RSpKv5r3Xz4ctv for ; Sat, 19 Aug 2023 19:13:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692472385; bh=jgPWbNYwGMjaLQJIL5uPRkLD9JykAdrVEMDR4ZgrOmg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=S2End4gaznyz1KTIDM5BcCoiSZUtJEjbaPM3gJO+FmZ6QeG6aJL7n2U3KigNMrxnBgbrSXOx/CE97KEx3Eb36G4Br5Ouq0bnoAihdo8qBJH8pxf6mLEbf6NhUfqGjt/UTiag3sUDmhQ8hjoJSOLE3V02jPOXfboFd0rfkTAMLYtil+ll4qUGuEnnqM7W85fSHkEk1VfNys68xOIadxVKFcI9Wjelh59QpCjhyRBObucGwSCfOUhgLgXvjuxuEcoN2tab/dtoPB4iICgBHuv/XWDbpKdl+EZWQLnMAvRvvR7I6Bf+v7ZWrk+HIRU9Cr2u1nhgQHG/aBsB2HqRZju7oQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692472385; bh=dyFi+IWSIoFhgLWrqT+6uUzrHf8mu4+kNqTmr9Bqmnn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=o/VxAjI1h8CJ98Fo11deTmnCEbZQMf/NxI9E1FuuYNGkLAK57xkvnfGa7RAynmz+xIbODwWPYaBt6TrcHFIGo6MZH6jQ5+GWQtdA468BOO5tqOKNE3n+21s2wFZcSdMIUu9Lxo4TNyzzxHMEDda+wtX9J4tCuzUTjqRqjTo+lLxN76k35x12AZjdmAFiHllzldAD2gcXnlsFqezDylM3fsULOf/4ImlTI7Kk1t4acIjst9CZJvSfn8ca0tqmnyhORG/Kr9hcEr/9PqOjRQxg362uw782X6oDKtdtkimfxbUwj1jj6Je77DpWbfgxPZpYTZwF6qXvQoobvsv4uZ1GIw== X-YMail-OSG: COxikb8VM1kxTPKAUggnpn92DFSjRrLoLW5fCGG31uCgWQfBklyVguaktwdk5Ze k_2b51NMZ2WQ_eGTcQ10CW.Az.NOEj8GuenmUFgDbQEzbu9Z5abH7LYOZqfUF7MzThQD7DvWE5a7 a1HJBvubWq1fydVhOmH2FQaQsc1q2JC9uJfJw8KHXUx7B53s.Je0g1pGCsr82n8QIJiFYb2B4KL2 UIn_BqT0P_vqEi4s97IUGn2OFwlVGvmC80l8bQHPuZOh540YQP2jr6pTz_qzgTGwVAetqsLvnOq1 bXGE3N2c5XcLTW67ldqzSLjHZNi8DDMCd_0Me0DRgImnUMNahPtE2wMKA1Bz5BNhSIyfgdzMpHNH YhE6hCWaij.EV.QMqkgjU_jjAZACuU7pH_TfqAHgjU3E3ZU1ntWnMu_Y6FpnU6rxw52REfPkcVes 1eM.0sPC64ahHHKFJn2YfqwWNU.8H5m8giKouZfEwYefNdurYXRa0stgUm4AhaPyf7PRJDCUeNl7 vL1wiRFZtvB9P0m7pe8AWijFpyjmwJlANJ40ijRwHcGraMNkpksXEX.NUQYPDsSBxIfa2DRtCNFV RLoSSDLeqoc8Z699ZLso67NAAlHVbMjU0P_rd0zp36qcjqUXUvkRyy4qJGDoNup3c3c4Ja4LIIW_ T7HfHmVUJ7Dw_.P8hm7LEyI_sw7NMK1XaG4enGkBBvK_AH111.NzyX_F8MY6Uu9v5CHnd1j_XRcT vOlE0qrc5nelQGNLPgkAFzlFecePdl8LTm6opUwRvYGi45jEUNeNwE2MNHnfMMhDtVV416ZTm45m N3KfCqOhe7iDGtzST0vWC2fKbLwj0Dyv4bw0XANrh7CwQu5WRjW6RTW5KXtBi.QiPEhOgpqSNyNz QnyHswJib6r_kIKJmUsNNY6ECdDE0FKsn8EYpYIS_Pzuvf8pEFTR6FfhPlB0BZ2xTifQBk7QbugP GfHBTTCO1z8KW4WRXMcbUGMuy3rHhH_c_D30prt5WHR2d0073hdnRZk2aAQQIWW7mgp3OHKfhAIl 4_liye7RnKdnaBt4bpQYqIUK.MTtYB4LQOjm.0us_RPXu_Xfgo68P9QaftXo.QUW6NaH5owMbv7L JJ0oGreB.Z6qeUgKOPCOXCMz2iGiz92LzJmljeE7.kz_weueaB6MCjaOcMSFer9.QfTJq.bh8mHZ 6sInf4lc18.4_geRgX8v6f7QLUL_W3yg09cl3ng8Sj.jTblnLmcOJ2qn8V38s9aLn0pSZSgEkude YiWjYLH17uPhoC94AWeE.Otxo36IKrae1IPwugI5SVPY7WDNQgT4hyQEvVGnD.rbIe3FHSRiQJeZ wHVVYVrqn_HGBulit.bLOABZSct_QOjH_QKf.2IBgDGgmDdfhTXU5dETIXo1wVrNg0TNoBW5fq4V uqoKalLaJ_HeNDdAxBSR.bQtCVMx7A2OVu0yOljhYw3sc2ooxBGsSDPEI3vyhHOCqEBwsSvazduV O_yHGVH.0rx2xoeWZLRb6IVQU285gqG_k9eJppQUu3yEsHFap8bWdFtqaVW3tO.1cQdoLK12NWqv vcP9tpyWVvGIIXch8toz6lh9CqGo9Jh59oZyudIeGAgZE.Ngos9NC6scqoTQTrqNSKsoXQmx.oAI pc.9kJe7kxZOdZ03ZdDjvM687z307k3t3h2dbGMEbMpT1.lDrNn9F6jlRGAWhVXNZysmJpenOLBN R206Z8oSDVTlxsfOnLOAEAMVDdO8MiVmHoloxHgWoJp_gubBW0OpiM9QA5rVarDqbu9CqqwZj4zU 3fSejI3LZggbDKv3x6yIGwCloNrvaGJ7o9dagXfS.hBS68rWmxYlw_pbkmmcw71Bj2IId_FJeqiU laUO5W2w.0aoMJc6bljyEluyg1kGcSSLFLhimoEssLIiQDbP.6C04M2toTc4QWQUMKSifv8ks.90 ykMBYgeKA6VG._XTRjIOV7095XDMcqMZfXF1VMpxtkxyTHvmbcZ.7ykFB.QpAx76TtQwLhTuKRM0 ru1r2uN72pCH4TyLxfPMnt6xlAV2OyEdBf44YTrT_QRFxpkSmj5DeFszFwi6T.cpnAm.5qmw_YBo S88QtPz_wp2tplI49epYO7VDOulQvV7Nc0YPYpyEW3J0mqE.S5xkQ7oSZNvCEYHcW9HdQWEVWs7M HUr706wxDtTkPndIHFQPWQLMYj1CIOibw9Xv1f4b0qOL9y06LZOySvNmHGa8fE8UkmvXNsFi_l9k PGPOoVsLr8OBNYU.JEIwm97du3rJnovUWCtwm8xcZLFhDCxfc3.sHtNr4U_uanGlXoaJvJe0vFhe lEg-- X-Sonic-MF: X-Sonic-ID: 4327a53d-3414-4bba-894e-80b3fafe86aa Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Aug 2023 19:13:05 +0000 Received: by hermes--production-ne1-7b767b77cc-ht9fv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 824199641347677fafe4d20b75b11776; Sat, 19 Aug 2023 19:13:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Unable to boot Pi 3b+ [crashes during bcm_sdhci_attach for Broadcom 2708 SDHCI controller for modern RPi* firmware] From: Mark Millard In-Reply-To: <7d49ebe8-89c7-4483-ae8c-7de27049a59c@box559.com> Date: Sat, 19 Aug 2023 12:12:52 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6baa4f78-6648-45a2-a4c6-96bfcaeecdea@box559.com> <1DF8A97C-2CA3-4223-9194-F16C5AEB49D8@yahoo.com> <8C766959-8B62-4823-A183-69CC9BA91DF5@yahoo.com> <32684f44-cb45-438b-a48b-a09b8a02454a@box559.com> <7D95EB12-B628-44D4-B01A-42EEF98C1E07@yahoo.com> <19C95492-994B-4137-AE78-EFFD4D016F87@yahoo.com> <0ef0907d-17a7-45cd-ab5a-c2cbd482aed8@box559.com> <7d49ebe8-89c7-4483-ae8c-7de27049a59c@box559.com> To: Peter G X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RSpKv5r3Xz4ctv X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 19, 2023, at 11:59, Peter G wrote: > Mark Millard wrote on 2023-08-19 02:14: > [...] >> The thing to log would probably be a boot attempt of a fresh >> 13.2-RELEASE that has had the RPi* firmware ( including >> bcm271*.dtb files and overlays/ ) from 14.0-ALPHA2 (or ALPHA1) >> substituted, probably also having had u-boot.bin substituted. >> In other words, avoiding having any old vintages of those >> materials. I'd suggest leaving EFI/ and dtb/ alone. Those have >> files built as part of FreeBSD. >> If nothing else, this could help with identifying analogous >> contexts in the future if others have problems. >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >=20 > I copied these files > start*.elf > fixup*.dat > bcm* > overlays/* > u-boot.bin > from > = FreeBSD-14.0-ALPHA2-arm64-aarch64-RPI-20230818-77013f29d048-264841.img > to > FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img > and booted the modified image. >=20 > The crash is back. The console log is at: > https://box559.com/console-13.2-RELEASE-mod4.txt >=20 Thanks. To publicly/broadly publish the crash material part of that log file: . . . sdhci_bcm0: mem 0x7e300000-0x7e3000ff = irq 17 on simplebus0 Fatal data abort: x0: ffffffff x1: 0 x2: ffff0000008d6ebe x3: 6e x4: ffff000000f4060c x5: 6e x6: ffff0000001927a8 x7: 6d63625f69636864 x8: ffff000000e34700 x9: 20 x10: 0 x11: 1 x12: 300000000006e65 x13: fefefefeff0100 x14: 69b x15: 1a x16: 0 x17: 0 x18: ffff000000f407e0 x19: ffffffff x20: 0 x21: ffff000000be6000 x22: ffff000000be6000 x23: ffffa00000ddec38 x24: ffff000000938016 x25: ffff000000961e00 x26: ffff0000008f9bfb x27: ffffa00000dced60 x28: 31e00000 x29: ffff000000f407e0 sp: ffff000000f407e0 lr: ffff000000880e04 elr: ffff00000087aefc spsr: a00000c5 far: 20 esr: 96000004 panic: vm_fault failed: ffff00000087aefc cpuid =3D 0 time =3D 1 KDB: stack backtrace: #0 0xffff0000004fd02c at kdb_backtrace+0x60 #1 0xffff0000004a8328 at vpanic+0x13c #2 0xffff0000004a81e8 at panic+0x44 #3 0xffff0000007f42e0 at data_abort+0x200 #4 0xffff0000007d3010 at handle_el1h_sync+0x10 #5 0xffff000000880e00 at bcm_sdhci_attach+0x318 #6 0xffff000000880e00 at bcm_sdhci_attach+0x318 #7 0xffff0000004e8f94 at device_attach+0x3fc #8 0xffff0000004eb134 at bus_generic_new_pass+0x120 #9 0xffff0000004eb0c4 at bus_generic_new_pass+0xb0 #10 0xffff0000004eb0c4 at bus_generic_new_pass+0xb0 #11 0xffff0000004eb0c4 at bus_generic_new_pass+0xb0 #12 0xffff0000004ed200 at root_bus_configure+0x40 #13 0xffff00000041e5e8 at mi_startup+0x11c #14 0xffff0000000008b4 at virtdone+0x78 Uptime: 1s =3D=3D=3D Mark Millard marklmi at yahoo.com